Testing Methodologies
These methodologies were written to test for WCAG 2.2 AA and to be used with the accompanying Issue Tracking Spreadsheet. The methodologies have been split into the following sections:Manual
These tests rely on testers to manually review elements on the page.1.2.1 Audio-only and Video-only (Prerecorded)
Manually check all pages with audio-only and video-only content to ensure text transcripts are available for audio and audio descriptions or text transcripts are available for videos. This can be done by playing the media and verifying the presence of an accessible alternative in the page content or through a clearly marked link.1.2.2 Captions (Prerecorded)
Make sure all prerecorded videos have captions. The captions should be accurate and synchronized with the video, identify speakers whose identities are not apparent visually, and describe important music and sound effects.1.2.3 Audio Description or Media Alternative (Prerecorded)
Ensure that all videos containing visual-only information have either an audio description or a full-text transcript. The audio description should be a synchronized soundtrack conveying all essential visual-only content, while the full-text transcript should include important details about any changes in scenery, expressions, or other essential visual-only information.1.2.4 Captions (Live)
Make sure all live videos (livestreams) have captions. Captions should be accurate and synchronized with the video, identify speakers whose identity is not apparent visually, and describe important music and sound effects.1.2.5 Audio Description (Prerecorded)
Play all prerecorded video content (anything that is not live) to verify that audio descriptions are present for videos containing significant visual information. This can involve using media players that support audio descriptions and checking that the option to turn them on is available and functional.1.3.3 Sensory Characteristics
Ensure no instructions on each page depend on visual characteristics (e.g., something's location, shape, size, orientation, etc.). For any instructions that reference visual characteristics, check that they also reference another non-visual characteristic (e.g., a text label that can be accessed by a screen reader and by people who cannot perceive color). Determine if any of those instructions reference sound prompts. For any instructions that reference sound prompts, check that they also reference another non-sound characteristic that can be accessed by people who cannot hear sound.1.3.4 Orientation
Ensure the content functions correctly in both landscape and portrait orientations without mandating a specific orientation unless a specific orientation is essential.1.3.5 Identify Input Purpose
Check that all form fields that require a user’s personal data have one of the accepted Input Purposes for User Interface Components and have the autocomplete attribute set to the appropriate value for that input purpose. This can be checked using the Autocomplete accessibility bookmarklet, which will identify if the autocomplete is being used and, if so, what attribute is being used on each form element.1.4.1 Use of Color
Make sure no page content depends solely on being able to see colors (e.g., red vs. blue) to be completely understood. Check that the information conveyed by color is also conveyed visually without relying on color, e.g. via a symbol or text or font weight or pattern, ensuring links are underlined or identified another way, etc (for the color blind) and an accessible text or programmatic alternative (for screen reader users).
1.4.2 Audio Control
If there is any audio (including audio in a video) that plays automatically and lasts for more than 3 seconds, make sure there is a way to stop, pause, or mute the audio, or the volume is adjustable by the keyboard alone. Make sure the audio volume controls do not control the overall system volume.
1.4.4 Resize Text
Check that text can be zoomed up to 200% by setting your viewport to 1366px wide by 768px high and zoom with your browser to 200%. Check that the page is readable and functional. If this test is failed, you need to perform a second test. Navigate to your browser’s settings and increase the font size from 16 to 32. Check that the page is readable and functional. If either test passes, the criterion is satisfied.
1.4.5 Images of Text
Verify that all text on the page is rendered text and not an image of text. This can be done by highlighting the text or seeing if the text zooms with the rest of the content. Images of text are only allowed if the image is essential (i.e., logos, branding, graphs, etc.).
1.4.10 Reflow
Set your browser viewport to 320 CSS pixels wide and 256 pixels high at 100% zoom OR 640px width by 512px height at 100% and then zoom to 200%. Check that all content can be read and there is no loss of functionality without scrolling in two directions.
2.2.1 Timing Adjustable
Test any web pages or functionalities with time limits by attempting to adjust or turn off the time limit through the website's interface or looking for a warning message that appears at least 20 seconds before the time limit expires. Users should be given at least 10 time limit extensions. Ensure keyboard accessibility and that screen readers can adequately announce time limit warnings and adjustment options.
2.2.2 Pause, Stop, Hide
If there is any moving, blinking, or scrolling content (including banner rotators and videos) that starts automatically and lasts for more than 5 seconds, make sure there is a way to stop it.
2.3.1 Three Flashes or Below Threshold
Check if there is flashing or blinking content. If there is, count the number of times the content flashes or blinks in any one-second period, or count the number of flashes or blinks in 10 seconds and divide by 10.
2.4.4 Link Purpose (In Context)
Make sure the destinations/functions of all links and buttons on each page are clear based on the link/button text and the surrounding context (i.e., users shouldn't be surprised by where they go or what happens). The ANDI Bookmarklet can be used to view a list of all the links on the page and their destination.
2.4.5 Multiple Ways
Make sure there are multiple ways to reach each page that is part of a set unless it is a step in a process, or the site is very small (e.g., a search function and link in the navigation, or link in the site map and link in navigation).
2.4.6 Headings and Labels
Ensure all headings and labels are accurate, descriptive, and meaningful to the content in that section.
2.5.1 Pointer Gestures
All operation functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture.
2.5.2 Pointer Cancellation
Ensure that at least one of the following is true for functions that can be operated with a single pointer: No Down-Event, Abort or Undo, Up Reversal, or Essential.
2.5.3 Label in Name
Check that for UI components with labels that include text or images of text; the programmatic name contains or is exactly the text presented visually.
2.5.4 Motion Actuation
Ensure that any functionality that can be operated by device motion or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation unless the motion is essential for the function, and doing so would invalidate the activity.
3.2.2 On Input
Make sure changing form inputs (e.g., checkboxes, dropdowns, text boxes, etc.) does not unexpectedly cause major changes to context.
3.2.3 Consistent Navigation
Make sure items in navigation bars and menus are in the same relative order and place on all related pages.
3.2.6 Consistent Help
Check that help mechanisms provided (if any) are available in the same location on each page within a set of web pages.
3.3.1 Error Identification
Test forms by leaving inputs blank and by filling them out with invalid information (e.g., enter "1" for "State" in an address), and make sure that errors are described in text, and that it is clearly indicated which inputs had which errors. Make sure descriptions are descriptive enough to help users fix problems.
3.3.3 Error Suggestion
Test forms by leaving inputs blank and by filling them out with invalid information (e.g., enter "1" for "State" in an address), and make sure that error messages include suggestions for resolving them (when it's possible for the system to do so), unless security or purpose would be compromised (e.g., no suggestions should be provided when a form element is part of a quiz). Examples of error messages can include Indicating a required field has been left blank, Indicating the required format for the field in error, or Indicating a range of valid values for the field in error.
3.3.4 Error Prevention (Legal, Financial, Data)
Make sure users can review, correct, check, or reverse the submission of any legal or financial information or any data they will have access to later (e.g., if a user can submit information that involves financial transactions, legal commitments, or contracts, or data they can later access, they must be able to verify and correct it before it is submitted, or be able to change or undo it later).
3.3.7 Redundant Entry
Identify any processes that require users to enter data and check that if the user is asked to enter the same data again, it is auto-populated, or the data is available to be selected, so it doesn’t need to be retyped (i.e., information can be selected from a drop-down or copy and pasted from text on the page). Exceptions to this rule include where re-entering information is essential, if it is to ensure the security of content, or if the information is no longer valid.
3.3.8 Accessible Authentication (Minimum)
Identify any authentication process and verify that at least one method is available that does not include a cognitive function test or a mechanism available to assist users in completing cognitive function tests.
Screen Reader
These tests rely on the use of a screen reader. Different screen readers rely on different keystrokes to navigate web pages. To find the keyboard shortcuts for the screen reader you plan to test with, refer to Deque University’s Screen Reader Keyboard Shortcuts and Gestures.
1.3.1 Info and Relationships
Use a screen reader to navigate through tables (e.g., "t" key in NVDA). Make sure the screen reader identifies all tables on each page as tables, and that tables are properly structured. Make sure table headings (e.g., content in the first row) are read out for all cells that they organize (e.g., all cells in that column). Make sure presentation tables have role="presentation" or role="none". Additionally, ensure that lists are utilizing proper list markup and are read out as lists. Headings should also be properly marked up with appropriate heading levels. Headings should only be used to structure the document, and not to stylize the text.
1.3.2 Meaningful Sequence
Have a screen reader (e.g., NVDA or VoiceOver) read through all content on each page (e.g., Ctrl+Home then Insert+Down Arrow in NVDA). Make sure everything is read out and that it's read out in an order that makes sense.
2.4.1 Bypass Blocks
Make sure there are headings at the top of each content area (i.e., content after main navigation and site banners) by finding it with the keyboard in a screen reader (e.g., "h" key in NVDA) or there is a link at the very start of each page that directs focus to the start of unique content when activated or that there are landmarks on the page (i.e., a <main> sectioning element or a role="main" ARIA landmark). Landmarks and headings can also be exposed/checked with the ANDI Bookmarklet.
2.5.7 Dragging Movements
Find all the instances on the page that require a dragging movement, such as sliders and drag-and-drop elements. Ensure that all actions that can be completed with a dragging movement can also be achieved using a single pointer (mouse, pen, or touch) and one or more single-touch actions (tap, click).
3.2.4 Consistent Identification
Ensure that all user interface elements (i.e., links, buttons, etc.) that perform the same function and are repeated across pages are read out the same by the screen reader.
3.3.2 Labels or Instructions
Make sure visible labels or instructions are provided in text for all form fields that require user input. Required form fields should have a label indicating it is required, instructions that say it is required, or an error message that tells the user it is required.
4.1.2 Name, Role, Value
Navigate to all the user interface components on the page and ensure that the screen reader is correctly conveying the component's role (i.e., button, link, radio button, text field, etc.), its name (i.e., label on a form control, name of a tab, etc.) and any applicable values (i.e., selected, disabled, expanded/collapsed, on/off, etc.).
4.1.3 Status Messages
Trigger any status messages on the page and check that the screen reader announces the message. Status messages provide information on the result of an action, the wait status of an application, the progress of a process, or the existence of errors.
Keyboard
Keyboard testing involves utilizing only your keyboard to navigate the page and interact with content. Use the TAB key to navigate forward and SHIFT + TAB to navigate backward. Use the ENTER key to activate links, ENTER, or SPACEBAR to activate buttons. For more keyboard testing commands, please refer to WebAIM's Keyboard Testing.
1.4.13 Content on Hover or Focus
Find all the instances where additional content appears when the element gains keyboard focus or is hovered over with a mouse. Ensure that all the content that appears is dismissible (a mechanism to dismiss the content is available, like the ESC or Enter key), hoverable (if hovering your pointer triggers the content, then the pointer can be moved over the additional content without it disappearing), and persistent (the additional content remains visible until the trigger is removed, it s dismissed, or it is no longer valid).
2.1.1 Keyboard
Make sure everything on each page works with a keyboard (i.e., everything that can be done with a mouse/touchscreen also can be done without one). Users should be able to reach and interact with all interactive elements on the screen. Ensure that users can scroll to every region of the page.
2.1.2 No Keyboard Trap
Make sure keyboard focus can't be stuck anywhere. Use the TAB and SHIFT+TAB to navigate through the page. Check that standard exit keys work (Enter, Spacebar, ESC). If moving away from a component requires more than TAB or SHIFT-TAB, unmodified arrow keys, Enter, Spacebar, or ESC, verify that the user is provided instructions for moving focus away.
2.1.4 Character Key Shortcuts
Check the help documentation for the existence of any keyboard shortcuts for the webpage. Determine if any single key shortcuts can be turned off, remapped, or are only active when the element is in focus.
2.4.3 Focus Order
Use the tab key on the keyboard to move through each page, and make sure the order that elements receive focus makes sense (it does not have to be top-bottom, left-right). Make sure inactive/disabled parts of pages aren't reached by keyboard. This includes making sure that focus is trapped in dialogs, it is not a failure if non-interactive content receives keyboard focus.
2.4.7 Focus Visible
Use the tab key on the keyboard to move through each page, and make sure there is always a clearly visible way to tell where the focus is. All interactive elements on the page must receive focus. If there are places where the focus indicator is not present, check to see if the default focus indicator is being overridden. Use the tab key on the keyboard to move through each page, and make sure there is always a clearly visible way to tell where the focus is. All interactive elements on the page must receive focus. If there are places where the focus indicator is not present, check to see if the default focus indicator is being overridden.
2.4.11 Focus Not Obscured (Minimum)
Use the keyboard to navigate all the focusable elements on the page and ensure that some part of the element remains visible while each element is in focus.
3.2.1 On Focus
Use the tab key on the keyboard to move through each page and make sure that changing focus does not automatically trigger major unexpected changes to content.
Color Contrast analyzer
These tests use the Color Contrast Analyzer listed on the Evaluation Tools page.
1.4.3 Contrast (Minimum)
Use the dropper/pixel tool in Colour Contrast Analyser to ensure that all text and icons (not including logos and inactive content) have sufficient contrast against their backgrounds (4.5:1 for normal text and 3:1 for large text).
1.4.11 Non-text Contrast
Use the dropper/pixel tool in Colour Contrast Analyser to ensure that the visual presentation of UI components and graphical objects has a contrast ratio of at least 3:1 against adjacent colors.
Reviewing Code
These tests will require you to inspect a page’s underlying code. To get to the code, right-click the page and select “Inspect” from the menu.
3.1.2 Language of Parts
Identify any words, phrases, or passages in a different language from the rest of the page. Inspect the code to see if the language change is properly marked with the lang attribute.
Bookmarklets
These tests require using the JavaScript Bookmarklets for Accessibility Testing listed on the Evaluation Tools page. After you install the bookmarklets, you can click the bookmarklet from the page you want to test. Note: while bookmarklets can be useful tools to test the accessibility of a site quickly, sometimes additional tests are needed to confirm issues.
1.1.1 Non-text Content
Utilizing the bookmarklet that exposes alternative text, make sure all non-text content (images, audio, video, animations, buttons, etc.) has a description that identifies the content or provides equivalent information, unless it is purely decorative (i.e., not meaningful), in which case it should have alt="".
1.4.12 Text Spacing
Utilize the text spacing bookmarklet and visually confirm the text spacing responds by increasing the line height, spacing between paragraphs, letter spacing, and word spacing.
2.4.2 Page Titled
Use the Page Title Bookmarklet to expose the page title and verify that it accurately reflects the page's purpose.
2.5.8 Target Size (Minimum)
Utilize the target size Bookmarklet to determine if target sizes are large enough. With the bookmarklet, green dots are elements with a sufficient target size, and blue dots are elements with a target size that is too small. Note: Links within sentences or blocks of text are out of scope for this criterion.
3.1.1 Language of Page
Utilize the Lang bookmarklet to expose the page’s lang attribute and verify that it accurately reflects the language of the page.