MDAS-M v.0.9.1

Step 1: Identify Content

Use the ANDI: graphics/images module to find the images. Start with the first image outlined by ANDI: graphics/images. Use the “Focus on next element” button to find all images on the page. For each image found by ANDI: graphics/images, determine if the image is meaningful or decorative. This test is for meaningful images.

1. All images which convey information should be considered meaningful images.
2. Images are not pure decoration if they serve to illustrate text content, suggest mood or tone, or create specific sensory experiences, such as a section dividers or bullet icons that use imagery or designs that convey specific moods or tones. If they convey any information, AT users should receive the same benefit of that information.

Note:

1. ANDI may identify images that are included as a sub-component of a focusable element. In such cases, test the image using the ANDI: focusable elements module instead.
2. WCAG defines “pure decoration” as “serving only an aesthetic purpose, providing no information, and having no functionality.”
3. WCAG defines “specific sensory experiences” as “a sensory experience that is not purely decorative and does not primarily convey important information or perform a function.”

Step 2: Test Content

1. Review the ANDI Output for the meaningful image.
   1. The ANDI Output must provide an equivalent description of the image. This can be provided by a brief description of the image in the ANDI Output and instructions about where to obtain the full description.
   2. If the image is used as a CAPTCHA, ANDI Output describes the purpose of the CAPTCHA.
   3. If the image is of meaningful text, ANDI Output contains the same text.
   4. If the image is of a test or exercise that would be invalid if presented in text, ANDI Output describes the purpose of the image (it should not provide the same information needed to pass the test).
   5. If the image is intended to create a specific sensory experience, ANDI Output contains a descriptive label, and where possible, additional descriptive text.
   6. If an image is a component or child of a focusable element (e.g., a button or a link), evaluate the accessible name for the entire focusable element, not just the image. Use ANDI: focusable elements (and/or ANDI: links/buttons if applicable) to determine the accessible name for the combined element.

Step 3: Evaluate and Record Results

Failure Matrix

Due to the variability of failure conditions that can occur with this test, this matrix is not exhaustive. Evaluators should use their best judgement on Priority for failures that are not in the matrix.

Step 1: Identify Content

Use the ANDI: graphics/images module to find the images. Start with the first image outlined by ANDI: graphics/images. Use the “Focus on next element” button to find all images on the page. For each image found by ANDI: graphics/images, determine if the image is meaningful or decorative.

1. Images that are pure decoration, used only for visual formatting, or are not presented to users, should be considered decorative. Examples of this are:
   1. a swirl in the corner that conveys no information but just fills up a blank space to create an aesthetic effect
   2. images used as bullet points
   3. an abstract graphic used to separate sections of a page
   4. an invisible image that is used to track usage statistics
   5. part of a link to improve appearance or to increase the clickable area
2. Images are not pure decoration if they serve to illustrate text content, suggest mood or tone, or create specific sensory experiences, such as a section dividers or bullet icons that use imagery or designs that convey specific moods or tones. If they convey any information, AT users should receive the same benefit of that information.

Note:

• ANDI may identify images that are included as a sub-component of a focusable element. In such cases, test the image using the ANDI: focusable elements module instead.
• WCAG defines “pure decoration” as “serving only an aesthetic purpose, providing no information, and having no functionality.”
• WCAG defines “specific sensory experiences” as “a sensory experience that is not purely decorative and does not primarily convey important information or perform a function.”

Step 2: Test Content

Review the ANDI Output for the decorative image and verify that it is blank.

Step 3: Evaluate and Record Results

Failure Matrix

Due to the variability of failure conditions that can occur with this test, this matrix is not exhaustive. Evaluators should use their best judgement on priority for failures that are not in the matrix.

Step 1: Identify Content

Use the ANDI: graphics/images module to find CSS background images. If the “find background” and “hide background” buttons are available, background images are on the page. Any changes to meaningful background images that occur automatically or as a result of interaction with the page should be included in this test.

Step 2: Test Content

1. Select the “find background” button in ANDI: graphics/images to outline all background images (in green).
2. Find the outlined background images within the page. (ANDI will not display information for background images.)
3. Determine whether important information provided by the background image is available without the background image.
   1. Select the “hide background” function in ANDI: graphics/images to hide background images and help determine if the image’s information is also available on the page without the background image.
   2. Review the sequence or positioning of the image to determine whether equivalent information is presented in the same logical order.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all images of text. EXCLUDE text that is part of a picture that contains significant other visual content such as graphs, screenshots, and diagrams, which visually convey important information more than just text.

Step 2: Test Content

1. Determine if text can be used instead of the image of text to present the same effect and information.
   1. Logotypes (text that is part of a logo or brand name) cannot be replaced by text.
   2. Type samples, branding, images of specific fonts that are not widely supported are additional examples of images of text that cannot be replaced by text.
2. Determine if the image of text can be visually customized: adjust the font, size, color and background with controls provided by the web page.
   1. Customizing font size for an image of text also implies the ability to adjust the size without pixelation (which is typically evident when simply using the browser resize functionality to resize images).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify any pre-recorded synchronized media content. EXCLUDE media that is clearly identified as a media alternative for text.

Step 2: Test Content

1. Enable captions through the synchronized media player functions and play the media.
   1. A separate media file with captions may be provided to meet this requirement (i.e., captioned media version is a different file). If provided, test that one.
2. Listen to the audio of the entire synchronized media. Compare the audio to the captions for accuracy, time-synchronization, and equivalence.
   1. Captions should include all dialogue and equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.
   2. The definition of captions includes synchronization. If they are not synchronized, they are not considered captions.
   3. Captions must not obscure relevant content on the video.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all pre-recorded audiovisual media, video-only, and animated content.

• In a video-only presentation, information is presented in a variety of ways including animation, text or graphics, the setting and background, the actions and expressions of people, animals, etc.

EXCLUDE any media intended as a media alternative for text if it is clearly labeled as such and synchronized media that does not contain visual content.

Step 2: Test Content

1. Determine whether a text or audio alternative is provided for all media content that contains video (such as a transcript in text that provides a description of video content and actions or an audio track).
   1. Note: An image of a transcript does not meet this requirement.
2. Play the media content entirely while reviewing the text or audio alternative.
3. Determine whether the information in the text or audio alternative includes the same information that the video displays (e.g., if the video includes multiple characters, the alternative must identify which character is associated with each depicted action).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all pre-recorded audio-only content. EXCLUDE any audio-only content that:

• Is clearly labeled as a media alternative for text, OR
• Consists of short sounds used to notify the user, such as confirmation beeps and error notifications.

Step 2: Test Content

1. Determine if, for each audio-only content, a transcript is provided.
   1. Determine whether each transcript is text, (i.e., an image of a transcript would not be sufficient to pass this test).
2. Play the audio-only content entirely while reviewing the transcript.
3. Determine whether the information in the transcript is an accurate, correctly sequenced, and complete representation of the audio-only content.
   1. To be a complete representation of the content, the transcript must also describe relevant sounds in addition to dialogue, such as doors banging, sirens wailing, identification of speakers in dialogue, etc.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify any live synchronized media content. These requirements are only intended for broadcast of synchronized media. EXCLUDE two-way synchronized media calls between two or more individuals through web apps.

Step 2: Test Content

1. Enable captions through synchronized media player functions.
2. Listen to the audio of the synchronized media. Compare the audio to the captions for accuracy, time-synchronization, and equivalence.
   1. Lower accuracy of captions for live broadcasts may be acceptable due to limitations of real-time caption capabilities.
   2. The definition of captions includes synchronization. If they are not synchronized, they are not considered captions.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all time-based media content; that is: pre-recorded and live synchronized, audio-only, and video-only content.

Step 2: Test Content

1. Determine if, for each time-based media content, visible text exists adjacent to the content that describes the time-based media and/or gives its title.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify ALL text AND images of text. EXCLUDE text that is:

• In logotypes: logo or brand name
• For inactive (disabled) user interface elements
• For purely decoration purposes and not meaningful, i.e., having no functionality
• Contained within a picture that contains significant other visual content (not to be confused with complex graphics that have text that is meant to be read)

Note:

• Some text may not initially be visible on the page, including text that becomes visible on mouseover or when an element receives focus. Nevertheless, the text must still conform to the color contrast requirement, wherever it occurs.

Step 2: Test Content

1. Launch ANDI: color contrast.
2. Review any “Contrast Alerts” in ANDI’s “Accessibility Alerts” section to identify any text that fails to meet the minimum contrast ratio.
3. In ANDI’s “Accessibility Alerts” section, identify any “Manual Contrast Tests Needed.”
   1. If the text is not selectable or appears on a background image, determine the contrast using the Colour Contrast Analyser.
   2. Open the Colour Contrast Analyser tool, select the Foreground color-dropper button, and click a pixel in the text font. If the text color is varied in appearance or color, choose a pixel that provides the least contrast.
   3. Select the Background color-dropper button, then click a pixel in the background close to the text. If the background is varied in appearance or color, choose a pixel that provides the least contrast.
   4. Identify the Contrast Ratio
   5. Compare the contrast ratio against the minimum required contrast ratio identified in the ANDI Contrast Ratio output.
4. If the page contains an image of text alone, or an image with text and no other significant content, test the image of the text with the CCA to determine the contrast ratio between the foreground (text) and background. Note: This is for instances where it is impossible for the ANDI: color contrast module to detect the presence of the text.
   1. Select the graphics/images module in ANDI.
   2. Use the ANDI arrow buttons to identify any images of text or images with text and no other significant content.
   3. Open the CCA and test the contrast of the text in the image.
      1. Select the Foreground color-dropper button and click a pixel in the text font. If the text color is varied in appearance or color, choose a pixel that provides the least contrast.
      2. Select the Background color-dropper button and click a pixel in the background close to the text. If the background is varied in appearance or color, choose a pixel that provides the least contrast.
   4. Determine whether the resulting contrast ratio is at least 4.5:1.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Open ANDI: graphics/images
2. Document graphics that a user would need to perceive to understand the content, such as icons or graph lines/bars.

EXCLUDE logos, flags, pictures of real-life scenes such as photos of people or scenery, screenshots, graphics that have corresponding text that communicates the same information, and graphics that cannot be represented in any other way (e.g., diagrams of medical information that use the colors found in biology or color gradients that represent a measurement, such as heat maps). Note: For testers who are new to testing this success criterion, it is highly recommended to review Understanding Non-text Contrast prior to completing this test to better understand what constitutes a graphic that is needed to understand the content and what is considered an adjacent color.

Step 2: Test Content

