MDAS-M v.0.9

Perceivability (P)

Content does not rely on the user having specific sensory perception in order to identify, recognize, understand, and/or use it.

1. Images

ID Test Name Test Condition Impacts
P.1.1 Meaningful images have equivalent text descriptions The accessible name and accessible description for a meaningful image provides an equivalent description of the image. Blind
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
Result Condition(s)
PASS If the following is TRUE:

  1. The ANDI Output contains the equivalent description for the meaningful image and/or refers to a description in the page content.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain meaningful images.
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.

Failure Condition MDAS Failure Priority
Text alternative does not completely convey image purpose or meaning or has minor inaccuracies 1.1.1 Non-text Content Moderate
Text alternative has major inaccuracies 1.1.1 Non-text Content Serious
Text alternative is a filename or placeholder text 1.1.1 Non-text Content Serious
Image does not have alt attribute 1.1.1 Non-text Content Serious
Complex images: long description is not provided, does not serve the same purpose as image, or does not present the same information 1.1.1 Non-text Content Serious
Functional images: text alternative misrepresents the function that occurs when image is interacted with; or does not have a text alternative 1.1.1 Non-text Content Critical

ID Test Name Test Condition Impacts
P.1.2 Decorative images are hidden from AT There is no accessible name and accessible description for a decorative image. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The ANDI Output for a decorative image is blank
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain decorative images.
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.

Failure Condition MDAS Failure Priority
Decorative image has a text alternative that may confuse a user 1.1.1 Non-text Content Moderate
Decorative image has a text alternative that will likely not confuse a user 1.1.1 Non-text Content Minor
Decorative image text alternative is the filename or placeholder 1.1.1 Non-text Content Serious
Decorative image does not have an alt attribute or aria-hidden=true 1.1.1 Non-text Content Serious

ID Test Name Test Condition Impacts
P.1.3 Meaningful CSS images have text alternatives The background image is not the only means used to convey important information Blind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The background image is decorative, OR
  2. The meaning of the background image is also available without the background image.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain background images.
Failure Matrix
Failure Condition MDAS Failure Priority
CSS background image conveys important information that is not available elsewhere on the page 1.1.1 Non-text Content Serious

ID Test Name Test Condition Impacts
P.1.4 No unnecessary images of text The image of text cannot be replaced by text or is customizable. Low vision
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The image of text cannot be replaced with text, OR
  2. The image of text can be visually customized.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain Images of Text
Failure Matrix
Failure Condition MDAS Failure Priority
Image of text could be replaced with real text 1.4.5 Images of Text Moderate

2. Multimedia

ID Test Name Test Condition Impacts
P.2.1 Pre-recorded audiovisual media have captions The synchronized media provides accurate captions for the audio content. Deaf, hard-of-hearing, cognitive, learning
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Captions are provided for all synchronized media content, AND
  2. Captions are accurate and include all dialogue and equivalents for non-dialogue audio information needed to understand the program content, including sound effects, e.g., music, laughter, speaker identification and location, AND
  3. All other relevant information in the video is clearly visible (not obstructed by captions) when captions are enabled.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain pre-recorded synchronized media.
Failure Matrix
Failure Condition MDAS Failure Priority
Captions are not provided for all synchronized media content 1.2.2 Captions (Prerecorded) Critical
Captions are not accurate and/or do not include all dialogue and equivalents for non-dialogue audio information needed to understand the program content, including sound effects, e.g., music, laughter, speaker identification and location 1.2.2 Captions (Prerecorded) Serious
All other relevant information in the video is not clearly visible (not obstructed by captions) when captions are enabled 1.2.2 Captions (Prerecorded) Moderate

ID Test Name Test Condition Impacts
P.2.2 Pre-recorded videos and animations have transcripts or audio descriptions The video or animation content is also available through an equivalent text or audio alternatives. Blind, deafblind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. A text or audio alternative is provided for all applicable pre-recorded audiovisual, video-only, and animated media content, AND
  2. The text or audio alternative is an accurate and complete representation of the video content in the media.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain pre-recorded audiovisual, video-only, or animated media content.
Failure Matrix
Failure Condition MDAS Failure Priority
A text or audio alternative is not provided for all applicable pre-recorded synchronized audiovisual media content 1.2.3 Audio Description or Media Alternative (Prerecorded) Serious
A text or audio alternative is not provided for all video-only content 1.2.1 Audio-only and Video-only (Prerecorded) Critical
The text or audio alternative is not an accurate and complete representation of the video content in the synchronized audiovisual media 1.2.3 Audio Description or Media Alternative (Prerecorded) Moderate
The text or audio alternative is not an accurate and complete representation of the video-only content 1.2.1 Audio-only and Video-only (Prerecorded) Serious

ID Test Name Test Condition Impacts
P.2.3 Pre-recorded audios have transcripts A text-based alternative is provided for audio-only content that provides an accurate and complete representation of the audio-only content. Deaf, hard-of-hearing, deafblind, cognitive, learning
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. A text-based transcript is provided for all audio-only content, AND
  2. The transcript is an accurate and complete representation of the audio-only content.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain pre-recorded audio-only content.
Failure Matrix
Failure Condition MDAS Failure Priority
A text-based transcript is not provided for all audio-only content 1.2.1 Audio-only and Video-only (Prerecorded) Critical
The transcript is not an accurate and complete representation of the audio-only content 1.2.1 Audio-only and Video-only (Prerecorded) Serious

ID Test Name Test Condition Impacts
P.2.4 Live audiovisual media have captions The live synchronized media provides accurate captions for the audio content. Deaf, hard-of-hearing, cognitive, learning
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Captions are provided for all live synchronized media, AND
  2. All captions are accurate, AND
  3. Any discrepancies between the captions and the audio output are minor in nature and do not significantly impact understanding (applicable to live captioning only).
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain live synchronized media.
Failure Matrix
Failure Condition MDAS Failure Priority
Captions are not provided for all live synchronized media 1.2.4 Captions (Live) Critical
All captions are not accurate 1.2.4 Captions (Live) Serious
Discrepancies between the captions and the audio output are not minor in nature and significantly impact understanding 1.2.4 Captions (Live) Serious

ID Test Name Test Condition Impacts
P.2.5 Media can be identified by text Time-based media have a descriptive text identification Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. All time-based media content has visible adjacent text that describes the media and/or gives it its title.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain time-based media.
Failure Matrix
Failure Condition MDAS Failure Priority
Time-based media content does not have visible adjacent text that describes the media and/or gives it its title 1.1.1 Non-text Content Minor

3. Contrast

ID Test Name Test Condition Impacts
P.3.1 Text has sufficient contrast The visual presentation of text and images of text have sufficient contrast. Low vision, colorblind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The contrast between the text and its background is equal to or greater than the minimum required contrast ratio identified in the ANDI Contrast Ratio output, OR
  2. If the text is an image of text, the contrast between the image of text and its background is equal to or greater than 4.5:1 as identified using the Colour Contrast Analyser.
FAIL ALL of the PASS conditions are FALSE
DNA The page has no visible text or images of text, is a logo, inactive (disabled) user interface element, decorative, or is contained within a picture that contains significant other visual content
Failure Matrix
Failure Condition MDAS Failure Priority
Large text (18 pt or 14 pt bold) has less than a 3:1 contrast ratio with its background 1.4.3 Contrast (Minimum) Serious
Regular text or image of text has less than a 4.5:1 contrast ratio with its background 1.4.3 Contrast (Minimum) Serious

ID Test Name Test Condition Impacts
P.3.2 Informational graphics have sufficient contrast Parts of graphics required to understand the content have a 3:1 contrast ratio against adjacent colors, except when a particular presentation of graphics is essential to the information being conveyed Low vision, colorblind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The graphic’s meaningful aspects have at least 3:1 contrast with its least contrasting adjacent colors, OR
  2. If that contrast ratio is less than 3:1, assuming that the area with the low contrast is invisible, the graphical object is still understandable
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain graphics, or the graphic is one of the following: a logo, a flag, a picture of real-life scenes such as photos of people or scenery, graphics that have corresponding text that communicates the same information, a screenshot, or a graphic that cannot be represented in any other way
Failure Matrix
Failure Condition MDAS Failure Priority
The graphic is not understandable because its meaningful aspects have less than a 3:1 contrast with their least contrasting adjacent color and the meaningful aspects need that contrast for understanding 1.4.11 Non-text Contrast Moderate

ID Test Name Test Condition Impacts
P.3.3 UI states have sufficient contrast Visual information required to identify user interface elements and their various states, except for inactive elements or where the appearance of the element is determined by the user agent and not modified by the author, have a contrast ratio of at least 3:1 against adjacent color(s). Low vision, colorblind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. For the default state of the element, the distinguishing indicator(s) have at least a 3:1 contrast ratio with at least one of its adjacent colors, AND
  2. For each element state where its visually appearance changes from the default state, the state’s distinguishing indicator(s) have at least a 3:1 contrast ratio with at least one of its adjacent colors
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain interactive UI elements, the UI element is disabled/inactive, and/or the UI element is using the browser/operating system provided styles
Failure Matrix
Failure Condition MDAS Failure Priority
The distinguishing indicator(s) of an element have less than a 3:1 contrast ratio with all of its adjacent colors for at least one state of an element 1.4.11 Non-text Contrast Moderate

4. Sensory Characteristics

ID Test Name Test Condition Impacts
P.4.1 Meaning is not communicated using color alone Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Colorblind, low vision
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. When color is used to convey information, indicate an action, prompt a response or distinguish a visual element, another visual, onscreen method is used to convey the information which does not use color.
FAIL ANY of the PASS conditions are FALSE
DNA No content relies on color to convey meaning
Failure Matrix
Failure Condition MDAS Failure Priority
Color is used to covey meaning without a secondary visual method to convey the information 1.4.1 Use of Color Serious

ID Test Name Test Condition Impacts
P.4.2 Instructions do not rely on only sensory characteristics for understanding Instructions provided for understanding and operating content do not rely solely on sensory characteristics of elements, such as shape, color, size, visual location, orientation, or sound. Blind, low vision, deaf, hard-of-hearing
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. When instructions use shape, color, size, location, orientation, or sound to convey meaning, another method that does not rely on sensory characteristics is provided.
FAIL ANY of the PASS conditions are FALSE
DNA The page’s instructions do not rely on sensory information
Failure Matrix
Failure Condition MDAS Failure Priority
Instructions provided for understanding or operating content relies solely on a sensory characteristic of an element 1.3.3 Sensory Characteristics Serious

5. CAPTCHA

