Archive

Archive for the ‘Accessibility’ Category

WAI-ARIA accessibility – Notes from converting a web-based mapper.

December 2, 2010 Leave a comment

You can find the WAI-ARIA Spec here:   http://www.w3.org/TR/wai-aria/

The first step in making a more accessible version of one of our web mappers, Roam, was to ensure that the site itself was navigable using the keyboard.

Keyboard Support and Managing Focus (from ARIA standard)

  • There always needs to be a focus
  • All interactive objects should be focusable
  • All parts of composite interactive objects should either be focusable or have a documented alternative method to achieve their function, such as a keyboard short cut.
  • There should be an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element.

Tabindex used implement managing focus

Can also be used to give elements focus that would not normally be in the tab order (e.g. divs)

For Roam the focus should initially take you to the main content, the map which you can zoom in and out of using the following keyboard inputs:

+ Will zoom the map in

– Will zoom the map out

Arrow keys Will pan the map in the direction of the arrow.

If you hit tab you should get to the Task Menu. This will eventually allow you to expand/collapse the Task Menu but this has not been implemented. Pressing Tab again will take you to the first element in the task menu (Search). From this element you should be able to navigate as follows:

Arrow Keys Switch between the available panels (search, print etc.)

Return / Space Expand or collapse the selected panel

Tab (While panel expanded) moves focus into this panel.

Notes from a yahoo developer adding ARIA support to an accordion widget.

Hitting Tab again will take you through the items on the toolbar above the map (Reset to GB, previous map, next map and print map). These are treated as standard buttons/links. Tab to move between them and return or space will activate the button. The focus will then move to the Hints and Tips section which can be navigated in the same way as the Task Menu. The links on the banner will gain focus (Edina, Home, Contact us) and then finally the terms and conditions link.

ARIA Tags and expected behaviours

It is important to first implement the behaviour that the tag you want to use expected before using this tag on an element.

The tags used in Roam are below:

Role Tags (XHTML) – Landmarks

The role tag is used to define landmarks, to aid in quick navigation.

Below is an image and description of the landmarks specified for Roam (using the Juicy Studio plugin for Firefox to display the landmarks):

main:  Main content in a document. Set to the map for Roam.

banner: Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width. Set to the banner used in Roam.

complementary: A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

This region was used twice in Roam, for the Task Menu and for the Hints and Tips section. Both of these are complimentary to the main content (the map).

contentinfo: Meta information about the content on the page or the page as a whole. Used for the Terms and conditions bar and copyright text at the base of the page in Roam.

search: A region that contains one or more widgets used to define and execute a search. Used for the place name / grid ref search in Roam.

You can hear the landmarks being announced when using some screen readers. Supported in JAWS 10 only at the moment – use ctl+ insert + semi-colon to list landmarks.

Other Role Tags.

tab / tablist / tabpanel: Used for the side panel Task Menu and Hints and Tips sections. Tablist is used to contain the tabs, and tab panel is used for the expanded content element for each tab.

alert / alertdialog: Used when displaying alerts for searches, generating print map etc. The alert dialog tag is used when focus is required to close the alert. At the moment only used for the search dialog.

button: Used for basic buttons on the toolbar above the map.

navigation: Used for the home link.

tree / treeitem: Used in the legend (map content control) section which displays a legend in tree view. Note that the arrow keys can be used to navigate through the tree items.

ARIA Tags.

aria-expanded: Can be true or false and used in the two side panels (The Task Menu and the Hints and Tips) to show if the currently selected section has been expanded or not.

aria-live: This is used to mark a region as a live region. This means that the content is likely to change without the page being refreshed. Using this tag means that compatible screen readers will read out the changes
that are made as they happen (the ‘rudeness’ of these messages can be configured).

This shows a couple of the live regions in the Roam client. The name of the current view being looked at is marked as this changes when the user zooms in or out. The search results section is also marked as a live region as it gets changed (results added/changed) when a search is made.

Other potential live regions in Roam include the coordinates under the Map Information panel and the my maps listing.

