Application Accessibility Testing

Screen reader users may find it difficult (and sometimes impossible) to use some applications, depending on the level of accessibility built into them. As an example, a blind user is unable to use the mouse to activate controls, and must rely on the keyboard. If no provision for keyboard access is provided by the application, the screen reader user will likely be unable to get to such controls and activate them.

As background information, JAWS for Windows is the most popular screen reading software in the world. Out of the box, the JAWS software works with Windows, Microsoft Office and most internet browsers. Unfortunately, many applications did not make provision for use by blind users, and often lack the accessibility features required.

The JAWS software offers many advanced tools to work around less-accessible applications, including the possibility of scripting. But the advanced tools are usually unknown to average screen reader users, and scripting should be seen as a last resort, as any change in the application may very well void all scripting efforts. It’s also possible that applications are impossible to script to work with screen reading software. Best is, and will always be, that the application developers integrate accessibility from the start.

When planning to use a non-standard application with JAWS, the first step would be to test the application accessibility. Below are a few points that the user and/or support staff should be testing. Based on the outcome, recommendations should be made to the application developers on improving the application’s accessibility features.

Finally, if it is not possible for the developers to correct the issues with the accessibility of their application, a professional on-site application accessibility assessment will be required. During the assessment, a demonstration by an expert user of the application, on the required functions and features requiring access with JAWS, will be essential. This process does not guarantee a solution to the problem or creating an accessible/blind-friendly version. We typically quote for 1-day assessment and scripting, after which we will know how much work will further be required, and if it is possible to make the application accessible.

General Accessibility Testing Checklist:
(component used as a collective term for a button, edit field, checkbox, control, etc.)

  • Run the application using only the keyboard and ensure each component which performs a user function can be accessed using the keyboard,
  • Does the application provide keyboard equivalents for all mouse actions, including buttons, scroll windows, text entry fields and pop-up windows?
  • When navigating screens and dialog boxes using the keyboard, does the focus follow the active cursor and moves in a logical tab order among fields, text boxes and focal points?
  • Is there a well-defined focal point that moves with keyboard navigation (e.g. can you use the Arrow keys to navigate through a list and use the Space Bar or Enter key to select the desired item)?
  • Are shortcut keys provided for all pull-down menus?
  • Ensure the keyboard focus is set to a component when a window is activated,
  • Ensure component labels are set properly and spoken,
  • Ensure text is echoed when you type characters,
  • Ensure highlighted text is spoken,
  • Ensure icon descriptions are set and spoken.

Making an Application Accessible – Basic Requirements:

  • Enable keyboard navigation to all functions of the application,
  • Configure keyboard shortcuts as part of the application,
  • Ensure that the tab orders in the application windows and dialog boxes follow a logical sequence and that all fields and buttons can be accessed when navigating using the Tab key,
  • Ensure that menus and window tabs can be accessed and navigated using the keyboard,
  • All buttons and fields have to be labelled and classed correctly to ensure that JAWS can identify the type of control and read its label to the user,
  • Use standard Windows colours to ensure the correct identification of text,
  • Reduce the use of graphics and images, and where used, ensure that Alt text is provided in the image properties,
  • Fields that auto populate have to be accessible and focus has to move to these areas in order for JAWS to automatically detect and read the information,
  • The use of unique Control ID’s for each control will enable better accessibility.

Find below the Guidelines for Application Software Accessibility published by the Centre for Excellence in Universal Design (CEUD), established by the National Disability Authority (NDA) of Ireland. These guidelines cover application software running under any operating system or runtime environment. We find these guidelines to be an invaluable source of information for application developers and testers.

Guidelines for Application Software Accessibility

Was this article helpful?

Related Articles