ID Test Name Test Condition Impacts
P.5.1 CAPTCHAs have formats for both blind and Deaf users Alternative forms of CAPTCHA are provided and have text alternatives that identifies them and describes their purpose. Blind, Deaf
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The CAPTCHA has a format for users without vision, AND
  2. The CAPTCHA has a format for users without hearing, AND
  3. The CAPTCHA has a text alternative that identifies it and describes its purpose.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain CAPTCHAs.
Failure Matrix
Failure Condition MDAS Failure Priority
CAPTCHA does not have a format for users without vision 1.1.1 Non-text Content Critical
CAPTCHA does not have a format for users without hearing 1.1.1 Non-text Content Critical
CAPTCHA does not have a text alternative that identifies it and describes its purpose 1.1.1 Non-text Content Moderate

Structure (S)

Content is structured so that it is understandable in different forms of presentation.

1. Titles

ID Test Name Test Condition Impacts
S.1.1 Page has title that describes its topic or purpose A title is defined for the page that describes the topic or purpose of the content Blind, cognitive disabilities, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The page has a title AND
  2. The Page Title accurately identifies the contents or purpose of the web page, AND
  3. If the web page is part of a set of web pages, the Page Title accurately distinguishes the web page from other pages in the web site.
FAIL ANY of the PASS conditions are FALSE
Failure Matrix
Failure Condition MDAS Failure Priority
The page does not have a title 2.4.2 Page Titled Moderate
The page title does not accurately describe the topic or purpose of the page content 2.4.2 Page Titled Moderate
The page title does not accurately distinguish the page from other pages in the web site 2.4.2 Page Titled Minor

ID Test Name Test Condition Impacts
S.1.2 Frame title describes its contents Each <frame> has a title attribute that describes its content. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. All frames have a title attribute that describes its content.
FAIL ANY of the PASS conditions are FALSE
DNA No Frames are identified
Failure Matrix
Failure Condition MDAS Failure Priority
Frame title does not describe its contents 4.1.2 Name, Role, Value Moderate

ID Test Name Test Condition Impacts
S.1.3 Iframe name and description describes its contents The combination of accessible name and description for each <iframe> describes its content. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The ANDI Output for each <iframe> in the tab order sufficiently describes its content.
FAIL ANY of the PASS conditions are FALSE
DNA No iframes are identified or if the iframes are explicitly excluded from the tab order (i.e., the tabindex is a negative number)
Failure Matrix
Failure Condition MDAS Failure Priority
The iframe’s accessible name and/or description does not describe its contents 4.1.2 Name, Role, Value Moderate

2. Language

ID Test Name Test Condition Impacts
S.2.1 Page language is marked up properly The default human language of each web page can be programmatically determined. Blind, cognitive, learning, language
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The default primary language is correctly specified per IANA, AND
  2. The identified language in the lang attribute correctly matches the default human language for the page.
FAIL ANY of the PASS conditions are FALSE
Failure Matrix
Failure Condition MDAS Failure Priority
The default primary language of the page is not defined programmatically 3.1.1 Language of Page Serious
The programmatically defined language of the page is different than the language of the text of the page (e.g., the page is in English, but the page is marked up as Cantonese) 3.1.1 Language of Page Critical

ID Test Name Test Condition Impacts
S.2.2 Content in a different language than the rest of the page is marked up properly The human language for any content segment that differs from the default human language of the page can be programmatically determined. Blind, cognitive, learning, language
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The language for the content segment that differs from the primary default language of the page is correctly specified per IANA, AND
  2. The identified language in the lang attribute correctly matches the human language for the content segment
FAIL ANY of the PASS conditions are FALSE
DNA All of the content in the page is in the same human language.
Failure Matrix
Failure Condition MDAS Failure Priority
A sentence or more differs from the primary language of the page and is not correctly specified programmatically 3.1.2 Language of Parts Serious
A word or phrase differs from the primary language of the page and is not correctly specified programmatically 3.1.2 Language of Parts Moderate
The programmatically identified language of text that is different than the primary page language does not match the human language of that text (e.g., the text is in Spanish, but is coded as German) 3.1.2 Language of Parts Critical

3. Landmarks

ID Test Name Test Condition Impacts
S.3.1 Content contained within appropriate landmarks All perceivable content is located within a container with the appropriate landmark role and those containers have accessible names that describe their topic or purpose. Blind
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
Structural Section Element or Role Needs Accessible Name More than one?
Header <header> or role=banner Note: <header> does not have banner role if child of <article>, <aside>, <main>, <nav>, or <section>. Exclude <header>s that are children of these elements. Yes, if more than one No Note: Iframes, frames, and elements with application roles do not count and may have one banner landmark themselves
Nav <nav> or role=navigation Yes, if more than one Yes
Search role=search Yes, if more than one Yes
Main <main> or role=main Yes, if more than one No Note: Iframes, frames, and elements with application roles do not count and may have one main landmark themselves
Form <form> or role=form Yes Yes
Aside <aside> or role=complementary Yes, if more than one Yes
Footer <footer> or role=contentinfo Note: <footer> does not have contentinfo role if child of <article>, <aside>, <main>, <nav>, or <section>. Exclude <footer>s that are children of these elements. Yes, if more than one No Note: Iframes, frames, and elements with application roles do not count and may have one contentinfo landmark themselves
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. Each visual structural section is located within an element with the appropriate landmark role, AND
  2. If multiple instances of the same landmark role exist on the page, that they all have unique accessible names that describe their purpose, AND
  3. All forms have an accessible name that describes their purpose, AND
  4. The page only contains one instance of each of these landmarks: banner, main, contentinfo; except when page contains nested document and/or application roles, each one can have one.
FAIL ANY of the PASS conditions are FALSE
DNA The page structure is too simple for landmarks OR is a document or a desktop or mobile application.
Failure Matrix
Failure Condition MDAS Failure Priority
At least one visually apparent section is not located within the appropriate landmark. 1.3.1 Info and Relationships Moderate
Two or more instances of a landmark exist on a page and at least one does not have an accessible name that describes its purpose 4.1.2 Name, Role, Value Moderate
At least one form element exists on the page without an accessible name that describes its purpose 4.1.2 Name, Role, Value Minor
The page contains multiple instances of: banner, main, or contentinfo (additional instances not located inside of a document or application role) 4.1.2 Name, Role, Value Moderate

4. Headings

ID Test Name Test Condition Impacts
S.4.1 Headings describe topic or purpose Each heading describes the topic or purpose of its content. Language, cognitive, learning, blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The heading describes the topic or purpose of its content.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain headings.
Failure Matrix
Failure Condition MDAS Failure Priority
The heading does not describe the topic or purpose of its content 2.4.6 Headings and Labels Moderate

ID Test Name Test Condition Impacts
S.4.2 Headings are programmatically determinable Each visual heading is programmatically determinable. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Each visual heading is programmatically defined.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain visual headings.
Failure Matrix
Failure Condition MDAS Failure Priority
Visual heading is not programmatically defined 1.3.1 Info and Relationships Moderate

ID Test Name Test Condition Impacts
S.4.3 Semantic heading structure logically matches visual heading presentation Programmatic heading levels logically match the visual heading presentation within the heading structure. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Every programmatically identified heading level logically matches the visual heading presentation on the page, AND
  2. There is no heading level conflict.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain headings.
Failure Matrix
Failure Condition MDAS Failure Priority
Programmatic heading structure does not logically match the visual heading presentation 1.3.1 Info and Relationships Serious

5. Lists

ID Test Name Test Condition Impacts
S.4.1 Lists are of the proper type All visually apparent lists are programmatically identified according to their type. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. All content that has the visual appearance of a list is defined programmatically as a list, according to the type of list.
    1. An unordered list (with or without bullets) is marked as an unordered list (ul).
    2. An ordered list is marked as an ordered list (ol).
    3. Terms and their descriptions that are presented in the form of a list are marked as a description list (dl) AND
  2. All programmatic list relationships, including nesting and hierarchies, are consistent with the list relationships presented visually.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain visually apparent lists
Failure Matrix
Failure Condition MDAS Failure Priority
Primary content that has a visual appearance of a list is not defined programmatically as a list 1.3.1 Info and Relationships Moderate
Secondary content that has a visual appearance of a list is not defined programmatically as a list 1.3.1 Info and Relationships Minor
Programmatic list relationship is not consistent with the list relationships presented visually 1.3.1 Info and Relationships Moderate

6. Tables

ID Test Name Test Condition Impacts
S.6.1 Data tables are identified programmatically Each data table has programmatic markup to identify it as a table. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. It is possible to navigate in ANDI: tables to each data table using the ANDI Analyze Previous/Next Table buttons, AND
  2. The data table DOES NOT have an ARIA role=”presentation” assigned, AND
  3. The data table DOES NOT have any ANDI Table alerts for incorrect use of ARIA table attributes.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain data tables
Failure Matrix
Failure Condition MDAS Failure Priority
Content that serves as a data table is not marked up as a data table or is marked up incorrectly 1.3.1 Info and Relationships Serious
Data table has a role of presentation or none assigned 4.1.2 Name, Role, Value Serious
ARIA table attributes are used incorrectly on a data table 4.1.2 Name, Role, Value Serious

ID Test Name Test Condition Impacts
S.6.2 Data table cells are associated with relevant headers All data cells are programmatically associated with relevant headers. Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Table column headers are associated with each of the data cells in the column.
  2. Table row headers are associated with each of the data cells in the row.
  3. If sub headers are present for either columns or rows, they are also associated with affected data cells.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain data tables OR the data tables do not require row or column headings for understanding
Failure Matrix
Failure Condition MDAS Failure Priority
Table column headers are not associated with each of the data cells in its column 1.3.1 Info and Relationships Serious
Table row headers are not associated with each of the data cells in its row 1.3.1 Info and Relationships Serious
Table sub headers are not associated with affected data cells 1.3.1 Info and Relationships Serious

ID Test Name Test Condition Impacts
S.6.3 Layout tables do not have semantic meaning The layout table DOES NOT designate the layout table using ARIA role=”table” AND DOES NOT include table header structure and relationship elements and/or associated attributes. Blind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The <table> element includes the attribute role=”presentation”, OR
  2. BOTH of the following are TRUE:
    1. The layout DOES NOT use role=”table” or any associated ARIA table attributes (e.g., role=”row”, role=”columnheader”), AND
    2. The layout DOES NOT include table structure and relationship elements or associated attributes (e.g., <th>, scope=”row”)
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain layout tables
Failure Matrix
Failure Condition MDAS Failure Priority
Layout table and/or its elements have semantic meaning 1.3.1 Info and Relationships Serious

7. Reading Order

