You are currently browsing the category archive for the ‘Accessibility’ category.

I gave a presentation today on how we can create web mapping applications that address accessibility guidelines.  I’m not sure if I can share the slides, as they are EC branded…but I think I can share the transcript of the presentation to anyone who is interested:

Slide: Title

Web Mapping Accessibility and CLF 2.0

Alecia Fowler

Environment Canada

February 2011

Slide: Introduction

During this presentation I will discuss what steps we can take to create accessible web mapping applications.  I’ll talk about why it is not a clear cut case and where the grey areas are.  We have been able to identify some solutions but there are still gaps so please feel free to ask questions or bring up any ideas.

Slide: CLF 2.0

The goal of CLF 2.0 is to created uniform, accessible web content with a departmental branding

The Federal Governments stance on Accessibility is stated in Treasury Boards Common Look and Feel for the Internet 2.0: http://www.tbs-sct.gc.ca/clf2-nsi2/index-eng.asp

The standard is comprised of 4 parts:

From a web mapping point of view we are concerned with Part 2 and Part 3, I will cover Part 3 the Standard on Common Web Page Formats first as it is a bit more straightforward.

Slide: Standard on Common Web Page Formats

This part of the standard covers the layout and formatting of web pages.  The design is further expanded on to reflect department specific branding though Environment Canada’s E-Communications department.  They have a design guide which stipulates the usage, style and colour of various page features.  This guide is useful for static pages but when it comes to dynamic web applications there are more unknowns.

EC Internet Look and Feel Guide http://intranet.ec.gc.ca/communications/default.asp?lang=En&n=243D8F0F-1

We have recently finished a project for the Communications branch.  As they are responsible for web content consistency it is a safe bet to model your web mapping content after them.

The application was built with two interfaces.  One that fits nicely into the CLF template and looks similar to all other EC pages, and one that looks more like mainstream web mapping applications:

Map of EcoAction Funded Projects

http://maps-cartes.ec.gc.ca/ecogeo/

Slide: Standard on Accessibility, Interoperability and Usability of Web sites

Satisfying Part 2 of the CLF standard is not as simple as it deals with web accessibility.

  • The goal of web accessibility is to ensure that content online is available to all people regardless of disability.
  • Most of the information in a web mapping application is found in the map which can only be accessed visually.
  • Due to its high dependence on vision, other accessibility requirements often get overlooked

Slide: W3C WCAG Checkpoints

The CLF standard requires web content to satisfy the Priority 1 and 2 checkpoints of the W3C’s Web Content Accessibility Guidelines which are divided into 4 categories to ensure you content is perceivable, operable, understandable, and robust.

  • Perceivable
    • Provide text alternatives for non-text content.
    • Provide captions and alternatives for audio and video content.
    • Make content adaptable; and make it available to assistive technologies.
    • Use sufficient contrast to make things easy to see and hear.
  • Operable
    • Make all functionality keyboard accessible.
    • Give users enough time to read and use content.
    • Do not use content that causes seizures.
    • Help users navigate and find content.
  • Understandable
    • Make text readable and understandable.
    • Make content appear and operate in predictable ways.
    • Help users avoid and correct mistakes.
  • Robust
    • Maximize compatibility with current and future technologies

But some of these priorities don’t affect web-mapping applications, so we’re just going to concentrate on the ones that do.

  • Perceivable: Provide text alternatives for non-text content.
  • Perceivable: Make content adaptable; and make it available to assistive technologies.
  • Perceivable: Use sufficient contrast to make things easy to see and hear.
  • Operable: Make all functionality keyboard accessible.
  • Understandable: Make text readable and understandable.
  • Robust: Maximize compatibility with current and future technologies

Slide: W3C WCAG Checkpoints

Make content adaptable; and make it available to assistive technologies.

  • Offering information in multiple formats
    • The life of a web mapping application is the data, so please offer a text-based version of the data you are loading into the map
  • Allow your users to download it themselves
  • Display it in charts, tables, and graphs etc.
  • Have the most accessible version of your site as the first format encountered by a visitor

Example: National Pollutant Release Inventory (NPRI)

http://www.ec.gc.ca/inrp-npri/default.asp

  • Online data
  • Online maps
  • Downloadable map layers for Google Earth (.kmz)
  • Downloadable data for Microsoft Access (.mdb)
  • Download data for Microsoft Excel (.xls)

Slide: W3C WCAG Checkpoints

Use sufficient contrast to make things easy to see and hear.

This checkpoint has to do with the cartography of the map.  The design should take into account any colour blindness or weak vision of the user.  This could be text size or colour choice for symbology.

Slide: W3C WCAG Checkpoints

