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:
These tests rely on testers to manually review elements on the page.
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.
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.
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.
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.
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.
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.
Ensure the content functions correctly in both landscape and portrait orientations without mandating a specific orientation unless a specific orientation is essential.
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.
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).
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.
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.
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.).
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.
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.
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.
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.
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.
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).
Ensure all headings and labels are accurate, descriptive, and meaningful to the content in that section.
All operation functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture.
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.
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.
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.
Make sure changing form inputs (e.g., checkboxes, drop-downs, text boxes, etc.) does not unexpectedly cause major changes to context.
Make sure items in navigation bars and menus are in the same relative order and placed on all related pages.
Check that help mechanisms provided (if any) are available in the same location on each page within a set of web pages.
Test forms by leaving inputs blank and by filling them with invalid information (e.g., enter "1" for "State" in an address), and make sure 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.
Test forms by leaving inputs blank and by filling them 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.
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).
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.
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.
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.
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 utilize proper list markup and are read out as lists. Headings also should be properly marked up with appropriate heading levels. Headings should only be used to structure the document, not to stylize the text.
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.
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 also can be exposed/checked with the ANDI Bookmarklet.
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 also can be achieved using a single pointer (mouse, pen, or touch) and one or more single-touch actions (tap, click).
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.
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.
Navigate to all the user interface components on the page and ensure that the screen reader correctly conveys 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.).
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 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.
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, is dismissed, or it is no longer valid).
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.
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.
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.
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.
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.
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.
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.
These tests use the Color Contrast Analyzer listed on the Evaluation Tools page.
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).
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.
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.
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.
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.
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="".
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.
Use the Page Title Bookmarklet to expose the page title and verify that it accurately reflects the page's purpose.
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.
Utilize the Lang bookmarklet to expose the page’s lang attribute and verify that it accurately reflects the language of the page.