ID Test Name Test Condition Impacts
S.7.1 Content order and meaning preserved without CSS positioning The reading order of the content (in context) is correct, and the meaning of the content (in context) is preserved without CSS positioning. Blind, language
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The sequence and meaning of the content (in context) is understandable without CSS positioning.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain content positioned using CSS
Failure Matrix
Failure Condition MDAS Failure Priority
Content sequence and/or meaning is not understandable without CSS positioning 1.3.2 Meaningful Sequence Moderate

8. Parsing

ID Test Name Test Condition Impacts
S.8.1 Element IDs are unique Element IDs are unique Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. No duplicate IDs are reported for visible and/or interactive elements
FAIL ANY of the PASS conditions are FALSE
DNA The page is not web content
Failure Matrix
Failure Condition MDAS Failure Priority
Page has duplicate IDs on visible and/or interactive elements 4.1.1 Parsing Serious

User Interface Elements (E)

User Interface Elements are understandable and operate as expected.

1. Form Labels, Instructions, Description, and Purpose

ID Test Name Test Condition Impacts
E.1.1 Form fields have visible labels or instructions that describe their purpose Visual labels or instructions are provided for form inputs that describe their purpose. Cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Visual labels or instructions are provided for each form input AND
  2. The visual labels or instructions describe the topic or purpose of their associated form input AND
  3. Labels are still visible when form input has focus.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain form input or all form inputs are disabled.
Failure Matrix
Failure Condition MDAS Failure Priority
Visual label or instructions not provided for form input 3.3.2 Labels or Instructions Serious
Visual label or instructions do not describe the form input’s topic or purpose 2.4.6 Headings and Labels Serious
Label does not remain visible when form input has focus 3.3.2 Labels or Instructions Moderate

ID Test Name Test Condition Impacts
E.1.2 Form fields are described programmatically The combination of the accessible name, accessible description, and other programmatic associations (e.g., table column and/or row associations) describes each input field and includes all relevant instructions and cues (textual and graphical). Blind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The ANDI Output includes all relevant instructions and cues for the form element, including when fields are required, OR
  2. A combination of ANDI Output AND other programmatic association includes all relevant instructions and cues, OR
  3. The combination of the programmatically determined button context and the ANDI Output provide adequate description of each buttons’ purpose.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain form elements
Failure Matrix
Failure Condition MDAS Failure Priority
The combination of the accessible name, accessible description, and other programmatic associations does not describe and/or include all relevant instructions or cues for a form field 1.3.1 Info and Relationships Serious

ID Test Name Test Condition Impacts
E.1.3 Purpose of form fields that collect user information programmed On web page form field inputs that collect information about the user, the purpose of each input is programmatically determinable Cognitive disabilities, motor disabilities
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
Data Type Autocomplete Value
Full name name
Prefix or title (e.g., “Mr.”, “Ms.”, “Dr.”) honorific-prefix
First name given-name
Middle name additional-name
Last Name family-name
Suffix (e.g., “Jr.”, “B.Sc.”, “MBASW”, “II”) honorific-suffix
Nickname, screen name, handle: a typically short name used instead of the full name nickname
Job title organization-title
Username username
A new password new-password
The current password for the account identified by the username field (e.g., when logging in) current-password
Company name corresponding to the person, address, or contact information in the other fields associated with this field organization
Street address (multiple lines, newlines preserved) street-address
Street address (one line per field, line 1) address-line-1
Street address (one line per field, line 2) address-line-2
Street address (one line per field, line 3) address-line-3
The most fine-grained administrative level, in addresses with four administrative levels address-level4
The third administrative level, in addresses with three or more administrative levels address-level3
The second administrative level, in addresses with two or more administrative levels; in the countries with two administrative levels, this would typically be the city, town, village, or other locality within which the relevant street address is found address-level2
The broadest administrative level in the address, i.e., the province within which the locality is found; for example, in the US, this would be the state; in Switzerland it would be the canton; in the UK, the post town address-level1
Country code country
Country name country-name
Postal code, post code, ZIP code, CEDEX code (if CEDEX, append “CEDEX”, and the dissement, if relevant, to the address-level2 field) postal-code
Full name as given on the payment instrument cc-name
First name as given on the payment instrument cc-given-name
Middle name as given on the payment instrument cc-additional-name
Last name as given on the payment instrument cc-family-name
Code identifying the payment instrument (e.g., the credit card number) cc-number
Expiration date of the payment instrument cc-exp
Month component of the expiration date of the payment instrument cc-exp-month
Year component of the expiration date of the payment instrument cc-exp-year
Security code for the payment instrument (also known as the card security code (CSC), card validation code (CVC), card verification value (CVV), signature panel code (SPC), credit card ID (CCID), etc.) cc-csc
Type of payment instrument cc-type
The currency that the user would prefer the transaction to use transaction-currency
The amount that the user would like for the transaction (e.g., when entering a bid or sale price) transaction-amount
Preferred language language
Birthday bday
Day component of birthday bday-day
Month component of birthday bday-month
Year component of birthday bday-year
Gender identity sex
Home page or other web page corresponding to the company, person, address, or contact information in the other fields associated with this field url
Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field photo
Full telephone number, including country code tel
Country code component of the telephone number tel-country-code
Telephone number without the country code component, with a country-internal prefix applied if applicable tel-national
Area code component of the telephone number, with a country-internal prefix applied if applicable tel-area-code
Telephone number without the country code and area code components tel-local
First part of the component of the telephone number that follows the area code, when that component is split into two components tel-local-prefix
Second part of the component of the telephone number that follows the area code, when that component is split into two components tel-local-suffix
Telephone number internal extension code tel-extension
Email address email
URL representing an instant messaging protocol endpoint (for example, “aim:goim?screenname=example” or “xmpp:fred@example.net”) impp
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. For form fields that collect information about the user that are identified as data types in the input purposes table, the field’s autocomplete attribute has the value that corresponds to the data type.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain form fields that collect information about the user, content is an application, content is a document.
Failure Matrix
Failure Condition MDAS Failure Priority
The autocomplete attribute of a form field that collects user information is not defined or is defined as “off” or “on” 1.3.5 Identify Input Purpose Moderate
The autocomplete attribute of a form field that collects user information has an improper value (i.e., the field collects the user’s full birthdate, but the value is ‘bday-day’ or ‘country-name’) 1.3.5 Identify Input Purpose Serious
A form field that does NOT collect user information (i.e., “Mother’s last name”) has an autocomplete attribute that is intended for user information (i.e., ‘last-name’) 1.3.5 Identify Input Purpose Serious

ID Test Name Test Condition Impacts
E.1.4 Related form elements are semantically grouped and labeled Form elements that are logically related are grouped semantically and the group is labeled. Blind
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. ANDI Accessibility Components list includes an identical legend or group attribute for each field in a non-radio button logically related groupings of fields, OR
  2. For groupings of radio buttons, the ANDI Accessibility Components list includes a radiogroup attribute that is identical for each field in the group.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain form fields or the form fields are not logically related.
Failure Matrix
Failure Condition MDAS Failure Priority
Logically related form fields are not programmatically grouped and labeled 1.3.1 Info and Relationships Serious

2. Form Errors

ID Test Name Test Condition Impacts
E.2.1 Form errors described in text, associated with field, and provide correction guidance The item in error is identified in text, sufficiently described to the user in text, is programmatically associated with the field, and guidance for correcting errors is provided when appropriate. Blind, cognitive, learning, language
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The form field with the error is identified in text AND
  2. The error message is programmatically associated with the form field that has the error AND
  3. ONE of the following error suggestion requirements/exceptions are TRUE
    1. The error text includes suggestions for correction, OR
    2. The form field error cannot provide suggestions because it would jeopardize the security or purpose of the content (e.g., “this email exists in the system” or “the answer to this test question is X”), OR
    3. ALL of the following are TRUE
      1. The form field input is not mandatory/required, AND
      2. The form field input is not required to be in a specific data format (e.g., email@example.com or 614-987-6543), AND
      3. The form field input is not required to be one of a limited set of values (e.g., user inputs “12” in a month field that only accepts month names like “December”)
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain forms with validation.
Failure Matrix
Failure Condition MDAS Failure Priority
Field error is not identified in text 3.3.1 Error Identification Serious
Error message is not programmatically associated with the form field with the error 1.3.1 Info and Relationships Moderate
Error text does not provide suggestions to resolve error 3.3.3 Error Suggestion Serious

ID Test Name Test Condition Impacts
E.2.2 Submission of form errors is prevented The web page allows the user to check, reverse, and/or confirm submission. Blind, Cognitive, Learning
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
Result Condition(s)
PASS ANY of the following are TRUE

  1. The user can reverse the submission, OR
  2. The user is presented with an option to review, confirm, and correct information before finalizing the submission, OR
  3. The page checks data for input errors and allows the user an opportunity to correct any errors.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain content that submits user form entries that result in or causes legal commitments or financial transactions, modify or deletes user-controllable data in a data storage system, or submits user test responses.
Failure Matrix
Failure Condition MDAS Failure Priority
The user cannot reverse the submission, AND The user is not presented with an option to review, confirm, and correct information before finalizing the submission, AND The page does not check data for input errors and allows the user an opportunity to correct any errors. 3.3.4 Error Prevention (Legal, Financial, Data) Serious

3. Form Interaction

ID Test Name Test Condition Impacts
E.3.1 Changing form field value does not change context Changing field values/selections (e.g., entering data in a text field, changing a radio button selection) does NOT initiate an unexpected change of context. Blind, low vision, cognitive disabilities, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Changing the value of a form element does not initiate an unexpected context change.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain form elements.
Failure Matrix
Failure Condition MDAS Failure Priority
Changing the value of a form element initiates an unexpected context change 3.2.2 On Input Serious

4. Custom Input Elements

ID Test Name Test Condition Impacts
E.4.1 Switch Inputs Switch inputs are keyboard accessible and have appropriate names, roles, and values Blind, motor disabilities
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. Example of a switch input
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The switch can be toggled on and off using the Space key AND
  2. The element that serves as the switch toggle has the role of switch AND
  3. If the switch is not a checkbox input, it has an aria-checked of false in the “off” state AND
  4. If the switch is not a checkbox input, it has an aria-checked of true in the “on” state
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain switches.
Failure Matrix
Failure Condition MDAS Failure Priority
The switch cannot be toggled on and off using the Space key 2.1.1 Keyboard Critical
The switch toggle does not have the role of switch 4.1.2 Name, Role, Value Serious
The current state of the switch (on or off) is not reflected programmatically (aria-checked) or is reflected incorrectly (state is off when visually it’s on and vice versa) 4.1.2 Name, Role, Value Critical

5. Links

