digital media access group

...excellent accessibility research and consultancy

home >  

This is a archived version of the DMAG website, but the information remains for reference. Please visit the new website for updated information.

Why automatic accessibility checking is not enough

By Louise McIver, published 15th June 2004.


Just because your website passes W3C validation [1] or is Bobby [2] approved does not guarantee that it is accessible. These tools are good as a guide, a way of identifying problems with your code, but manual checking is also required to ensure as high a level of accessibility as possible [3]. Human judgement is needed to test for compliance with many of the W3C guidelines [4], and user testing is required to identify further accessibility problems [5].


Automated tools are limited in many ways, a good example of which is they can check that images have alt text but can't make sure that it is appropriate. For example, the image below has completely inappropriate alt text but would pass all validation.


cute cat

alt text: scary dog


They can't identify presentational accessibility problems such as; colour used to convey information, patterned backgrounds which make the foreground difficult to read, inappropriate type faces and illegible colour schemes. This all requires a person, armed with knowledge of accessibility issues, to go through a website and perform these checks.


Manual testing is needed to ensure that a site is fully accessible via the keyboard and to check that the layout and presentation is logical both with and without stylesheets. It is also required to check that text can be resized via browser settings and that layout remains legible when the window is resized.


To give a true assessment of compliance with various browsers and assistive technologies requires the site to be viewed and navigated within them.


What to do

To ensure that your website is as accessible as possible you must firstly understand the W3C guidelines and the reasons behind them. Bobby, or similar validation, can then be used to identify and resolve any errors in code.


There are then a number of tests which can be performed with your browser; view the site with images turned off, with different text sizes, in different window sizes, with stylesheets turned off, with frames and scripts turned off, and with different colour schemes. At all stages you should check that the pages are logically laid out, readable, and easily navigated.


The next stage is to perform all of the above checks in different browsers: Opera, Netscape, Mozilla and Internet Explorer can all be downloaded from the internet.


View the site with a text browser such as lynx, which can be downloaded from http://lynx.browser.org/, check that the site is easily navigated and understood. Also use a speech browser on the site to ensure that it is comprehensible when spoken, a free trial version of IBM's HomPage Reader can be downloaded at http://www.ibm.com/able/hpr.html.


Ideally sites should also be tested by users with disabilities, as this can often reveal problems not covered by the other tests.



References

  1. W3C Validator - http://validator.w3.org
  2. Bobby - http://bobby.watchfire.com/bobby/html/en/index.jsp
  3. Evaluating Web Sites for Accessibility - http://www.w3.org/WAI/eval/
  4. W3C Web Content Accessibility Guidelines (WCAG) - http://www.w3.org/TR/WCAG10/
  5. The Web: Access and Inclusion for Disabled People - http://www.drc-gb.org/publicationsandreports/2.pdf