Difference between revisions of "Accessibility Testing"

From Dreamwidth Notes
Jump to: navigation, search
(General: *** 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 ita)
(Low Vision: Opera increases images along with text when you use "zoom")
Line 72: Line 72:
 
** Firefox3
 
** Firefox3
 
** Beta versions of Safari?
 
** Beta versions of Safari?
 +
** Opera
 
** 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)

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:

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