ID Test Name Test Condition Impacts
E.5.1 Link purpose is determinable in context The purpose of each link can be determined from any combination of the link text, accessible name, accessible description, and/or programmatically determined link context. Blind, motor disabilities, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The combination of the programmatically determined link context and the ANDI Output provide adequate description of the link’s purpose.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain links.
Failure Matrix
Failure Condition MDAS Failure Priority
The link’s purpose cannot be determined by any combination of the link text, accessible name, accessible description, and/or programmatically determined link context 2.4.4 Link Purpose (In Context) Serious

6. Buttons

ID Test Name Test Condition Impacts
E.6.1 Button label describes topic or purpose The label of the button (both text and non-text) describes the button’s topic or purpose Cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The visual label of the button describes its topic, purpose, function, or associated content.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain buttons.
Failure Matrix
Failure Condition MDAS Failure Priority
The button’s visual label does not describe its topic or purpose 2.4.6 Headings and Labels Serious

ID Test Name Test Condition Impacts
E.6.2 Button name describes its purpose The accessible name of the button describes its purpose Blind
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The accessible name of the button describes its topic, purpose, function, or associated content.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain buttons.
Failure Matrix
Failure Condition MDAS Failure Priority
The button’s accessible does not describe its purpose 1.1.1 Non-text Content Serious

ID Test Name Test Condition Impacts
E.6.3 Non-native and Toggle Buttons All buttons can be activated using the Space and Enter keys and maintain the proper roles, states, and programmatic associations. Blind, motor disabilities
Step 1: Identify Content

Identify all interactive elements on the page that, when activated, trigger an action or event. 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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The button receives keyboard focus AND
  2. The button can be activated by both the Space key and Enter key AND
  3. The button has a role of button AND
  4. If the button is a toggle (two-state, on and off) button, its current pressed state is reflected programmatically
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain custom buttons or toggle buttons.
Failure Matrix
Failure Condition MDAS Failure Priority
The button does not receive keyboard focus 2.1.1 Keyboard Critical
The button cannot be activated by the Enter and/or Space key 2.1.1 Keyboard Critical
The button does not have a role of button 4.1.2 Name, Role, Value Serious
The state of the toggle button is not reflected programmatically (aria-pressed) 4.1.2 Name, Role, Value Critical

7. Sectioning Elements

ID Test Name Test Condition Impacts
E.7.1 Accordions Accordions are keyboard accessible, and its elements (header and panel) have the appropriate roles, states, and programmatic relationships Blind
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). Screenshot of an accordion element
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The accordion receives keyboard focus AND
  2. The accordion can be expanded and collapsed via keyboard AND
  3. The According Header
    1. Has a role of button AND
    2. Has an aria-expanded of true when accordion is expanded AND
    3. Has an aria-expanded of false when the accordion is collapsed AND
    4. Has an aria-controls of the Accordion Panel element AND
  4. The Accordion Panel
    1. Has a role of region AND
    2. Has an aria-labelledby of the Accordion Header element.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain accordions.
Failure Matrix
Failure Condition MDAS Failure Priority
The accordion does not receive keyboard focus 2.1.1 Keyboard Critical
The accordion cannot be expanded and/or collapsed with the keyboard 2.1.1 Keyboard Critical
The Accordion Header does not have a role of button 4.1.2 Name, Role, Value Moderate
The Accordion Header does not communicate its collapsed/expanded state using aria-expanded 4.1.2 Name, Role, Value Serious
The Accordion Header is not programmatically associated with the Accordion Panel (aria-controls) 1.3.1 Info and Relationships Minor
The Accordion Panel does not have a role of region 4.1.2 Name, Role, Value Minor
The Accordion Panel is not labeled by the Accordion Header element 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value Minor

ID Test Name Test Condition Impacts
E.7.2 Tabs Tabbed Interfaces are keyboard accessible, operate via keyboard in an expected manner, and they and their components have appropriate names, roles, and programmatic associations Blind, motor disabilities
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. Screenshot of tabbed interface from BUX 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.

Component Name Description
Tabbed Interface The set of Tab elements and their associated Tab Panels
Tab List The grouping of Tabs within a tablist element
Tab A button in the Tab List that serves as the label for a Tab Panel and, when activated, displays the panel
Tab Panel Element that contains the content associated with the Tab
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The active Tab receives keyboard focus, AND
  2. Pressing the Tab keyboard key moves focus to either the associated Tab Panel OR an interactive element within the Tab Panel, AND
  3. Pressing the right arrow key moves keyboard focus sequentially to Tabs to the right of the active Tab AND wraps around to the beginning when focus reaches the end of the Tab List, AND
  4. Pressing the left arrow key moves keyboard focus sequentially to the Tabs to the left of the active Tab AND wraps around to the end when focus reaches the beginning of the Tab List, AND
  5. Associated Tab Panels are displayed when either the Tab receives focus OR when the Enter key is pressed on the focused Tab, AND
  6. The Tab List has a role of “tablist”, AND
  7. The Tab List has a name that is descriptive of the Tabbed Interface’s purpose, AND
  8. If the Tabbed Interface has a visible label or header, the name is the same as the visible label or header, AND
  9. The Tab List aria-orientation matches the visual presentation of the Tab List, AND
  10. Each Tab has a role of “tab,” AND
  11. Each Tab has a name that is descriptive of its Tab Panel’s purpose, AND
  12. The active Tab has an aria-selected of “true,” AND
  13. Each Tab’s aria-controls is its associated Tab Panel element, AND
  14. Each Tab Panel has a role of “tabpanel,” AND
  15. Each Tab Panel aria-labelledby is its associated Tab.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain tabbed interfaces.
Failure Matrix
Failure Condition MDAS Failure Priority
The active Tab does not receive keyboard focus 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Critical
Pressing the Tab keyboard key moves focus to the next Tab instead of the Tab Panel or an interactive element within the Tab Panel 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Moderate
Pressing the Tab keyboard key does not move focus to the Tab Panel or an interactive element within the Tab Panel 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Serious
The Tab List cannot be navigated using the right and left arrow keys 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Serious
Tab Panels are not displayed when their associated Tab receives focus OR the associated Tab does not activate them when using the Enter key 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Critical
The Tab List does not have a role of tablist 4.1.2 Name, Role, Value Serious
The Tab List does not have a name that is descriptive of the Tabbed Interface’s purpose 4.1.2 Name, Role, Value Moderate
The Tab List name is different than the visible label or header 2.5.3 Label in Name Moderate
The Tab List aria-orientation value does not match its visual presentation 4.1.2 Name, Role, Value Moderate
One or more Tabs do not have a role of tab 4.1.2 Name, Role, Value Serious
One or more Tabs do not have a name that is descriptive of the Tab Panel’s purpose 4.1.2 Name, Role, Value Serious
The active Tab does not have an aria-selected of true 4.1.2 Name, Role, Value Serious
One or more Tabs do not have an aria-controls that is associated with its Tab Panel element 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value Moderate
One or more of the Tab Panels do not have a role of tabpanel 4.1.2 Name, Role, Value Serious
One or more Tab Panels do not have aria-labelledby of its associated Tab element 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value Moderate

ID Test Name Test Condition Impacts
E.7.3 Carousels All visually apparent carousels are programmatically identified, have an accessible name, and can be accessed and executed using only the keyboard. Blind, motor disabilities
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.

Component Name Description
Carousel The entire element, containing the slides, next and previous slide controls, rotation control button, and slide picker.
Carousel Container The outermost DOM element that contains all of the Carousel elements. Important: Be careful to not confuse this with elements further up the DOM tree, for example, a wrapper div one level above the Carousel in the tree that is used for style or layout purposes.
Rotation Control Button The button that stops and starts the automatic rotation of the Carousel.
Slide A group that contains an image and typically also contains a heading, preview text, and/or call to action (CTA) link.
Slides Container The DOM element that contains all of the Slides in the Carousel.
Next Slide Control An interactive element, often styled as an arrow, that displays the next slide in the rotation sequence.
Previous Slide Control An interactive element, often styled as an arrow, that displays the previous slide in the rotation sequence.
Slide Picker A group of elements, often styled as small dots, that enable the user to pick a specific slide in the rotation sequence to display.
Slide Picker Control An interactive element, often styled as a small dot, that picks a specific slide in the rotation sequence to display. Slide Pickers are made up of multiple Slide Picker Controls.
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
Result Condition(s)
PASS If ALL of the following are TRUE:

  1. The Carousel Container:
    1. Has a role of region AND
    2. Has a name that is descriptive of the Carousel’s purpose AND
    3. If the Carousel has a visible label, the name is the same as the visible label AND
    4. Has a roledescription of carousel, AND
  2. If the Carousel rotates automatically:
    1. Hovering the mouse pointer over the Carousel content pauses the automatic rotation AND
    2. The automatic rotation pauses when every interactive element in the Carousel receives keyboard focus AND
    3. The automatic rotation resumes when keyboard focus is moved outside of the Carousel AND
    4. A Rotation Control Button exists to start and stop the Carousel AND
    5. The Rotation Control Button is always visible AND
    6. The Rotation Control Button is the first child element of the Carousel container AND
    7. The Rotation Control Button contains a visible label consisting of a play/pause icon, play/pause text, or a combination of both AND
    8. The Rotation Control Button has a role of button AND
    9. The Rotation Control Button has a name like “Stop Automatic Slide Show” when the Carousel is rotating AND
    10. The Rotation Control Button has a name like “Start Automatic Slide Show” when the Carousel is not rotating AND
    11. The Slides Container IS NOT an aria-live region while the slides are rotating AND
    12. When the Carousel is not rotating, the Carousel starts rotating when the Rotation Control Button is activated using the keyboard AND
    13. When the Carousel is rotating, the Carousel stops rotating when the Rotation Control Button is activated using the keyboard AND
  3. The Slides Container is a polite aria-live region when the Carousel is not rotating automatically AND
  4. If the Carousel has a Slide Picker:
    1. The first Slide Picker Control in the Slide Picker receives keyboard focus AND
    2. Pressing the tab key moves focus out of the Slide Picker and NOT to the next Slide Picker Control AND
    3. Pressing the right arrow key moves focus to the subsequent Slide Picker Controls and also displays the subsequent Slides AND
    4. Pressing the left arrow key moves focus to the previous Slide Picker Controls and also displays the previous Slides AND
    5. The Slide Picker has a name of Slides AND
    6. The Slide Picker has a role of tablist AND
    7. Each Slide Picker Control has a name that reflects the position of the Slide associated with the control, i.e., Slide 1, AND
    8. The active Slide Picker Control has an aria-selected of true AND
    9. Inactive Slide Picker Controls DO NOT have an aria-selected of true AND
    10. Each Slide Picker Control is programmatically associated with its corresponding Slide via aria-controls AND
  5. The Slides:
    1. Have a role of group if the Carousel DOES NOT have a Slide Picker AND
    2. Have a role of tabpanel if the Carousel has a Slide Picker AND
    3. Have a name that includes the position number of the slide in the set and the total number of slides, i.e., 1 of 6, AND
    4. Have a roledescription of slide AND
  6. The Next Slide Control:
    1. Contains a visible label consisting of a right-pointing icon, the word “Next” or a combination of both AND
    2. When activated using the keyboard, the Carousel moves to the next slide AND keyboard focus remains on the Next Slide Control AND
    3. Has a role of button AND
    4. Has a name of Next Slide AND
    5. Is programmatically associated with the Slides Container AND
  7. The Previous Slide Control:
    1. Contains a visible label consisting of a left-pointing icon, the word “Previous” or a combination of both AND
    2. When activated using the keyboard, the Carousel moves to the previous slide AND keyboard focus remains on the Previous Slide Control AND
    3. Has a role of button AND
    4. Has a name of Previous Slide AND
    5. Is programmatically associated with the Slides Container
