Difference between revisions of "Accessibility Testing"

From Dreamwidth Notes
Jump to: navigation, search
(adding fangs)
(Dyslexia: +more problematic elements from UX/dyslexia article)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
+
Accessibility is not the same as usability, but it overlaps because a lot of disabilities make it harder to deal with stuff that 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. [http://www.w3.org/WAI/eval/selectingtools.html The w3c explains the limitations of validation tools and how to choose one].
+
Some accessibility features can be tested automatically with tools, but much of it comes down to human judgment. In fact, some accessible pages will fail markup validation because some validators don't understand accessibility markup such as WAI-ARIA. The W3C [http://www.w3.org/WAI/eval/selectingtools.html explains the limitations of validation tools and how to choose one].
  
[http://jimthatcher.com/testing1.htm 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.
+
[http://jimthatcher.com/testing1.htm Jim Thatcher's analysis of what accessibility testing is possible] is a good start, but is 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 ==
 
== General ==
 +
 
These things are generally good things to do and also have implications for disability accessibility.
 
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 need to validate fully to whatever DTD they've specified. '''Note:''' If adding accessible markup stops a validation tool from working, it may be out-of-date. 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.
+
* Pages should degrade gracefully in the absence of capabilities for Flash, JavaScript, images, CSS, and so forth. 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. The product should never change user-entered HTML tags if avoidable, *especially* if doing so will move away from semantic toward formatting-based markup.
+
* Proper semantic markup should be used: headers for headings, ACRONYM and ABBR tags, EM/STRONG rather than I/B tags, and so forth. The product should never change user-entered HTML tags if avoidable, ''especially'' if doing so will move away from semantic toward formatting-based markup.
* WAI-ARIA roles and landmarks should be used
+
* WAI-ARIA roles and landmarks should be used.
  
 
== Blindness ==
 
== 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.
 
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.
  
* 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. However, sighted developers and testers can still be minimalist screen reader testing. See our list of [[Adaptive technology#Screenreaders|screen readers]].
+
* 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. However, sighted developers and testers can still perform minimalist screen reader testing. See our list of [[Adaptive technology#Screenreaders|screen readers]].
* Check tab order for everything, especially things which are AJAXey and therefore have changing tab order
+
* Check tab order for everything, especially things which are AJAXey and therefore have changing tab order.
  
 
=== Relevant reading ===
 
=== Relevant reading ===
 +
 
* [http://webaim.org/projects/screenreadersurvey/ WebAIM screen reader survey results]
 
* [http://webaim.org/projects/screenreadersurvey/ WebAIM screen reader survey results]
  
 
== Color Blindness ==
 
== 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.  
+
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 ===
 
=== Tools & Resources ===
Line 33: Line 36:
 
== Deafness ==
 
== Deafness ==
  
* Any official videos put on the site (eg "how to use" screencasts) should have captions available.
+
Any official videos put on the site (such as "how to use" screencasts) should have captions available.
  
 
== Deafblindness ==
 
== 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.
+
 
 +
This disability is a double-whammy, as many of the solutions to problems faced by blind or deaf users rely on the other sense -- e.g., audio alternatives to CAPTCHAs.
  
 
* Even captions for videos will probably be inaccessible. Separate methods of obtaining the information such as transcripts are needed.
 
* 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.
+
* Information needs to be concise. Many deafblind users will be using Braille displays that give a single line of text that's 40 characters long.
* see above for more links
+
  
 
== Dyslexia ==
 
== Dyslexia ==
  
* Contrast (too high can be a problem)
+
A too-high or too-low contrast can be a problem.  Other elements that can make things difficult for people with dyslexia: justified text; double-spacing after periods; long, unbroken blocks of text; serif fonts; italicized text.  ([http://uxmovement.com/content/6-surprising-bad-practices-that-hurt-dyslexic-users/ source])
  
== Keyboard-only Users ==
+
== 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.
+
* Make sure anything triggered by mouse movements (such as hover attributes) that's needed for site use has a keyboard-accessible alternative.
* Check tab order for everything, especially things which are AJAXey
+
* 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).
+
* There must be alternatives to places where one would need to control-click to select multiple elements of a list. For example, choosing tags, where the current keyboard alternative is to remember the names of your tags and type them in.  
* Test with [https://addons.mozilla.org/en-US/firefox/addon/879 mouseless browsing] Firefox extension
+
* Test with the [https://addons.mozilla.org/en-US/firefox/addon/879 mouseless browsing] Firefox addon.
  
 +
== Low vision ==
  
== Low Vision ==
+
* Too-low contrast is a problem.
 
+
* The default font size should be reasonable.
* Contrast (low is a problem)
+
* Robustness of layout to font size increases (command-+ / ctrl-+) must be tested in Internet Explorer, Firefox, Safari, Opera, and Chrome.
* Default font size should be reasonable
+
* For those browsers that have the capability (Firefox 3 and all versions of Opera), page size increases -- scaling images as well as text -- must be tested.
* Robustness of layout to font size increases (eg command-+/ctrl-+) must be tested in Internet Explorer, Firefox, Safari, Opera, and Chrome.
+
* Alternate layouts with less visual "clutter"/"noise" may be needed for some people (equivalent to LJ's Lynx site scheme).
* 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 ==
 
== 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.
+
 
 +
This refers to users who are able to use a mouse but have some difficulty with it. Keyboard equivalents are a solution to some users in this group, but others 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.
 
* 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.
+
* Minimise/eliminate use of any elements that require clicking and dragging, as this is most difficult for many users.
 
* Remember [http://en.wikipedia.org/wiki/Fitt%27s_law Fitt's law].
 
* Remember [http://en.wikipedia.org/wiki/Fitt%27s_law Fitt's law].
  
== Neurological Problems ==
+
== Neurological problems ==
This category would include people on the autism spectrum, people with traumatic brain injuries, stroke survivors, and several other groups.
+
 
 +
This category includes 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.
 
* Anything on the page that moves (Flash, animated GIFs, etc.) can be sufficiently distracting to make the page unreadable.
* [http://www.webaim.org/articles/evaluatingcognitive/ evaluating cognitive usability]
+
* [http://www.webaim.org/articles/evaluatingcognitive/ Evaluating cognitive usability].
  
 
== Speech Recognition Users ==
 
== Speech Recognition Users ==
 +
 
All of the issues listed for keyboard users apply to speech recognition users. See our list of [[Adaptive technology#Speech-recognition|speech recognition systems]].
 
All of the issues listed for keyboard users apply to speech recognition users. See our list of [[Adaptive technology#Speech-recognition|speech recognition systems]].
  
Line 91: Line 96:
 
=== Validators ===
 
=== Validators ===
  
* [http://validator.w3.org/check?uri=referer markup validation w3c validator]
+
* [http://validator.w3.org/check?uri=referer Markup validation W3C validator]
* [http://www.w3.org/WAI/ER/tools/ searchable list of evaluation tools] hosted at w3c
+
* [http://www.w3.org/WAI/ER/tools/ Searchable list of evaluation tools] hosted at W3C
* [http://wave.webaim.org/ wave] and [http://wave.webaim.org/toolbar wave toolbar]
+
* [http://wave.webaim.org/ Wave] and [http://wave.webaim.org/toolbar Wave toolbar]
 +
 
 +
== Testing external tools  for accessible integration ==
 +
 
 +
* [[JavaScript widget testing]]
  
 
[[Category:Accessibility]]
 
[[Category:Accessibility]]
 +
[[Category:Testing]]

Latest revision as of 14:19, 31 March 2013

Accessibility is not the same as usability, but it overlaps because a lot of disabilities make it harder to deal with stuff that 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 judgment. 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 is 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 a validation tool from working, it may be out-of-date. 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, and so forth. Whenever possible, the absence of those capabilities should give as rich a user experience as their presence.
  • Proper semantic markup should be used: headers for headings, ACRONYM and ABBR tags, EM/STRONG rather than I/B tags, and so forth. The product should never change user-entered HTML tags if avoidable, especially if doing so will move away from semantic toward formatting-based markup.
  • 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.

  • 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. However, sighted developers and testers can still perform minimalist screen reader testing. See our list of screen readers.
  • 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 (such as "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 -- e.g., audio alternatives to CAPTCHAs.

  • 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 that give a single line of text that's 40 characters long.

Dyslexia

A too-high or too-low contrast can be a problem. Other elements that can make things difficult for people with dyslexia: justified text; double-spacing after periods; long, unbroken blocks of text; serif fonts; italicized text. (source)

Keyboard-only users

  • Make sure anything triggered by mouse movements (such as hover attributes) that's needed for site use has a keyboard-accessible alternative.
  • Check tab order for everything, especially things which are AJAXey.
  • There must be alternatives to places where one would need to control-click to select multiple elements of a list. For example, choosing tags, where the current keyboard alternative is to remember the names of your tags and type them in.
  • Test with the mouseless browsing Firefox addon.

Low vision

  • Too-low contrast is a problem.
  • The default font size should be reasonable.
  • Robustness of layout to font size increases (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 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

This refers to users who are able to use a mouse but have some difficulty with it. Keyboard equivalents are a solution to some users in this group, but others 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 that require clicking and dragging, as this is most difficult for many users.
  • Remember Fitt's law.

Neurological problems

This category includes 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.
  • 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

Testing external tools for accessible integration