Make all functionality keyboard accessible.

Your web mapping application should not rely solely on the mouse for access to any feature or information

  • Map Tips
  • Point Selection
  • Map Navigation

This is common for web mapping applications as much of the information and features are embedded into the map.

Slide: W3C WCAG Checkpoints

Make text readable and understandable.

  • The advantage of using maps to convey spatial data is that they allow for an easier understanding of spatial relationships and patterns
  • If the alternate to a map is access to the data in raw format it should be laid out in an understandable way not just a data dump

Slide: W3C WCAG Checkpoints

Maximize compatibility with current and future technologies

In order to do this we recommend Progressive Enhancement as a design approach to any web page.

Helpful Links:

http://en.wikipedia.org/wiki/Progressive_enhancement

http://www.alistapart.com/articles/understandingprogressiveenhancement/

Slide: Web Mapping Accessibility Template (WMAT)

The Inter-Agency Committee on Geomatics (IACG) Web Mapping and Accessibility Sub-group is comprised of subject matter experts from various departments across the federal government.  It is our goal to create a best practices guide for the community.  WMAT is a demo that we will be using to show how these best practices are put into play.  We are hoping it will encourage communication throughout the departments and encourage feedback on how to make an accessible application usable.

We will be releasing an updated version that will have widgets for various web mapping components that developers will be able to use on their own sites.

Associated Links

IACG Sub-Group: http://www.gcpedia.gc.ca/wiki/Inter_Agency_Committee_on_Geomatics/Web_Mapping_and_Accessibility

WMAT: http://maps-cartes.ec.gc.ca/wmat/

Slide: W3C WCAG Checkpoints

There is one outstanding checkpoint:

Provide text alternatives for non-text content.

I’ve saved this for the end as this is the most complicated checkpoint, and one we have yet to have a solution for.  The map is non-text content.  To satisfy this checkpoint we need to describe the map in a meaningful, comparable way to the understanding a person takes away from viewing the map.

Consider:

  • The amount of data behind building a map image.  The number of layers, and how each of those layers represented and interact with each other.
  • The different types of maps there are.  Does map type affect a description?
  • An interactive web mapping application, every time the extent changes or the layers change.  Should the description then also be updated?

Slide: “Describing a Thematic Map”

I chose to delve a little deeper into this area for my research as it was out of scope for anything we could answer as a web mapping development team.

My research question was: How does a sighted person describe a thematic map?

I was hoping to find a way to form meaningful text descriptions of a thematic map that would not just be useful to visually impaired users, but potentially sighted users as well.

I conducted a study where I asked members of the sighted community to describe various thematic maps.

Slide: Database of words

I then took the resulting data and tagged what I thought to be as keywords in the descriptions.

Slide: Categories

I further divided the keywords into categories and sub-categories by looking at how they were used in the descriptions and what they were meaning to convey.

  • Directional
  • Topographical
  • Quantitative
  • Shape
  • Landmark
  • Query Data
  • Thematic
  • Size
  • Jurisdiction
  • Colour
  • Distance
  • Location

Slide: Proposed Description Framework

My study resulted in the following proposed framework in how to structure a description of a thematic map:

A description of a thematic map should relay context by providing

  • Query data, for a general understanding of what the map is representing;
  • Jurisdiction, for a specific area the map is covering;
  • Location, to give real-life names to the area of jurisdiction;

The points shown in the thematic layer should be described in relation to the various topographical features and landmarks by specifying:

  • Size
  • Distance
  • Direction
  • Placement

These descriptions are enriched through the use of descriptive words of the various layers and their features, which should relay

  • Shape
  • Size
  • Colour
  • Direction
  • Quantity

Slide: Example

This map is showing locations of facilities which reported pollutant releases in Canada in 2008. There is a town named Springfield, which is based along the east bank of a river. The river runs alongside the town from north to south. Approximately half way down, the river is joined by a smaller river that arches from the left. At the point where the two rivers join is a railway track. There are 3 facilities shown, the first is at the terminus of the railway track. The second point is located at the south end of the town and to the east of the first point. There is a small park near the center of town and bordering the east side of the river, as well as an orange symbol over the river about X km north of the park. The third point is due east of these two features, and is just outside the north-east side of the town.

Slide: Resources

Common Look and Feel for the Internet 2.0

http://www.tbs-sct.gc.ca/clf2-nsi2/index-eng.asp

CLF 2.0 Part 2: Standard on the Accessibility, Interoperability and Usability of Web Sites

http://www.tbs-sct.gc.ca/clf2-nsi2/clfs-nnsi/clfs-nnsi-2-eng.asp

CLF 2.0 Part 3: Standard on Common Web Page Formats

