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:
- Clarify Natural Language Use:
- 4.1 (P1) - Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
- 4.3 (P3) - Identify the primary natural language of a document.
- Design for device independence
- 9.4 (P3) - Create a logical tab order through links, form controls, and objects.
- 9.5 (P3) - Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.
- Provide clear navigation mechanisms
- 13.1 (P2) - Clearly identify the target of each link.
- 13.2 (P2) - Provide metadata to add semantic information to pages and sites.
- 13.6 (P3) - Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.
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:
- 4.1 (P1) - Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
- 4.3 (P3) - Identify the primary natural language of a document
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:
- Examine the page code:
- Home Page Reader (HPR)
- Read the text and listen if it is spoken in the right language when language changes occur on the page; and/or check that the natural language of document is properly identified and read
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:
- Check for the existence of <span lang="..."> or <q lang="..."> at places where the language changes within the page.
- Check for a "lang" attribute in the HTML element. E.g. [lang="fr"] and possibly [xml:lang="fr" lang="fr"] to identify the primary language of the page.
(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:
- 9.4 (P3) - Create a logical tab order through links, form controls, and objects.
- 9.5 (P3) - Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.
- 13.6 (P3) - Group related links, identify the group (for user agents) and, until user agents do so, provide a way to bypass the group.
- 9.3 (P2) - For scripts, specify logical event handlers rather than device-dependent event handlers.
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:
- "Tab" through the page from the address box back to the address box:
- IE - use the "tab" and "shift-tab"
- FireFox - use the "tab" and "shift-tab"
- Opera - use "Q" and "A" for links; "tab" for form elements
- Lynx- use up/down arrow keys
- HPR - use "tab" and "shift-tab"
- Check for proper use of tabIndex if used - no number can be repeated; all numbers must be positive.
- The WAVE
- AIS Web Accessibility Toolbar
- Structure / accessKeys
- Structure / tabIndex
- Structure / Event Handlers
- Code inspection
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.
- Any browser - 'Tab' through site
- Can you access all the obvious/visual links?
- Does tabbing show up invisible (skip to content) links at the start of the page? Check the status bar.
- Check that the "tab" order or keyboard navigation order on the page is sensible; in most cases this means following the visual order, any other order should be questioned.
- Check for hidden (useless or repeated or irrelevant) links that may not be visible to mouse users (the focus disappears).
- Check for scripted links and menus that are not real anchor <a href > elements; these can be clickable with a mouse, but never accessible via the keyboard as the keyboard can only place focus on <a href > elements or form controls.
- Check that you can get to all form elements.
- Have accessKeys been provided?
- Do they work?
- Are they sensible? (0-9 are the safest as they conflict the least with key used by various software packages and/or assistive technologies.)
- Have they been described in Help or elsewhere?
- Does a "skip to content" link and associated anchor exist?
- Is it visible or invisible? (Visible will be usable by more people.)
- Does it work for keyboard navigation?
Clear Links
Checkpoint:
- 13.1 (P2) - Clearly identify the target of each link.
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:
- Any browser
- Visual inspection of link text
- 'Tab' through site - does tabbing show up invisible links (other than skip links at the start of the page)? Check the status bar.
- Bobby or Cynthia Says
- AIS Web Accessibility Toolbar
- Doc info / List links
- Doc info / List linked PDFs
- Code inspection
- HPR
- generate a list of links (Ctrl - L) and see if link text is clear, understandable and appropriate out of context
- can you bypass the menus?
- Opera
- generate a list of links (Ctrl - J) and see if link text is clear, understandable, appropriate out of context and related to the URL
- Lynx
- check for invisible links not obvious in IE
- Compare the text-based link information with the graphical in IE
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
- Inspect the page for clear link text
- Does "more", "click here", "link to ..." exist?
- If these exist - do they have clear link titles?
- Does any link text begin with "click here to ...."?
- Display a list of links
- Do they make sense when not embedded in the page?
- Does the 'link title' associated with any link make sense on its own?
- Does the ALT text associated with graphic-based links describe the link destination?
- Are there any hidden links (links that are not visible) on the page?
- If they exist, are they sensible to occur on the page or do they appear to be artifacts of page updates or borrowed code?
- Are there any self-referential links (reloading the current page)?
- Do all non-HTML links (to other file types or downloads) indicate the file type and size?
Discussion - Are "404" (page not found) errors 'clear links'?
Metadata
Checkpoint:
- 13.2 (P2) - Provide metadata to add semantic information to pages and sites.
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:
- HPR
- announces the page title on loading
- MetaBrowser - displays
- displays the page and its metadata in a split screen
- AIS Web Accessibility Toolbar
- Code inspection
- Watchfire WebXact
- provides a metadata summary
Demonstration:
A selection of pages were used to demonstrate these tools.
Activity
Use one or more of the tools to check if:
- There is a clear (and unique) page title?
- The other metadata (especially the description and keywords) is sensible for the page and up-to-date?
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/