aria-labelledby: This is used on elements whose content can be labelled by text in a different element. The value of this attribute is the id of the element which contains the label text for this element. For example it is used in Roam on the main map content which is labelled by the View name element in the toolbar. It is also used to associate the expandable tabpanels with their tabs (as required in the spec).

aria-describedby: This tag is used to point to an element whose text content describes this element. This is used in Roam to point to an element which describes the map in text format.

Javascript libraries and ARIA

Much of the documentation for ARIA support in the Javascript widget sets is quite sketchy. Roam uses ExtJS which claims to have some support however does not provide any documentation on this. The only support that seems to be implemented is the aria-enabled tree widget which we have used in Roam for the legend (Map Content Control) section.

Some more information can be found here on other javascript libraries and their ARIA support.

Much of the support for the accordion layout used in Roam had to be specifically implemented as the ExtJS accordion widget does not provide any keyboard support as standard.

Accessibility and OpenLayers

In openlayers you can add the KeyboardDefaults control which allows the map to be panned or zoomed using the keyboard controls described above. However this has the problem that it cannot tell if the map is the element which currently has focus, so that a keyboard press, for example using the arrow keys anywhere on the document would pan the map.

This is obviously not what we want as the arrow keys are needed to navigate the menus and select search results, and you don’t want to be panning the map as you look through the available menu tools.

This is considered a bug in the current openlayers and the developers are currently proposing restricting the map responses if the element currently focused is a form element. This does solve the problem of moving through a set of results using the mouse (as this uses a form element) but does not solve the problem of using the keyboard to navigate other widgets. For example the aria standard requires the arrow keys to be used for navigation through trees and menus which may not be in form elements. This still results in map panning when it shouldn’t.

To get around this for Roam I have made an adaptation to the KeyboardsDefaults controls which checks to see if the map is currently in focus and only allows keyboard controlled panning and zooming then. This makes the website very much more accessible for keyboard only users.

Testing Accessibility

This seemed to be the hardest part, as you can implement the tags following the standard but not see any difference in behaviour from any of the screen readers as only certain tags are supported by certain screen reader and browser combinations.

Screen Readers Used

JAWS 11 (demo)
NVDA
(free – windows only)
Fire Vox
(firefox extension)

In order to find out what tags are supported by particular browser and screen reader combinations, and to find out what the expected behaviour is I found the codetalks Set of ARIA Test Cases very useful.

Additional FireFox Extensions

As well as the screen reader extension Fire Vox, I also found it useful to have the following extensions which help visualise and summarise the tags used:

 

I also used the following more general extensions for web development which help in allowing you to inspect the elements in the page in more detail:

Access Keys

In addition to the ARIA standard, you can also improve the accessibility of the website by adding some access keys. There exist various standards however the following seems most applicable to EDINA.

Access Key UK Government standards

S – Skip navigation
1 – Home page
2 – What’s new
3 – Site map
4 – Search
5 – Frequently Asked Questions (FAQ)
6 – Help
7 – Complaints procedure
8 – Terms and conditions
9 – Feedback form
0 – Access key details

The following elements support the ACCESSKEY attribute: A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA. Note to use access keys in firefox use shift+alt+accesskey. Note OL Map is in a div, so will not support an access key.

In Roam the Home Page, Search, Help and Terms and Conditions access keys were implemented.

Further Work for Roam

In Roam you can collapse and expand the entire left and right panels to enable you to see more of the map on your screen. This should be possible using the keyboard (Return or Space when title is focused) and should mark all the content within these panels as aria-hidden when it is no longer viewable to the user. It should also mark the panel itself as in a collapsed state using the aria-expanded=false attribute.

aria-hidden: This is used to show that an element is not visible to the user. This should be used in the side panels when they are collapsed or in the case of the Map Content Control section when they are not visible to the user (because the panels for all product legends exist but only one is visible at a time – the one corresponding to the product currently being viewed).

The ‘My Maps’ section is not currently very accessible as the widgets used are not accessible using the keyboard and are not correctly tagged. This is potential future work.

Categories: Accessibility