1. Assess what part of each graphic is needed to understand what it represents. In this test, those parts will be called its meaningful aspects.
2. Identify the adjacent color(s). This typically is the page background.
3. Open the Colour Contrast Analyser (CCA) tool.
4. For each meaningful aspect, grab its color for the CCA foreground section. Then grab each adjacent color in the CCA background section.
   1. If there are multiple colors and/or a gradient, choose the least contrasting area to test.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements to identify all interactive elements on the page.
2. Document each element that ANDI: focusable elements identifies.
   1. For each element that is used on the page multiple times, verify if they have identical hover, focus, and checked states. If all of the similar looking elements appear to have identical state indicators, only document and test one instance of that element.
3. Close ANDI and move to step 2 to test the content.

EXCLUDE inactive/disabled elements and user-agent defined states (the element looks the same as the native browser/operating system style). Note: For testers who are new to testing this success criterion, it is highly recommended to review Understanding Non-text Contrast prior to completing this test to better understand all of the different ways an element is distinguishable as interactable and what is considered an adjacent color.

Step 2: Test Content

1. For each element documented from step 1, identify and document if its visual appearance changes for each of the following states:
   1. Hover
   2. Focus
   3. Active (click down and hold to see)
   4. Checked (applies to checkboxes, radio buttons, switches, and related elements)
2. Starting with the default state of the element, and repeating for each of the visually distinct states identified in 1, perform the following test:
   1. Identify all of the ways in which the control might be distinguished by a user. In this test, they will be called its distinguishing indicator(s). For example:
      1. Button
         1. Default state might be distinguishable by its text, background color, and/or border.
         2. A focused button is typically distinguishable by its border, while a hovered button is typically distinguishable by its background color.
      2. Checkbox or radio button
         1. Default state it is typically distinguishable by its border.
         2. A checked checkbox/radio button is typically distinguishable by its checkbox graphic, while a focused checkbox is typically distinguishable by its border or background color.
      3. Link
         1. Default state it is typically distinguishable by its text and/or underline.
         2. A focused or hovered link is typically distinguishable by its border, underline, or color.
      4. Form Input
         1. Default state it is typically distinguishable by its border or its background color.
         2. A focused input is typically distinguishable by its border or its cursor/caret (the line inside of the input)
      5. Switch/toggle button
         1. Default state is typically distinguishable by its background color, border, and/or the background color or border of the knob inside of it.
         2. A focused switch/toggle button is typically distinguishable by its border.
   2. Identify the adjacent color(s). This typically is the page background, but for elements that contain multiple elements (e.g., a switch/toggle button), this may also include colors within the element that contrast one element with another (e.g., the switch knob vs its track).
   3. Open the Colour Contrast Analyser (CCA) tool.
   4. For each distinguishing indicator, grab its color for the CCA foreground section.  Then grab each adjacent color in the CCA background section.
      1. Tip: Use a snipping or screenshotting tool that has a timer (such as the Windows “Snipping Tool” application) to capture the element in the state that you are testing.
3. Document the contrast ratio (if there is more than one distinguishing indicator and/or adjacent color, document the highest contrast ratio).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify content that relies on color to convey meaning, such as indicate an action, prompt a response, or distinguish a visual element.

Step 2: Test Content

1. Determine whether color is the only visual method used to convey information (e.g., review the onscreen text for a full description and/or look for other visual cues).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify instructions for understanding and operating content that rely on sensory information to convey information, e.g., references to shape, color, size, visual location, orientation, or sound.

Step 2: Test Content

1. Determine if the instructions using sensory characteristics provide details that allow content to be located, identified, understood, and operated without any knowledge of its shape, color, size, orientation, or relative position.
2. Check for any auditory cues that are provided as instructions for understanding and operating content.
   1. Ensure sound is not muted while testing.
   2. Determine whether there are visual and/or textual cues that provide the same information.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all CAPTCHA inputs.

Step 2: Test Content

1. Determine if the CAPTCHA provides a format for users without vision. This could be text or text alternative; or a button that, when activated with a keyboard, announces what the user needs to input to pass the CAPTCHA.
2. Determine if the CAPTCHA provides a format for users without hearing. This could be text, graphics, or image of text. Almost all CAPTCHAs meet this requirement.
3. If the CAPTCHA is an image, determine whether the CAPTCHA has a text alternative (such as a label) that identifies it as a CAPTCHA and describes its purpose.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

All web pages, applications, and documents.

Step 2: Test Content

1. Launch ANDI: structures
2. Review the alerts in ANDI’s “Accessibility Alerts” section to determine whether ANDI displays any of the following Invalid HTML Alerts:
   1. “Page has no <title>”
   2. “Page <title> cannot be empty”
3. In ANDI, select “more details”, then “page title.”
   1. A modal dialog box will appear with the identified page title listed.
4. Evaluate the purpose and content of the web page.
5. Determine whether the Page Title is a meaningful representation or indication of page content.
   1. If the web page is part of a set of web pages, determine whether the Page Title is sufficient to distinguish the web page from other pages.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Launch ANDI. If a Frame is used, ANDI will provide a notification that frames have been detected.
   1. If there are no Frames, ANDI will provide no notification.

Note:

• In HTML5 the <frame> element is marked as obsolete. While the <frame> element has been deprecated in HTML5, testers may still encounter web pages and/or web applications with code that, while outdated, can and should still be accessible.
• Frame content must be tested for conformance with all other applicable tests.
  • To open each Frame to test: Launch ANDI and select “Cancel”. A list of Frames will show; select the link to test an individual frame.

Step 2: Test Content

1. Launch ANDI. If a Frame is used, ANDI will provide a notification that Frames have been detected. Select “Cancel” to test an individual Frame.
2. ANDI will list each Frame, and, if available, the associated title attribute.
3. If there is no title attribute, ANDI will reveal an “alert”.
4. Select each link to access each frame. Review the Frame to understand its content. Navigate back to the page being tested and launch ANDI again.
5. In ANDI, review each frame’s corresponding title attribute for a meaningful description of content.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Use ANDI to identify all iframes in the tab order.

1. Launch ANDI: iframes to navigate to and highlight iframes on the page. If there is not an option for the iframes module, there are no iframes on the web page.
2. Use the “Next Element” button to find all iframes that have the following listed in the Accessibility Component:
   1. a tabindex value that is not negative (e.g., 0, 1) meaning the iframe is in the tab order OR
   2. no tabindex shown.

Test only these <iframes>.
Note: A negative tabindex such as -1 means that the iframe is explicitly excluded from the tab order. Do not test iframes explicitly excluded from the tab order. Note: All visible iframe content must be tested for conformance with all other applicable tests. To open each iframe to test: Within ANDI: iframe, select the button to “test in new tab.”

Step 2: Test Content

1. Launch ANDI: iframes
2. Review the ANDI Output for each iframe that has a non-negative tabindex value or where the tabindex is not defined to determine whether the accessible name and description accurately describe the content of each <iframe>.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify all pages with text.
2. Review the page content to identify the default human language of the page (the language in which most of the page is presented).

Note:

• “Human language” refers to the language that people use to communicate with one-another as opposed to coding languages used to produce software and web content.

Step 2: Test Content

1. Launch ANDI: structures.
2. Click the “more details” link, then “page language.”
   1. ANDI will display a dialog listing the value of the lang attribute assigned to the <html> element of the page.
   2. If no lang attribute is defined or if the attribute is empty, ANDI will provide a warning in the same dialog.
3. Consult the Internet Assigned Numbers Authority’s (IANA) Language subtag registry to determine whether the language is properly defined and matches the default human language for the page.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify any text content that differs from the default human language of the page including alternative text.
2. Identify the human language of the text content that differs from the default human language of the page.

Note:

• Proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text do not require a lang attribute different from the default language of the page and are not covered by this test.

Step 2: Test Content

