Home → Accessibility → Information Technology IT Accessibility Committee (ITAC) → Screen Reader Accessibility Checklist
Screen Reader Accessibility Checklist
This unofficial guide is intended to help interested parties determine what is necessary to assure that an application adheres to the Maine State Software Accessibility Policy and/or the Maine State Web Accessibility Policy. It is in no way intended as a replacement for either of those policies.
IT application accessibility allows a person with disabilities to submit, update and retrieve information from an application and more importantly allows that person to do the work that is expected of them in an acceptable timeframe.
It is also important to note that it is easy to try and pin application accessibility to black and white, yes or no answers. This method does not really work. Some of the test related factors determining accessibility are as follows:
- Application complexity
- User training and familiarity with the application Work flow expectations
- Application design and layout
The bottom line is: Can a disabled user get the job done within an acceptable timeframe?
Testing with a screen readerA screen reader is an adaptive third party software tool that interfaces with the PC and provides a very sophisticated level of voice output. These tools are commonly used to test the usability of an application. Testing with an SR does not include tests for low vision, hearing nor cognitive disabilities.
The key to a screen reader's workability is that it must see text to react. Since voice recognition (voice input) software also uses text to function, the SR test is considered valid for voice recognition users as well.
Web applicationsWeb Applications are highly desirable and consequently extremely common because of their lower total costs of ownership. It is therefore appropriate to focus on understanding how a screen reader (SR) interprets a web page/application.
Screen Reading Web Content
In order for an SR to work with a web page, it moves all content of a loaded page into its own buffer to facilitate its feature set. By doing this the software can parse the structure of the page and identify all of its controls such as drop down boxes, edit boxes, etc. and present them in manner meaningful to the user.
This makes proper control labeling and logical layout essential for productive use. The screen reader presents content to the user that is available within the focus of the cursor. Additionally the screen reader needs to be able to process the content according to its appropriate context. Document controls like drop down boxes and edit boxes require the Screen reader be placed in forms mode which allows the user to operate the controls. While in forms mode, it is not possible to read the text of a web page outside the control where the cursor resides.
- Is it possible to navigate to all text using the keyboard only?
- Is it possible to navigate to all controls using the keyboard only?
Controls can include application navigation bars, menu items, edit fields, check boxes, radio buttons, drop down lists, pick lists, all buttons, all graphic navigation icons, read only fields, table headers, and table items. Are the following controls properly labeled?
- Edit boxes (data entry fields)
- Drop down lists (combo boxes)
- Includes the label for the entire drop down and each list item as it is cursored through and highlighted
- Check boxes. Including the name of the check box and whether or not it is checked or unchecked.
- Radio buttons - These are particularly difficult to label. It is a best practice to avoid them and opt for drop downs instead even for one of two choices.
- Graphic icons/buttons - The label for these must be text and not a graphical representation of text.
- Simple tables are highly recommended where the first row of the table consists of the header for each column and if applicable the first column consists of each row header.
- HTML tables are much easier to make work with screen readers than desktop application tables, unless desktop application tables are MS Word or Excel based.
- In addition to proper labeling and the ability to navigate to each control:
- Can drop down items be cursored through without change event activation? Pressing enter on a highlighted item or tabbing to a button for that highlighted item should activate if this is used as a control.
- Are all errors or messages displayed as a pop up so that the user knows they are there?
- If an error or message dialog box pops up, can it be closed without effecting the user's cursor position on the application page.
- Are the contents of all edit fields (whether enterable or read only) navigable text?
This usually can be verified if the cursor resides in the edit field and can navigate using keystrokes.
- Are mandatory data entry fields text labeled so that the user knows they are required?
- Are controls for each screen or page organized for logical sequential tab navigation?
- Incorporate a skip to content link.
When a screen reader loads each new page, it usually fills it's buffer as mentioned above. This forces the cursor to default to the top. A skip to content link at the top of each page ahead of the generic links provided on every page allows the user to quickly get to the new content of the page.
- Speaking of content
Due to the nature of the SR, it reacts to changes on the screen. The way Ajax is drawn to the screen causes no page loading for new content. Therefore, the SR does not know there is new content and the blind user will not know anything changed.
The State of Maine tests applications primarily using Jaws from Freedom Scientific, the most widely used screen reader.
Refer to the Maine State OIT accessibility web site and the State of Maine web accessibility policy.