Accessibility Testing

Preliminary notes on accessibility testing. Rickybuchanan 13:04, 4 February 2009 (UTC)

Accessibility is not the same as usability, but it overlaps.

Some stuff can be tested automatically with tools - eg validation - but lots of it can't and comes down to human judgement. Good description here: What accessibility testing is possible Even they miss some stuff - contrast appropriate for dyslexics, moving image problems that people with some neuro deficits have, everything important being keyboard-only accessible. Probably more I forget.

Disabilities which have relevance to web accessibility:

Blindness

The one everybody thinks about.

• CAPTCHAs
• Screen reader friendliness (JAWS, WindowEyes, VoiceOver, NVDA, others?)
• Check tab order for everything, especially things which are AJAXey

Deafness

• Make sure any videos put on the site officially (eg "how to use" screencasts) have captions available.

Deafblindness

Double-whammy as many of the solutions to problems faced by blind or deaf users rely on the other sense - eg audio alternatives to CAPTCHAs.

Dyslexia

• Contrast (too high can be a problem)
• CAPTCHAs

Keyboard-only Users

• Make sure anything triggered usually by mouse movements (eg :hover attributes) which is needed for site use has a keyboard-accessible alternative.
• Check tab order for everything, especially things which are AJAXey
• Potentially hideable alternative text for all images which are used for site navigation and control (e.g. the "tag/memory/etc." icons) for direct keyboard access. Note this is not the same as alt tags.

Low Vision

• Contrast (low is a problem)
• CAPTCHAs
• Font size
• Robustness of layout to font size increases (eg command-+/ctrl-+) under IE, Firefox, Safari, etc - they differ so need to test all.
• Alternate layouts with less visual "clutter"/"noise" if needed (eg LJ's Lynx sitescheme)

Neurological Problems

• Things that move
• CAPTCHAs