FAIL If ANY PASS condition is FALSE
DNA If there are no carousels on the page.
Failure Matrix
Failure Condition MDAS Failure Priority
The Carousel Container does not have a role of region 4.1.2 Name, Role, Value Minor
The Carousel Container does not have a name that is descriptive of the Carousel’s purpose 4.1.2 Name, Role, Value Moderate
The Carousel Container’s name is not the same as the visible label 2.5.3 Label in Name Minor
The Carousel Container does not have a roledescription of carousel 4.1.2 Name, Role, Value Moderate
Autorotating Carousels: Hovering mouse pointer over Carousel does not pause auto rotation 2.2.2 Pause, Stop, Hide Serious
Autorotating Carousels: Auto rotation does not pause when interactive elements receive focus 2.2.2 Pause, Stop, Hide Serious
Autorotating Carousels: Auto rotation does not resume when focus is moved out of Carousel Best Practice Minor
Autorotating Carousels: Rotation Control Button does not exist 2.2.2 Pause, Stop, Hide Critical
Autorotating Carousels: Rotation Control Button not first child of Carousel 1.3.1 Info and Relationships Minor
Autorotating Carousels: Rotation Control Button label does not reflect button purpose 2.4.6 Headings and Labels Moderate
Autorotating Carousels: Rotation Control Button does not have role of button 4.1.2 Name, Role, Value Serious
Autorotating Carousels: Rotation Control Button does not have accessible name that describes purpose (like “Stop Automatic Slide Show” when Carousel is rotating and “Stop Automatic Slide Show” when Carousel is not rotating) 4.1.2 Name, Role, Value Serious
Autorotating Carousels: Slides Container is an aria-live region when slides are rotating 4.1.3 Status Messages Critical
Autorotating Carousels: Rotation Control Button does not start and/or stop the rotation using the keyboard 2.1.1 Keyboard Critical
Slides Container is not a polite aria-live region when the Carousel is not rotating automatically 4.1.3 Status Messages Minor
Carousels with Slide Pickers: Slide Picker Controls do not operate with keyboard 2.1.1 Keyboard Critical
Carousels with Slide Pickers: Each Slide Picker Control receives keyboard focus with tab key ARIA 1.1 2.3 Managing Focus Minor (Moderate if 6+ Slides)
Carousels with Slide Pickers: Slide Picker does not have a name of “Slides” 4.1.2 Name, Role, Value Minor
Carousels with Slide Pickers: Slide Picker does not have a role of tablist 4.1.2 Name, Role, Value Moderate
Carousels with Slide Pickers: At least one Slide Picker Control does not have a name that reflects the position of the Slide associated with the control 4.1.2 Name, Role, Value Minor
Carousels with Slide Pickers: Active Slide Picker Control does not have an aria-selected of true 4.1.2 Name, Role, Value Minor
Carousels with Slide Pickers: Inactive Slide Picker has an aria-selected of true 4.1.2 Name, Role, Value Serious
Carousels with Slide Pickers: At least one Slide Picker Control not programmatically associated with its corresponding Slide via aria-controls 1.3.1 Info and Relationships Minor
Carousels with Slide Pickers: At least one Slide does not have a role of tabpanel 4.1.2 Name, Role, Value Moderate
Carousels without Slide Pickers: At least one Slide does not have a role of group 4.1.2 Name, Role, Value Moderate
At least one Slide does not have a name that includes the position number of the slide in the set and the total number of slides 4.1.2 Name, Role, Value Moderate
At least one Slide does not have a roledescription of slide 4.1.2 Name, Role, Value Minor
The Previous and/or Next Slide Control do not contain a visible label describing their purpose 2.4.6 Headings and Labels Moderate
The Previous and/or Next Slide Control do not operate as expected with the keyboard 2.1.1 Keyboard Critical
The Previous and/or Next Slide Control do not have a role of button 4.1.2 Name, Role, Value Serious
The Previous and/or Next Slide Control do not have a name that describes their purpose 4.1.2 Name, Role, Value Serious
The Previous and/or Next Slide Control is not programmatically associated with the Slides Container 1.3.1 Info and Relationships Minor

8. Navigation Elements

ID Test Name Test Condition Impacts
E.8.1 Navigation Menus Navigation menus properly identify their purpose to screen readers and are completely navigable by keyboard and mobile devices. Blind, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Navigation menu has a role of navigation, AND
  2. If multiple navigation menus appear on a page, the navigation menu has a name that describes its purpose, AND
  3. Navigation menu follows an expected keyboard pattern
    1. Navigation items and subitems can be navigated between using the Tab key AND/OR
    2. Navigation items and subitems can be navigated between using the arrow keys AND there are visual and screen reader instructions that describe this interaction pattern if the Tab key does not also navigate between items. AND
  4. Submenus are opened by one of the following methods
    1. When the menu item receives keyboard focus, OR
    2. When the Enter and Space keys are pressed on the menu item AND the menu item IS NOT a link that navigates to a new page when clicked on, OR
    3. A button immediately following the menu item opens the submenu with the Enter and Space keys AND has an accessible name that describes its purpose, AND
  5. Submenus close when the Escape key is pressed AND focus moves back to the menu item that opened the submenu, AND
  6. Screen readers announce when submenus are opened and closed AND
  7. If an active page is called out visually, screen readers announce it as the active page when it receives screen reader focus AND
  8. Navigation is fully operable using a mobile screen reader swipe interface.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain navigation menus.
Failure Matrix
Failure Condition MDAS Failure Priority
Navigation menu does not have a role of navigation 4.1.2 Name, Role, Value Serious
Navigation menu is one of multiple navigation menus on page and it does not have an accessible name that describes its purpose 4.1.2 Name, Role, Value Moderate
Navigation menu does not follow an expected keyboard pattern 2.1.1 Keyboard, Fundamental Keyboard Navigation Conventions for ARIA widgets Critical
Submenus are not opened by a keyboard accessible mechanism 2.1.1 Keyboard Critical
Menu item opens a submenu using the Enter and Space keys but is also a link 2.1.1 Keyboard; 4.1.2 Name, Role, Value Critical
Submenu trigger button does not have an accessible name that describes its purpose 4.1.2 Name, Role, Value Serious
Submenu does not close and move focus back to the menu item when the Escape key is pressed 2.4.3 Focus Order Serious
Screen reader does not announce when the submenu is opened and closed 4.1.2 Name, Role, Value Serious
Screen reader does not announce the visually apparent active page 4.1.2 Name, Role, Value Moderate
Navigation is not full operable using a mobile screen reader swipe interface Functional consideration for blind individuals Critical

ID Test Name Test Condition Impacts
E.8.2 Skip Links/Bypass Mechanisms A keyboard-accessible method is provided to bypass repetitive content. Blind, motor disabilities, low vision, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. There is a keyboard-accessible method provided to bypass repetitive content, AND
  2. When activated, the method works, and the block of content is bypassed.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain blocks of content that are repeated on other web pages.
Failure Matrix
Failure Condition MDAS Failure Priority
No bypass mechanism exists 2.4.1 Bypass Blocks Serious
The bypass mechanism is not keyboard accessible 2.1.1 Keyboard Critical
The bypass mechanism does not move focus past the repetitive content but moves focus near it 2.4.1 Bypass Blocks Moderate
The bypass mechanism does not move focus at all 2.4.1 Bypass Blocks Serious

9. Information Elements

ID Test Name Test Condition Impacts
E.9.1 Modal Dialogs Modal dialogs follow expected keyboard interaction patterns, and its components have the proper roles, states, and names Blind, motor disabilities
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.

Component Name Description
Modal Dialog An overlayed window that is displayed when the Triggering Element is activated, prevents users from interacting with elements outside of it while it is opened, retains focus while it is open, and, when closed, moves focus back to the Triggering Element if it still exists.
Triggering Element The element that opens the Modal Dialog when activated and receives focus when the Modal Dialog is closed if it still exists.
Close Button A button that closes the Modal Dialog. Typically has an “X” icon as the label or the text “Cancel” or “Close.” Not included in all implementations, but required when the Modal Dialog cannot be closed using the Escape key.
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Focus moves into the Modal Dialog AND
  2. Focus stays within the Modal Dialog and does not move behind the dialog AND
  3. Pressing the escape key closes the dialog OR a keyboard accessible Close Button exists to close the dialog AND
  4. Closing the dialog moves focus back to the Trigger Element OR the most logical location AND
  5. The Modal Dialog has a role of dialog AND
  6. The Modal Dialog has a name that is descriptive of its purpose AND
  7. The Modal Dialog name contains the text of the visible title, if one exists AND
  8. The Modal Dialog has aria-modal set to true.
FAIL ANY of the PASS conditions are FALSE
DNA This is a document, web or mobile application, or the page does not contain modal dialogs.
Failure Matrix
Failure Condition MDAS Failure Priority
Focus does not move into the modal dialog upon activation 2.4.3 Focus Order Serious
Focus is not retained inside of the modal dialog 2.4.3 Focus Order; 2.4.7 Focus Visible Moderate
Pressing the escape key or another keyboard accessible mechanism does not close the modal dialog 2.1.1 Keyboard Critical
Closing the dialog does not move focus to the most logical element 2.4.3 Focus Order Serious
The Modal Dialog does not have a role of dialog 4.1.2 Name, Role, Value Moderate
The Modal Dialog does not have a name that is descriptive of its purpose 2.4.6 Headings and Labels Moderate
The Modal Dialog has a name that does not include its visible title 2.5.3 Label in Name Moderate
The Modal Dialog does not have aria-modal set to true 4.1.2 Name, Role, Value Moderate

