Screen reader accessibility verification test for Web checklist V5.1

1.1a: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
1.1c: Client-side image maps are used and alternative text is provided for image map hot spots. Equivalent text links are provided if a server-side image map is used. Verify several things concerning images:

1. For meaningful images, the screen reader must recognize and speak aloud the alt text, and verify that the text is meaningful.
2. If the image is too complex to describe in the alt text, (such as in the case of a complex image or chart), the alt text must inform the user as to where to find the accessible text alternative.
3. For decorative or redundant images, the screen reader must ignore the image.

How to test 1.1a and 1.1c:

Action:

Use one of the following methods to either view or listen to the alt text for each image.

• If the screen reader has a feature to display graphics list, then use it to quickly list all images that contain alt text. If there is no such feature, navigate to each image.
• Or, use the screen reader to announce the page content. For images that contain non-null alt text, be sure the screen reader announces the alt text. The screen reader should ignore images that contain null alt text. (If the image is also a link, the Tab key may also be used to navigate to the image when using the Microsoft® Windows® operating system.)

Required test techniques:

1. For each image that contains alt text:
• Verify that the alt text is meaningful.
• Verify that the image is not really redundant or decorative, and should therefore have null alt text.
• Here are some examples of meaningful alt text:
• If an image contains just text (such as, an image button), the alt text should be the same as the text shown in the image.
• Note that for some images, the word "meaningful" can sometimes be somewhat subjective. Judgment must be used to determine whether the image adds value to the surrounding text, and that the alt text announced by the screen reader adequately summarizes the information provided by the image.
2. For each image that does not contain alt text (images that are ignored by the screen reader or are not in a graphics list presented by the screen reader):
• Verify that the image is truly decorative or redundant, and should indeed have null alt text.
3. If the image is too complex to adequately describe briefly with alt text (such as graphs or charts),
• Verify that the alt text informs the user where to find the proper accessible alternative for the image. (There are multiple ways to provide an additional text alternative. For example, the text alternative may be linked using a long description (longdesc) tag, or it may be inline text found after the image, or a text link adjacent to the image might link to a resource that describes the image, or by using WAI-ARIA aria-describedby property).
• Verify that the text alternative completely describes the content in the complex image.
• Verify that the alternative is accessible.
4. For the area elements of image maps,
• Verify each area of the image map has alternative text that is the same as the text label on the image.
• Verify one text link for each active hotspot for a server side map is provided and the user can activate these links and access the contents.

1.1b: A descriptive label is provided for time-based media, including live audio-only or live video-only content. Non-text content that is used to confirm that content is being accessed by a person rather than a computer is available in different forms to accommodate multiple disabilities.

How to test 1.1b:

Action:

• Use the screen reader navigation keys (normally the arrow keys or the Tab key) to navigate to any time-based media content on the page.
• Listen to the descriptive labels using the screen reader as each time-based media gets focus.

Required test techniques:

1. For each live audio-only and live video-only,
• Verify that a descriptive label that clearly describes the purpose of live audio-only and live video-only content is provided.
• Example: A live video feed of the east coast highway has the following descriptive label "Live video picture of East Coast Highway just south of the I-81 interchange showing current traffic conditions."
2. For the non-text content intended to provide a specific sensory experience,
• Verify that an accepted name or a descriptive name of the non-text content is provided.
• Example 1: A painting of the Mona Lisa has an alternate text of "Mona Lisa, by Leonardo da Vinci" Example 2: A sound file has an alternate text of "Fifth graders playing a Theremin".
3. If non-text content is a CAPTCHA,
• Verify that a text alternative that identifies the non-text content as a CAPTCHA is provided.
• When an alternate version of a CAPTCHA is available, verify that the text alternative also includes instructions about how to find the alternate version.

1.2b: Audio descriptions of video, or a full multimedia text alternative including any interaction, are provided for prerecorded multimedia.

How to test 1.2b:

It is important that a person who is blind or visually impaired have access to the visual information provided in the multimedia through audio description or full multimedia text alternative describing everything that is happening in the multimedia.

Required test techniques:

1. For prerecorded audio-only, video only or Audio + video content listen to the screen reader output and verify:
• That description of all the meaningful video, meaningful audio and interaction from the multimedia are read, so that a blind or visually impaired user has the same information as a sighted user.

1.3a: Information structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
1.3c: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
1.3d: Form element labels can be programmatically determined.
1.3e: Table cells and relationships between cells can be programmatically determined

How to test 1.3a, 1.3c, 1.3d, 1.3e:

