Accessibility Testing

From Dreamwidth Notes
Revision as of 19:20, 12 October 2009 by 173.48.172.175 (Talk)

Jump to: navigation, search

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 but much of it comes down to human judgement. In fact, some accessible pages will fail markup validation because some validators don't understand accessibility markup such as WAI-ARIA. The w3c explains the limitations of validation tools and how to choose one.

Jim Thatcher's analysis of what accessibility testing is possible is a good start but not comprehensive. For example, it misses 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. *Note:* if adding accessible markup stops validation it may be out of date validation tool. Make sure that the tool is up to date but don't remove the accessible markup.
  • Pages should degrade gracefully in the absence of capabilities for Flash, JavaScript, images, CSS, etc. Whenever possible, the absence of those capabilities should give as rich a user experience as their presence.
  • 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)
*considers* That's a good point. Very few people are at all on board with the semantic difference, so whichever way this is done there will be accessibility slippage. I revise my suggestion to "leave the user-entered html tags as is instead of changing them at all". branchandroot 20:05, 16 February 2009 (UTC)
I'd hope that any screen reader software would be able to interpret I/B tags as EM/STRONG. This should be tested though. If it's found that they don't, perhaps allowing users the ability to convert them through the use of styles could be a solution? I agree that the author shouldn't be forced into using one or the other, and should be allowed to choose appropriately. Touchy issue, this one. --Textish 00:47, 17 February 2009 (UTC)
Current accessibility best practice seems to assume that I/B gets parsed universally as EM/STRONG so we don't need to worry too much about it. -- Jadelennox
  • WAI-ARIA roles and landmarks should be used

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.
As discussed below, CAPTCHAs are difficult for people with disabilities across the board. Perhaps some method of e-mail verification might replace the need? This topic deserves much discussion. --Textish 01:11, 17 February 2009 (UTC)
There is no such thing as a fully accessible CAPTCHA. That blind computer users can't use any of the options. However, WebAIM has written an introductory essay on designing spam-free accessible forms that puts more of the onus on the form designer. Alternately, we could prominently link to Webvisum, a Firefox add-on that includes captcha solving. --Jadelennox
  • 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. See our list of screen readers.
This is important. I believe that sighted users can, however, test simple screen readers, such as those included in Dragon NaturallySpeaking and other simple screen readers that do not offer much more than screen scraping. I'd be willing to volunteer time to testing Dragon NaturallySpeaking's screen reading compatibility myself. --Textish 01:11, 17 February 2009 (UTC)
  • 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 to colour.

Tools & Resources

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.
  • see above for more links

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
  • 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).
  • Test with mouseless browsing Firefox extension


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 in Internet Explorer, Firefox, Safari, Opera, and Chrome.
  • For those browsers that have the capability (Firefox 3 and all versions of Opera), page size increases - scaling images as well as text - must also be tested.
  • 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"
  • evaluating cognitive usability

Speech Recognition Users

All of the issues listed for keyboard users apply to speech recognition users. See our list of speech recognition systems.

Tools to help test accessibility

Using commonly installed tools to test

Freely available specialized testing tools

Validators

Retrieved from "http://wiki.dreamwidth.net/wiki/index.php?title=Accessibility_Testing&oldid=6577"