ID Test Name Test Condition Impacts
E.9.2 Hover/focus tooltips The tooltip appears on both hover and focus, does not contain interactive elements, the message is announced to screen reader users, remains visible until it is closed, can be hovered into, and, if it obscures content, it can be closed using a keyboard mechanism. Blind, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. The tooltip appears when triggering element receives keyboard focus AND
  2. The tooltip appears when triggering element receives mouse hover AND
  3. The tooltip does not contain interactive elements AND
  4. The tooltip remains open until it is closed by the user AND
  5. The user can hover over the tooltip message without the tooltip closing AND
  6. There is a keyboard mechanism to close the tooltip if it obscures other content AND
  7. The tooltip message is announced by screen readers
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain tooltips that appear on hover and/or focus OR the tooltips are native to the browser or operating system.
Failure Matrix
Failure Condition Priority MDAS Failure
Tooltip does not open on keyboard focus 2.1.1 Keyboard Critical
Tooltip does not open on mouse hover Functional consideration for motor and cognitive disabilities Serious
Tooltip contains interactive elements 4.1.2 Name, Role, Value Moderate
Tooltip closes without user interaction 1.4.13 Content on Hover or Focus Moderate
Tooltip message cannot be hovered over without the tooltip closing 1.4.13 Content on Hover or Focus Moderate
Tooltip that obscures content cannot be closed via a keyboard mechanism 1.4.13 Content on Hover or Focus Serious
Tooltip message is not announced by screen reader 4.1.2 Name, Role, Value Critical

ID Test Name Test Condition Impacts
E.9.3 ARIA Live messages Messages are announced to screen reader users at the appropriate time based on the severity, importance, and/or context of the message Blind
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
Live Region Type Appropriate Attributes Inappropriate Attributes
Alert role=alert OR aria-live=assertive role=status, log, marquee, or timer aria-live=polite or off
Status role=status OR aria-live=polite role=alert, log, marquee, or timer aria-live=assertive or off
Log role=log OR aria-live=polite AND aria-atomic=false role=alert, status, marquee, or timer aria-live=assertive or off aria-atomic=true
Marquee role=marquee role=alert, status, log, or timer aria-live=assertive or polite
Timer role=timer role=alert, status, log, or marquee aria-live=assertive or polite
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Messages indicating important changes in content that do not receive focus are located in a live region AND
  2. The live region has the appropriate role and/or ARIA attributes based on the message’s context, severity, and importance
FAIL ANY of the PASS conditions are FALSE
DNA This is a document, web or mobile application, or the page does not contain messages that do not receive focus and should not be announced to screen reader users.
Failure Matrix
Failure Condition MDAS Failure Priority
Important changes in page content that do not receive focus are not located in a live region 4.1.3 Status Messages Critical
The message is not located in the correct type of live region based on the context in which it appears 4.1.2 Name, Role, Value Serious

ID Test Name Test Condition Impacts
E.9.4 Alert dialogs Dialogs that interrupt a user’s workflow to communicate an important message are identified as such with the proper roles and ARIA attributes and are keyboard accessible Blind, motor disabilities
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.

Component Name Description
Alert Dialog The element that contains all elements of the dialog, including the title, alert message, and any other related elements such as dialog buttons
Title The element that contains the title of the dialog. This may not exist in all implementations.
Alert Message The element that contains the alert
Dialog Buttons The buttons that the user interacts with for their response. These may not exist in all implementations.
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Focus moves into the alert dialog AND
  2. If the purpose of the alert dialog is to perform a destructive action, the initial focus is not moved to the element that will perform the destructive action AND
  3. Focus stays within the alert dialog and does not move behind the dialog AND
  4. Pressing the escape key closes the dialog OR another keyboard accessible mechanism exists to close the dialog AND
  5. Closing the dialog moves focus back to the element that triggers the dialog OR the most logical location AND
  6. The Alert Dialog has a role of alertdialog AND
  7. The Alert Dialog has a name that is descriptive of its purpose AND
  8. The Alert Dialog name contains the text of the visible Title, if one exists AND
  9. The Alert Dialog has aria-modal set to true AND
  10. The Alert Dialog has an aria-describedby association with the Alert Message
FAIL ANY of the PASS conditions are FALSE
DNA This is a document, web or mobile application, or the page does not contain alert dialogs, or the alert dialog is native to the operating system or browser.
Failure Matrix
Failure Condition MDAS Failure Priority
Focus does not move into the alert dialog upon activation 2.4.3 Focus Order Serious
The initial focus is moved to the element in the alert dialog that will perform the destructive action Functional consideration for vision and cognitive disabilities Moderate
Focus is not retained inside of the alert dialog 2.4.3 Focus Order; 2.4.7 Focus Visible Moderate
Pressing the escape key or another keyboard accessible mechanism does not close the alert dialog 2.1.1 Keyboard Critical
Closing the dialog does not move focus to the most logical element 2.4.3 Focus Order Serious
The Alert Dialog does not have a role of alertdialog 4.1.2 Name, Role, Value Moderate
The Alert Dialog does not have a name that is descriptive of its purpose 2.4.6 Headings and Labels Moderate
The Alert Dialog has a name that does not include its visible Title 2.5.3 Label in Name Moderate
The Alert Dialog does not have aria-modal set to true 4.1.2 Name, Role, Value Moderate
The Alert Dialog does not have an aria-describedby association with the Alert Message 4.1.2 Name, Role, Value Moderate

10. Single Page Applications

ID Test Name Test Condition Impacts
E.10.1 Single Page Application Page Change When a new page is loaded in a Single Page Application (SPA), the page title is updated to reflect the topic or purpose of the new page, the new page title is announced, focus is automatically moved to a logical location in the new page, and the page is added to the browser history. Blind, low vision, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. The page title changes when a new view or page is loaded
  2. The new page title is announced
  3. Focus goes to a logical location on the new page/view
  4. Each page is added to the browser history
FAIL ANY of the PASS conditions are FALSE
DNA This is a document, desktop or mobile application, the site does not have more than one distinct page, or the site is a multi-page application.
Failure Matrix
Failure Condition MDAS Failure Priority
The page title does not change when a new view or page is loaded 2.4.2 Page Titled Serious
The new page title is not announced 4.1.3 Status Messages Serious
Focus does not go to a logical location on the new page/view 2.4.3 Focus Order Serious
Page is not added to the browser history Functional consideration for vision and cognitive disabilities Minor

99. All Other Custom Elements

ID Test Name Test Condition Impacts
E.99.1 All Other Custom Elements All custom elements (i.e., non-native) that do not have MDAS-M test processes meet the WCAG name, role, value, non-text content, and info and relationships requirements, as well as follow established keyboard interface patterns defined in the ARIA Authoring Practices Guide (APG) Blind, low vision, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. The name of the element describes its purpose and can be programmatically determined, AND
  2. The element has the proper role that can be programmatically determined, AND
  3. The element communicates its changes in state to assistive technologies, when applicable, AND
  4. The element communicates its changes in value to assistive technologies, when applicable, AND
  5. The element’s properties can be programmatically determined, AND
  6. States, properties, and values that can be set by the user can be programmatically set using methods that are supported by user agents, including assistive technologies, AND
  7. Related element components are programmatically associated with each other, AND
  8. User interface elements follow established keyboard navigation patterns
FAIL ANY of the PASS conditions are FALSE
DNA This is a document, desktop or mobile application or the page does not include non-native user interface elements.
Failure Matrix
Failure Condition MDAS Failure Priority
The name of the element cannot be programmatically determined 4.1.2 Name, Role, Value Serious
The name of the element does not describe its purpose 1.1.1 Non-text Content Serious
The element does not have the proper role that can be programmatically determined 4.1.2 Name, Role, Value Serious
The element does not communicate its changes in state to assistive technologies 4.1.2 Name, Role, Value Critical
The element does not communicate changes in value to assistive technologies 4.1.2 Name, Role, Value Critical
The element’s accessibility properties cannot be programmatically determined 4.1.2 Name, Role, Value Serious
States, properties, and values that can be set by the user cannot be programmatically set using methods that are supported by user agents, including assistive technologies 4.1.2 Name, Role, Value Critical
Related element components are not programmatically associated with each other 1.3.1 Info and Relationships Serious
Element does not follow established keyboard navigation patterns 2.1.1 Keyboard Critical

Usability

The interface is usable with different types of input devices, adjustable to user’s needs, and does not interfere with the user’s ability to use it.

1. Keyboard

ID Test Name Test Condition Impacts
U.1.1 Functionality is keyboard accessible All non-path dependent functionality can be accessed and executed using only the keyboard and non-standard keyboard interactions are visually and programmatically documented. Blind, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. All non-path dependent functionality can be accessed and executed using the keyboard, AND
  2. All essential information can be accessed via keyboard interaction OR the information is available elsewhere on the page AND
  3. Where custom keyboard strokes are required for functionality, instructions are visible and announced by screen readers.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain interactive functionality, or the interactive functionality is path dependent.
Failure Matrix
Failure Condition MDAS Failure Priority
Functionality cannot be accessed and executed using the keyboard 2.1.1 Keyboard Critical
Essential information cannot be accessed because the element that provides access is not keyboard accessible 2.1.1 Keyboard Critical
Instructions for custom keystrokes are not visually available Functional consideration for sighted keyboard users Serious
Instructions for custom keystrokes are not announced by screen readers Functional consideration for blind keyboard users Critical

ID Test Name Test Condition Impacts
U.1.2 Keyboard focus is always visible A visible indication of focus is provided when focus is on the interface element. Low vision, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. When each interface element receives focus, there is a visible indication of focus.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain elements that receive keyboard focus.
Failure Matrix
Failure Condition MDAS Failure Priority
All or most interactive elements do not have a visible indicator of focus 2.4.7 Focus Visible Serious
A primary interactive element does not have a visible indicator of focus 2.4.7 Focus Visible Moderate
A secondary interactive element does not have a visible indicator of focus 2.4.7 Focus Visible Minor

ID Test Name Test Condition Impacts
U.1.3 Focus order preserves meaning and operability The focus order preserves the meaning and operability of the web page. Motor disabilities, low vision, blind
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. The focus order preserves the meaning of the page, AND
  2. The focus order preserves the operability of the page.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain elements that receive keyboard focus
Failure Matrix
Failure Condition MDAS Failure Priority
Focus order does not preserve the meaning and/or operability of the page 2.4.3 Focus Order Serious