http://www.tbs-sct.gc.ca/clf2-nsi2/clfs-nnsi/clfs-nnsi-3-eng.asp

EC Internet Look and Feel Guide http://intranet.ec.gc.ca/communications/default.asp?lang=En&n=243D8F0F-1

Map of EcoAction Funded Projects

http://maps-cartes.ec.gc.ca/ecogeo/

National Pollutant Release Inventory

http://www.ec.gc.ca/inrp-npri/default.asp

Progressive Enhancement:

http://en.wikipedia.org/wiki/Progressive_enhancement

http://www.alistapart.com/articles/understandingprogressiveenhancement/

I was in Ottawa earlier this week with Dan to present our groups work in web-mapping accessibility to date.  The represented agencies were Statistics Canada, Natural Resources Canada, Parks Canada and one more group which I am blanking on right now.   After a couple meetings with the IACG, it is apparent that each agency has chosen to tackle the web-mapping accessibility problem a bit differently, which I think will be useful for the IACG as we will all be able to contribute something different to the cause.  Technically we all have the same target audience, Canadian citizens, so I think our solutions have been based on the purpose of the web-mapping applications for each agency.

The importance of the purpose of the map was highlighted when I presented my thesis work to them as a point of interest.  There was a general consensus that in my study, I shouldn’t just be asking the participants to describe a map on its own, but I also need to supply the query options that were chosen in order to produce that map.  I agree wholeheartedly with this, and it has been a topic of numerous discussions with my research partner.  The reason I’ve decided to first gather some descriptions based on the map without the query options is because I’m going off very little ground work in this area (at least that I have been able to find so far)*.  I would like to start out with descriptions of just the map, and then follow up with gathering descriptions based on the map AND its query to see how they compare and contrast, which I think will give me that much more to go off of when analyzing the descriptions.  I feel like going straight to the map and its query is skipping a few steps, and canceling out options before exploring them properly.

It became clear after taking Steve’s course, and meticulously going over this study with Jon and Greg, that it’s tricky to design a solid research study…I guess I’m playing it safe and trying to cover all my bases.  I hope I’m not wasting time, as I’m pretty positive the descriptions gathered without the matching queries will be vague, but I want to avoid making assumptions if I can.

Nevertheless, the presentation went well and ignited some great discussion.  My extreme fear of presenting thanks the IACG group for keeping it casual and more of an open forum…if only they could all be like that ;)

* The areas that I HAVE been able to find great research in are cartography, describing basic static images, and directional-based map accessibility.

We had our first IACG meeting recently, after our break from the summer. It reminded me yet again how interesting I find this web-mapping accessibility “problem” AND the fact that other people find it interesting too!

Two different groups gave presentations on the status of the web-mapping accessibility solution in their groups. It was nice to see that we are all basically on the same track. It was also clear that some departments have certain areas of strength and expertise that will definitely be helpful to draw upon.

We are splitting up into three different task forces to address specific problems regarding web-mapping accessibility:

  1. To establish a set of best practices associated with developing accessible interfaces that deliver web-mapping for use on the World Wide Web.
  2. To establish a set of best practices associated with the accessible description of map content delivered for use on the World Wide Web.
  3. To provide a consultative forum for the federal geomatics community on accessible web-mapping issues.

I’ll be giving a presentation at next month’s meeting to share what EC has done with our web-mapping applications. Everyone seemed very interested in my research at uoft, so I will present that next month as well. It will give me a chance to strengthen my presentation skills…not something I enjoy flexing. I do think that the committee will take a lot from it, and probably contribute greatly as they are all the subject matter experts from various government agencies.

I had a talk with Jeff Stark (EC’s accessibility go-to guy) a little while ago about the issues we are facing with web-mapping accessibility. Currently our development group has only really been concentrating on the map tools. Making sure all of the controls are accessible and usable. The next step I think will be to tackle accessing the points on the map, and stripping out the javascript.

The way we could present the point information will be interesting to tackle. Jeff was saying that Atlas Canada allows a user to enter a latitude and longitude or through entering place and feature names. I checked this out, and it seems to act like more of a quick zoom.  To actually interact with points on the map, you have to use the mouse.  This may be a useful technique to use with some of our maps in the future.  Though, as we use mostly thematic maps, the users of our maps will most likely not know the lat/long of the facility/monitoring station/point they are looking for…it is a nice feature though and something to keep in mind.

I think as users narrow their search, having the available points display in a data grid below the map would be useful. This was discussed within our team as a way to deal with the NPRI information, as in Alberta alone there over 4000 facilities that report pollutant information, and performance-wise that is a heavy load on the map, and also hinders usability.  We will see what comes out of the next iteration of our web-mapping template :)