Actions:

Navigate to specific elements in the content and listen to the screen reader output. When interacting with different types of content, traverse through the content forward as well as in reverse. When the screen reader provides functionality to quickly navigate to specific types of content, use that method to locate that content and navigate to it. Listen to the screen reader and interact with the content/elements using the screen reader's recommended methods. Navigation to specific types of content might include:

• Tables
• Forms and form controls
• Lists
• Headings
• Links

Required test techniques:

1. For each data table in the content,
1. Verify that a meaningful summary for the table is provided.
2. Traverse the data table using the screen reader's recommended method. Traverse forward as well as backward through the content.
3. Verify column headers are provided when traversing columns. The screen reader should announce the header followed by the cell contents.
4. Verify row headers are provided when traversing rows. Screen readers normally announce row headers followed by the cell contents.
5. If a Caption for the table is provided, verify the caption for the table is read by the screen reader and is an appropriate caption for the table. For example, the caption should not be the same as the table summary.
2. For each form control in the content,
1. Verify that a label that identifies the purpose of the control before the input element for the form control is provided or a title is provided where labels cannot be used and that the screen reader reads the label or the title provided.
2. Verify that groups of logically related input elements are contained within group and a description of that group is provided and the screen reader can read this information.
3. For all form fields where input is required, verify that the screen reader conveys to the user that the input is required when the field receives focus.
3. For each list in the content,
1. Verify that content that has the visual appearance of a list (with or without bullets) is announced as an unordered list.
2. Verify that content that has the visual appearance of a numbered list is announced as an ordered list. Verify that the numbers are read with the items in the list.
4. For each header in the content,
1. Verify any content that appears to be a heading within the Web content is announced as a header along with its level.
5. Verify that all content including tables, forms, and lists are announced in a linear logical form as it appears visually and the content makes sense.
6. For each word that appears to have non-standard spacing between characters:
1. Verify that the screen reader announces the entire word and does not spell the word letter by letter.

1.3f: Hiding content using style sheets:

How to test 1.3f:

This technique applies to Web pages where content has been hidden from the visual display of a Web page, and is intended for use with screen readers to provide additional information to blind users.
Note that this test requires an understanding of the product specification and the intended design of the Web page, as well as understanding which areas of the Web page are expected to contain hidden content that is intended for use by screen readers.

Required test technique:

1. Navigate to all areas of the Web page that contain hidden content.
• Verify that the screen reader speaks the hidden content as expected and the content is meaningful.

• 2.1a: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
• 2.1b: Scripts are keyboard accessible. If the content affected by scripting is not accessible, an accessible alternative is provided.
• 2.4e: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
• 4.1b: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

How to test 2.1a, 2.1b, 2.4e, 4.1b:

Required test technique:

1. Navigate the content of the Web page using combination of Tab and arrow keys.
1. Verify that the user can navigate to and operate each control or function with 'Enter' key or 'Space' in the content with keyboard or keyboard interface using a screen reader "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints".
• Example: User can tab to a tree widget and use arrow keys to navigate the items within the tree widget.
2. Verify that the Name, Role, State and Value if any, are announced for each instance of links and form controls.
2. For the content that relies on sequential navigation in order to be understood, verify that the focus order is logical, preserves meaning and operability when traversing using keyboard navigation and the screen reader.
3. If any content is generated or changed by the script on the page, in a new window or a popup, verify that the updated content is announced by the screen reader appropriately.
4. If any content is generated or changed dynamically, verify that the updated content is inserted in the Document Object Model (DOM) immediately following its trigger element and so it is the next element the screen reader encounters.

2.4a: Navigational features - A mechanism is available to bypass blocks of content that are repeated on multiple Web units and skipping over navigation links to get to main content of page.
2.4c: Frames - A title and an accessible frame source are provided for each frame

How to test 2.4a, 2.4c:

It is important to structure Web content in such a way that content is found quickly and easily by using methods other than a mouse. This means providing a way to skip over the primary navigation links with a skip to main content link, grouping elements together along with functionality that allows users to skip over large blocks of similar content like navigation links, use of frames to organize its content, and the use of WAI-ARIA landmark roles in the content. For details on support for WAI-ARIA landmarks refer the development section of this checkpoint point.
WAI-ARIA landmarks are required as follows:

• A main landmark is always required.
• A search landmark is required if the page contains a search field.
• A navigation landmark is required if the page contains a set of navigation links.

Actions:

