Skip to main content
"By creating we think, by living we learn" Patrick Geddes
Main University menu
 

Intranet

Templates Top-Level Menu

Appendix 2: Accessibility evaluation

The Web Accessibility Service is happy to provide advice on evaluating web resources for accessibility or to conduct evaluations; but staff are encouraged to carry out their own accessibility evaluations wherever possible. The following is a basic list of techniques for carrying out a rudimentary accessibility review of a web site:

  1. Colour contrast: compare the colours of text and background using a tool such as the free Colour Contrast Analyser tool. Does it report possible problems with low contrast?
  2. Check pages in a non-graphic browser such as Lynx (for more information see http://en.wikipedia.org/wiki/Lynx_(web_browser)). This shows you pages in a stripped down, linearised form, with no images, no columns or tables, and no styling, and gives an approximation of what would be read out by a screen reader. Does what you see make sense? Is any essential information missing?
  3. Check for structural HTML: Use a tool like the Web Developer Toolbar or Web Accessibility Toolbar to highlight all instances of headings and table headings on a page. Are all headings appropriately identified? Do tables have row and column headings?
  4. Listen to the resource spoken by a screen reader. Either ask a blind person to access the site, or try listening to the page yourself using the free NonVisual Desktop Access screen reader, or the demonstration version of the JAWS screen reader. Does what you hear make sense? Do links appear in a logical order? Can you hear distinguishing information that requires you to be able to see the page - such as colour or position (for example reference to "items in red" or "the menu on the right" - although note that terms such as "above" and "below" are acceptable, as these terms are generally understood in English to mean previous and subsequent content respectively)?
  5. Keyboard accessibility: Navigate through the resource using the keyboard. Can all information and functionality be accessed using the keyboard? (Essential keys are: Tab to move forward to the next link, Shift+Tab to move to the previous link, Return to follow the currently in focus link. In forms, the space bar switches on and off checkbox values, the cursor keys allow access to drop down menus and to change radio button values.)
  6. Print quality check: Print off a page in black and white. Can you read and understand all information on the page?
  7. Multimedia: If there is multimedia on the web site, does it have captions or a transcript? (Captions are what the BBC calls "subtitles" - text showing spoken dialogue and additional audio information for people who cannot hear it. In the accessibility world, subtitles means a textual translation of the spoken language into another language - in other words captions are an accessibility solution for people who cannot hear, and subtitles are an accessibility solution for people who cannot understand what they hear.) For video, is audio description available?
  8. HTML validity: Check selected web pages using an HTML validator, such as the W3C HTML Markup Validation Service website - do any errors arise?
  9. Automated accessibility check: Run selected pages through an online accessibility checking tool - does it report any problems? (Note that automated accessibility checking tools can only check for some, not all, accessibility problems.)

Once you have carried out the above techniques:

  1. Make a note of all the potential accessibility barriers you find - and make sure you act to remove them (or provide ways round them).
  2. Keep a note of any barriers that are difficult or impossible to remove - and consider how someone who encounters them can be supported in other ways.
  3. Keep evaluating as your resource evolved - new barriers can inadvertently appear whenever new content is added or existing content edited.

For more advice, speak to the Web Accessibility Service.

Previous: 8. Appendix 1. The need for an internal definition of best practice in accessible Web design

Index

Back to Top

Edit