Accessibility Testing

From Dreamwidth Notes
Revision as of 13:04, 4 February 2009 by Rickybuchanan (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

Color Blindness

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

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