This post was most recently updated on June 17th, 2019
Accessibility Testing is a subset of usability testing, and it is performed to ensure that the application being tested is usable by people with disabilities like hearing, color blindness, old age and other disadvantaged groups.
People with disabilities use assistive technology which helps them in operating a software product.
Many people confuse usability with accessibility. To keep it simple – Usability is focused on the product, and Accessibility is focused on the user.
Within accessibility testing there are several different roles that model a disability or challenge:
For people who are blind:
Access by people who are blind is usually accomplished using special screen reading software to access and read the contents of the screen, which is then sent to a voice synthesizer or dynamic braille display.
On computers which use a graphic user interface this is a bit tricky, but there are a number of things that application software developers can do to make it possible for people using screen readers to detect and figure out what is on the screen. These include:
Using the system tools wherever you can
- draw and erase all text on the screen;
- display all cursors and pointers
using the system standard controls whenever possible;
- drawing tools in tool bars, palettes and menus that are separate items (rather than one big graphic of toolbar) as this makes it possible for screen readers to identify the number, location and shape of the individual tools so that they can be identified and named.
You can also increase the compatibility of your software with screen readers using the following considerations:
- if text is embedded in a graphic image, using a special technique to make the text known to screen reading software (see detailed notes);
- if you use your own highlight or focus techniques, dragging system cursors with you (even if invisible);
- using consistent or predictable screen and dialog layouts;
- not using pop-up help balloons that disappear if the focus changes unless there is a way to lock them in place so that the focus (e.g., cursor) can be moved there to read them;
- using single column text whenever possible;
- Giving controls logical names, even if the name is not visible on screen (screen readers can access this information and use it to describe the type and function of the control on the screen).
- Providing keyboard access to all tools, menus, and dialog boxes.
Since screen readers can only read text (or give names to separately identifiable icons or tools) it is a good idea to:
- avoid unlabeled “hot spots” on pictures as a control scheme (unless redundant with menu selection);
- avoid non-text menu items when possible or incorporate cues (visible or invisible) (screen readers can ‘see’ text that is written to screen in an invisible color);
- Avoid non-redundant graphic tool bars if possible.
For people with physical disabilities
Increase Accessibility of your software
- By avoiding timed responses (less than 5-8 sec.) or allowing the response time to be changed;
- By providing keyboard access to all toolbars, menus, and dialog boxes (whose functions are not also in the menu);
- By not interfering with access features built into the operating system (e.g. Sticky Keys, Slow Keys, Key Repeating etc.)
For people who are hard of hearing or deaf
Increase Accessibility of your software
- By providing all auditory information in a visual form as well;
- By ensuring that all visual cues are noticeable if one is not looking at the screen;
- By having a mode of operation that will work in noisy environments or if sound is turned off;
- By supporting a Show Sounds feature if it exists in the operating system of your computer (a Show Sounds feature allows a user to specify that all sound should be accompanied by a visual event including a caption for any spoken text which is not already presented on screen.). You should make sure that product support people are reachable via Text Telephones (also called TDD’s or Telecommunications Devices for the Deaf).
For People with color blindness
Increase Accessibility of your software
- By making color coding redundant with other means of conveying information.
- By making sure that your program can operate in monochrome mode.
- By using colors which differ in darkness so that they can be distinguished by this as well as color.
For People with low vision
Increase Accessibility of your software
- By allowing the user to adjust the fonts, colors and cursors used in your program to make them more visible.
- By using a high contrast between text and background;
- By not placing text over a patterned background where the two might interfere with each other;
- By using a consistent or predictable layout for screens and dialogs within the program
- By providing access to tools, etc., via menu bar;
- By using recommended line width information when drawing lines (if such information is provided by the system).
In addition, you can increase the compatibility of your software with low vision access features/software
- By using the system pointers wherever possible, as well as the system caret or insertion bar if one is available.
- If you use your own highlight/focus indicator, drag the system cursor with you ½ even if it is invisible. This makes tracking the focus much easier for screen enlargement or “pan and zoom” features.
- If the operating system has a High Contrast setting, support it.
For people with language or cognitive disabilities
This is perhaps one of the most difficult areas to address. Part of the difficulty lies in the tremendous diversity that this category represents. It includes individuals with general processing difficulties (mental retardation, brain injury, etc.), people with very specific types of deficits (short term memory, inability to remember proper names, etc.), learning disabilities, language delays, and more. In addition, the range of impairment within each of the categories can (like all disabilities) vary from minimal to severe, with all points in between. In general, software that is designed to be very user friendly can facilitate access to people with language or cognitive impairments.
Somewhat more specifically, you can increase the accessibility of your software
- by making sure that all messages and alerts stay on screen until they are dismissed;
- by making language as simple and straightforward as possible, both on screen and in the documentation;
- By using simple and consistent screen layouts.
In addition, because print disabilities are more common among people with language and cognitive impairments, you can increase the accessibility of your software by ensuring that it is compatible with screen reading software. (See the section titled “For People Who Are Blind,” above.)
For people in general
Finally, you can increase the overall accessibility of your software
- by making sure that your documentation is available in electronic form (that can be accessed by screen reading software) so that it is available to people who cannot handle or read your printed manuals;
- by making sure that your product support people are aware of disability access issues and are aware that people with disabilities routinely use your products;
- by having particular product support people identified who specialize in handling any incompatibility associated with the use of your product with disability access products (all support people should be able to handle regular product use questions of people who have disabilities, but it is usually helpful to focus incompatibility problems to a few people who can become more familiar with the issues and work arounds);
- By forwarding any access or compatibility problems identified by product support people to product designers (and setting lower trigger levels for incidence vs. priority for fixing).
