W3C Web Accessibility Initiative


This page contains material related to a presentation at the Web Accessibility Best Practices Evaluation Training in Paris, France in July 2004. It is not intended to stand-alone; rather, it is primarily provided as reference material for participants in the training.

Scope of Training and Materials: This one-day training focused on select topics that were particularly suited to the circumstances of this specific hands-on training session. It did not to cover all aspects of evaluating Web accessibility, and did not cover all Web Content Accessibility Guidelines (WCAG) 1.0 checkpoints.
No Endorsement or Recommendation of Evaluation Tools: W3C/WAI does not endorse Web accessibility evaluation tools and does not recommend one tool over another. Some tools were listed, demonstrated, and used in activities in this training. Mention of a specific tool does not imply endorsement nor recommendation. WAI does provide a comprehensive list of Evaluation, Repair, and Transformation Tools for Web Content Accessibility.


Evaluating Navigation

Andrew Arch, NILS and Sylvie Duchateau, BrailleNet

Last updated: 26 July 2004

WCAG 1.0 Checkpoints covered:

Introduction

Navigation is the key to using the Web for all users. However, for people with disabilities, various techniques can mean the difference between using the site at all, struggling with it, or using it efficiently.

Language issues

Checkpoints:

Overview:

In many countries, lots of web sites are in multiple languages. E.g. the Eurostar site can be viewed in French, Dutch or English; the Canadian Government produces all its material in English and in French; many Australian Government departments produce resources in 'community languages' in addition to English.

Identifying language changes in a document, and identifying the primary language of a document, will allow users with speech synthesisers to hear the spoken text in the appropriate language. It will also allow search engines to recognise the document language.

Within the page, use the "lang" attribute with the <span> and <q> elements to identify another language. To set the page default language, set the "lang" attribute on the HTML element for HTML pages; for XHTML set the "lang" and "xml:lang" attributes.

Tools:

Demonstration:

Some international pages were demonstrated to participants, who had to identify if language changes were implemented or not. To check those checkpoints, one can take any international Web site using multiple languages and undertake the activities described below.

Activity:

(NB a sub-language is allowed, e.g."en-au"; Valid codes are available; any two-letter primary-tag is an ISO 639 language abbreviation and any two-letter initial subtag is an ISO 3166 country code)

Keyboard navigation

Checkpoints:

Overview:

Not all users will be using a mouse to select a link or form control; some will "tab" because of a physical disability, others because they can't see the mouse pointer (and some because they find the keyboard quicker). In HTML, developers should ensure a logical page design (or specify tab order via the "tabIndex" attribute).

Keyboard shortcuts (accessKeys) can provide a quick means of moving to places of interest, key links, or key form elements on a page. Support is variable across browsers, operating systems and assistive technologies. HPR does not handle accessKeys. JAWS and WindowEyes both do.

Being able to jump straight to the page content, instead of tabbing through all the navigation and house-keeping links, makes page use almost as efficient for a non-mouse user as it is for mouse users who can just click directly on a link they see in the page content. For a screen-reader user, the ability to choose to avoid listening to the common page elements is extremely useful. In HTML, developers should group links; identify the group; skip the group.

Many developers use JavaScript to create links; these need to be input device independent (especially keyboard accessible) to be accessible to all users.

Tools:

Demonstration:

Some pages providing access to menus only through the mouse were demonstrated. Sites using a specific tab order were also shown.

Activity:

On any site, it is possible to use the presented tools to test the accessibility of keyboard navigation, and verify if all links and form elements can be accessed through the mouse and through the keyboard. Undertake the following activities to test for the ability to navigate efficiently and effectively by keyboard.

Clear Links

Checkpoint:

Overview:

Web pages need clear link text - some users will see the links out of context. As a consequence, if links are not clear, those users waste time following them - and then have to return to the previous page. If links lead to non-HTML files, users may not want to download them or may be unable to utilise the format provided. If a page is long, then clear links can help navigate within the page more easily. Furthermore, the destination of the link should be indicated with clear link text, not an instruction to "click".

Tools:

Demonstration:

Some pages with unclear and hidden links were demonstrated to the participants.

Activity:

Use 2 or 3 tools to check for 'clear links' on any site of your choice

Discussion - Are "404" (page not found) errors 'clear links'?

Metadata

Checkpoint:

Overview:

Metadata is the key to describing web pages. Titles are used to identify a page and must be clear and unique; other elements are used to catalogue pages and need to be kept current.

Tools:

Demonstration:

A selection of pages were used to demonstrate these tools.

Activity

Use one or more of the tools to check if:

Conclusion / Summary

Evaluating the accessibility of site navigation and its compliance to the afore mentioned checkpoints requires the use of more than one tool. It is possible to check those checkpoints first by inspecting the code, maybe with the assistance of the AIS Toolbar, then in using graphical browsers and compare results with the use of textual browsers, or in disabling scripts. Moreover, some semi-automated tools, such as the WAVE, link checker, and spidering tools can also be useful. The input of users to check if they can easily navigate through the site is also an essential component.

References

AIS Web Accessibility Toolbar
http://www.nils.org.au/ais/web/resources/toolbar/
Bobby
http://bobby.watchfire.com/
Cynthia Says
http://www.cynthiasays.com/
FireFox
http://www.mozilla.org/products/firefox/
Home Page Reader (HPR)
http://www-3.ibm.com/able/solution_offerings/hpr.html
Internet Explorer (IE)
http://www.microsoft.com/windows/ie/default.mspx
Lynx
http://lynx.browser.org/
Metabrowser
http://metabrowser.spirit.net.au/
Opera
http://www.opera.com/
WAVE
http://www.wave.webaim.org/
WebXact
http://webxact.watchfire.com/