1. Launch ANDI: structures; click the “more details” link, then “[#] lang attributes”. If the [#] is zero, no content was marked with a lang attribute.
2. Locate the markup added to the web page that identifies the element to which the attribute is applied, and the language defined in the language attribute value (e.g., “en” for English).
   1. Mouseover or tab to the markup to reveal the beginning and end of the element.
   2. Determine whether the entire passage is enclosed within the element.
3. Consult the Internet Assigned Numbers Authority’s (IANA) Language subtag registry to determine whether the language is properly defined and matches the human language for the content segment.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify the visual structure of the content and identify the areas of content that fall within one of these categories:
   1. Header – The top section of the page that typically contains the site name, logo, search, and one or more navigation bars
   2. Nav – Sections that contain collections of navigational elements (typically links) for navigating the page or related pages. Many sites have more than one Nav and at least one typically appears as a child of a Header. In addition, breadcrumbs and pagination are Navs.
   3. Search – Sections that contain elements that are used for search functionality.
   4. Main – The primary content of the page. Excludes sidebars.
   5. Form – Sections that contain form inputs and elements. Forms that are used for search should have a role=search and not a form role.
   6. Aside – Sidebars and other supporting sections of the page, complementary to the main content at a similar level in the DOM hierarchy, that remain meaningful when separated from the main content.
   7. Footer – The bottom section of the page that typically contains copyright, physical location, contact information, and accessibility statement.
2. Use ANDI to identify all programmatically defined landmarks.
   1. Launch ANDI: structures.
   2. Select the “landmarks” button within ANDI: structures.
   3. ANDI will add dotted outlines around each identified landmark.

EXCLUDE documents and desktop/mobile applications.

Step 2: Test Content

1. In ANDI: structures “landmarks”, verify that each visual structural section, defined in step 1, is located within an element with the appropriate landmark role.
2. Verify that if multiple instances of the same landmark role exist on the page, that they all have unique accessible names AND that all forms have an accessible name.
3. Verify that the page only contains one instance of each of these landmarks: banner, main, contentinfo
   1. Exclude iframes, frames, and elements with an application role in this analysis

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify all visually apparent headings, which denote sections of content.
   1. Headings are often in a larger, bolded font separated from paragraphs by extra spacing (though not always). Note the hierarchy and structure of each heading with respect to other headings on the page.
   2. Some headings are not visible but serve a broader purpose, i.e., navigational wayfinding for screen reader users.
2. Use ANDI to identify all programmatically defined headings: <h1> to <h6> or ARIA role=”heading”.
   1. Launch ANDI: structures.
   2. Select the “headings” button within ANDI: structures.
   3. ANDI will add dotted outlines around each identified heading that is visible on the page.

Step 2: Test Content

1. For each visually identified heading, compare the heading text to the content beneath the heading.
2. For each programmatically defined heading, compare the accessible name to the content beneath the heading.
3. Verify that the heading describes the topic or purpose of the content beneath the heading.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify all visually apparent headings, which denote sections of content.
   1. Headings are often in a larger, bolded font separated from paragraphs by extra spacing (though not always). Note the hierarchy and structure of each heading with respect to other headings on the page.

Step 2: Test Content

1. Select ANDI: structures and review the ANDI Output for each visually apparent heading. ANDI outlines all headings with a dotted purple line.
   1. If ANDI does not identify a visually apparent heading, then the heading is not defined programmatically.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Identify all visually apparent headings, which denote sections of content.
   1. Headings are often in a larger, bolded font separated from paragraphs by extra spacing (though not always). Note the hierarchy and structure of each heading with respect to other headings on the page.
2. Use ANDI to identify all programmatically defined headings: <h1> to <h6> or ARIA role=”heading”.
   1. Launch ANDI: structures.
   2. Select the “headings” button within ANDI: structures.
   3. ANDI will add dotted outlines around each identified heading that is visible on the page.

Step 2: Test Content

1. Launch ANDI: structures and select the “view headings list” button to display the Structure Outline.
2. Mouse over or tab through each of the headings in ANDI’s Structure Outline to review the ANDI Output for each heading.
   1. ANDI will identify heading level conflicts if found. Ex: “Heading element level <h1> conflicts with [aria-level=”2″].”
3. Compare the heading levels listed in the Structure Outline to the page content. Determine whether the heading levels logically match the visual heading presentation within the heading structure.
   1. The most important heading(s) should have the highest priority level. For example, heading level 1 is a higher level than heading level 2, which is higher than heading level 3.
   2. Headings with an equal or higher level start a new section; headings with a lower level start new subsections that are part of the higher leveled section.
   3. A heading level 1:
      1. Cannot be used more than once on a page (unless it is in a modal dialog that is not visible upon page load)
      2. Is not required to match the page title
   4. The level of headings may not always be in sequence but may be valid as it relates to the visual structure/importance communicated by visible headings on the page. For example, an <h2> heading may be used for a navigation structure that precedes an <h1> title on a page. It is also acceptable to have <h3> then <h5> without an <h4> in between.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all visually apparent lists on the page. Note:

• Exclude menus or other elements that are part of the page’s navigational framework from this test. Developers might use list elements to create grouped navigational items, such as menus, submenus, lists of navigation links, breadcrumbs, etc. while styling them to remove bullets or numbering and orienting the lists horizontally instead of vertically. If these navigational elements are part of the page’s navigational framework, separate from the main content, they should not be considered visually apparent lists for this test and should be excluded. However, any lists which are part of the main content should be included.
• Not all lists require markup. For instance, a list of items in a sentence, separated by commas, do not have to be included in a bulleted or numbered list.

Step 2: Test Content

1. Launch ANDI: structures and select the “lists” button.
2. Review the information under “List Elements,” noting the number of lists identified and their types.
3. For each list, visually determine the type of list; determine if it appears to be ordered, unordered, or a description list. Exclude menus and navigational framework elements from this test, unless they are part of the main content.
   1. Ordered – numbered sequentially and, if necessary, hierarchically (e.g., 1, 2, 2.a, 2.a.i, etc.) and are used where sequence or the ability to reference specific items by number/letter are important.
   2. Unordered – not numbered and are used where a specific sequence or the ability to reference specific items by number/letter are not important.
   3. Description list (dl) – used to groups terms with their descriptions.
4. Review the visual representation of list relationships, including order, hierarchy, and nesting compared to the programmatic list definitions presented via the ANDI output.
   1. It is possible to provide any number of nested list combinations using ordered, unordered, and definition lists. ANDI identifies each nested list separately. Review each list using the “Inspect Next Element” button to determine if the visual nesting and relationship matches the programmatic nesting and relationships.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all data tables (including images of data tables) where data cell(s) require header(s) for understanding. Note:

• To assist with identification of data tables, use ANDI:
  1. Launch ANDI: structures, then select the “reading order” link.
  2. The markup added to the page indicates the order that assistive technology will read the content
• Data tables are those tables where information in a cell requires a row or column header to adequately describe the cell’s contents. The reading order of a data table will not be sensible when read without the row and/or column headers. The content in a data table would be best understood when it is NOT read in the order that ANDI marks on the page.
• EXCLUDE content that does not require a row or column header for understanding:
  • Layout tables are used for placement of elements on the page for visual aesthetics without an informational relationship between headers and the information in the data cells. Content is understandable when read in the marked reading order.
  • Where content that is visually presented in a table but is understandable when read in the marked reading order, the content does not require a data table structure. This may occur when a CSS technique has been used to visually present information.

Step 2: Test Content

1. Launch ANDI: tables.
   1. Determine whether ANDI detects and identifies the data table(s). ANDI will identify any non-hidden tables coded using <table>, role=”table”, or role=”grid”.
2. If the tables module does not display as an option in the modules selection list, then ANDI has not detected any table programmatically on the page (meaning any content presented visually in a table does not have programmatic markup to identify it as a table).
3. If the ANDI: tables module is available, use ANDI’s “Analyze Next Table” button to sequentially highlight the detected tables on the page. If the table in question is not outlined by ANDI and/or it is not possible to navigate to the table using ANDI, then ANDI has not detected that table programmatically (meaning the content presented visually in that table does not have programmatic markup to identify it as a table).
4. Review any data tables that use role=”presentation”.
   1. ANDI will display role=”presentation” in the Element information and/or under Accessibility Alerts.
   2. A data table that includes role=”presentation” will not convey the table semantics to a screen reader and would fail this test.
5. ANDI Output will display an alert whenever ARIA role=”table” is not coded correctly.
6. Use the Analyze Previous/Next Table buttons in ANDI to navigate to each of the identified tables on the page.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all data tables (including images of data tables) where data cell(s) require header(s) for understanding. Any changes to data tables that occur automatically or as a result of interaction with the page should be included in this test. Note:

• To assist with identification of data tables, use ANDI:
  1. Launch ANDI: structures, then select the “reading order” link.
  2. The markup added to the page indicates the order that assistive technology will read the content
• Data tables are those tables where information in a cell requires a row or column header to adequately describe the cell’s contents. The reading order of a data table will not be sensible when read without the row and/or column headers. The content in a data table would be best understood when it is NOT read in the order that ANDI marks on the page.
• EXCLUDE content that does not require a row or column header for understanding:
  • Layout tables are used for placement of elements on the page for visual aesthetics without an informational relationship between headers and the information in the data cells. Content is understandable when read in the marked reading order.
  • Where content that is visually presented in a table but is understandable when read in the marked reading order, the content does not require a data table structure. This may occur when a CSS technique has been used to visually present information.

Step 2: Test Content

1. Navigate to each data cell with ANDI: tables.
2. The headers of the data cell will be highlighted on the page. Verify that all of the table headers (row and/or column headers) that describe the data cell are highlighted.
   1. Alternatively, verify in the ANDI Output that all of the table headers (row and/or column headers) that describe the data cell are listed.
   2. If there are sub headers for either columns or rows, ensure that both the main header and the sub header is highlighted/listed for affected data cells.
3. Using ANDI, move each data cell in the table and repeat #2 for each.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify any programmatic tables where the table structure is used purely for layout purposes. EXCLUDE data tables. Note:

• To find programmatic tables on the page, use ANDI: tables (as in the previous test).
  1. If the ANDI: tables module does not display as an option in the modules selection list, then there is no programmatic table on the page.
• To assist with identifying layout tables:
  1. Launch ANDI: structures, then select the “reading order” link.
  2. The markup added to the page indicates the order that assistive technology will read the content
• Content that is within a layout table does not require row or column headers for understanding. This content should be sensible when read in the reading order identified by ANDI.

Step 2: Test Content

1. Inspect the “Element” output in ANDI to determine whether the layout uses role=”table”.
2. Inspect the ANDI output and any associated alerts to determine whether a <table> includes header structure elements and/or attributes (e.g., <th>, scope=”row”).
   1. If a table has an ARIA role=”presentation” assigned and the table also denotes header relationships (e.g., using <th>, scope=”row”) ANDI will provide a corresponding alert; ignore this alert on a layout table. A table that includes role=”presentation” will not convey the table semantics to a screen reader. Therefore, the table structure semantics (e.g., <th>, scope=”row”) can be ignored if the table is indeed a layout table.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Use ANDI to identify all content positioned with CSS and inline styles.

1. Launch ANDI, then select the Advanced Settings button; then select “linearize page” to remove CSS positioning from elements on the page.
2. If content is positioned with CSS, the information will be displayed with blue highlighting around the elements and those elements will be placed in the page in the same order in which they appear in the page code.
3. ANDI: structures, and the “reading order” link can also be used to reveal the reading order prior to linearizing the content. But it will not identify which content has been positioned with CSS.

Step 2: Test Content

1. Review all highlighted, linearized content.
2. Determine whether the reading order of content is still understandable after linearization. If necessary, toggle the linearization button to view the original position of the content. If content becomes illegible due to overlapping, etc., this is not a failure of this test, which is to verify if the programmatic reading order is understandable.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

All page content. Non-web content DOES NOT APPLY (DNA). This includes documents and native applications.

Step 2: Test Content

1. Send the serialized DOM of the current page to the W3C HTML validation service using the “Check Serialized DOM of current page” bookmarklet. A new tab will open to the W3C HTML validation service.
2. Once on the W3C HTML validation service page, use the “Duplicate IDs” bookmarklet.
3. If any duplicate IDs are reported, verify that they are not associated with visible and/or interactive elements.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements to identify any form elements on the page, e.g., text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to form elements/controls, e.g., groupings, order of completion, special conditions, qualifiers, format instructions.

EXCLUDE disabled input elements. These do not receive keyboard focus, cannot be selected and cannot be modified.

Step 2: Test Content

1. Determine if each form input provides visual labels or instructions.
   1. One example of instructions is indicating a field as required.
   2. Note: “visual labels” are not always going to be text. An icon is acceptable to meet this requirement if its meaning is universally understood (such as a magnifying glass icon for a search input) or understandable within the context of the page. However, evaluators should mark this test as a failure if they have reason to believe that the icon will not be understood.
   3. For this test, it is unnecessary for the labels or instructions to be programmatically associated with the input.
2. Verify that the labels or instructions describe the topic or purpose of the form input.
3. Move focus into each form input and ensure that the label is still visible.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements to identify any form elements on the page, e.g., buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to form elements/controls, e.g., groupings, order of completion, special conditions, qualifiers, format instructions.

EXCLUDE disabled input elements. These do not receive keyboard focus, cannot be selected and cannot be modified. Any changes to form elements that occur automatically or as a result of interaction with the page should be included in this test. Form fields are not required to have programmatic associations with form section headings unless there is significant risk of confusion.

Step 2: Test Content

1. Launch ANDI: focusable elements (this is the default selection).
2. Use the mouse or ANDI’s next/previous element buttons to highlight each focusable form element and review the ANDI output.
3. Review the ANDI Output for each focusable form field.
4. If the ANDI Output does not adequately define the form element, review other programmatic associations, such as table headings or location in a hierarchical list structure, to determine whether they provide or contribute to the form element’s description, cues, or instructions.
   1. In cases where the purpose of the button is intentionally vague or ambiguous (e.g., the content to be revealed after selecting a link to “Door 1,” “Door 2,” or “Door 3” is intended to be a surprise), it may be sufficient for the combination of button text, accessible name, accessible description, and/or button context to refer to the button purpose vaguely or ambiguously.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements to identify all text and numeric inputs, text areas, and select elements.
2. Test each of these fields that collects information about the user of the page.

EXCLUDE all fields that do not collect information about the user of the page (e.g., “Mother’s Last Name” would be excluded while the user’s “Last Name” would be included). This test DOES NOT APPLY for any non-HTML (web) based content, i.e., documents and applications.

Step 2: Test Content

1. Run the “Autocomplete Attribute” bookmarklet, which will display the autocomplete attribute on the page for every field that has one.
2. Look at each field that collects information about the user of the page and see if it collects one of the types of data identified in the first column of the input purposes table below.
   1. If it does not, the field does not apply (DNA)
3. Verify that the autocomplete attribute of the field is set to the autocomplete value that corresponds to the type of data the field collects (second column of the input purposes table).

Input Purposes Table

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements and identify form inputs, text areas, checkboxes, radio buttons, and select elements.
2. Identify fields that are in visual proximity to other fields and/or are visually grouped under a descriptive heading.
3. Note the fields that are related to each other. These will include, but are not limited to all radio buttons, groupings of checkboxes, and groupings of text inputs (such as a phone number group that has three inputs, one for area code, second for prefix, and third for line number or a group that contains multiple address lines, city, state, and ZIP code).

EXCLUDE groupings that are not logically related, e.g., a section of a form that is collecting a name, address, and phone number – all of these elements together are not logically related, but the name fields need to be semantically grouped, as do the address fields, as do the phone number fields. INCLUDE PDF documents but EXCLUDE the semantic grouping requirement, as PDFs do not have semantical elements to group elements. Still ensure that grouped fields have a visible label.

Step 2: Test Content

For each logically related grouping of fields:

1. Using ANDI, step through each form element of the group.
2. Under ANDI’s Accessibility Components list, ensure that one of the following are listed and that its value is identical for each form element in the group:
   1. legend
   2. group
   3. radiogroup if the grouped form elements are radio buttons

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all automatic input error detection, error notifications, error suggestions, and related instructions:

1. Use ANDI to identify any form elements on the page.
2. Find all instructions and cues (textual and graphical) that are related to form elements/controls, e.g., groupings, order of completion, special conditions, qualifiers, format instructions.
3. Intentionally enter values and/or make selections that violate format and/or other form instructions to reveal automatic notifications of input errors.

Step 2: Test Content

1. Intentionally violate formatting and other form instructions, e.g., leave a required form field empty, use a different date format than is required, and/or create a password that does not meet the password strength requirements.
2. Attempt to submit the form and/or move to the next page.
3. Determine whether the error is identified and described in text.
   1. The form field with the error is identified in text, e.g. “Error: Password field.”
   2. Text describes the error, e.g., in a dialog message that states “the Password you entered is incorrect.”
4. Verify if the error message is programmatically associated with the form field
   1. Open ANDI to the “focusable elements” module (default module)
   2. Move ANDI focus to the form field
   3. Verify that within the ANDI Accessibility Components list, an “aria-describedby” attribute exists and its output is the same as the error text from the previous steps
5. If the form field is mandatory, requires a specific data format, and/or is required to be one of a limited set of values, determine whether the error text includes suggestions for correction (unless doing so would jeopardize the security or purpose of the content).
   1. Mandatory field example: “ZIP Code cannot be empty”
   2. Specific data format example: “Phone number is not in a valid format. It should be like 614-987-6543 (with dashes) or 6149876543 (without dashes)”
   3. Limited set of values example: “Month should be the full name of the month. Did you mean ‘December’?”

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify Content that:

1. Submits user form entries that result in or causes legal commitments or financial transactions
2. Submits user form entries that modify or deletes user-controllable data in a data storage system
3. Submits user test responses

Step 2: Test Content

1. Complete the required form fields with intentional errors and submit the content.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: focusable elements to identify any form elements on the page, e.g., buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to form elements/controls, e.g., groupings, order of completion, special conditions, qualifiers, format instructions.

EXCLUDE disabled input elements. These do not receive keyboard focus, cannot be selected and cannot be modified.

Step 2: Test Content

1. Use the keyboard to navigate to form elements, e.g., text fields, radio buttons, checkboxes, buttons.
2. Complete the form element, e.g., select the radio button or check box, type information into the text box, select an item from the drop down.
3. Exit (tab away from) the completed form element and determine whether there are any instances of an unexpected change of context.
4. Changes in context include changes of user agent, viewport, focus, content that changes the meaning of the page, e.g., a form is automatically submitted when exiting a field, a new window is launched when a radio button is selected.
   1. Note: A change is not considered unexpected if:
      1. The user is notified that a change of context is about to occur (both visually and announced via screen reader).
      2. The control is clearly intended to initiate a change in context when activated.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Switch inputs are custom input elements that allow users to choose either “on” or “off” value. They are named as such due to their similarity to physical switches, like light switches. They are made up of a “thumb” (typically signified as a circle) and a “track” (typically signified as an oval). The location of the thumb inside of the track indicates whether the switch is on or off.
Image © 2023 W3C®

Step 2: Test Content

Switch inputs can be developed using multiple different techniques. This test is agnostic to the technique used, when possible.

1. Navigate to the switch input.
2. Verify that it toggles between on and off when the Space key is pressed.
3. Open ANDI and select the focusable elements module (default).
4. Locate the element that serves as the switch toggle. This may be a generic element (div, span, etc.), checkbox input, or button.
5. Verify that it has a role=switch.
6. If the switch is NOT a checkbox input, verify the following:
   1. When the switch is in the “off” state, it has an aria-checked=false.
   2. When the switch is in the “on” state, it has an aria-checked=true.

Note: The tester may need to move the ANDI focus away from the switch and back to the switch between toggling it on and off for the aria-checked value to be reported correctly.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Use ANDI: links/buttons to identify all links. EXCLUDE links that function as an anchor or target and are not perceivable or selectable by users.

Step 2: Test Content

1. Evaluate the ANDI Output for link purpose.
2. Determine whether the ANDI Output, in combination with the programmatically determined link context (text that is in the same sentence, paragraph, list item, or table cell as the link or in a table header cell that is associated with the table cell that contains the link) adequately describes the link’s purpose or function.
   1. In cases where the purpose of the link is intentionally vague or ambiguous (e.g., the content to be revealed after selecting a link to “Door 1,” “Door 2,” or “Door 3” is intended to be a surprise), it may be sufficient for the combination of link text, accessible name, accessible description, and/or link context to refer to the link purpose vaguely or ambiguously.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify interactive elements on the page that hyperlink to a new resource when activated.

EXCLUDE links that are not perceivable or selectable by users and <a> (anchor) elements that perform button-like functionality (these are tested separately in E.6.3. Non-native and Toggle Buttons).

Step 2: Test Content

1. Evaluate the ANDI “Element” output for the element and verify that it is one of the following:
   1. <a> element OR
   2. Any other element with a role=link
2. If it is not an <a> element, verify that
   1. It receives keyboard focus AND
   2. Its hyperlink function can be activated using the keyboard by pressing the Enter key

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: links/buttons to identify all buttons.
2. Review the page for interactive elements that act as buttons (elements that, when activated, trigger an action or event) that were not found by ANDI.

EXCLUDE buttons that are not perceivable or selectable by users.

Step 2: Test Content

1. Evaluate the visual label of the button.
2. Determine whether the visual label adequately describes the button’s purpose, function, or associated content.
   1. Note: “visual labels” are not always going to be text. An icon is acceptable to meet this requirement if its meaning is universally understood (such as a magnifying glass icon for a search input) or understandable within the context of the page. However, evaluators should mark this test as a failure if they have reason to believe that the icon will not be understood.
   2. Note: The accessible name of the button should NOT be considered in this test. This test is only for the visual label of the button.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use ANDI: links/buttons to identify all buttons.
2. Review the page for interactive elements that act as buttons (elements that, when activated, trigger an action or event) that were not found by ANDI.

EXCLUDE buttons that are not perceivable or selectable by users.

Step 2: Test Content

1. Expand the buttons list (“show buttons list”)
2. Evaluate the Accessible Name & Description of the button.
3. Determine whether the accessible name adequately describes the button’s purpose, function, or associated content.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all interactive elements on the page that, when activated, trigger an action or event. These may include <a> (anchor) elements that are incorrectly being implemented for button purposes.
EXCLUDE native <button> elements unless they are toggle (two-state) buttons and links that navigate to a different page or a different part of the page.

Step 2: Test Content

1. Activate the button using a mouse and note what action happens.
2. Move keyboard focus to the button element.
3. Press the Enter key and verify that the noted action occurs.
4. Press the Space key and verify that the noted action occurs.
5. Open ANDI and select the focusable elements module (default).
6. Move ANDI focus to the button and verify that it has role=button.
7. If the button is a toggle (two-state, on and off) button, verify that
   1. When the button is not pressed/off, under ANDI Accessibility Components, aria-pressed is false.
   2. When the button is pressed/on, under ANDI Accessibility Components, aria-pressed is true.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Accordions are elements that are used to hide content and reveal the content on interaction, referred to as “collapse” and “expand.” They are made up of two components: the Accordion Heading (which is a button that contains the accordion’s title) and the Accordion Panel (which contains the content that is hidden when the accordion is collapsed).
Example of an accordion element from Buckeye UX (BUX)

Step 2: Test Content

1. Use a keyboard to navigate to the Accordion Header and verify that it receives keyboard focus.
2. Press the Space key and verify that the accordion expands and the Accordion Panel is visible. Press the Space key again and verify that the accordion collapses and the Accordion Panel is no longer visible.
   1. If the Space key does not work, try pressing the Enter key.
3. Open Google Chrome’s accessibility inspection tool.
4. Using the inspection tool, select the Accordion Header. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Accordion Header “Role” has a value of “button.”
   2. The Accordion Header “Expanded” has a value of “true” when the accordion is expanded and “false” when the accordion is collapsed.
   3. The Accordion Header “Controls” value is the element that contains the Accordion Panel.
5. Using the inspection tool, select the Accordion Panel. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Accordion Panel “Role” has a value of “region.”
   2. The Accordion Panel “Labeled by” is the Accordion Header element.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Tabs, or Tabbed Interfaces (as they will be called throughout the remainder of this test), are a set of content sections that display one section of content at a time. They often resemble a set of physical file folders with tabs labeling each folder, but sometimes do not visually resemble them. Example of a Tabbed Interface from Buckeye UX (BUX)

Step 2: Test Content

Component Descriptions

Due to the complexity of this test, descriptions of each of the major Tabbed Interface components are defined in this table. The component names are used in the test process. Use this table as a reference.

Steps

1. Press the Tab keyboard key until a Tab in the Tab List receives keyboard focus.
2. Verify that the active Tab is the one that receives keyboard focus.
3. Press the Tab keyboard key and verify that keyboard focus moves to either the Tab Panel OR an interactive element within the Tab Panel.
4. Move keyboard focus back to the active Tab.
5. Press the right arrow key and verify that either
   1. Focus moves to the next Tab (or, if focus is on the last Tab, its moved to the first Tab) AND the associated Tab Panel is activated/displayed, OR
   2. Focus moves to the next Tab (or, if focus is on the last Tab, its moved to the first Tab) AND pressing the Enter key on the next Tab displays the associated Tab Panel.
6. Press the left arrow key and verify that either
   1. Focus moves to the previous Tab (or, if focus is on the first Tab, its moved to the last Tab) AND the associated Tab Panel is activated/displayed, OR
   2. Focus moves to the previous Tab (or, if focus is on the first Tab, its moved to the last Tab) AND pressing the Enter key on the previous Tab displays the associated Tab Panel.
7. Open Google Chrome’s accessibility inspection tool.
8. Using the inspection tool, select the Tab List. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Tab List “Role” has a value of “tablist.”
   2. The Tab List “Name” has a value that is descriptive of the Tabbed Interface’s purpose
   3. If the Tabbed Interface has a visible label or header, verify that the “Name” is the same as the visible label
      1. The Tab List “Orientation” matches the visual presentation of the Tab List (“horizontal” if presented left-to-right, “vertical” if presented top-to-bottom)
9. Using the inspection tool, select the active Tab. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Tab “Role” has a value of “tab.”
   2. The Tab “Name” has a value that is descriptive of the Tab Panel’s purpose
   3. The Tab “Selected” has a value of “true.”
   4. The Tab “Controls” is the associated Tab Panel element.
10. Using the inspection tool, select the active Tab Panel. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
    1. The Tab Panel “Role” has a value of “tabpanel.”
    2. The Tab Panel “Labeled by” is the associated Tab element.
11. Repeat 9 and 10 for each Tab element, ensuring that the Tab is activated first.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all visually apparent carousels, a web pattern consisting of a container with multiple items, called “slides”, where:

• each slide is a subsection of the web page, coded with HTML, with meaningful content;
• the slides within a carousel form a group of related items, each with similarly structured content;
• the slides do not represent a series of steps to be completed in a specific order;
• all slides can be accessed without navigating to a new web page;
• only a subset of slides are displayed at one time if the viewing area is too narrow to display them all;
• slides are rotated forwards or backwards by the user, automatically at regular intervals, or both;
• slides rotate on one axis only (usually horizontally); and
• if rotated automatically, each slide stays in view for some amount of time before the next rotation.

Exclusions:

• An embedded video or animated GIF is not a carousel, because each frame is not a meaningful subsection of the web page.
• Continuously scrolling text, like a marquee or ticker, is not a carousel because it does not pause between rotations.
• A paginated list or data table is not a carousel, because the data repeats in two axes (vertically within each page, and horizontally between pages).
• If the slides are a series of steps that must be completed in a specific order, then the structure is not a carousel.

Additional considerations:

• Because the number of visible slides may vary with screen width, it is possible that an element may be a carousel at small screen widths, but not at large screen widths. Here is an example. Be sure to reduce screen size while testing to help ensure all carousels are identified.
• The Carousel Pattern is distinct from the Tabs Pattern.
  • If there are Previous and Next Slide Controls (typically icon buttons) to navigate the slides, then treat the element as a carousel.
  • If the slides advance automatically at set intervals, then treat the element as a carousel.
  • If both of the above are false, (i.e., slides can only be changed by choosing from a slide picker; i.e., a list of buttons or tabs representing all slides) then the element may be treated either as tabs or a carousel, at the tester’s discretion.
• A carousel may be implemented by coding the slides as tab panels, and the slide picker as tabs. If so, or if the carousel visually appears to be tabs, then the element must pass both this test and the Tabs Pattern test.

Step 2: Test Content

Component Descriptions

Due to the complexity of this test, descriptions of each of the major carousel components are defined in this table. The component names are used in the test process. Use this table as a reference.

Steps

1. Open Google Chrome’s accessibility inspection tool.
2. Using the inspection tool, select the Carousel Container. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Carousel Container “Role” has a value of “region.”
   2. The Carousel Container “Name” has a value that is descriptive of the Carousel’s purpose
      1. If the Carousel has a visible label, verify that the “Name” is the same as the visible label
      2. Verify that the “Name” does not include the word “carousel.”
   3. The Carousel Container “roledescription” has a value of “carousel.”
3. If the Carousel rotates automatically, verify the following. If it does not, skip to step 4.
   1. Ensure that the Carousel is in automatic rotation mode.
   2. Hovering the mouse pointer over the Carousel content pauses the automatic rotation.
   3. The Carousel pauses automatic rotation when keyboard focus is moved to each interactive element inside of the Carousel Container. Note: This behavior must exist for every interactive element within the Carousel Container or the content fails.
   4. The automatic rotation resumes when keyboard focus is moved outside of the Carousel Container. Ensure that the mouse pointer is not hovered over the carousel when performing this part of the test to avoid false test failure.
   5. A Rotation Control Button exists to start and stop the Carousel.
   6. The Rotation Control Button is always visible.
   7. The Rotation Control Button is the first child element in the Carousel Container.
   8. The Rotation Control Button contains a visible label consisting of a play/pause icon, play/pause text, or a combination of both.
   9. Using the inspection tool, select the Rotation Control Button. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
      1. The Rotation Control Button has a Role of “button.”
      2. The Rotation Control Button has a Name like “Stop Automatic Slide Show.”
      3. The Rotation Control Button has a Focusable attribute of “true.”
   10. Using the inspection tool, select the Slides Container. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
       1. The Slides Container DOES NOT have a Live region attribute/value.
   11. The Carousel stops rotating when the Rotation Control Button is activated using the keyboard.
       1. If it does not stop rotating, stop the rotation using another means before completing the next step.
   12. Using the inspection tool, select the Rotation Control Button. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
       1. The Rotation Control Button has a Name like “Start Automatic Slide Show”
   13. The Carousel starts rotating when the Rotation Control Button is activated using the keyboard.
   14. Stop the Carousel rotation.
4. Using the inspection tool, select the Slides Container. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Slides Container has a Live region of “polite.”
5. If the Carousel has a Slide Picker, verify the following. Otherwise, skip to step 6.
   1. The first Slide Picker Control in the Slide Picker receives keyboard focus.
   2. Pressing the tab key moves focus out of the Slide Picker and NOT to the next Slide Picker Control.
   3. Move keyboard focus back to the first Slide Picker Control.
   4. Press the right arrow key. The focus moves to the next Slide Picker Control and the next Slide in the sequence is displayed. Repeat for each Slide Picker Control.
   5. Press the left arrow key. The focus moves to the previous Slide Picker Control and the previous Slide in the sequence is displayed. Repeat for each Slide Picker Control.
   6. Activate the first Slide Picker Control if it is not already.
   7. Using the inspection tool, select the Slide Picker. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
      1. The Slide Picker has a Name of “Slides.”
      2. The Slide Picker has a Role of “tablist.”
   8. Using the inspection tool, select the active Slide Picker Control. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
      1. The Slide Picker Control has a Name that reflects the position of the Slide this Slide Picker Control will display when activated (i.e., if this is the second dot, the Name needs to be something like “Slide 2.”)
      2. The Slide Picker Control has a Role of “tab.”
      3. The Slide Picker Control has a Focusable of “true.”
      4. The Slide Picker Control has a Selected of “true.”
      5. Click or activate the button within the Slide Picker Control’s Controls tree. That will select the item that this element Controls within the inspection tool. Verify that the element it selects is the Slide it controls
   9. Using the inspection tool, select the Slide Picker Control immediately following the one you just tested. If the one you just tested is the last Slide Picker Control in the Slide Picker, continue to Step 6.
      1. Verify that the Slide Picker Control has a Selected of “false” or does not have a Selected attribute.
      2. Activate the next Slide Picker Control in the Slide Picker and repeat steps 5.8 and 5.9.
6. Using the inspection tool, select the active Slide. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. If the Carousel does NOT have a Slide Picker, the Slide has a Role of “group.”
   2. If the Carousel has a Slide Picker, the Slide has a Role of “tabpanel.”
   3. The Slide has a Name that includes the position number of the active slide and the total number of slides (i.e., “3 of 6” where 3 represents that the active slide is the third slide within the set of slides and 6 represents the total number of slides).
   4. The Slide has a roledescription of “slide.”
   5. Repeat this step for every Slide in the Carousel.
7. Using the inspection tool, select the Next Slide Control.
   1. Verify that the Next Slide Control contains a visible label consisting of a right-pointing icon, the word “Next,” or a combination of both.
   2. Verify that the Carousel moves to the next slide AND keyboard focus remains on the Next Slide Control when it is activated using the keyboard.
   3. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
      1. The Next Slide Control has a Role of “button.”
      2. The Next Slide Control has a Name of “Next Slide.”
      3. The Next Slide Control has a focusable of “true.”
      4. Click or activate the button within the Next Slide Control’s Controls tree. That will select the item that this element Controls within the inspection tool. Verify that the element it selects is the Slides Container.
8. Using the inspection tool, select the Previous Slide Control.
   1. Verify that the Previous Slide Control contains a visible label consisting of a left-pointing icon, the word “Previous,” or a combination of both.
   2. Verify that the Carousel moves to the previous slide AND keyboard focus remains on the Previous Slide Control when it is activated using the keyboard.
   3. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
      1. The Previous Slide Control has a Role of “button.”
      2. The Previous Slide Control has a Name of “Previous Slide.”
      3. The Previous Slide Control has a focusable of “true.”
      4. Click or activate the button within the Previous Slide Control’s Controls tree. That will select the item that this element Controls within the inspection tool. Verify that the element it selects is the Slides Container.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Navigation menus include any grouping of links that are for the purpose of navigating between different pages on the website or parent website (e.g., the global OSU navigation). These include, but are not limited to, primary navigation menus, secondary navigation menus, page navigation menus, footer navigation menus, menu buttons, breadcrumbs, and pagination.

Step 2: Test Content

1. Open Google Chrome’s accessibility inspection tool.
2. Using the inspection tool, select the Navigation Menu. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Navigation Menu “Role” has a value of “navigation”
   2. If there are multiple navigation menus on the page, the Navigation Menu “Name” has a value that is descriptive of its purpose.
3. Press the Tab key until the first item in the Navigation Menu receives keyboard focus.
4. Verify that at least ONE of the following are true in regard to navigating between top menu items
   1. If a submenu is opened when the menu item receives focus, that pressing the Tab key or Down Arrow key moves focus into the submenu AND pressing the Escape key closes the submenu and moves focus back to the menu item AND either b or c are true, OR
   2. Pressing the Tab key moves focus to the subsequent top level menu items, OR
   3. Pressing the arrow keys moves focus between top menu items AND there are visual instructions that describe this interaction pattern AND the instructions are announced to screen reader users when the first menu item receives focus.
5. If a submenu exists and is not opened when the menu item receives focus, either
   1. It opens with both the Enter key and Space key AND the menu item is NOT a link that navigates to a new page when clicked on, OR
   2. A button exists immediately following the menu item that opens the submenu when it is activated with the keyboard
6. Open Google Chrome’s accessibility inspection tool.
7. Using the inspection tool, select the button. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The button “Role” has a value of “button”
   2. The button “Name” has a value that is descriptive of its purpose, i.e., “Additional items for [menu item]”
8. Open the submenu, press the escape key and verify that the submenu closes and focus moves back to the menu item.
9. Open the submenu and verify that the items receive keyboard focus with the Tab key.
10. Open a desktop screen reader.
11. Verify that when submenus are opened, the screen reader announces that they are “expanded” AND when submenus are closed, the screen reader announces that they are “collapsed.”
12. If the active page is called out visually, verify that the screen reader announces the active page when it receives screen reader focus.
13. Open the page on a mobile device and open its screen reader.
14. Verify that all of the navigation menu functionality works with the screen reader swipe interface.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify block(s) of content that are repeated on other pages within the site.

• Blocks of content that are repeated on other pages may include navigation links, page headers, tabs, and banners.
• Blocks of content do not have to be exactly the same to be considered repetitive; blocks of content could be considered to repeat if they contain the same type of information and/or serve the same purpose.

EXCLUDE small sections, such as repeated individual words, phrases, or single links. They are not considered repetitive blocks of content. Note:

• Most web browsers provide keyboard shortcuts to move the user focus to the top of the page or browser; providing a method to bypass a set of navigation links located at the bottom of a web page may be unnecessary.

Step 2: Test Content

1. Starting at the top of the page, use keyboard commands to navigate forward to repetitive blocks of content. Note: Some bypass functions may not be visible until they receive focus.
2. Determine whether a keyboard-accessible method was provided to bypass repetitive content (e.g., skip links, hotkeys, scripted elements, etc. Frames may work as a bypass method in some browsers but not others).
   1. Launch ANDI: focusable elements to check for skip links, hide options, collapse menu and other elements with similar bypass functionality.
      1. Note: ANDI’s “tab order” feature under the focusable elements module may help evaluate the order in which bypass methods occur relative to other content.
      2. Alternatively, launch ANDI: links/buttons and select the “view links list” button.
   2. Turn on screen reader and use keyboard commands to activate the bypass function.
      1. Multiple blocks of repeated content may require multiple methods to bypass the blocks; it may not be possible to bypass all blocks of repeated content with a single method.
      2. If the new content is not announced immediately, navigate to the next item with the screen reader to verify that the focus moved past the repetitive content.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

EXCLUDE modal dialogs used for the purpose of diverting users’ attention to an important message. Those elements are tested in test E.9.4 Alert Dialogs. The following DO NOT APPLY and should not be tested:

1. Documents.

Step 2: Test Content

Component Descriptions

Due to the complexity of this test, descriptions of each of the major Modal Dialog components are defined in this table. The component names are used in the test process. Use this table as a reference.

Steps

1. Move keyboard focus to the Triggering Element and activate it.
2. Verify that the Modal Dialog appears and focus is moved to an element within it.
3. Press the Tab key multiple times and verify that focus does not go behind the dialog. Repeat by pressing the Shift and Tab keys simultaneously multiple times.
   1. Note: Focus moving into the browser controls is expected behavior and does not constitute a failure for this step.
4. Open Google Chrome’s accessibility inspection tool.
5. Using the inspection tool, select the Modal Dialog. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Modal Dialog “Role” has a value of “dialog.”
   2. The Modal Dialog “Name” has a value that is descriptive of its purpose
   3. If the Modal Dialog has a visible Title, verify that the “Name” is the same as the Title.
      1. The Modal Dialog has a “modal” attribute with the value of “true.”
6. Press the escape key and verify that the dialog closes, and focus moves back to the Triggering Element OR the most logical location if the element no longer exists. If the escape key does not close the dialog, verify that a keyboard accessible Close Button exists that closes the dialog.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

A hover/focus tooltip is an element that contains a message that is displayed when a triggering element receives mouse hover and/or keyboard focus. Note: Tooltips that are only displayed when the element receives either hover or focus are within the scope of this test. A test for these types of tooltips – Toggle Tooltips – will appear in a future version of the MDAS-M. EXCLUDE tooltips that are native to the browser or operating system, that is, tooltips that appear because the “title” attribute is set on the element. The following DO NOT APPLY and should not be tested:

1. Documents.

Step 2: Test Content

1. Verify that the tooltip is displayed when the triggering element receives mouse hover.
2. Verify that the tooltip is displayed when the triggering element receives keyboard focus.
3. Verify that the tooltip does not contain interactive elements.
4. Verify that the tooltip remains visible until it is closed.
5. Remaining careful to not move the mouse pointer outside of the triggering element or tooltip, move the mouse pointer to the tooltip and ensure that the tooltip remains visible.
6. Open screen reader.
7. Move focus to the triggering element.
8. Verify that the tooltip content is announced by the screen reader.
9. Close screen reader.
10. If the tooltip obscures content on the page, press the escape key to close the tooltip. If the escape key does not close the tooltip, look for instructions for other keyboard mechanisms to close it.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Open screen reader
2. Navigate the page using the keyboard. Interact with each interactive element.
3. Listen for announcements that are not the typical screen reader output. Note which actions you took that activated that announcement. EXCLUDE any actions that resulted in focus moving to a new element or the appearance of a dialog window.
4. Look for important changes of the page content that were not announced. Note which actions you took that activated those changes. EXCLUDE changes that are NOT one of the following:
   1. Success or results of an action
   2. Waiting state of an application
   3. Progress of a process
   4. Existence of errors

This DOES NOT APPLY (DNA) for non-web content (documents and applications).

Step 2: Test Content

1. Refresh page
2. Open ANDI and go to the structures module (sANDI)
3. For each action noted in the “Identify Content” step, perform the action and follow these steps
   1. In sANDI, if live regions exist on the page, they will be listed at the “# live regions” link. Activate the link and locate the live region that contains the announcement. If it exists, ensure that it is highlighted in ANDI.
   2. Determine what type of live region it should be based on the context in which it appears
      1. Alert: The message is important and time sensitive. The user must hear it immediately even if it interrupts other messages. It requires the user’s immediate attention. Alerts should be rare.
      2. Status: The message is advisory. The user can hear it after other messages are announced and still understand the context in which it applies.
      3. Log: The message is part of a larger group of messages located within a meaningful sequence. Examples include chat logs, messaging history, game logs, and error logs. Logs are uncommon and have a specific use case.
      4. Marquee: The message is non-essential and changes frequently. Examples include stock tickers. Marquees are uncommon.
      5. Timer: The message is a numerical counter which indicates an amount of elapsed time from a start point or the time remaining until an end point. Timers are uncommon and have a specific use case.
   3. Using the “Live Region ARIA Attributes” table below, verify that the ANDI Accessibility Components includes the appropriate attributes for the type of live region the message should be.
   4. If no message exists or the message is not located within a live region, it FAILS.

Live Region ARIA Attributes

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Interact with all of the interactive elements on the page and note which actions display a dialog that requires user response (e.g., confirmation and cancel buttons). EXCLUDE dialogs that are native to the operating system or browser. This DOES NOT APPLY (DNA) for non-web content (documents and applications).

Step 2: Test Content

Component Descriptions

Due to the complexity of this test, descriptions of each of the major alert dialog components are defined in this table. The component names are used in the test process. Use this table as a reference.

Steps

1. Perform the action that displays the alert dialog.
2. Verify that focus has moved to an interactive element inside of the alert dialog
   1. If the purpose of the alert dialog is to confirm a destructive action, verify that focus is NOT moved to the element that will perform the destructive action (i.e., Delete, Discard, etc.).
3. Press the Tab key multiple times and verify that focus does not go behind the dialog. Repeat by pressing the Shift and Tab keys simultaneously multiple times.
   1. Note: Focus moving into the browser controls is expected behavior and does not constitute a failure for this step.
4. Open Google Chrome’s accessibility inspection tool.
5. Using the inspection tool, select the Alert Dialog. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The Alert Dialog “Role” has a value of “alertdialog.”
   2. The Alert Dialog “Name” has a value that is descriptive of its purpose
   3. If the Alert Dialog has a visible Title, verify that the “Name” is the same as the Title.
      1. The Alert Dialog has a “modal” attribute with the value of “true.”
      2. The Alert Dialog “Described by” value is the element that contains the Alert Message.
         1. This can be additionally verified by comparing the “Description” attribute to the Alert Message text.
6. Press the escape key and verify that the dialog closes, and focus moves back to the element that triggers the dialog OR the most logical location. If the escape key does not close the dialog, verify that a keyboard accessible mechanism exists that closes the dialog.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Activate the “SPA Detection” bookmarklet.
2. Read the instructions in the alert and press “OK.”
3. On the page, click on a link that will go to another page on the same website.
4. If the “Leave Site” alert appears before the new page is loaded, this website/application DOES NOT APPLY (DNA).
5. If no “Leave Site” alert appears before the new page is loaded, this is a SPA. Follow the test procedure in step 2.

The following DO NOT APPLY and should not be tested:

1. Websites that do not have more than one distinct page, meaning that none of the internal links on the page go to another page or replace the page content with other page content.
2. Documents.
3. Mobile and Desktop applications.

Step 2: Test Content

1. Open the “structures” module in ANDI (sANDI).
2. In sANDI, in the “more details” menu button, select “page title.”
3. Note the page title.
4. Refresh the page (if a confirmation alert appears asking if you want to reload the site, press the “Reload” button).
5. Open a screen reader.
6. Click on a link that will go to another page on the same website.
7. Verify that the new title of the page is announced.
8. Verify that focus is moved to a logical location, such as the H1, error message, or first form element in a multipage form.
9. Close the screen reader.
10. Open the “structures” module in ANDI (sANDI).
11. In sANDI, in the “more details” menu button, select “page title.”
12. Verify that the page title reflects the new content on the page and is different than the page title noted in #3.
13. Activate the browser back button and verify that the initial page/screen loads.
14. Activate the browser forward button and verify that the page/screen opened in #6 loads.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify user interface elements that have not been evaluated in the “E” series of MDAS-M tests. As of this version, these include, but are not limited to:

1. Custom checkboxes
2. Comboboxes (input widget that has an associated popup)
3. Datepickers and Timepickers
4. Grids
5. Listboxes
6. Non-navigational Menus, Menubars, and Menu Buttons
7. Meters
8. Progress indicators
9. Sliders
10. Spinbuttons
11. Toolbars
12. Tree views
13. Tree grids
14. Window splitters

This test DOES NOT APPLY to the following types of content:

1. Documents.
2. Mobile and Desktop applications.

Step 2: Test Content

1. Locate the type of interface element in the WAI-ARIA Authoring Practices Guide (APG)
   1. If the element is not documented here, acceptable alternative references include Inclusive Components, UK Design System, and U.S. Web Design System (USWDS).
      1. Note: The design systems should be used as code and user experience research references for testers to identify the proper ways that certain elements should be implemented. Testers should NOT provide links to the GOV.UK or USWDS websites as remediation advice without explicitly stating that these are examples and providing as much context as possible. Developers without extensive accessibility experience are likely to misinterpret links to these references as advice to use the design systems in their projects.
      2. Less experienced evaluators are encouraged to contact the ADA Digital Accessibility Center (accessibility@osu.edu) for guidance on interpreting these resources and synthesizing them into their testing plan.
2. Open Google Chrome’s accessibility inspection tool.
3. Using the inspection tool, select the element you are testing. In the Accessibility tab (bottom panel), under “Computed Properties,” verify that
   1. The element’s “Role” matches the appropriate role as defined in the WAI-ARIA 1.1 Definition of Roles list.
   2. The element’s “Name” has a value that is descriptive of its purpose
      1. If the element has a visible title, verify that the “Name” is the same as the title.
4. If the element features any interactivity that is not path-dependent, the keyboard interface follows the guidelines provided in the WAI-ARIA APG “Developing a Keyboard Interface” document.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use the mouse or other pointing device to determine available functions provided by interactive elements (including drop-down menus, form fields, revealing/hiding content, tooltips, AND all interactive interface elements).
2. Use the mouse to identify instances where interactive elements provide information that is essential to understanding or operating the page content.
3. Open ANDI to the “focusable elements” module (default), which will highlight all elements on the page that can receive keyboard focus.

Note: Much of this testing will have already been performed if the tester completed the User Interface Element (E) tests. Testers do not need to repeat this test on elements they have already tested. If any of those tests failed on keyboard access grounds, however, this test should be marked as a failure. EXCLUDE functions that require input that depends on the path of the user’s movements, such as handwriting and free-hand drawing. Functions that do not depend on a specific path, such as vector drawing and drag and drop interfaces, must NOT be excluded and MUST be tested.

Step 2: Test Content

1. Use the keyboard to operate identified functionality and/or access the essential information: access (e.g., Tab to) the element and execute (e.g., press Enter or Space with focus on the element, press the Arrow keys to navigate between items within a composite control).
   1. If an interactive element does not have keyboard access, determine if there is another keyboard accessible method available on the page which provides the same functionality, e.g., one of two print methods provided is keyboard accessible, etc.
   2. If an interactive element does not provide access to essential information via keyboard interaction, determine whether the information is available elsewhere on the page (e.g., as text).
   3. If standard keystrokes (Tab, Shift + Tab, Arrow keys, Enter, Space) do not access and operate the controls but custom keystrokes do, OR the standard keyboard strokes are used in a way that the average keyboard user would find confusing, ensure instructions for the keystrokes are
      1. Visible, e.g., by displaying them when the control has keyboard focus or in an easy-to-find location that can be accessed using standard keystrokes.
      2. Announced by the screen reader, e.g., when the control receives keyboard focus or in an easy-to-find location that can be accessed using standard keystrokes.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Use the keyboard to navigate to keyboard-accessible interface elements (including drop-down menus, form fields, revealing/hiding content, tooltips, AND all interactive interface elements).

Step 2: Test Content

1. Determine whether there is a visible indication of focus on the element that has keyboard focus.
   1. When the keyboard focus is on a frame, some browsers will display a visible focus and some may not. Where a visible focus is not available on a frame, do NOT consider this a failure of the web content.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

This test is applicable to all pages, applications, and documents that are navigable using a keyboard interface.

Step 2: Test Content

1. Use the tab key to move focus through the page.
2. Determine if the focus order impacts the page meaning (e.g. form fields for a mailing address are presented in the expected sequence).
3. This is most often noticeable when focus order does not follow the logical order of operation (normally top to bottom, left to right).
4. It may be necessary to use the keyboard to activate trigger controls that reveal hidden content with focusable elements (e.g., menus, dialogs, modal dialog boxes, expandable tree list) to check the focus order to, from, and within the revealed content.
5. It may be helpful to launch ANDI: focusable elements and select tab order.
6. Backward focus order does not have to mirror the forward focus order. However, it must preserve the meaning and operability of the page.
7. For modal dialog boxes, keyboard focus navigating both forward and backward should remain within the modal dialog box until it is closed.

Note:

• Focus order does not necessarily need to be top to bottom, left to right.
• When the focus order does not affect meaning or operability, this test Does Not Apply. Example: A row of icons linking to social media may not need to be navigated in a particular order.
• ANDI tab order markup may be slightly different from actual keyboard tab order in certain browsers. Always use the results from keyboard tab order.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Using the keyboard, identify all elements that reveal additional content when receiving keyboard focus. Examples are custom tooltips, sub-menus, and other nonmodal popups.

EXCLUDE where the browser controls the visual presentation of the new content (such as the HTML title attribute as a tooltip).

Step 2: Test Content

1. Unless the content communicates an input error or does not obscure or replace other content, verify the new content is dismissible without the need to move keyboard focus. This is usually implemented with the Escape key.
2. Verify that after the content is dismissed, focus is located on the element that triggers the new content or the most logical location.
3. Verify that UNTIL the keyboard focus is moved elsewhere or the content is dismissed, the new content persists (remains visible).

NOTES:

• Modals are not included as they take focus away from the triggering element as the new content appears and this criterion assumes focus stays on the trigger.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Use the keyboard to navigate to keyboard-accessible interface elements (including drop-down menus, form fields, revealing/hiding content, tooltips, AND all interactive interface elements).

Step 2: Test Content

1. When the interface element receives focus, evaluate whether an unexpected change of context occurs, e.g., a new window is launched, or focus is moved to another interface element.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use the mouse or other pointing device to determine available functions provided by interactive elements (including drop-down menus, form fields, revealing/hiding content, tooltips, AND all interactive interface elements).
2. Use the mouse to identify instances where interactive elements provide information that is essential to understanding or operating the page content.

Step 2: Test Content

1. Use standard navigation keys (e.g., TAB, SHIFT + TAB, arrow keys, CTRL + TAB, etc.) to navigate through all keyboard focusable elements on the page.
2. Determine whether there are any instances where keyboard navigation becomes trapped:
3. Keyboard users are unable to move away from an element, e.g., using the Tab or arrow key
4. Keyboard access is restricted to a small section of the page with no way to navigate out of the “loop” to the rest of the page.
5. Keyboard users cannot navigate back out of continuous scrolling content (content that loads automatically when the user reaches the end), such as social media feeds.
6. If a keyboard trap is found:
   1. Attempt to exit the trap by pressing the ESC key.
   2. If that does not work, inspect any help (contextual help, or application help) and documentation for notification of available alternate keyboard commands (e.g., non-standard keyboard controls, access keys, hotkeys) to escape/avoid the keyboard trap.
   3. Determine whether the alternate command(s) work.

Note:

• In case of a keyboard trap, continue to test interactive elements after the trap by using the mouse to bypass the trap or refreshing the page and using the keyboard to navigate backwards through the page.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Use the mouse or other pointing device to determine available functions provided by interactive elements (including drop-down menus, form fields, revealing/hiding content, tooltips, AND all interactive interface elements).
2. Use the mouse to identify instances where interactive elements provide information that is essential to understanding or operating the page content.

Step 2: Test Content

1. Determine whether there are any instances where the timing of the keystrokes is required to activate the element, e.g., the speed at which a password keystrokes are typed is part of the password authentication.
2. If there is a timing dependent functionality, determine if there is another keyboard accessible method available on the page, which does not require specific timing.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

All page content.

Step 2: Test Content

1. Open screen reader
2. Move focus to web page window and press the CTRL key to silence the screen reader
3. Run the “Remove Page Focus” bookmarklet to ensure that the focus is not on an interactive element
4. Run the “Trigger Character Key Shortcuts” bookmarklet
5. Watch the page and listen to the screen reader output to see if any functionality is triggered. An alert will pop up to notify you when the test is complete
6. Verify for each such shortcut found:
   1. An option for disabling the shortcut is available (and the shortcut action can be achieved through another means) OR
   2. An option for remapping the shortcut that includes non-printing characters (e.g., Ctrl, Alt).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

For each page or view, identify all functionality activated with multipoint (two or more fingers or gestures required together) or path-based (where the path requires the user to make contact with at least one intermediate point before ending the gesture) gestures. EXCLUDE where such gestures are essential to functionality, such as drawing a signature on a mobile device. Notes:

• Dragging is not a pointer gesture because it is not path-based.
• This test does not apply to user agent (device, operating system, browser) or assistive technology gesture actions.

Step 2: Test Content

1. Identify any functionality that requires multipoint or path-based gestures to activate.
   1. Examples include Taps and swipes with two or more fingers, split taps, two finger pinch/zoom.
2. Verify for each such required gesture found, the same functionality can also be achieved using only a provided single pointer option (such as taps, double taps, single-click, double-click, click-and-hold, long presses or non-path based dragging actions).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. For each page or view, identify all functionality activated using a single pointer (one point of contact on the screen). This includes but is not limited to links, buttons, check boxes, radio buttons.

EXCLUDE where completing the function on the down-event is essential, such as a digital piano or where functions emulate a keyboard or with numeric keypads. Notes:

• Single pointer includes single and double taps and clicks, long presses, and path-based gestures including mouse clicks.
• This test does not apply to user agent or assistive technology pointer actions.

Step 2: Test Content

1. Activate the element and note what functionality happens.
2. Left click down on the element and hold the left click button.
3. While holding the left click button down, drag the mouse pointer away from the element and then release the button. If this is a drag and drop element, ensure that the button is NOT released in the drop target area.
4. For elements that have a single tap or long press as input, verify that the function did not happen. If it does, go to step 6.
5. For drag and drop elements, verify that the action is reverted (i.e., the element that was being dragged moves back to its original position).
6. If the function happens, verify that one of the following are true:
   1. There is a mechanism to abort the function before completion.
   2. There is a mechanism to undo the function after completion.
   3. Releasing the button (the “up event”) reverses what happened when the mouse button was clicked (the “down event”).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Using a mouse, identify all elements that reveal additional content when hovered over. Examples are custom tooltips, sub-menus, and other nonmodal popups.

EXCLUDE where the browser controls the visual presentation of the new content (such as the HTML title attribute as a tooltip).

Step 2: Test Content

1. Unless it communicates an input error or does not obscure or replace other content, verify the new content is dismissible without the need to move the pointer hover. This is usually implemented with the Escape key.
2. Verify that UNTIL hover is moved elsewhere, the new content persists (remains visible).
3. Verify that the mouse pointer can be moved over that same new content without the new content closing.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

On devices with motion sensors, identify any controls that are activated by device motion or user motion. Ask the developers if any motion actuation is included in the app. EXCLUDE: Where motion is essential, such as with a step counter and assistive technology based on head or eye movement tracking.

Step 2: Test Content

1. Verify for each such instance found:
   1. Standard keyboard accessible interface elements are provided as an alternate activation method. AND
   2. A mechanism exists to disable the motion actuation.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Conduct this test for all pages or views.

EXCLUDE pages or views or elements where the display orientation is essential to the functionality of a feature such as an application for scanning bank checks, piano keyboard simulator, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation. EXCLUDE documents and applications on devices that do not support changing the device orientation.

Step 2: Test Content

1. Ensure the selected page is at 100% zoom.
2. Resize the viewport to 1240px by 767px. 1240 represents landscape and 767 represents portrait orientation:
   1. Open Chrome DevTools (right click in the page and select “Inspect”)
   2. In the upper left corner of the DevTools screen select the “Toggle device toolbar” icon representing a landscape screen with a mobile device in front of it.
   3. In the toolbar that opens on the webpage, in the “Dimensions” dropdown, choose “Responsive” and enter 1240 and 767 into the size inputs to the right.
   4. To toggle between landscape orientation (1240px) and portrait orientation (767px), click the toggle icon to the right of the size input boxes. The two width values will trade positions in the input boxes. The first number is the current viewport width.
3. Observe the content present at the 1240px width. (Toggle the widths until 1240 shows in the left-most width input box.)
4. Toggle the orientation to the 767px width.
5. Ensure that all content and functionality present in landscape orientation is also available in portrait mode with no content disappearing, being cut off, or overlapping.
   1. Here “available” means either directly on the screen, or revealed by accessible controls, or accessible with direct links. An example of an accessible control is the hamburger icon replacing the main menu. This passes the test if the icon is an accessible control.

NOTES:

• The zoom level will change as the viewport width is toggled but has no impact on this test.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Launch ANDI: focusable elements (this is the default selection). This will highlight each focusable element (controls) on the page. Find all elements with text or text image labels.

Notes:

• The ANDI Output appears within the ANDI information banner when focus is on an interactive element.
• The ANDI Output shows the accessible name for the control.
• Controls include links, buttons, form inputs, menus.

Step 2: Test Content

1. For each focusable element with a text or text image label:

1. Put focus onto a highlighted element. Is there ANDI Output?
   1. If NO, this control FAILS. Make note of the specific element. Continue testing with next highlighted element.
   2. If Yes, continue:
2. Does the ANDI Output exactly match the visible text comprising the visible label, with no part of the label missing, the words in the same order, and with no additional text added in? For example, the visible text label says, “Preferred Nick Name” and the ANDI Output says, “Preferred Nick Name” and nothing else.
3. If Yes, the control PASSES the test. Continue testing with next highlighted element.
4. If NO, continue:
5. If the ANDI Output contains any additional words other than what is visible in the label, are those words at the end of the visible label and NOT at the beginning or interspersed between?
6. If YES, this element PASSES. For example, the visible text label says, “Preferred Nick Name” and the ANDI Output says, “Preferred Nick Name Here”
7. If NO, this element FAILS. The added words do not come at the end. For example, the visible text label says, “Preferred Nick Name” and the ANDI Output says, “Your Preferred Name Nick” or “Preferred Awesome Nick Name”

Notes:

• Icons in a text editor such as “B” for bold and “ABC” for spell checking should not use such visible text as the accessible name. The accessible name should state the function the icon triggers, such as “Bold” or “Spell check”. Likewise, a greater-than symbol or less-than symbol (> <) used as arrows should have an accessible name that describes the functionality of the arrow, such as “Play” or “Next” or “Previous”.
• Where punctuation is included at the end of a label’s text, such as a “:” or “…” it is not an error to not include the punctuation in the accessible name but in best practice, the name should match the label exactly, including punctuation.
• Letter case can be disregarded.
• Placeholder text is considered a text label if no other label is present.
• All focusable elements should be tested against this criteria, do not stop testing when the first “FAIL” is logged. Track which elements pass and which fail for the report.

If the visible label reads, “Preferred Nick Name”

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

All text on a page. EXCLUDE captions for synchronized media and images of text.

Step 2: Test Content

1. Use built-in browser zoom functions to resize the text to at least 200%.
2. If any of the content did not zoom using the built-in browser functions, determine whether there is a non-AT mechanism to resize page content to 200% of its original size, e.g., Operating System, platform, or other mechanism provided directly by the web page/application.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

1. Conduct this test for all pages or views.

EXCLUDE pages or views where the only content present requires two-dimensional layout for usage or meaning and there is nothing else on the page, such as menus, headers, or footers. EXCLUDE parts of content that require two-dimensional layout for usage or meaning and would suffer from being limited to 320px width such as some tables, maps, presentations, games, diagrams, graphics, or toolbars needed to edit content. NOTE: Although tables are exempt from the rule, the individual data cells are not unless they too contain content that requires two-dimensions for usage or meaning. EXCLUDE PDFs that contain form fields, as Acrobat does not support reflowing for files that contain them.

Step 2: Test Content

1. Ensure the selected page is at 100% zoom.
2. Resize the viewport to 1280px x 1024px using the Zoom Test bookmarklet, which will open the current page in a window of that size.
3. Set the page view to 400% zoom.
4. Verify that all content and functionality is still available and does not overlap or obscure other content, regardless of whether the user needs to scroll in both directions to access it all.
   1. Here “available” means either directly on the screen, or revealed by accessible controls, or accessible with direct links. An example of an accessible control is the hamburger icon replacing the main menu. This passes the test if the icon is an accessible control.
5. Verify that all content and functionality is reachable without having to scroll both vertically and horizontally.
   1. Scrolling down the page like users typically do at any zoom level counts as scrolling vertically, so this step is to verify users do not also have to use horizontal scrolling to access content.

NOTES:

• Zoom is controlled with CTRL + or – for Windows, Command – or + for Mac.
• To use the Zoom Test bookmarklet, drag the link you find on the DAC website to your bookmark bar. Click the new bookmark from the test page.
• A viewport 1280px x 1024px zoomed to 400% is equivalent to a viewport 320px wide zoomed to 100% or a 640px wide viewport zoomed to 200%. If preferred, either of these two alternate widths used with their associated zoom levels may also be used to test.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

All web page text content, except video captions embedded/burned directly into the video frames (open captions) and images of text (for this test, canvas implementations of text are considered to be images of text). EXCLUDE all non-web content (documents and applications).

Step 2: Test Content

1. Open the page in another browser window, so that you have a page for comparison.
2. On the testing page, start and enable captions for media that contain them, then pause the media.
3. Activate the “Text Spacing Test” bookmarklet.
4. Verify the following between the testing page and the comparison page:
   1. All text content, except for open captions and images of text, adapts to the new text spacing minimums.
   2. As the result of this test, no content is clipped, cut off, obscured, or overlapped.
   3. Any content that is truncated as the result of this test (including by, but not limited to, the use of ellipses) can be revealed by a keyboard accessible mechanism.
   4. All page functionality that worked prior to the test continues to work.

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify elements that have the same functionality within a set of web pages or application screens.

Step 2: Test Content

1. Launch ANDI: focusable elements.
2. Examine the ANDI Output for each identified element.
   1. Consistent text alternatives for interface elements that perform the same function are not always truly “identical.” This is acceptable if they follow a consistent format. For instance, in the use of a graphical arrow at the bottom of a web page that links to the next web page, the text alternative may be: “Go to page 4.” However, the same arrow image on the next page should then state “Go to page 5.”
   2. A single non-text-content-item may be used to serve different functions. In such cases, different text alternatives are necessary and should be used. Examples can be commonly found with the use of icons such as check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the web page. A check mark icon button may function as “approve”, “mark completed”, or “include”, to name a few, depending on the situation. Using “check mark” as the text alternative across all web pages does not help users understand the function of the button. Different text alternatives can be used when the same non-text content serves multiple functions

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify all navigational elements that are repeated on multiple pages within the website.

• Note: Navigational elements are any components that provide a user the ability to locate specific information or functionality across the website. These can be static or interactive elements, and groupings of components can also meet this definition.
• This includes, but is not limited to, global navigation menu, sidebar navigation menu, global search fields, skip navigation, and breadcrumbs.

Step 2: Test Content

1. Review multiple web pages of the web site to identify navigational components that are repeated on multiple pages. Do not initiate changes to the content.
2. Review the order of the navigational elements and compare it to the order on the other pages where they appear
   • Note: ANDI’s “tab order” feature under the focusable elements module may help evaluate the focus order of interactive interface elements. ANDI’s “reading order” feature under the structure module may also help evaluate the content order of both focusable and non-focusable elements.

Note:

• Same relative order is defined as same position relative to other items. Items are considered to be in the same relative order even if other items are inserted or removed from the original order. For example, expanding navigation menus may insert an additional level of detail or a secondary navigation section may be inserted into the reading order.
• This test applies to both the relative order of the element groups (i.e., a primary navigation menu in comparison to the site header) as well as the items within those groups (i.e., the links in a navigation menu).

Step 3: Evaluate and Record Results

Failure Matrix

Step 1: Identify Content

Identify visual content that:

• Starts moving, blinking, or scrolling without user activation (including videos, synchronized media, and scrolling text), AND
• Moves, blinks, or scrolls continuously for more than 5 seconds, AND
• Is not the only content on the page.

EXCLUDE content where the movement, blinking, or scrolling of the content, if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.

Step 2: Test Content

1. Determine if there is an evident mechanism for the user to pause, stop, or hide the content.
2. Activate the mechanism.
3. Verify that the mechanism performs its identified function.