In the meantime though, Jeff and his group will hopefully take a look at what we’ve done so far and ensure we are on the right track.

As most people interested in reading this blog know, the driving force behind choosing my thesis topic was because it is of great importance at my place of employment.  Treasury Board, the agency in charge of enforcing CLF standards has been pushing for Web-Mapping applications to be either made accessible or taken down.  As my team has a web-mapping group of programmers, who are responsible for a large chunk of the web-mapping applications pushed out by Environment Canada nationally, we have a large stake in this.

So aside from working with Greg and UofT, I am also working with other federal departments to come up with a solution to this problem.  Agriculture Canada has done a lot of work in this area, and like us has addressed all accessibility issues except for obviously the main map image.  They have met with Treasury Board and have gotten a pass on some of their applications, as they are arguing that the map can be accessed through using the Mouse Keys function built into the operating system.

Now, although this isn’t actual accessibility, it has pleased treasury board.  EC seems to be the only group that is going as far as we are to address the accessibility of the image.  Our next step will have to be to make an appointment with treasury board. After I get back from Fredericton this will be next on my plate.  Meanwhile we have a government wiki where I will be posting tips and tricks about web-mapping accessibility in order to help out agencies that do not have developers dedicated to this task.

I met with Byron Moldofsky on May 20th, who is the manager of the Cartography office at the university.  He was very helpful in pointing me to people that could help me in my research, as well as giving me his general comments.  He also gave me NPRI maps that his own team had already made, which I thought was a pretty funny coincidence, and my team appreciated them, they are now hanging in our GIS pod :)

Fraser Taylor seems to be the person to talk to, as he coined the term “Cybercartography”.  He is a Geography and Environmental professor at Carleton University.  We have touched base through email, and he has pointed me to some of his students who are working around the area of web-mapping accessibility.  One is interested in the policy side of accessibility which will be handy from an Environment Canada point of view.  We shall see what will develop.

I’ll be in Ottawa in June for work, so hopefully I can meet with Fraser and his students then.

I have a preference for the way accessible web-mapping is presented and I think I need to put it out there.  I have had this “argument” with other developers on my team (you know who you are), and while I understand their viewpoint, I am leaning toward the opposite camp.

Call me a dreamer, but I would like to work towards an interface that doesn’t separate the two streams of users that I am addressing here with my research, the visually impaired, and everyone else.  I think that to truly make the web accessible to all, then there should be no division.  I mean sure, you should have the ability to choose your preferences, and tailor your web experience in a way that best suits you, but I don’t think that it should be two totally separate applications.

I see the textual description as a complement to the visual map, an enhancement.  As a sighted user, I may also want to interact with the textual component, not just the visual map and vice versa.  May I remind you that visually impaired does not only include people who are blind.

But will this approach to design create an application that in the end, just frustrates all users?  This is a risk, and maybe the fact of the matter is that it would be better for all users to have the seperate streams.  I don’t technically know the answer, I just have a personal ideal solution..and it’s my research, I can conduct it how I want to, can’t I?  I will look into it to see if there has been any research done on this and keep you posted.  But in the meantime, you could put in your 2 cents…

I fear there are many more to go :(

I presented to Greg’s group on December 4th.  I was pleasantly surprised at the amount of interest it generated…although it could have been brought about though pity due to my obvious nervousness.  Nevertheless, I’m sure each time it will get just a little bit easier.  I got some great feedback and ideas…if only I could remember it all as I seemed to have blacked the whole tramautic event out of my memory. Ok no more complaining, I will suck it up.

There are so many things I haven’t even taken into account, and I need to figure out the scope of this project.  One attendee (I wish I could remember her name) brought up the point about all of the things sighted people automatically infer from a map, just from experience.  How can we capture all of this?

Jorge spoke of a game where a person is blindfolded and the other player has to describe a picture of some sort to them.  Studies such as these will come in useful when deciding on a textual description of a map.

And of course, as expected, I got the text-based search comment.  I’m not sure if my argument against this is strong enough, must work on it.

I’ve uploaded the presentation, I’m due to give another one next week to the CS’s at Environment Canada.  I also have a bunch of papers I need to put up on here so stay tuned.

Web Accessibility: A Foundation for Research

Simon Harper, Yeliz Yesilada

This textbook is aimed towards academics in order to cover a broader view of Web accessibility.  It shows chapter by chapter, existing research and future developments of many branches of accessibility.  This will hopefully be a great help to my own research, and give me an all-encompassing understanding of Web Accessibility…so far no mention of web-mapping though.

Follow

Get every new post delivered to your Inbox.