Navigate to specific elements in the content and listen to the screen reader output. When the screen reader provides the functionality to quickly navigate to specific types of content, use that method to locate the content, navigate to it, and listen to the screen reader as well as interact with the content as denoted to validate the implementation. Navigation to specific types of content might include:

• Links
• Lists
• Frames
• Landmarks
• Headings

Required test techniques:

1. Navigate to the Web page that uses a navigation bar or other banner information that is located at the beginning of the Web page. When the screen reader provides functionality for navigating, use that functionality as part of this validation.
1. Verify that a 'main landmark' is provided to get to the main content on the page. Use the screen reader functionality to display a list of landmarks.
2. Verify that a 'Skip to main content' link is provided at the top of the page. This should be the first link in the screen reader links list dialog.
3. Verify that the link description is appropriate, unique, and that activating this link moves the focus to the appropriate content.
4. If the page contains a search field and the screen reader provides the list landmarks functionality, verify a 'search landmark' is provided in the list of landmarks.
5. If the page contains a set of navigation links, verify a 'navigation landmark' list displays all the navigation landmarks on the Web page. Perform this test using the functionality provided by the screen reader.
2. Navigate to blocks of repeated material in the Web content and verify at least one of the following is true.
1. If heading elements are used for blocks of material in the Web content, navigate to or skip through them using the functionality built into the screen reader.
2. If frame elements are used for blocks of material in the Web content, navigate to or skip through them by using the functionality built into the screen reader. Also be sure the appropriate information is announced by the screen reader. For example, the screen reader should announce the appropriate title for the frame or iframe.
3. If a user interface control is used that allows the repeated content to be expanded or collapsed,

• Verify that the end user can use the screen reader to activate the user interface control and read the expanded and collapsed content in a logical order.

3. When links are provided at the top of the page to navigate to each area of the content, or links are provided at the beginning of each block of material to allow the user to skip blocks of repeated material then,
1. Verify that the description of the link communicates the intent to navigate to content area or skips the block of content appropriately.
2. Verify that the end user can use the screen reader to activate these links to navigate to or skip the appropriate content.

2.4d: Page titles- Web pages have titles that describe a topic or purpose.
2.4f: Link purpose - The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

How to test 2.4d, 2.4f:

Screen readers help users who are blind orient themselves by reading page titles before reading other page content. This enables the quick identification of pages within a Web site or Web application. If titles are missing or not descriptive, it forces screen reader users to browse deeply into the content in order to determine the essence of a page.

Action:

• Use the screen reader functionality to list page titles and the links list dialog

Required test techniques:

1. For every page of the Web content,
1. Verify that the screen reader announces the page title and that the title is relevant to the content of the Web page.
2. For every link on the page
1. Verify that the link text describes the purpose of the link using the links list feature of the screen reader. Be sure link text is unique for each link.
2. When it isn't possible to provide descriptive text in links, verify that the user is able to determine the purpose of a link from the surrounding text and the link context without having to move focus away from the link.
3. Note: It is recommended that any additional information needed to understand the link precedes the link to help the screen reader user. For example, the link text is combined with the preceding header or the enclosing list.

3.2b: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
3.3a: Help users avoid and correct mistakes.
3.3b: Labels or instructions are provided when content requires user input.

How to test 3.2b, 3.3a, 3.3b:

1. It is essential that screen reader users are notified in advance what to expect when they activate or use a control.
2. Help users avoid and correct mistakes.
3. Labels or instructions are provided when content requires user input.

Action:

• Navigate through the content using the screen reader.
• When the screen reader provides a short cut to navigate to forms, use that functionality to locate and interact with forms.

Required test techniques:

1. For all form fields that require user input,
• Verify that the purpose of the field can be identified through descriptive labels or title, input formats, or mandatory fields.
• If text instructions are provided at the beginning of a form or set of fields that describes the necessary input, verify that the screen reader can read the instruction.
2. Locate content where changing the setting of a form control results in a change of context,
• Verify that the screen reader announces an explanation of what will happen when the control is changed prior to the controls activation.
3. Submit the form deliberately causing errors by leaving one or more mandatory fields or entering invalid data,
• Verify that the screen reader can read the generated error message either in a popup window or displayed on the current page and the message identifies the field in error explains the appropriate reason for the error.

When invalid data is entered in fields verify that the screen reader conveys the data that was flagged as invalid to the user.

4. Identify incomplete fields: Provide text descriptions that are read by the screen reader that identify required fields that were not completed.
5. User input: Provide a text description that is read by the screen reader when user input falls outside the required format or values.