You Are Not Done Yet: Accessibility

You are not done testing yet unless...you have verified your application plays nicely with the accessibility features of your operating system. Accessibility features are vital to customers who are blind, deaf, or use assistive input devices, but they are also extremely useful to many other people as well. For example, comprehensive large font support will be much appreciated by people with failing eyesight and/or high DPI screens.

Some of the following terms and utilities are specific to Microsoft Windows, but other operating systems likely have something similar.

• Verify that every control on every dialog and other user interface widget supports at least the following Microsoft Active Accessibility (MSAA) properties:
  • Name - its identifier
  • Role - a description of what the widget does, e.g., is it invokable, does it take a value
  • State - a description of its current status
  • Value - a textual representation of its current value
  • KeyboardShortcut - the key combination that can be used to set focus to that control
  • DefaultAction - a description of what will happen if the user invokes the control; e.g., a checked check box would have a Default Action of "Uncheck", and a button would have a Default Action of "Press"
• Verify that changing the value of each control updates its MSAA State and Value properties.
• Run in high contrast mode, where rather than a full color palette you have only a very few colors. Is your application still functional? Are all status flags and other UI widgets visible? Are your toolbars and other UI still legible? Does any part of your UI not honor this mode?
• Run in large font mode, where the system fonts are all extra large. Verify that your menus, dialogs, and other widgets all respect this mode, and are still legible. Especially be on guard for text that is truncated horizontally or vertically. To really stress your UI, do this on a pseudo-localized build!
• Run with Sound Sentry, which displays a message box, flashes the screen, or otherwise notifies the user anytime an application plays a sound. Verify that any alert or other sound your application may play activates Sound Sentry.
• Run with sticky keys, which enables the user to press key chords in sequence rather than all at once. The operating system will hide much of these details from your application, but if your app ever directly inspects key state it may need to explicitly handle this state.
• Run with mouse keys, which enables the user to control the mouse pointer and buttons via the numeric keypad. Again, the operating system will hide much of these details from your application, but if your app ever directly inspects mouse state it may need to explicitly handle this state.
• Run with no mouse and verify that every last bit of your UI can be accessed and interacted with solely through the keyboard. Any test case you can execute with a mouse should be executable in this mode as well.
• Run with a text reader on and your monitor turned off. Again, you should be able to execute each of your test cases in this state.
• Verify focus events are sent when each control loses and receives focus.
• Verify the tabbing order for each dialog and other tab-navigable UI component is sensible.
• Verify that any actionable color item (e.g., that red squiggly line Microsoft Word displays underneath misspelled words) can have its color customized.
• Verify that any object which flashes does so to the system cursor blink rate.

How completely you support these various accessibility features is of course a business decision your team must make. Drawing programs and other applications which incorporate graphics, for example, may decide to require a mouse for the drawing bits. As is also the case with testability, however, accessibility-specific features are often useful in other scenarios as well. (The ability to use the keyboard to nudge objects in drawing programs tends to be popular with customers of all abilities, for example.)

Posted by The Braidy Tester at 07:30 AM  Permalink