Skip to main content

Screen reader

Testers use a screen reader to confirm that the experience parallels the results from manual testing and is equivalent to the intended design. This step ensures that the visual information on the screen is reinforced programmatically.

Get a screen reader

Test with a screen reader

    Check meaningful sequence

  • Make sure that...
    • Information with a specific order is available to the screen reader
    • When the screen reader deviates from visual order, the reading order does not alter its meaning
    Why?

    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.

    Fully addresses
  • Verify ALTs, labelling, and foreign phrases

  • Make sure that...
    • Images have meaningful and appropriate ALT text
    • Form field labels are clear and properly associated with the fields
    • The label text matches the output from the screen reader
    • Required form fields are announced
    • Headings are descriptive and at an appropriate hierarchy
    • Link names are descriptive
    • Foreign phrases and pages are indicated or pronounced properly by the screen reader
    Why?

    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.

    Completes testing for:
  • Compare keyboard operation and output

  • Make sure that...
    • Screen reader output is in sync with item in focus when navigating
    • Keyboard interaction continues to work while using the screen reader
    • Display of name, role, value, and state information matches screen reader output
    • Bypass blocks navigation works with the screen reader
    Why?

    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.

    Completes testing for:
    Partially addresses
  • Check page structure, tables, and headings

  • Make sure that...
    • Table captions are properly associated with tables
    • Table row and column headers are available to the screen reader
    • Regions are appropriately structured and labeled
    • Page, dialog, and frame titles are unique and concise
    Why?

    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.

    Completes testing for:
    Partially addresses
  • Confirm content interaction works with the screen reader

  • Make sure that...
    • Dynamic update triggers and effects work with the screen reader
    • Mechanism is available to pause or stop the audio that plays automatically, or a mechanism is available to control audio volume independently from the overall system volume level
    • User’s point of regard is properly handled and announced by the screen reader
    • Error handling and instructions, including programmatic identification of associated inputs, and required or invalid states, are exposed to the screen reader
    • Status messages appearing on screen are announced by the screen reader
    • Error messages and time limit notifications are properly announced by the screen reader
    Why?

    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.

    Completes testing for:
  • Reporting bugs in the screen reader

  • 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.