This document describes the formal testing process of the Digital Accessibility team.
The City evaluates applications against WCAG 2.1 Level AA, along with a set of established best best practices and WCAG 2.1 AAA criteria outlined in the City of Toronto Digital Accessibility Principles & Resources ("City Standard").
The testing processes described below assume an experienced accessibility tester is executing the evaluation. This document should be considered a guide, not an exhaustive list of tests. It is expected that experienced accessibility testers will recognize issues not included here. Tests will continue to be added to this document as they are developed and adopted.
Please see our Web Accessibility Tools List for a list of tools, plugins, etc. that can be used when executing these tests.
For the purposes of this document, the phrase "the page" refers to the page, screen, or view under examination. |
Use the various semi-automated testing tools and browser plugins to review the following:
Review the page as a whole.
Any issues raised by a tool should be further examined as a candidate for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
Check the page's document structure. Document any of the following issues:
Missing <h1> level heading, incorrect heading nesting (skipped heading levels), headings used for display or presentation only, headings that do not describe the content that the section contains.
Check the page's colour contrast. (Use a tool that supports WCAG 2.1 AAA contrast testing, such as the WCAG Contrast checker browser extension.)
Text: All body text has a contrast ratio of at least 7:1, unless it is large scale text.
Large scale text: Contrast ratio of at least 4.5:1. Higher contrast ratios are preferred.
Large scale text is defined as:
1.2 rem or larger (if bold) or 1.5 rem or larger (if not bold);
120% or larger (if bold) or 150% or larger (if not bold) of the default size for body text.
Boldface is defined as a font-weight of 700 or more.
Link text: Contrast ratio of at least 3:1 with any surrounding body text.
UI components such as icons, inputs, buttons, their outlines, and their various states must have sufficient contrast.
When colour is used to distinguish state, this difference needs to have a contrast of at least 3:1 against adjacent colour(s).
Components must be sufficiently distinct from their own background. This contrast ratio must be at least 3:1 against adjacent colour(s).
Check the use of colour. View the page in grayscale and visually check for colour and contrast issues.
Do meaningful details disappear? Sections and boundaries denoted by colour alone?
View the page with styling disabled ("No style").
The visual reading order should remain logical and intuitive.
The reading order should be programmatically determinable. See Understanding Success Criterion 1.3.2: Meaningful Sequence for information on how to ensure reading order is programmatically determinable.
View the page after applying text spacing updates (e.g., using the Text Spacing Bookmarklet).
Any loss of content or functionality should be documented.
Check the page's use of HTML5 and ARIA Landmarks.
Landmarks should be present.
Landmarks should be used according to ARIA specifications and HTML5 specifications (e.g. nested appropriately, used only once for banner, contentinfo, and main roles).
Content contained within the landmark matches the correct use case for that landmark (e.g., contentinfo landmark is used for footer content).
All content is within a landmark. There are a small enough number of landmarks that users have a concise overview of the content.
For landmarks that are used more than once on a page, the landmarks are labelled where appropriate.
Labels, where used, are unique and sufficiently descriptive.
HTML5 landmarks, where available, are preferred.
Check the page uses valid code.
Any significant errors reported by code validation tools should be further examined as a candidate for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
For pages with dynamic code, check the page uses valid code as the DOM is updated and changed.
Use the browser's developer tools to test the generated markup. Do not test by URL.
Any significant errors reported by code validation tools should be further examined as a candidate for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
If the page supports Responsive Design and/or Adaptive Design, repeat all of the above steps at each major breakpoint.
Any new errors or differences from the above results should be further examined as candidates for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
While the steps outlined in the above Section A, Semi-automated Testing, can identify several major code-related issues, code inspection is still required, in particular:
Inspection of tool-identified issues.
Where an automated or semi-automated tool identifies an issue, experienced accessibility testers are expected to review all aspects of the issue raised, including the underlying code, to identify:
Whether the issue is a Violation of the City Standard and
Possible approaches to remediate the issue.
Check for use of inline styles.
Use the browser's Developer Tools to inspect the DOM.
Search the HTML for inline styles (e.g., search for "style=").
Examine the search results as candidates for documentation.
If an item is confirmed as a Violation of the City Standard, it is documented.
The page has a <title> element (or equivalent).
Every page has a descriptive, informative, unique title.
The title describes the content, topic, or purpose of the page.
The page's title is unique and distinguishable from other pages.
If there are frames on the page, all frames and iframes have titles.
Single page applications (SPAs) must explicitly update the page's title when changes in the view mimic a new page.
SPAs explicitly announce to the screen reader the new page title.
If the page supports Responsive Design and/or Adaptive Design, repeat all of the above steps at each major breakpoint.
Any new errors or differences from the above results should be further examined as candidates for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
Explore the page content for interactive elements.
Identify all interactive elements that respond to the mouse (e.g., hover, click, etc.).
These interactive elements must have corresponding responses when keyboard testing (see C.2 Keyboard Testing for more information) .
Test pointer cancellation for all interactive elements that can be activated with mouse.
With mouse cursor positioned over target, click and hold primary mouse button.
Ensure element is not activated on the down event of the mouse click.
With mouse cursor positioned over target, click and hold primary mouse button. While holding the mouse button, move mouse cursor away from target, then release the mouse button.
Ensure element is not activated.
If element is a drag-and-drop component:
Clicking primary mouse button selects an item.
If mouse cursor is not moved, releasing mouse button should deselect the item.
Exception: If the functionality requires an action to happen on the down event (e.g., a drum machine).
The following tests begin on the page immediately before the page under examination.
Navigate to the page. Using a keyboard, press the tab key until you have cycled through all focusable elements on the page and focus has been returned to the browser navigation bar.
Check bypass block links (or "skip links") are present.
These links can be visible by default or visible on focus.
Absence of skip links should be documented.
If skip links are present, one of them needs to be the first element in the focus order of the page.
If the first focusable element is not a skip link, this should be documented.
Check for logical focus order.
The sequence of the focus order of all focusable elements on the page follows the intuitive reading order of the page (typically top-down, left-to-right).
All elements which visually appear to be interactive receive keyboard focus.
Focus should move through all actionable objects, elements, and controls (e.g., buttons, radio buttons, checkboxes, dropdowns, menus, etc.).
If elements thought to be interactive do not get keyboard focus, determine whether they can be interacted with using a mouse or other input.
All elements with mouse interactions (e.g., hover effects, etc.) can receive keyboard focus.
Focus should move through all actionable objects, elements, and controls (e.g., buttons, radio buttons, checkboxes, dropdowns, menus, etc.).
Check for visible focus.
All focusable elements have a visible focus state.
Visible focus must have sufficient contrast with adjacent UI elements and their own background (contrast ratio is at least 3:1).
Focus is never lost on an invisible element.
Visible focus does not land on an otherwise visibly empty portion of the screen.
Focus does not disappear between elements.
Keyboard traps.
The page is free of keyboard traps.
Where traps exist, there is a clear instruction (also announced by screen readers) on how to exit the trap using keyboard alone.
Check that focusing on any element does not trigger a change of context.
Changes should only occur when the user interacts with an element.
If focusing on an element reveals content (e.g., tooltip, popup, dropdown).
Determine if the revealed content is Dismissable, Hoverable, and Persistent.
See C.2.2 Interaction Test for more information.
If the page supports Responsive Design and/or Adaptive Design, repeat all of the above steps at each major breakpoint.
Watch for new elements that are introduced in each view.
Any new errors or differences from the above results should be further examined as candidates for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
Repeat the above steps using a screen reader.
Document any new errors or differences.
Navigate to the page. Using a keyboard, press the tab key to move focus to each interactive element. Interact, using keyboard alone, with the element. Repeat until you have cycled through all focusable elements on the page and focus has been returned to the browser navigation bar.
Check bypass block links (or "skip links") work correctly.
Enter key activates the link.
Activating the link moves you to the expected target of the link.
Keyboard focus is moved as well as visible focus. Pressing the tab key should move to the next focusable element after the target destination.
Check links work correctly.
Enter key activates the link.
Activating the link moves you to the expected target of the link.
Link takes you to another page or a destination within the current page.
The link text is appropriately descriptive and accurate. The purpose/target of the link is easily understood.
Check buttons work correctly.
Both Enter key and Spacebar key activate the button.
The button text is appropriately, accurately, and uniquely descriptive. The resulting action is expected.
UI elements that change context upon input:
Change as expected based on UI element type (e.g., checkbox is selected or deselected).
Change as expected based on information provided to the user in advance.
Buttons that toggle content (e.g., popup, accordion, other content disclosure - click to open the content):
The new content receives focus or is the element immediately following the toggle in the DOM.
The new content can be interacted with.
Closing the new content returns focus to button being tested.
Autocomplete Search inputs. Try to use when empty, with a character or two for an initial search, and with phrases and words.
If there is a dropdown result list, you can interact with it (e.g., arrow up and down).
Focusing on any element does not trigger a change of context (e.g., pressing tab while on a suggested result triggers a search, arrow down to a result triggers a search, etc.).
Content revealed on hover or focus (tooltips, popups, dropdown menus - hover or focus to open the content).
Note: these tests are NOT intended for modals or browser-generated "tooltips" (i.e., tooltips from the title attribute or the HTML5 required attribute).
Revealed content can be dismissed with the Escape key.
Content persists until dismissed (i.e., remains on screen and does not disappear after a set time).
User can tab to focusable elements within the revealed content without the content disappearing.
If using a mouse, hovering over the same element will trigger the same revealed content.
If the page supports Responsive Design and/or Adaptive Design, repeat all of the above steps at each major breakpoint.
Watch for new elements that are introduced in each view.
Any new errors or differences from the above results should be further examined as candidates for documentation.
If the issue is confirmed as a Violation of the City Standard, it is documented.
Repeat the above steps using a screen reader.
Document any new errors or differences.
Test pointer cancellation for all interactive elements that can be activated by tap.
Tap target and keep finger on screen.
Ensure element is not activated on the down event of the tap.
Tap target and keep finger on screen. Move finger away from target, then release.
Ensure element is not activated.
If element is a drag-and-drop component:
Tapping selects an item.
If finger/stylus is not moved, lifting finger from screen should deselect the item.
Exception: If the functionality requires an action to happen on the down event (e.g., a drum machine).
Pinch-to-zoom should increase the text size.
Orientation (landscape/portrait) can be changed.
Exception: A specific display orientation is essential.
For interactive elements operated using path-based gestures (e.g. swipe, drawing a shape), or multi-point gestures (e.g. pinch-zoom, two-finger tap)
Targets are provided for a single tap/click to perform the same action? (e.g. arrow buttons along with a swipe navigation; plus/minus buttons along with pinch-zoom).
The following screen reader + browser combinations are used to perform these tests:
JAWS + IE 11 (Windows)
NVDA + latest Firefox (Windows)
VoiceOver + latest Safari (both macOS and iOS)
TalkBack + latest Chrome (Android)
Page title is announced with each page.
The title is informative and unique. The user knows where they are in the set of pages.
The title changes with each new page.
Single page applications (SPAs) must explicitly announce to the screen reader changes in the view that mimic a page change.
Each new change in the view updates the title in the browser tab.
Check all interactive elements are announced in a predictable way.
The visible text matches the text-to-speech output (or at least begins with the same text).
Where an interactive element appears on multiple pages, it is consistently identified (e.g. a button labelled "search" on one page is not labelled "find" on another page)
Determine if image is decorative or informative.
Informative images add understanding and context to the page.
Decorative images are not essential to understanding the content and purpose of a page or merely provide visual decoration (e.g., borders, spacers, and corners).
Images use alt text. Text alternatives can appear in the body text of the page.
All images have an alt attribute
Decorative images have an empty alt attribute (i.e.., alt="").
Informative images have a text alternative that conveys the intended meaning or content of the image.
If the text alternative for an informative image appears in the body text of the page, the image has an empty alt attribute.
Images of text.
Generally, images should be free of text.
When an image has text and that text is important to the understanding of the page, then that text should appear in the body of the page or in the alt text of the image.
Alt text adds understanding and context to the page.
Alt text is adequately descriptive, but not too descriptive.
Conveys information in a short phrase or sentence (i.e., "tweet length").
The description is appropriate for the image context.
Graphical link.
The alt text describes the link's purpose/target, not the image itself.
Background image.
Background images that convey information should have a text equivalent.
The information conveyed by the background image should be represented somewhere in the page's body text.
Scan the page using the headings method for the screen reader you are testing with (e.g., NVDA: H key to discover headers, 1-6 key to traverse specific levels).
Verify that the page has a single level 1 heading (<h1>) being used as the title of the content.
Absence of headings is a Violation of the City Standard.
The <h1> should make sense.
The <h1> should be relevant to the content of the page.
Cycle through the headings on the page.
Headings describe the content of the sections they contain.
Headings should not be used for styling of content.
Everything that looks like a heading is tagged as a heading.
Body text that visually appears to have the role of a heading is identified as a heading by the screen reader.
Scan the page using the landmarks method for the screen reader you are testing with (e.g., NVDA: D key to discover and traverse landmarks).
Listen to the landmark announcements to see if they are described by some labelling method.
Descriptions, where used, make sense for the content of the landmark.
If there is more than one of a particular type of landmark, each has a unique description.
Scan the page using the lists method for the screen reader you are testing with (e.g., NVDA: L key to discover lists, I key to traverse them).
Everything that looks like a list is tagged as a list.
All elements which are visually styled as lists are announced by the screen reader as lists.
Scan the page using the button method for the screen reader you are testing with (e.g., NVDA: B key to discover and traverse buttons).
Buttons have actions. Links have destinations.
Elements that are announced as a button do something when activated.
Elements that are announced as a link go somewhere when activated.
For screen readers that support this feature, bring up the list of links on the page and the list of headings on the page (e.g., NVDA: Elements List screen - NVDA key + F7).
List of links.
The purpose/target of a link is clear from the link text alone.
Links with same link text, go to the same destination.
External links are indicated (e.g., "opens in a new window").
List of headings.
The content and structure of the page is clear from the headings list alone.
No headings in the same section have the same text.
When important changes in content happen, the change is announced by the screen reader.
Important changes in content include success or results of an action, waiting state of an application, or notification of errors in a form submission.
Keyboard focus does not change when the status message is announced. (The status message does not receive focus.)
The status message does not require a user action to dismiss.
The status message is adequately descriptive but concise.
Visually scan the page for colour issues not flagged by semi-automated testing tools.
Check the page's colour contrast.
Text: All text has a contrast ratio of at least 7:1, unless it is large scale text.
Large scale text: Contrast ratio of at least 4.5:1. Higher contrast ratios are preferred.
Large scale text is defined as:
1.2 rem or larger (if bold) or 1.5 rem or larger (if not bold);
120% or larger (if bold) or 150% or larger (if not bold) of the default size for body text.
Boldface is defined as a font-weight of 700 or more.
Link text: Contrast ratio of at least 3:1 with any surrounding body text. UI components such as icons, inputs, buttons, their outlines, and their various states must have sufficient contrast.
When colour is used to distinguish state, this difference needs to have a contrast of at least 3:1 against adjacent colour(s).
Components must be sufficiently distinct from their own background. This contrast ratio must be at least 3:1 against adjacent colour(s).
Check if colour is used to convey information without other textual or visual cues.
View the page in grayscale and visually check for colour and contrast issues.
Do meaningful details disappear?
Sections and boundaries denoted by colour alone?
Check if images are used for content or functionality.
Use the browser's settings to disable images.
Load the page and review it for all missing content or functionality.
Watch for buttons, links, and text that disappears.
Browser zoom 200%
Set browser's zoom to 200%
Check if content remains visible and legible. No content should be obscured by other content. The page should reflow gracefully.
If using zoom does cause the page layout to change, anything pushed off of the side of the browser's viewport should be visible by using the browser's vertical scroll bar.
Horizontal scrolling is only allowed in the case of content designed to scroll horizontally or content that requires 2D layout like maps and data tables.
No interactive controls should become unusable due to clipping after the page is zoomed.
It is visually obvious that content is truncated. There is some indication of truncation. Content that becomes truncated can be viewed in full on activation or once the item receives focus.
Text-only zoom 200%
Firefox supports text-only zoom - (Alt + V, Z, T sets the browser to zoom text only).
Resize text-only to 200% and check if content still visible, legible, and usable.
Font size increased 200%
Firefox supports changing the browser's default font and font size (see Options -> Language and Appearance -> Fonts & Colors).
Double the browser's default font size (e.g., 16pt to 32 pt).
Check if content remains visible, legible, and usable. No content should be obscured by other content. The page should reflow gracefully.
Links are visually distinguishable from the surrounding text.
Links in body text should be distinct in a way that does not rely on colour alone. It is preferred that links in body text are underlined.
Use of colour alone is a Violation of the City Standard.
Link colour has sufficient contrast from body text colour.
Contrast ratio of link text to adjacent body text is at least 3:1.
If not already distinctly identified (e.g., underline, position), there is also another indicator when the link receives focus/hover (e.g. underline).
Links consistently use the same colour across this page and all pages.
Links need to be easily identifiable for users. A consistent appearance can help users identify links from other body text.
Links that open in a new tab or window are visually indicated.
The visual indication that the link will open a new window is also reliably spoken to assistive technologies, announcing that the link opens in a new window.
Font(s) used are legible and readable.
Use a small number of font faces.
Font styling or appearance is not used to convey meaning.
Screen readers ignore visual styling (colour, font size, boldface, ALL CAPS, etc.).
The semantics of the styling should be conveyed programmatically (e.g., <em>, <h2>, etc.). When this is not possible, the semantics need to be conveyed through text (e.g., hidden text reads "Deleted:" to denote strikethrough text).
Font size set with relative units.
Font size is set in percent, ems, or rems.
No blinking or moving text.
If blinking or marquee text is present, there is an obvious accessible way to stop this behaviour.
Use of text alignment.
Full justification (where text is aligned spread over the whole column width) can cause large spaces between words and letters creating "rivers" in the text.
Ragged right (left-justify) text is preferred.
Any flashing content on the page:
Flashes less than three times per second.
Has an obvious accessible pause/stop/hide control.
Note: As a rule, keyboard controls and ARIA roles, states, and properties for components should match the patterns outlined in the WAI-ARIA Authoring Practices 1.1 Specification.
For all components with state, ensure the state is announced by screen readers.
For all components with instructions, confirm that the instructions do not rely solely on visual- or audio-only information.
The following considerations apply to navigation regions, menus, and other navigation elements.
All levels of navigation can be accessed via keyboard alone.
Keyboard navigation does not involve excessive tabbing through navigation items
Arrow keys and bypass blocks are available for large navigation blocks to lighten the tab load.
All navigation elements are correctly labelled. The purpose / target of navigation elements is clear and predictable.
When activated, they take you where you expect to go.
Navigation is consistent across all groups of pages.
Links and buttons with the same label do the same thing and are located in the same place.
There are multiple ways to locate a page within a set of pages.
Multiple navigation mechanisms exist for the site (e.g., navigation, site map, site search).
Users can arrive at a page in more than one way.
The following considerations apply to modals.
When you open a modal, all these are true:
Initial visible focus and keyboard focus is in a logical place (e.g., "Cancel" button on a confirmation modal for an action that cannot be undone, etc.).
A close button for the modal is present and accessible via keyboard alone.
Pressing the escape key closes the modal.
Keyboard focus is trapped within the modal.
Users, especially screen reader users, cannot interact with content outside of the modal.
The use of carousels is not recommended. The following considerations apply to carousels.
Autoplay
Autoplay should be avoided.
Accessible, keyboard operable controls should be provided to stop or play the carousel.
All slides and their contents are keyboard operable.
All slide content (or a useful text alternative) is available to screen readers.
The use of iframes is not recommended. The following considerations apply to iframes.
iframe has a title.
The title is descriptive and informative.
Title describes the topic or purpose of the iframe.
Iframe Is keyboard navigable
Content of the iframe is announced correctly by the screen reader.
User can interact with the content as expected when a screen reader is running.
Content is not obscured at large or small breakpoints.
Ensure downloadable content can be downloaded using the keyboard.
Content dynamically generated by the application will also need to be reviewed for accessibility.
Dynamically generated content includes PDFs, email, etc.
Forms have several unique issues that require further attention in addition to the testing activities already described above.
All form controls (including any submit button) can be interacted with according to WAI-ARIA Authoring Practices specification(s).
If the form imposes any kind of time limits, ensure it meets WCAG SC 2.2.1 Timing Adjustable.
If the form involves legal or financial transactions, modifying user data, or submitting test responses, ensure it meets WCAG SC 3.3.4 Error Prevention (legal, financial, data).
Manually review the code for the form against the following considerations:
Required fields are indicated programmatically.
Error and information/instruction messages are programmatically associated with their form elements.
Grouped form items are grouped programmatically (e.g., with <fieldset> + <legend>, role="group" + aria-labelledby, <optgroup> where <options> are grouped in a <select>).
Where it does not interfere with privacy, autocomplete attributes and autofill detail tokens are used (and used correctly).
Review all of the keyboard testing items listed in C.2 Keyboard Testing above.
Visible labels.
All input fields have a visible label. Placeholder text is not the sole way to identify the purpose of the field.
Label is adequately descriptive. The user understands what is being requested.
Using a mouse to click on the label sets focus to the associated input.
The label is programmatically associated with the form element.
Groups of controls
Related form elements are grouped in a fieldset, section, or similar programmatically semantic way.
Grouped controls have a heading, legend, and/or aria-label.
Any heading, legend, or aria-label describing the group is adequately descriptive. The user understands the relationship among the grouped controls.
Required fields
Required fields are indicated using more than colour alone.
Required fields are programmatically indicated as required (e.g., aria-required="true").
Symbols indicating a required field are explained in body text.
Error handling
Try to submit the form with as many errors as possible and evaluate the error messaging strategy:
Users should be aware there are errors in the form submission.
Error text is clearly visible near the input.
Error text is appropriately descriptive. The user knows what the issue is and how to fix it.
Complete the form correctly using the keyboard, then submit the form.
A success message should appear. Users should be aware that the form has been submitted successfully.
Repeat the steps listed in G.2.3 Forms Keyboard Testing using a screen reader.
Navigate the form content using the "forms/focus mode" of the screen reader.
Using the TAB key will navigate between form controls and buttons.
For each form element that you navigate to in "focus mode":
The correct label for the element is announced.
Help text visually placed near the form element is announced as part of the form element (e.g., using aria-describedby).
If the form element is visually indicated as required, it is announced as "required".
If a form element is announced as "required", it is also visually indicated as "required".
Groups of controls.
For form controls grouped together visually with a heading or legend (and/or aria-label), the heading/legend is announced before the form controls' label.
The announced heading, legend, and/or aria-label is sufficiently descriptive such that a non-visual user will understand the relationship(s) shared by the group.
Error handling.
Try to submit the form with as many errors as possible.
Users are made aware that there are errors in the form submission.
Navigate through the form elements in "focus mode".
For every field with an error, the error text is announced by the screen reader.
The error announcement is sufficiently descriptive such that a non-visual user will understand the error and how to fix it.
Complete the form correctly, then submit the form.
A success message should be announced. Users should be aware that the form has been submitted successfully.
Tables have several unique issues that require further attention in addition to the testing activities already described above.
Tables are used for data, not presentation.
White space characters are not used to format content into tables. Tables need to be coded as tables.
Manually review the code for the table against the following considerations:
Table has headers.
Column headers have their headers correctly marked up using <th>.
Row headers have their headers correctly marked up using <th>.
Column and row headers are not empty.
Row and column headers have scope attributes.
Scope attributes are assigned a value of row, col, rowgroup, or colgroup, depending on their relationship with related data cells.
If scope attribute is not used or table has a complex design.
Header cells have unique ID attributes.
Table data cell has been assigned a HEADERS attribute.
Data cell HEADERS attribute is correctly set to the value of all corresponding header cells' ID attribute values.
Multiple headers are announced in the correct order to understand a table data cell in a complex table.
HEADERS IDs are separated by a space and appear in the order in which they need to be announced for the tabular structure of the data to make sense.
Table has data cells.
Table data cells are correctly marked up using <td>.
Table is visually styled (font, colour, etc.) through CSS.
If CSS is removed, content of HTML tables still makes sense.
View the page with styling disabled ("No style").
With CSS disabled, content of HTML tables still makes sense.
If the page supports Responsive Design and/or Adaptive Design, review the table at each major breakpoint.
The table should resize gracefully.
If the table requires horizontal scrolling, ensure that this is clear to the user and remains keyboard operable.
Watch for new elements that are introduced in each view.
Screen readers may have a specific table navigation mode.
Navigate the table using the "tables mode" of the screen reader.
Ensure the screen reader's keyboard table navigation shortcuts behave as expected.
If the page supports Responsive Design and/or Adaptive Design, review the table at each major breakpoint.
Confirm that the table remains screen reader accessible at all major breakpoints.
The following considerations apply to multimedia and moving elements such as animations.
Autoplay
Autoplay should be avoided.
If autoplay is enabled for more than 3 seconds, obvious and accessible controls are provided to pause, stop, or hide.
Controls
Pause, Stop, Hide, etc. controls are easy to locate and keyboard operable.
Button labels are announced by screen reader on focus.
Captioning
Captions are provided for all videos with audio content.
All dialogue is included in the captions.
Non-speech sounds important to the understanding of the content are included in the captions.
Any related controls (e.g., turn on captions, change appearance, etc.) are easy to locate and keyboard operable.
If user cannot set appearance, default appearance of captions has sufficient contrast.
Text alternatives
A text alternative is provided for the video and/or the audio.
The method for accessing the text alternative is keyboard operable.
Audio description. One of the following is true:
All videos are sufficiently self-descriptive such that a special audio description version is not needed.
An alternative audio track or alternative video is provided for each video that includes the audio description.
The method for accessing this version is keyboard accessible.
Information important to the understanding of the content is included in the audio description.