Difference between revisions of "Accessibility Testing"

Revision as of 08:36, 16 February 2009

Accessibility is not the same as usability, but it overlaps because a lot of disabilities make it harder to deal with stuff which doesn't have great usability to begin with.

Some accessibility features can be tested automatically with tools - eg markup validation, colour contrast analysis - but much of it comes down to human judgement.

Good description here of what can and can't be tested: What accessibility testing is possible Even that site misses some stuff - contrast levels appropriate for dyslexics, moving image problems that people with some neuro deficits have, everything important being keyboard-only accessible, and probably other things.

General

These things are generally good things to do and also have implications for disability accessibility.

• Pages need to validate fully to whatever DTD they've specified.
• Pages should degrade gracefully in the absence of capabilities for Flash, JavaScript, images, CSS, etc.
• Proper semantic markup should be used, eg headers for headings, ACRONYM and ABBR tags, EM/STRONG rather than I/B tags.
  • This especially. The site should rewrite I/B tags, made in posts, into EM/STRONG, instead of the other way around which is what the current LJ code does. And the headers, oh my god, the headers. branchandroot
    • I think globally rewriting all I/B to EM/STRONG in users' entries is inappropriate; not everything italic is emphasised, and not everything bold is strongly emphasised. Sometimes italics are used for other purposes, too (e.g. in book titles). -- Pne 08:34, 16 February 2009 (UTC)

Blindness

This is the disability people usually think about when they discuss web accessibility, but it's important to remember it's not the only one.

• CAPTCHAs need audio options.
• Screen reader friendliness. Try very hard to get general screen reader users to do testing for us, rather than sighted people using screen readers which is a bad approximation.
  • JAWS
  • WindowEyes
  • VoiceOver
  • NVDA
  • Orca?
  • others?
• Check tab order for everything, especially things which are AJAXey and therefore have changing tab order

Relevant reading:

• WebAIM screen reader survey results

Color Blindness

• Things which are usually signalled to users through colour changes in interface elements must have some other signalling mechanism (such as change of image shape) in addition

Deafness

• Any official videos put on the site (eg "how to use" screencasts) should have captions available.

Deafblindness

This disability is a 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.

• CAPTCHAs are completely inaccessible and an alternative such as emailing support needs to be available whenever CAPTCHAs are used. Currently I think this is only journal creation, if that.
• Even captions for videos will probably be inaccessible. Separate methods of obtaining the information such as transcripts are needed.
• Information needs to be concise. Many deafblind users will be using braille displays which give a single line of text that's 40 characters long.

Dyslexia

• Contrast (too high can be a problem)
• CAPTCHAs can be inaccessible, even with audio alternatives, due to visual and auditory "noise"

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.
• Must have alternatives in places where you would usually control-click to select multiple elements off a drop-down list (e.g. choosing tags, where the keyboard alternative currently is to remember the names of your tags and type them in).

Low Vision

• Contrast (low is a problem)
• CAPTCHAs need audio equivalents
• Default font size should be reasonable
• Robustness of layout to font size increases (eg command-+/ctrl-+) must be tested.
  • IE
  • Firefox
  • Safari
  • Opera
  • Others?
• For those browsers that have the capability, page size increases - scaling images as well as text - must also be tested.
  • Firefox3
  • Beta versions of Safari?
  • Opera
  • Others?
• Alternate layouts with less visual "clutter"/"noise" may be needed for some people (equivalent to LJ's Lynx site scheme)

Mouse use problems

Users who are able to use a mouse but have some difficulty with it. Keyboard equivalents are a solution to some in this group, but some in this group will have no ability to use a physical keyboard either - only an on-screen keyboard (again, requiring mousing) will be used.

• Mouse targets need to be as large as possible.
• Minimise/eliminate use of any elements which require a mouse click-and-drag as this is most difficult for many users.
• Remember Fitt's law.

Neurological Problems

This category would include people on the autism spectrum, people with traumatic brain injuries, stroke survivors, and several other groups.

• Anything on the page that moves (Flash, animated GIFs, etc.) can be sufficiently distracting to make the page unreadable.
• CAPTCHAs can be inaccessible, even with audio alternatives, due to visual and auditory "noise"

Speech Recognition Users

All of the issues listed for keyboard users apply to speech recognition users.

• Systems we must test:
  • Dragon NaturallySpeaking Windows speech recognition
  • MacSpeech Dictate OS X speech recognition
  • Windows Vista built-in speech recognition

Resources

• Color Contrast Analyser checks for contrast which is too high as well as contrast that is too low.