ID Test Name Test Condition Impacts
U.1.4 Content that appears on focus can be dismissed and is persistent Content that appears on focus must be dismissible and persistent. Motor disabilities, low vision, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Unless the content communicates an input error or does not obscure or replace other content, the new content is dismissible without the need to remove the keyboard focus, AND
  2. Focus is located on a logical element after dismissing the content, AND
  3. The new content remains visible until focus is moved elsewhere.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain new content revealed with focus.
Failure Matrix
Failure Condition MDAS Failure Priority
Content that appears on focus cannot be dismissed without the need to remove the keyboard focus 1.4.13 Content on Hover or Focus Moderate
Dismissing the content moves focus to an illogical location 2.4.3 Focus Order Moderate
Content that appears on focus does not remain visible until focus is moved elsewhere 1.4.13 Content on Hover or Focus Serious

ID Test Name Test Condition Impacts
U.1.5 Focus does not initiate change in context When an interface element receives focus, it does not initiate an unexpected change of context. Blind, low vision, cognitive disabilities, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. An unexpected change of context is not initiated when an interface element receives focus.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain elements that receive keyboard focus.
Failure Matrix
Failure Condition MDAS Failure Priority
An unexpected change of context is initiated when a user interface element receives focus 3.2.1 On Focus Serious

ID Test Name Test Condition Impacts
U.1.6 No keyboard trap There is no keyboard trap. Blind, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Keyboard focus can be moved away from an element using either:
    1. Standard navigation keys
    2. Escape key
    3. Custom keystrokes (which are documented and available to users in the application). AND
  2. Keyboard focus can be moved away from each section of the page containing elements (and are not trapped in a “loop”, preventing access to other elements on the page) by using either:
    1. Standard navigation keys
    2. Escape key
    3. Custom keystrokes (which are documented and available to users in the application)
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain elements that receive keyboard focus.
Failure Matrix
Failure Condition MDAS Failure Priority
A keyboard trap exists on the page 2.1.2 No Keyboard Trap Critical

ID Test Name Test Condition Impacts
U.1.7 No keystroke timing Individual keystrokes do not require specific timings for activation of functionality. Motor disabilities,  cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. A keyboard method is provided for functionality to be activated without requiring users to perform specific timings for activation.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain interactive functionality.
Failure Matrix
Failure Condition MDAS Failure Priority
Keyboard functionality requires users to perform specific timings for activation 2.1.1 Keyboard Serious

ID Test Name Test Condition Impacts
U.1.8 Character key shortcuts can be disabled or remapped If a keyboard shortcut uses only printable character keys, users can disable OR remap the shortcut OR the shortcut is active only when the element has focus. Motor disabilities cognitive disabilities, blind
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
Result Condition(s)
PASS ANY of the following are TRUE:

  1. The shortcuts can be disabled and the associated action is available through other means.
  2. The shortcuts can be remapped to include nonprintable keys (e.g., Ctrl, Alt).
FAIL ALL of the PASS conditions are FALSE.
DNA The page does not contain keyboard shortcuts that use only printable character keys OR the shortcut only works on current focused element OR menus opened by any other means where single keys are then used to select items in the menu.
Failure Matrix
Failure Condition MDAS Failure Priority
Character key shortcut cannot be disabled, the action is not available through other means, or the shortcut cannot be remapped to use nonprintable keys. 2.1.4 Character Key Shortcuts Moderate

2. Mouse and Touch

ID Test Name Test Condition Impacts
U.2.1 Pointer gestures are also available with a single pointer Multipoint and path-based gestures not essential to functionality must also function with a single pointer. This holds true whether or not a screen reader is in use. Motor disabilities, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. For each instance of functionality activated by a multipoint gesture or a path-based gesture, the same function has controls available to achieve the same outcome using a single pointer.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain multipoint gestures OR path-based gestures OR if such gestures are essential to functionality, such as drawing a signature on a mobile device.
Failure Matrix
Failure Condition MDAS Failure Priority
Multipoint gesture functionality does not have a single pointer alternative 2.5.1 Pointer Gestures Critical
Path-based gesture functionality does not have a single pointer alternative 2.5.1 Pointer Gestures Critical

ID Test Name Test Condition Impacts
U.2.2 Pointer actions can be cancelled or undone No non-essential down-event activation is used for single point activation of controls. Activation occurs on the up-event and a mechanism to abort the function upon completion or to undo the function after completion is provided. If a down-event does exist, the up-event reverses any outcome. Low vision, cognitive disabilities, motor disabilities
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
Result Condition(s)
PASS ANY of the following are TRUE:

  1. The up-event completes the function AND a mechanism is provided to abort before completion or to undo after completion OR
  2. The up-event outside the control reverses the preceding down-event.
FAIL ALL of the PASS conditions are FALSE
DNA The page does not contain functionality that is activated using a single pointer OR it is essential that the functionality be performed on the down-event.
Failure Matrix
Failure Condition MDAS Failure Priority
Single pointer functionality occurs on the down event that cannot be aborted, undone, or reversed by the user 2.5.2 Pointer Cancellation Serious

ID Test Name Test Condition Impacts
U.2.3 Content that appears on hover can be dismissed, is persistent, and remains hoverable Content that appears on hover must be dismissible, persistent, and hoverable Motor disabilities, low vision, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Unless it communicates an input error or does not obscure or replace other content, the new content is dismissible without the need to remove pointer hover.
  2. The new content remains visible until hover is moved elsewhere.
  3. The pointer can hover inside the new content without it disappearing.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain new content revealed with hover.
Failure Matrix
Failure Condition MDAS Failure Priority
Content that appears on hover cannot be dismissed without the need to remove pointer hover 1.4.13 Content on Hover or Focus Moderate
Content that appears on hover does not remain visible until hover is moved elsewhere 1.4.13 Content on Hover or Focus Serious
Pointer cannot hover inside of content that appears on hover without it disappearing 1.4.13 Content on Hover or Focus Serious

3. Motion Input

ID Test Name Test Condition Impacts
U.3.1 Motion controls are also keyboard accessible and can be disabled If device or user motion triggers a function, the function can also be activated through standard user interface controls. The activation through motion can be disabled. Blind, motor disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE:

  1. Standard keyboard accessible interface elements are provided as an alternative method.
  2. A mechanism exists to disable the motion actuation.
FAIL ANY of the PASS conditions are FALSE
DNA The device does not use motion sensors, the page/app does not contain elements triggered by device or user motion, the motion is used to operate functionality through an accessibility supported interface, or the motion is essential for the function
Failure Matrix
Failure Condition MDAS Failure Priority
A standard keyboard accessible mechanism is not provided as an alternative method to perform the motion functionality 2.1.1 Keyboard; 2.5.4 Motion Actuation Serious
No mechanism exists to disable the motion actuation 2.5.4 Motion Actuation Critical

ID Test Name Test Condition Impacts
U.3.2 Device orientation not restricted Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. Motor disabilities
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
Result Condition(s)
PASS ALL the following are TRUE:

  1. All content and functionality is available in landscape orientation is also available in portrait orientation.
FAIL ANY of the PASS conditions are FALSE
DNA This test applies to all content except where the display orientation is essential to the functionality of a feature such as an application for scanning bank checks or a 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, or is a document, or is an application on a device that does not support changing orientation.
Failure Matrix
Failure Condition MDAS Failure Priority
Content and/or functionality is limited to a single orientation 1.3.4 Orientation Serious

4. Voice Input

ID Test Name Test Condition Impacts
U.4.1 Visible label text is in the element’s accessible name The text contained in an interactive control’s associated visible label also comprises the control’s entire accessible name or is the first part of the control’s accessible name. Motor disabilities, cognitive disabilities
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”

Passes Fails
“Preferred Nick Name” “Preferred Nick Name Here” “Preferred Nick Name So You Feel Seen” “Preferred Nick” “Preferred Name” “Nick Name Preferred” “Your Preferred Nick Name” “Preferred Awesome Nick Name” “Have a nice day”
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE:

  1. ANDI Output exists. AND
  2. The ANDI Output contains the visible text label with the words in the same order and being the first part of the accessible label. AND
  3. If the ANDI Output contains more text than appears in the visible text label, that additional text comes only after the visible label text
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain any visible text labels for focusable elements.
Failure Matrix
Failure Condition MDAS Failure Priority
The visible label is not included in the accessible name of the element 2.5.3 Label in Name Moderate
The visible label is not the first part of the accessible name of the element 2.5.3 Label in Name Moderate

5. Content Adjustable

ID Test Name Test Condition Impacts
U.5.1 Text can be resized without loss of content or functionality There is a mechanism to resize, scale, or zoom in on the text to at least 200% of its original size without loss of content or functionality. Low vision
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. There is a non-AT-reliant mechanism that allows the user to resize text to at least 200% of its original size, AND
  2. Text is not clipped, truncated or obscured, AND
  3. All functionality is available, AND
  4. All content is available.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain text
Failure Matrix
Failure Condition MDAS Failure Priority
Text cannot be resized to at least 200% of its original size using a non-AT-reliant mechanism 1.4.4 Resize Text Serious
Primary text is clipped, truncated, or obscured when text is resized to 200% 1.4.4 Resize Text Critical
Secondary text is clipped, truncated, or obscured when text is resized to 200% 1.4.4 Resize Text Serious
Primary content or functionality is no longer available when text is resized to 200% 1.4.4 Resize Text Critical
Secondary content or functionality is no longer available when text is resized to 200% 1.4.4 Resize Text Serious

ID Test Name Test Condition Impacts
U.5.2 Content can reflow without two-dimensional scrolling Except for parts of the content which require two-dimensional layout for usage or meaning, content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width equivalent to 320 CSS pixels and horizontal scrolling content at a height equivalent to 256 CSS pixels. Low vision
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
Result Condition(s)
PASS ALL the following are TRUE:

  1. All content and functionality is still available and does not overlap or obscure other content.
  2. All content and functionality is reachable without having to scroll both vertically and horizontally.
FAIL ANY of the PASS conditions are FALSE
DNA This test applies to all pages except where the only content on the page is one of the excluded elements AND meaning would be lost if this element was resized to 320px wide.
Failure Matrix
Failure Condition MDAS Failure Priority
Primary content or functionality is obscured or no longer exists when content is adjusted to reflow 1.4.10 Reflow Critical
Secondary content or functionality is obscured or no longer exists when content is adjusted to reflow 1.4.10 Reflow Serious
Content or functionality overlaps other content when content is adjusted to reflow 1.4.10 Reflow Moderate
Content or functionality requires both horizontal and vertical scrolling for understanding or use when content is adjusted to reflow 1.4.10 Reflow Moderate

