Difference between revisions of "Accessibility Testing"

From Dreamwidth Notes
Jump to: navigation, search
(Updated almost the whole page. Many additions.)
(Added mouse use problems.)
Line 70: Line 70:
 
** Others?
 
** Others?
 
* Alternate layouts with less visual "clutter"/"noise" may be needed for some people (equivalent to LJ's Lynx site scheme)
 
* 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 [http://en.wikipedia.org/wiki/Fitt%27s_law Fitt's law].
  
 
== Neurological Problems ==
 
== Neurological Problems ==

Revision as of 13:28, 5 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, etc.
  • Proper semantic markup should be used, eg headers for headings, ACRONYM and ABBR tags, EM/STRONG rather than I/B tags.

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:

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, to due 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.

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
    • 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?
    • 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, to due visual and auditory "noise"

Resources