Verify - screen reader

Checking meaningful sequence tests that the screen reader reads content in an order that preserves its intended meaning. It is important not to confuse the reading order with the keyboard navigation order. The tester has already verified the ability to navigate and get focus in the correct order using the keyboard. Here, the tester uses a screen reader to ensure that all content (not only interactive elements) is either read out in an order that matches the visual order of information on the screen, or that, where it deviates from the visual order, the reading order does not alter its meaning. This is accomplished by using the screen reader reading commands, such as the NextLine (Down arrow), getting lists of element types, such as headings and regions, or issuing a SayAll (Insert+Down arrow) command, which reads out all the content on the screen.

Testing alternative text, labels, headings, and foreign phrases with a screen reader is an effective means of verifying an equivalent experience. Testers should navigate to each image or bring up a list of images in the content and confirm that meaningful images have appropriate ALT text, are not redundant with the role of the control, and are not redundant with caption text. Navigate through each form field or bring up a list of form fields to confirm the labels are clear and properly associated with the fields. Test that the form information announced by the screen reader (the input’s “name”) matches or contains the text that appears in the label. Check that all the link names are descriptive.

Confirm all headings are properly properly spoken or bring up a list of headings and confirm they match all the headings in the content and are nested. Navigate to any phrases that are in a language that is different from the default language and confirm the screen reader either pronounces the language properly or indicates the presence of another language.

This step reconfirms the findings in the Test with a keyboard task using the screen reader in combination with a keyboard. Testers should pay particular attention that the speech output of the screen reader matches the visual information, and that keyboard interaction still functions with the screen reader running. Mismatches between speech output and visual information can be an indication of issues with the element’s name, role, states, and value. Testers may wish to check the screen reader’s verbosity settings and inspect code to verify if properties, relationships, and states are properly set.

Also, verify that mechanisms designed to bypass blocks of content function correctly with the screen reader.

Testing with the screen reader is an effective way of confirming the structure of certain elements of the content such as tables (captions, summaries, and header cells) and regions (WAI-ARIA landmarks). Also confirm that titles of pages, dialogs, and frames (or panes) are programmatically provided to the screen reader. Screen readers provide a means to list and navigate these structures as a way to improve testing efficiency.

This step reconfirms the findings in the Confirm page interaction manual testing, but using the screen reader in combination with a keyboard. Testers should pay particular attention that the speech output of the screen reader matches the visual information and that messages and dynamic updates are properly detected and announced by the screen reader. Testers may wish to inspect code to verify if properties, relationships, and states are properly set. Also check that messages and time limit notifications that appear on screen and do not take focus are still read by the screen reader depending on the verbosity settings.

Occasionally when testing with a screen reader you’ll discover a bug in the screen reader’s support of code that conforms to the standards. Also debug the issue with a different browser or platform. Consult with the bug reporting repositories to see if the bug has been previously reported, the status, or if you need to report a new bug.