ID Test Name Test Condition Impacts
U.5.3 Text spacing can be adjusted without loss of content or functionality On web pages, no loss of content or functionality occurs by setting all of the following (if supported by the page’s human languages and scripts) and by changing no other style property: line spacing 1.5 times font size; spacing following paragraphs 2 times font size; tracking 0.12 times font size; word spacing 0.16 times font size. Low vision, other visual disabilities, cognitive, language
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
Result Condition(s)
PASS ALL of the following are TRUE When text spacing is adjusted on the page to line spacing 1.5 times font size; spacing following paragraphs 2 times font size; tracking 0.12 times font size; word spacing 0.16 times font size (where these are supported), all of the following happen:

  1. All text content, except for open captions and images of text, adapts to the new text spacing minimums AND
  2. As the result of this test, no content is clipped, cut off, obscured, or overlapped AND
  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 AND
  4. All page functionality that worked prior to the test continues to work.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain text content or is a document or is a mobile or desktop application.
Failure Matrix
Failure Condition MDAS Failure Priority
Text does not adapt to text spacing adjustments 1.4.12 Text Spacing Moderate
Text is overlapped as a result of adjusting text spacing 1.4.12 Text Spacing Moderate
Primary content is clipped, cut off, or obscured as a result of adjusting text spacing 1.4.12 Text Spacing Critical
Secondary content is clipped, cut off, or obscured as a result of adjusting text spacing 1.4.12 Text Spacing Serious
Primary content that is truncated as a result of adjusting text spacing does not have a keyboard accessible mechanism to reveal the content 1.4.12 Text Spacing Critical
Secondary content that is truncated as a result of adjusting text spacing does not have a keyboard accessible mechanism to reveal the content 1.4.12 Text Spacing Serious
Primary functionality is no longer available as a result of adjusting text spacing 1.4.12 Text Spacing Critical
Secondary functionality is no longer available as a result of adjusting text spacing 1.4.12 Text Spacing Serious

6. Content Consistent

ID Test Name Test Condition Impacts
U.6.1 Element name and description consistent across website/application The accessible name and description is consistent for elements that perform the same function. Blind, cognitive, learning, language
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Elements with identical functionality are identified consistently.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain components that have the same functionality within a set of web pages.
Failure Matrix
Failure Condition MDAS Failure Priority
Element is not identified consistently on different pages on the website/different screens of the application 3.2.4 Consistent Identification Moderate

ID Test Name Test Condition Impacts
U.6.2 Navigational elements are in the same relative order across website/application Each navigational element occurs in the same relative order with regard to other repeated components on each web page where it appears. Blind, low vision, cognitive disabilities
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
Result Condition(s)
PASS ALL of the following are TRUE

  1. Each repeated component occurs in the same relative order with regard to other repeated components on each web page or application screen where it appears.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain components that are repeated on other web pages.
Failure Matrix
Failure Condition MDAS Failure Priority
Primary method of navigation (global navigation, search, primary skip nav link, etc.) does not occur in the same relative order on each web page or application screen where it appears 3.2.3 Consistent Navigation Serious
Secondary method of navigation does not occur in the same relative order on each web page or application screen where it appears 3.2.3 Consistent Navigation Moderate
Items within a method of navigation do not occur in the same relative order on each web page or application screen where the method of navigation appears 3.2.3 Consistent Navigation Serious

7. Content does not Distract or Interfere

ID Test Name Test Condition Impacts
U.7.1 Moving, blinking, and scrolling content can be controlled The user can pause, stop, or hide moving, blinking, or scrolling content. Cognitive, learning, attention deficit
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.
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. There is a mechanism that can pause, stop, or hide the content
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain moving, blinking, or scrolling content that plays automatically for more than 5 seconds OR if the moving, blinking, or scrolling content is the ONLY content on the web page
Failure Matrix
Failure Condition MDAS Failure Priority
Moving, blinking, or scrolling content plays automatically for more than 5 seconds without a mechanism to pause, stop, or hide it 2.2.2 Pause, Stop, Hide Critical

ID Test Name Test Condition Impacts
U.7.2 Auto-playing audio can be controlled The user can pause, stop, or control the volume of audio content that plays automatically for more than 3 seconds. Blind, cognitive, language
Step 1: Identify Content

Identify audio content that automatically plays (without user activation) for more than 3 seconds.

  • Content of this type includes alerts, sounds, and music.
Step 2: Test Content
  1. Determine if there is a mechanism for the user to pause or stop the audio or to control the volume of only the auto-playing audio.
  2. Activate the mechanism with both the keyboard and mouse.
  3. Verify that the mechanism works.
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. There is a mechanism that can pause or stop the audio or control (independent of the OS/browser) the volume of only the auto-playing audio
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain audio content that plays automatically for more than 3 seconds.
Failure Matrix
Failure Condition MDAS Failure Priority
Auto-playing audio does not have a mechanism to pause/stop or control (independent of the OS/browser) its volume 1.4.2 Audio Control Critical

ID Test Name Test Condition Impacts
U.7.3 Auto updating content can be controlled The user can pause, stop, hide, or control the frequency of automatically updating content. Cognitive, learning, attention deficit
Step 1: Identify Content

Identify content that:

  • Automatically updates (the content changes without user activation) AND
  • Is not the only content on the page

Content of this type includes timers, stock tickers, news carousels, and counters. EXCLUDE content, that 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 or to control the frequency of the update.
  2. Activate the mechanism.
  3. Verify that the mechanism performs its identified function.
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. There is a mechanism that can pause, stop, or hide the content or control the frequency of the update
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain auto-updating content or the auto-updating content is the only content on the page.
Failure Matrix
Failure Condition MDAS Failure Priority
No mechanism exists that will pause, stop, hide, or control the update frequency of auto updating content 2.2.2 Pause, Stop, Hide Critical

ID Test Name Test Condition Impacts
U.7.4 Time limits adjustable by user The user can turn off, adjust, or extend the time limit. Cognitive disabilities, blind, low vision, motor disabilities, deaf
Step 1: Identify Content

Identify any instances of content time limits. Time limits could be identified by:

  • Inspecting system or site documentation
  • Text description somewhere on the page where the time limit occurs
  • Pop-ups or other messages or warning indicators on the page
  • Allowing the page to be idle for an extended period of time to prompt a time-out notification or other indication that a time limit has occurred.

EXCLUDE:

  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.
Step 2: Test Content
  1. Determine whether the web page provides a mechanism to turn off, adjust, or extend the time limit.
    1. Turn off: the user can turn off the time limit before time expires
    2. Adjust: the user can adjust the time limit to at least ten times the length of the default setting before time expires
    3. Extend: the page provides a warning before time expires; for a period of at least 20 seconds, the user can extend the time limit with a simple action; the user can extend the time limit at least ten times.
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ANY of the following are TRUE

  1. The user can turn off the time limit before time expires, OR
  2. The user can adjust the time limit to at least ten times the length of the default setting before time expires, OR
  3. The page provides a warning before time expires AND:
    1. For a period of at least 20 seconds, the user can extend the time limit with a simple action (e.g., pressing the spacebar), AND
    2. The user can extend the time limit at least ten times.
FAIL ALL of the PASS conditions are FALSE
DNA There is no time limit for content or if the time limit meets one of the exceptions listed in the Identify Content section above.
Failure Matrix
Failure Condition MDAS Failure Priority
Time limits cannot be turned off before expiration, the user cannot adjust the time limit to at least 10 times the length of the default setting, and the user is not warned before time expires and given at least 20 seconds to extend the time limit with a simple action and the user is not allowed to extend the time limit at least 10 times. 2.2.1 Timing Adjustable Critical

ID Test Name Test Condition Impacts
U.7.5 No content flashes more than three times per second Pages must not have content that flashes more than three times per second. Photosensitivity, Vestibular
Step 1: Identify Content
  1. Visibly identify any page or video content that flashes or blinks rapidly. This includes all content may include words, graphics, animations, videos, or images.

EXCLUDE where the content obviously does not flash more than three times per second.

Step 2: Test Content
  1. For each occurrence of flashing content
    1. Determine if it flashes more than three time per second using one or more of these methods:
      1. Compare the rate of flashing to the rate of flashing in this three flashes example.
        1. If the content appears to flash more than the example, this content FAILS.
        2. If the content appears to flash more slowly than the example, this content PASSES.
      2. Count the number of times the content flashes in one second.
        1. Count the flashes for 10 seconds and then divide that number by 10
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE:

  1. The content does not flash more than three times per second.
FAIL ANY of the PASS conditions are FALSE
DNA The page does not contain flashing content.
Failure Matrix
Failure Condition MDAS Failure Priority
Content flashes more than three times per second 2.3.1 Three Flashes or Below Threshold Critical

Important note: Success criterion 2.3.1 permits content to flash more than three times per second if the flash is below the general flash and red flash thresholds. However, the software that can measure these thresholds does not work on modern operating systems/browsers. Additionally, while the informative documentation states that it is also acceptable if the area that is flashing is smaller than 25% of 10 degrees of a visual field, this is difficult for most evaluators to determine what that constitutes without extensive training. Because these thresholds cannot be accurately measured and the “small safe area” technique is difficult to test, they will not be considered when determining conformance. Any content that flashes more than three times per second does not conform.

8. Content is Findable

ID Test Name Test Condition Impacts
U.8.1 Multiple ways exist to locate pages There are two or more ways to locate a web page within a set of web pages. Blind, low vision, cognitive disabilities
Step 1: Identify Content

All web pages within a set of related web pages. EXCLUDE web pages that are the result of, or a step in, a process, such as an order confirmation form.

Step 2: Test Content
  1. Determine whether there are two or more ways to locate the specific web page within a set of web pages; these may include (but are not limited to) techniques such as:
  2. site maps
  3. site search
  4. tables of contents
  5. navigation menus or dropdowns
  6. navigation trees
  7. links between pages

Note: Additional techniques for locating a web page may be available beyond those listed in the test instructions.

  1. Verify that the identified techniques correctly function and lead to the web page within the site, for example:
  2. Links/menus lead to the corresponding pages of the site.
  3. The search form leads to the page(s) which contains the search term.
Step 3: Evaluate and Record Results
Result Condition(s)
PASS ALL of the following are TRUE

  1. At least two techniques exist to locate the web page within the site, AND
  2. The techniques function correctly such that they lead to the correct web page.
FAIL ANY of the PASS conditions are FALSE
DNA The page is not within a set of related web pages OR the web page is a result of, or a step in, a process.
Failure Matrix
Failure Condition MDAS Failure Priority
Fewer than two working techniques exist to locate web pages within a set of web pages. 2.4.5 Multiple Ways Moderate