Accessibility Checklist | BrowserStack Docs
Search`` K
Table of Contents
Search by title
No Result Found
Get your setup working faster. Join our Discord for optimisation tips from elite testers.Join our Discord
Accessibility checklist
You can use the following checklist to comprehensively resolve accessibility issues in your websites. Note that this checklist conforms to WCAG 2.2 AA standards.
Success criteria are categorized as developer-oriented, design-oriented, or content-oriented, based on the type of fix required to resolve the violations.
- Content-oriented fixes generally involve content changes, such as adding alt text, modifying or removing images, adding captions to videos, or other non-technical adjustments.
- Design-oriented fixes typically require adjustments to layout, visual hierarchy, color contrast, spacing, or iconography to enhance accessibility without changing the underlying content or functionality.
- Developer-oriented fixes often involve technical changes or codebase modifications to resolve violations.
WCAG 2.1 A
WCAG 1.1.1 - Non text Content
Compliance level - A
Content-oriented
Testing for compliance
- Review HTML Code: Check the HTML elements to ensure that all images, videos, and other non-text content have appropriate alt attributes or other text alternatives. Example for an informative image:
<img src="dog.jpg" alt="Dog with a bell attached to its collar." />
Copy icon Copy
- Use Assistive Technology: Conduct manual testing by navigating the site using assistive technologies (e.g., screen readers) to verify that non-text content is properly described and accessible.
Common mistakes to avoid
Inadequate Text Alternatives: Providing vague or non-descriptive text alternatives (e.g., using “image” or “graphic” as an alt text) does not fulfill the requirement. Alternatives should convey the purpose and content of the image.
Omitting Alt Attributes: Failing to include alt attributes on images or using empty alt attributes for meaningful images can lead to non-compliance.
Ignoring Decorative Images: While decorative images do not require text alternatives, they should be marked appropriately (e.g., using alt=””) to ensure assistive technologies ignore them.
Static Text Alternatives for Dynamic Content: Not updating text alternatives when the non-text content changes can mislead users relying on assistive technologies.
Using CSS for Important Information: Relying on CSS to convey critical information through images can result in accessibility failures if those images lack proper text alternatives.
References
WCAG 1.2.1 - Audio-only and Video-only (Prerecorded)
Compliance level - A
Content-oriented
Testing for compliance
Check the entire page or application to locate any instances of prerecorded audio-only (e.g., podcasts, speeches) or video-only (e.g., silent animations, tutorials with visual instructions) content.
For Audio-only Content, verify that a text transcript is provided. The transcript should contain all spoken dialogue, non-verbal sounds (e.g., laughter, music, sound effects), and other relevant auditory information.
For Video-only Content, verify that a text description (or an audio description) is provided. The description should convey all essential visual information, including actions, gestures, and other important visual details.
Common mistakes to avoid
Review the provided transcript or description to ensure it accurately represents the content of the audio or video.
Verify that the transcript or description is available near the corresponding audio or video content and is labeled clearly (e.g., “Transcript,” “Audio Description”).
If an audio description is provided for video-only content, ensure it is synchronized with the video so that users can follow the content easily.
References
WCAG 1.2.2 - Captions (Prerecorded)
Compliance level - A
Content-oriented
Testing for compliance
Identify Synchronized Media: Locate all video and audio content on the website that contains synchronized media.
Check for Captions: Verify that each piece of synchronized media has captions available. This can be done by playing the media and observing if captions appear.
Evaluate Caption Content: Ensure that the captions accurately reflect the audio content, including dialogue and significant sound effects.
Review Accessibility Features: Check if captions are enabled by default or easily accessible through the media player controls.
Use Assistive Technology: Test the media with a screen reader or other assistive technology to ensure that users can access the captions effectively.
Common mistakes to avoid
Omitting Captions: Failing to provide captions for synchronized media that contains audio content is a direct violation of this criterion.
Inaccurate Captions: Providing captions that do not accurately represent the spoken dialogue or important sounds can mislead users and fail to convey the necessary information.
Not Labeling Alternatives: If synchronized media serves as an alternative to text, ensure it is clearly labeled as such to avoid confusion regarding the need for captions.
Poor Caption Quality: Captions should be synchronized correctly with the audio. Delayed or poorly timed captions can hinder understanding.
Ignoring User Feedback: Failing to test captions with actual users who are deaf or hard of hearing can result in overlooking critical accessibility issues.
References
WCAG 1.2.3 - Audio Description or Media Alternative (Prerecorded)
Compliance level - A
Content-oriented
Testing for compliance
Identify Video Content: Locate the video that needs evaluation.
Check for Audio Descriptions: Determine if audio descriptions are provided during pauses in dialogue. Assess their accuracy and completeness.
Evaluate Text Alternatives: If audio descriptions are not available, check for a comprehensive text alternative that includes all visual information and non-speech sounds.
Manual Comparison: Perform a cognitive comparison between the original media and the audio descriptions or text alternatives to ensure equivalence.
Common mistakes to avoid
Inadequate Descriptions: Providing insufficient detail in audio descriptions, neglecting to describe important visual actions or context.
Overlooking Text Alternatives: Not offering a full text alternative when audio descriptions are not feasible or when the visual content is critical to understanding.
Ignoring User Controls: Failing to provide user controls for selecting audio descriptions or captions, which can hinder user accessibility.
Assuming All Content is Accessible: Even simple videos may need descriptions for clarity.
References
WCAG 1.3.1 - Info and Relationship
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Review HTML Structure: Examine the HTML markup to ensure that it uses semantic elements appropriately. Use heading tags (
,
, etc.) to create a logical hierarchy and structure in the content.
Check for Labels and Associations: Ensure that form elements (like input fields and checkboxes) have associated labels. Labels should be programmatically linked to their respective controls using the for attribute.Example:
<label for="username">Username:</label>
<input type="text" id="username" />
Copy icon Copy
Evaluate Tables: For tables, verify that header cells (
) are used correctly to define relationships between rows and columns. Each header should be programmatically associated with the corresponding data cells. Use Assistive Technology: Use screen readers or other assistive technologies to navigate the content. Check if the relationships and structures are conveyed correctly to users relying on these tools.
Check Text Descriptions: For any non-programmatically determined information, ensure that clear text descriptions are provided near the relevant content.
Common mistakes to avoid
Inadequate Use of Semantic HTML: Using non-semantic elements (like
or ) for structural purposes instead of appropriate HTML elements can hinder accessibility.Missing Labels: Failing to associate labels with form controls can lead to confusion for users relying on assistive technologies.
Improper Table Markup: Not using
elements correctly or failing to associate headers with data cells can make it difficult for users to understand the table’s structure. Over-reliance on Visual Cues: Relying solely on visual formatting (like color or font size) to convey information without providing programmatic alternatives can exclude users with visual impairments.
Neglecting Text Descriptions: If programmatic determination is not feasible, failing to provide adequate text descriptions can leave users without critical context or information.
References
WCAG 1.3.2 - Meaningful Sequence
Compliance level - A
Developer-oriented
Testing for compliance
Review Content Structure: Examine the HTML structure of the webpage to ensure that it uses semantic elements appropriately. Headings, lists, and tables should be correctly marked up to convey the intended order.
Check Visual vs. DOM Order: Ensure that the visual presentation of the content matches the Document Object Model (DOM) order. Use browser developer tools to inspect the HTML and verify that the order of elements in the markup corresponds to their visual arrangement.
Use Assistive Technologies: Test the webpage with a screen reader to confirm that the content is read in the correct order. Pay attention to whether the sequence makes sense and maintains the intended meaning.
Evaluate Layout Techniques: If CSS is used to position elements visually, ensure that it does not disrupt the logical reading order. Avoid using CSS properties that rearrange elements in a way that confuses the sequence.
Check for Interactive Elements: For pages with forms or interactive elements, ensure that the tab order follows the logical reading sequence, allowing users to navigate through the content intuitively.
Common mistakes to avoid
Inconsistent Order: Using CSS to visually rearrange content without maintaining the same order in the HTML can lead to confusion for users relying on assistive technologies.
Improper Use of White Space: Relying on white space characters to create visual separation or structure can result in a failure to convey the correct order, especially in tables or multi-column layouts.
Incorrectly Marked Tables: Failing to use proper table markup (
,
, ) can lead to a loss of meaning and structure when content is read by assistive technologies. Neglecting Headings: Not using headings correctly to establish a logical hierarchy can make it difficult for users to navigate the content effectively.
Ignoring User Feedback: Failing to test the page with actual users, especially those who rely on assistive technologies, can result in overlooking critical accessibility issues.
References
WCAG 1.3.3 Sensory Characteristics
Compliance level - A
Design-oriented
Testing for compliance
Review the entire page to identify any instructions provided to the user, especially those guiding navigation, interaction, or understanding of the content (e.g., “click the button to the right,” “select the green square,” or “follow the red arrow”).
Verify that instructions do not rely solely on sensory characteristics like color, shape, size, visual location, sound, or orientation. For example, instructions should not only state “click the green button” but should provide additional context, such as “click the green button labeled ‘Submit’.”
Ensure that instructions are understandable even if the user cannot perceive visual or auditory cues. For example, instructions should not rely on phrases like “the red line,” “the loud beep,” or “the square icon” without additional context that clarifies the instruction’s purpose.
Ensure that the content provides sufficient text-based instructions that describe the purpose or function, not just the sensory attributes.
Common mistakes to avoid
- Evaluate the language used in instructions to ensure clarity and consistency. Instructions should not rely on references that could be ambiguous (e.g., “Choose the link above” if there are multiple links).
References
WCAG 1.4.1 - Use of Color
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Visual Inspection: Review the website visually to identify instances where color is the only means of conveying information. Look for elements like error messages, required fields in forms, and charts or graphs.
Grayscale Viewing: Temporarily change your display settings to grayscale or use a browser extension that simulates color blindness. This helps to identify whether critical information can still be understood without color.
Check Forms and Indicators: Ensure that form fields, such as required fields or error messages, include text labels or symbols in addition to color cues. For example, a required field should be marked with an asterisk (*) and not just highlighted in red.
Evaluate Charts and Graphs: For charts or graphs, confirm that color is not the only way to distinguish between different data sets. Use patterns, textures, or labels to differentiate elements.
Use Accessibility Tools: Employ accessibility evaluation tools that can help identify color-related issues, such as contrast checkers or color blindness simulators.
Common mistakes to avoid
Relying Solely on Color: Using color alone to indicate required fields, error messages, or important content without supplementary text or symbols.
Inadequate Contrast: Failing to ensure sufficient contrast between text and background colors, which can make content difficult to read for users with low vision.
Ignoring Color Blindness: Not considering users who are color blind when designing color schemes, leading to situations where they cannot distinguish between critical elements.
Neglecting Additional Cues: Failing to provide alternative visual cues, such as underlines for links or patterns for data in graphs, which can exclude users who cannot perceive color differences.
References
WCAG 1.4.2 - Audio Control
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Identify Autoplay Audio: Check the webpage for any audio that plays automatically upon loading. This includes background music, sound effects, or any audio content that starts without user interaction.
Test Audio Controls: Verify that there are visible controls available for the audio, such as play, pause, stop, and volume adjustments. Ensure these controls are easily accessible and intuitive.
Functionality Check: Test the functionality of the audio controls. Ensure that:
The pause or stop button effectively halts playback.
The volume control allows users to adjust the audio level independently from the system volume.
Keyboard Navigation: Ensure that all audio controls can be operated using a keyboard alone. Users should be able to navigate to the controls and operate them without needing a mouse.
User Experience: Consider the placement of audio controls. They should be prominently displayed, ideally at the top of the page, so users can access them immediately if audio plays automatically.
Common mistakes to avoid
No Controls Provided: Failing to provide any mechanism to pause, stop, or control audio volume for automatically playing audio content.
Unpredictable Controls: Designing audio controls that are not intuitive or are difficult to find, which can frustrate users.
Inaccessible Controls: Not ensuring that audio controls can be operated via keyboard navigation, which excludes users who cannot use a mouse.
Autoplay Audio: Using autoplay for audio content without considering the user experience. Autoplay can be disruptive, especially if it competes with other audio outputs like screen readers.
Background Audio: Including background audio that plays continuously without user control, which can distract or overwhelm users, especially those with hearing impairments.
References
WCAG 2.1.1 - Keyboard
Compliance level - A
Developer-oriented
Testing for compliance
Keyboard Navigation: Use the keyboard to navigate through the website. Ensure that all interactive elements can be accessed using the Tab key, and that users can activate them using the Enter or Space key.
Focus Indicators: Check for visible focus indicators (such as outlines or highlights) on interactive elements when they are selected using the keyboard. This helps users identify which element is currently focused.
Form Controls: Test all form elements (e.g., text fields, checkboxes, radio buttons) to ensure they can be accessed and manipulated using the keyboard.
Skip Navigation: Look for “skip to content” links or similar mechanisms that allow users to bypass repetitive navigation links and jump directly to the main content.
No Keyboard Traps: Ensure that users can navigate away from all interactive elements using the keyboard. There should be no instances where users get “trapped” in an element and cannot exit without using a mouse.
Testing with Assistive Technologies: If possible, test the site with assistive technologies like screen readers to ensure that keyboard navigation works seamlessly with these tools.
Common mistakes to avoid
Missing Keyboard Focus: Failing to provide visible focus indicators on interactive elements can make it difficult for keyboard users to navigate.
Keyboard Traps: Creating interactive elements that do not allow users to escape using the keyboard, forcing them to use a mouse.
Inaccessible Form Elements: Not ensuring that all form controls are operable via keyboard, which can exclude users with mobility impairments.
Complex Navigation: Designing navigation that requires mouse actions (like hover menus) without providing keyboard alternatives can hinder accessibility.
Timing Restrictions: Imposing time limits on actions that cannot be extended or adjusted can create barriers for users who need more time to navigate using a keyboard.
References
WCAG 2.1.2 - No Keyboard Trap
Compliance level - A
Developer-oriented
Testing for compliance
Ensure that there are no elements or components where the keyboard focus becomes trapped, preventing the user from moving focus away from that element.
For modals, pop-ups, or dialogs, verify that the focus can move to and from the modal or dialog and back to the underlying page content.
Confirm that if a specific key or keystroke is required to move focus away from an element (such as Esc to close a modal or popup), this is clearly communicated to the user.
Common mistakes to avoid
Test any custom components or widgets (e.g., carousels, accordions, dropdown menus) to ensure that the focus can move in and out of these components using only the keyboard.
Verify that when interacting with dynamically updated content (such as expanding/collapsing sections or loading new content), the focus does not become trapped or lost.
References
WCAG 2.1.4 - Character Key Shortcuts
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Review the entire page to identify any keyboard shortcuts that use a single character key (letters, numbers, punctuation, or symbols).
Verify that users have a way to disable single character key shortcuts if they cause unintended actions.
Ensure there is a way for users to remap single character key shortcuts to a different key or key combination.
Common mistakes to avoid
Check if the remapping single character key shortcuts option is accessible and easy to locate and use.
Ensure that there are clear instructions on how to disable or remap single character key shortcuts within the website or application’s accessibility settings.
References
WCAG 2.2.1 - Timing Adjustable
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Identify Time-Based Media: Locate all instances of time-based media on the website, including videos, audio files, and any interactive elements that require timed responses.
Check for Controls: Ensure that there are controls available for users to pause, stop, or adjust playback speed. Verify that these controls are easily accessible and intuitive.
Test Functionality: Interact with the media using the provided controls. Confirm that users can pause or stop the media and that playback speed can be adjusted if applicable.
Evaluate User Experience: Assess whether the timing adjustments allow users to engage with the content effectively. This might include checking if users can replay sections or slow down the playback speed.
Keyboard Accessibility: Ensure that all controls for adjusting timing can be operated using a keyboard alone, allowing users who cannot use a mouse to interact with the media.
Common mistakes to avoid
Lack of Controls: Failing to provide any controls for users to pause, stop, or adjust the timing of time-based media.
Inaccessible Controls: Designing controls that are not easily accessible or intuitive, which can frustrate users trying to interact with the media.
No Playback Speed Options: Not offering options to adjust playback speed, which can hinder users who need slower playback to comprehend the content.
Ignoring Keyboard Navigation: Not ensuring that all media controls are operable via keyboard, excluding users with mobility impairments.
Inconsistent Timing: Creating time-based media that does not allow users to pause or replay sections, which can lead to confusion and hinder understanding.
References
WCAG 2.2.2 - Pause, Stop, Hide
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Identify Time Limits: Locate any time limits set by the content, such as session timeouts, timed quizzes, or real-time events.
Check for Turn Off or Adjust: Verify that users can either turn off the time limit or adjust it to a wide range (at least ten times the default setting).
Evaluate Warning and Extension: If the time limit cannot be turned off or adjusted, ensure that users are warned before the time expires and given at least 20 seconds to extend the limit with a simple action (e.g., pressing the space bar). Users should be allowed to extend the limit at least ten times.
Identify Real-time or Essential Exceptions: If the time limit is part of a real-time event or is essential to the activity, ensure that this is clearly communicated to users.
Test with Assistive Technology: Use screen readers or other assistive technologies to ensure that the time limit information and controls are accessible to users relying on these tools.
Common mistakes to avoid
Lack of Time Limit Controls: Failing to provide any mechanism for users to turn off, adjust, or extend time limits.
Insufficient Warning and Extension Time: Not giving users enough time to extend the limit (at least 20 seconds) or not allowing them to extend it enough times (at least ten).
Unclear Exception Explanations: Not clearly communicating to users when a time limit is part of a real-time event or is essential to the activity.
Inaccessible Time Limit Information: Not ensuring that time limit information and controls are accessible to users with disabilities, particularly those using assistive technologies.
References
WCAG 2.3.1 - Three Flashes or Below Threshold
Compliance level - A
Content-orientedDesign-oriented
Testing for compliance
Identify any elements or components that include flashing, blinking, or rapid changes in brightness or color. This includes videos, animations, GIFs, slideshows, ads, and other dynamic content.
Check if any identified flashing content flashes more than three times in any one-second period.
Ensure that the flashing area is not too large or intense, as this can increase the risk of triggering seizures.
Common mistakes to avoid
Pay special attention to any custom components, such as loading spinners, button animations, or visual effects triggered by user actions (e.g., hover effects, focus changes).
Ensure that flashes are not composed of contrasting red content against any color background, as this can increase risk.
Verify that the flashing does not become more intense or noticeable on different background colors or textures.
References
WCAG 2.4.1 - Bypass Blocks
Compliance level - A
Developer-oriented
Testing for compliance
Identify Navigation Elements: Review the webpage to identify all navigation elements, such as menus, links, and buttons that allow users to move to other pages or sections.
Check for Consistency: Ensure that navigation elements are consistent across all pages of the website. Users should be able to find navigation in the same location and format throughout the site.
Test Functionality: Click on each navigation element to confirm that it functions correctly and leads to the intended page or section. Ensure that users can navigate back to the previous page or return to the homepage easily.
Keyboard Navigation: Use the keyboard to navigate through the website. Ensure that users can access all navigation elements using the Tab key and can activate them using the Enter or Space key.
Evaluate Visibility: Ensure that navigation elements are clearly visible and easily identifiable. They should stand out from the rest of the content to help users locate them quickly.
Common mistakes to avoid
Inconsistent Navigation: Changing the location or format of navigation elements from page to page can confuse users and hinder their ability to navigate the site.
Missing Navigation Links: Failing to provide links to important pages, such as the homepage, contact page, or site map, can make it difficult for users to find their way around.
Poorly Labeled Links: Using vague link text (e.g., “click here”) that does not describe the destination can confuse users, especially those using screen readers.
Inaccessible Navigation: Designing navigation elements that cannot be accessed via keyboard or assistive technologies can exclude users with disabilities.
Overly Complex Navigation: Creating overly complicated navigation structures with too many options can overwhelm users and make it difficult for them to find what they need.
References
WCAG 2.4.2 - Page Titled
Compliance level - A
Content-oriented
Testing for compliance
- Check the Title Element: Inspect the HTML of each webpage to ensure that it has a element within the section. The title should be concise and descriptive.Example:
<head> <title>Contact Us - Company Name</title> </head>Copy icon Copy
Evaluate Title Clarity: Read the title as a user would and determine if it clearly conveys the content or purpose of the page. It should provide enough context to understand what to expect upon visiting the page.
Use Assistive Technology: Use screen readers to navigate through the website and listen to how the titles are read aloud. Ensure that they provide meaningful information about each page.
Consistency Across Pages: Ensure that titles are consistent in format across similar pages (e.g., all product pages should follow a similar titling convention).
Browser Tab Inspection: Open multiple tabs in a web browser and observe if each tab’s title helps you identify its content without needing to switch back and forth.
Common mistakes to avoid
Generic Titles: Using vague titles like “Home” or “Page 1” does not provide sufficient context about the content of the page.
Missing Titles: Failing to include a title element altogether can lead to confusion for users navigating through multiple pages.
Inconsistent Title Formats: Using different formats for similar pages can confuse users and make navigation more difficult.
Overly Long Titles: While titles should be descriptive, excessively long titles can be truncated in browsers or assistive technologies, which may lead to loss of important information.
Not Considering User Context: Titles should reflect not only the content but also consider how users might search for or reference that content.
References
WCAG 2.4.3 - Focus Order
Compliance level - A
Developer-oriented
Testing for compliance
Identify Interactive Elements: Review the webpage to identify all interactive elements, including links, buttons, form fields, and any other controls that users can interact with.
Tab Navigation: Use the Tab key to navigate through the interactive elements on the page. Observe the order in which the focus moves from one element to another.
Visual Inspection: Ensure that the focus order matches the visual layout of the page. The focus should move in a logical sequence that reflects how users would naturally read or interact with the content.
Keyboard Shortcuts: Check if any keyboard shortcuts or custom navigation methods are used and ensure they do not disrupt the logical focus order.
Use Assistive Technology: Test the webpage using screen readers or other assistive technologies to verify that they convey the focus order correctly to users.
Common mistakes to avoid
Non-Sequential Focus Order: Creating a focus order that does not follow a logical sequence can confuse users, especially those relying on keyboard navigation.
Overlapping Elements: Having overlapping interactive elements can lead to unpredictable focus behavior, making it difficult for users to navigate effectively.
Inconsistent Navigation: Changing the focus order between different pages or sections can disorient users and hinder their ability to navigate.
Using CSS for Visual Arrangement Only: Relying solely on CSS for visual arrangement without ensuring that the HTML structure reflects this arrangement can result in an illogical focus order.
Neglecting Form Elements: Failing to ensure that form fields are included in a logical sequence can create barriers for users filling out forms.
References
WCAG 2.4.4 - Link Purpose (In Context)
Compliance level - A
Content-oriented
Testing for compliance
Review Link Text: Examine all links on the webpage to ensure that the text used for each link clearly indicates its purpose or destination. Avoid using vague phrases like “click here” or “read more.”
Contextual Evaluation: Consider the context in which each link appears. Ensure that even if the link text is not descriptive enough on its own, the surrounding content provides sufficient context to understand its purpose.
Keyboard Navigation: Use keyboard navigation to tab through links on the page and listen to how they are read by a screen reader. Ensure that each link conveys its purpose clearly when announced.
Check for Redundancy: Ensure that links do not repeat unnecessarily within close proximity unless they lead to different destinations or actions.
Use Assistive Technology: Use screen readers to navigate through the links and verify that users can easily discern their purpose based on the link text and surrounding context.
Common mistakes to avoid
Vague Link Text: Using generic phrases such as “click here” or “more info” that do not provide meaningful information about where the link leads.
Lack of Context: Providing links without sufficient surrounding content that explains their purpose, making it difficult for users to determine their destination.
Inconsistent Link Text: Using different link texts for similar destinations can confuse users and make navigation less intuitive.
Overloading Links: Having multiple links in close proximity with similar text can overwhelm users and make it difficult to discern their differences.
Ignoring Visual Cues: Relying solely on visual cues (like color changes) to indicate links without ensuring that text alone conveys their purpose can exclude users with visual impairments.
References
WCAG 2.5.1 - Pointer Gestures
Compliance level - A
Developer-oriented
Testing for compliance
Identify components using complex gestures: Find all elements or functionalities that require multi-pointer or path-based gestures. Path-based gestures differ from dragging movements as not just the end points, but the path taken while performing the gesture is also important for ensuring the action is successful. Multi-pointer movements require starting a pointer movement that goes through at least one intermediate point before the end-point.
Test for simpler, single-point alternatives: Verify that users can perform the same action using simpler, single-point gestures like a tap, click, or keyboard input.
Check for accidental gesture triggers: Ensure that users can interact with elements without accidentally triggering a gesture.
Verify user instructions: Ensure that any instructions provided for gesture-based interactions are clear and easily understandable. If multi-pointer gestures are available (e.g., pinch-to-zoom), there should be clear alternatives explained for users who cannot perform them.
Repeat the above steps with different input devices and across different assistive technologies. Note that some elements could behave differently on different devices. For example, a slider on a touch-screen device requires a straight-line motion, but only requires a horizontal right to left movement with a mouse (the gesture is independent of the vertical motion of the mouse). It is thus path-based on the touch-screen device only, and not on the device using a mouse. Hence, it is important to test using different devices and, similarly, different assistive technologies.
Common mistakes to avoid
Relying solely on path-based gestures for interactions: Users should be able to interact using keyboard or single-tap/click mechanisms as alternatives.
Complex, unintuitive alternatives: Offering an alternative interaction that is overly complex or difficult to use is not compliant. For example, providing a complex set of keyboard shortcuts to achieve the gesture without clear instructions can be problematic.
Lack of visual feedback: When providing an alternative, it’s important to give clear visual feedback, such as highlighting the item that is being moved or changed.
References
- Pointer Gestures (Level A)
- Failure of Success Criterion 2.5.1 due to providing functionality via a path-based gesture without simple pointer alternative
WCAG 2.5.2 - Pointer Cancellation
Compliance level - A
Developer-oriented
Testing for compliance
Identify interactive elements: Find interactive elements that users can activate using a pointer (mouse, touch, or stylus), such as buttons, links, form fields, etc.
Test pointer activation: For each interactive element, verify that either:
- The action is triggered on release (i.e., when the pointer is lifted) and not when the pointer is initially pressed, or
It is possible to abort or undo the action after completion, or
The release of the pointer reverses the action, or
It is ultimately essential to the functionality that pressing the pointer triggers the action.
Check for keyboard alternatives: Verify that users who rely on keyboard navigation have a comparable experience. The action should only occur when the key is released (like with the pointer).
Look for feedback on cancelation: Ensure that users receive clear feedback if they cancel a pointer action.
Repeat the above steps with different input devices and across different assistive technologies.
Common mistakes to avoid
Triggering actions on pointer down: A common mistake is triggering an action (such as a button press) as soon as the user touches or presses down on the pointer, without waiting for them to release.
No cancelation option: If users cannot cancel a pointer-based action (e.g., by moving the pointer away or lifting a touch before release), it violates this criterion.
Poor visual feedback during interaction: Not providing clear visual or auditory feedback during pointer interactions can make it difficult for users to understand whether an action has been initiated or can be canceled.
Inconsistent behavior across input methods: Ensure that the same behavior applies across all input types.
References
WCAG 2.5.3 - Label in Name
Compliance level - A
Developer-oriented
Testing for compliance
Ensure Visible Labels are included in Accessible Names: The accessible name (e.g., aria-label or aria-labelledby) of a component must include the visible text that users can see as its visible label. Do not provide an accessible name that differs from the visible text. Even if extra information is added programmatically (e.g., “Send Form” instead of “Submit”), it should at least contain the visible label. Steps to test:
- Identify interactive elements like buttons, links, etc.
Use assistive technologies like a screen reader (eg. NVDA, VoiceOver) to compare their visible labels to their announced accessible name
Common mistakes to avoid
Mismatched labels: The accessible name uses a different word than the visible label. For example, the visible text says “Search” but the aria-label says “Go”.
Using placeholder text instead of labels: Placeholder text inside form fields might not be included in the accessible name. Placeholder text also gets removed once the user starts typing in, so it does not substitute accessible labels.
Missing or incorrect aria-label / aria-labelledby, using empty or generic labels
Labels via pseudo-elements or background images, without corresponding accessible names
References
- Label in Name (Level A)
- Failure due to the accessible name not containing the visible label text
- Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name
WCAG 2.5.4 - Motion Actuation
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Identify functionality triggered by motion, such as shaking, tilting, or rotating the device. On a mobile device or a device that supports motion sensors, verify that the intended motion activates the desired functionality.
Check for alternative input methods: Ensure that all motion-actuated features have alternative ways to perform the same action. Test if users can trigger the same function using standard input methods like keyboard navigation or touch/click gestures.
Disable motion actuation: Ensure there is a mechanism to disable motion actuation, particularly in environments where such movements could be accidental.
- Look for an option in the settings or controls to disable motion-based features.
Verify that when motion actuation is disabled, users can still perform the same action using alternative input methods.
Common mistakes to avoid
Providing no alternative input or no option to disable motion-based interaction.
Complex or hidden alternatives: Providing an alternative that is difficult to use or hard to find defeats the purpose. Ensure that the alternative is easy to access and intuitive, such as a clearly labeled button or keyboard shortcut.
No feedback on alternative input: When users trigger functionality through alternative input methods, there should be clear visual, auditory, or tactile feedback indicating that the action was successful.
References
WCAG 3.1.1 - Language of Page
Compliance level - A
Developer-oriented
Testing for compliance
- Check HTML Language Attribute: Inspect the HTML of the webpage to ensure that the tag includes a lang attribute that specifies the primary language.Example:
<html lang="en">Copy icon Copy
- Evaluate Multiple Languages: If the page contains content in multiple languages, ensure that each section is marked up correctly with the appropriate lang attribute.Example:
<p lang="fr">Bonjour, comment ça va?</p> <p lang="en">Hello, how are you?</p>Copy icon Copy
Test with Assistive Technology: Use screen readers to navigate through the webpage and verify that they correctly announce the language of the content based on the lang attributes.
Visual Inspection: Review the page visually to confirm that any language changes are clearly indicated and contextually appropriate.
Browser Developer Tools: Use browser developer tools to check for any errors or warnings related to language attributes in the markup.
Common mistakes to avoid
Missing Language Attribute: Failing to include a lang attribute in the tag can lead to confusion for users relying on assistive technologies.
Incorrect Language Specification: Using an incorrect or generic language code (e.g., lang=”en” instead of lang=”en-US” for American English) may result in improper pronunciation or understanding by screen readers.
Inconsistent Language Markup: Not marking up sections with different languages correctly can confuse users and hinder comprehension.
Neglecting Contextual Changes: If a page includes content in multiple languages, failing to indicate changes in language can disrupt the reading flow and understanding for users.
References
WCAG 3.2.1 - On Focus
Compliance level - A
Developer-oriented
Testing for compliance
Navigate and Focus on Interactive Elements: Use the Tab key to navigate through the page and set focus on interactive elements like buttons, input fields, dropdowns, and links. Check what happens when an element receives focus (i.e., is highlighted but not yet clicked or activated).
Observe Contextual Changes: After focusing on an element (but not activating it), ensure that:
No page automatically reloads.
No modal or pop-up automatically appears.
No content is rearranged or removed.
Focus does not shift unexpectedly to another part of the page.
Use Assistive Technology: Use screen readers or other assistive technologies to ensure that setting focus does not trigger unintended context changes.
Common mistakes to avoid
Auto-Submit Forms on Focus: Forms that automatically submit when a user selects or focuses on a dropdown option, radio button, or checkbox should be avoided. Any form submission or action should happen only when the user explicitly interacts, like pressing Enter or clicking.
Opening New Windows or Tabs: Any new content should be presented only after explicit user interaction (like clicking a link).
Unexpected Focus Shifts: Focus should not automatically shift to another part of the page (e.g., a pop-up) when a user focuses on a form field, dropdown, or link. Shifts in focus should occur only after user-triggered actions, such as form submission or clicking.
Auto-Scrolling or Automatic Movements: No part of the page should scroll automatically when a focus event happens.
References
WCAG 3.2.2 - On Input
Compliance level - A
Developer-oriented
Testing for compliance
Identify all input elements and test their behaviour on input change: Locate all user interface components that accept user input, like checkboxes, radio buttons, etc. Interact with each input component (e.g. entering text, selecting checkboxes, changing dropdown values) to observe if any unexpected changes occur, such as:
- Automatic form submission
Navigation to a new page or section
Major updates to the content or layout (e.g., window pop-ups, refresh of the page, hiding/showing content)
Check for explicit user action requirements: Ensure that any significant changes are only triggered by explicit user actions, like pressing the “Submit” button. If changes occur on input (such as updating a dynamic form), check whether the user is informed that changing the input will lead to these actions.
Test with keyboard navigation: Verify that no unexpected changes occur as a result of merely selecting or moving through fields.
Repeat the above with different assistive technologies and different input types.
Common mistakes to avoid
Triggering navigation or form submission on input change: Ensure that major actions (e.g., form submission, page redirection) are only triggered by explicit user actions, like clicking a button.
No user notification of changes: Failing to notify users when input changes cause significant actions (e.g., reloading a page, showing/hiding content) can create confusion.
Unexpected content updates, window pop-ups or page refreshes: Avoid automatically refreshing the page, triggering modals or pop-ups, or dynamically changing large portions of the content when users input data.
Inaccessible instructions: Not providing clear, accessible instructions when input changes will cause significant actions.
Poor handling of focus: When input changes cause content to update, focus can shift inappropriately, disorienting users of assistive technologies. Ensure that focus remains logical and clear.
References
- On Input (Level A)
- Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value
- Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the selection of a radio button, check box or select list is changed
WCAG 3.3.1 - Error Identification
Compliance level - A
Developer-oriented
Testing for compliance
Identify forms and input fields: Locate all forms and input fields on the website or application where user input is required.
Test submitting a form with errors: Purposely submit the form with incomplete or incorrect input (e.g., leave required fields empty or enter invalid data) to trigger error messages.
Check for visible error messages: Verify that error messages appear and are clearly visible in the interface. The error message should be in text form and describe the error precisely (e.g., “Please enter a valid email address” instead of a vague “Invalid input”).
Check for inline error messages: Ensure that error messages are provided near the problematic input field. For example, the message “This field is required” should appear next to the specific form field that has the error, not as a generic message at the top of the form.
Test with focus and keyboard navigation: Navigate through the form using only the keyboard to confirm that errors are accessible without using a mouse.
Common mistakes to avoid
No clear error message: A common mistake is to either not display any error message at all, or to display messages that are too vague.
Insufficient instructions: Clear instructions are often not provided to assist a user in filling out a form without making mistakes.
Errors only indicated visually: Relying solely on visual cues like red borders around input fields without providing accompanying text can make it difficult for screen reader users or those with color blindness to identify errors.
Poorly located error messages: Placing error messages far from the input fields can make it difficult for users to understand which input is causing the issue.
No real-time error feedback: If users are only notified of errors after form submission and not during the input process, they might make multiple errors, increasing frustration.
Inconsistent error identification: Providing inconsistent or incomplete error identification across different input fields can confuse users and prevent them from successfully submitting forms.
References
WCAG 3.3.2 - Labels or Instructions
Compliance level - A
Content-oriented
Testing for compliance
Identify User Input: Review the webpage to locate all areas where user input is required, such as form fields, search boxes, or interactive elements.
Check for Labels: Ensure that each user input area has a clearly associated label that describes the purpose of the input. Labels should be programmatically associated with the corresponding input element.Example:
<label for="username">Username:</label> <input type="text" id="username" />Copy icon Copy
Evaluate Label Clarity: Read the labels and instructions to determine if they provide sufficient information for users to understand what input is expected and how to provide it.
Test with Assistive Technologies: Use screen readers or other assistive technologies to navigate through the user input areas and verify that the labels and instructions are conveyed clearly to users.
Check for Consistency: Ensure that labels and instructions are consistent across similar user input areas throughout the website.
Common mistakes to avoid
Missing Labels: Failing to provide labels or instructions for user input areas can lead to confusion and frustration for users.
Unclear or Ambiguous Labels: Using vague or unclear labels that do not adequately describe the purpose of the user input can hinder users from providing the correct information.
Inconsistent Labeling: Using different labeling conventions for similar user input areas across the website can make it difficult for users to understand and navigate consistently.
Relying on Visual Cues Alone: Providing labels or instructions that are only visible visually, without ensuring they are also conveyed to assistive technologies, can exclude users who rely on those technologies.
Placing Labels in Inappropriate Locations: Positioning labels in a way that makes it unclear which input they are associated with can confuse users and make it difficult to understand the purpose of the input.
References
WCAG 4.1.1 - Parsing
Compliance level - A
Developer-oriented
Current Status: As of WCAG 2.2, SC 4.1.1 is no longer required for compliance, as it is considered always satisfied for content using HTML or XML.
Testing for compliance
Check Markup Validity:
- Ensure all elements have complete start and end tags.
Verify that elements are properly nested according to their specifications.
Check that there are no duplicate attributes within elements.
Confirm that IDs are unique unless specified otherwise by the markup language.
Use Validation Tools:
- Utilize HTML validators to check for errors in your markup.
Focus on related success criteria like Name, Role, Value (ARIA) and Info and Relationships.
Common mistakes to avoid
Ignoring Browser Compatibility: Not all browsers handle parsing errors the same way; ensure your content is tested across multiple browsers to see how it behaves.
Neglecting ARIA Attributes: Duplicate IDs can cause issues with ARIA roles; ensure unique identifiers are used consistently throughout the document.
Overlooking Nested Elements: Failing to properly nest elements can lead to parsing issues that affect how assistive technologies interpret content.
Assuming All Errors Are Accessibility Issues: Not all markup errors directly impact accessibility; focus on those that affect user experience and assistive technology performance.
References
WCAG 4.1.2 - Name, Role, Value
Compliance level - A
Content-orientedDesign-orientedDeveloper-oriented
Testing for compliance
Identify Interactive Components: List all interactive elements on your page, including buttons, links, form fields, and custom controls.
Check Accessible Names: Ensure each component has an accessible name:
- For standard HTML elements, this is often provided by the element or the aria-label attribute.
For custom components, use aria-label or aria-labelledby to define names where necessary.
Verify Roles: Confirm that each component has an appropriate role:
- Standard HTML elements automatically have roles (e.g., has a role of “button”).
For custom elements (like
or ), assign roles explicitly using the role attribute.Test State and Value Changes: Ensure that any state changes (like checked/unchecked for checkboxes) are programmatically determinable:
- Use browser developer tools or accessibility evaluation tools to check if changes are reflected in assistive technologies.
Use Accessibility Tools: Utilize tools like screen readers (e.g., NVDA or JAWS) to navigate through your components and verify that they announce the correct names, roles, and states.
Common mistakes to avoid
Neglecting Roles for Custom Controls: Failing to provide a role for custom controls created with generic HTML elements (like
or ) can lead to accessibility issues.Inadequate Naming: Not updating accessible names when content changes or not providing names at all can prevent users from understanding what actions they can take.
Ignoring State Changes: If state changes (like focus or selection) are not programmatically determinable, users may be unaware of the current status of a control.
Using Non-Accessible Elements: Relying on non-standard HTML elements without proper ARIA roles and properties can lead to significant accessibility barriers.
References
WCAG 2.1 AA
WCAG 1.2.4 - Captions (Live)
Compliance level - AA
Content-oriented
Testing for compliance
Review the entire page or application to locate any instances of live audio content in synchronized media (e.g., live broadcasts, webinars, video conferences, online meetings).
Verify that live captions are provided for all live audio content. Captions should be displayed in real-time and accurately represent the spoken dialogue and non-speech sounds (e.g., laughter, applause).
Common mistakes to avoid
Ensure that the captions are always visible or have an easy-to-use control to enable them if needed.
Ensure that captions are synchronized with the audio content in real-time, without significant delays.
References
WCAG 1.2.5 - Audio Description (Prerecorded)
Compliance level - AA
Content-oriented
Testing for compliance
Check the entire page or application to locate all instances of prerecorded video content with synchronized audio.
Verify that audio descriptions are provided for all prerecorded video content that contains visual information not conveyed in the existing audio.
Make sure that audio descriptions narrate relevant visual details such as actions, characters, settings, expressions, or changes in scenes that are necessary to understand the content.
For websites or applications that offer content in multiple languages, verify that audio descriptions are available in all relevant languages.
Common mistakes to avoid
Verify that the descriptions include all necessary details such as character movements, facial expressions, scene changes, on-screen text, and any other important visual information.
Confirm that users can easily turn the audio descriptions on or off using keyboard controls, voice commands, or other assistive technologies.
Ensure that the description is concise but informative, providing just enough detail without overwhelming the listener.
References
WCAG 1.3.4 - Orientation
Compliance level - AA
Developer-oriented
Testing for compliance
Check that the content is viewable and usable in both portrait and landscape orientations on all devices (desktop, tablet, mobile).
Verify that there is no functionality loss or content that becomes inaccessible or unreadable when switching orientations.
Ensure that the content does not automatically lock or force a specific orientation unless necessary.
Ensure that text does not become clipped, truncated, or overlap with other elements in different orientations.
Common mistakes to avoid
Check if text, images, and other UI elements (e.g., buttons, links, form fields) properly adapt when switching between portrait and landscape orientations.
Ensure that text does not become clipped, truncated, or overlap with other elements in different orientations.
Check that the application or website does not disable or override device-specific settings for orientation (e.g., lock screen orientation).
References
WCAG 1.3.5 - Identify Input Purpose
Compliance level - AA
Developer-oriented
Testing for compliance
Identify Input Fields: List all input fields in your form that collect user information.
Check Autocomplete Attributes: Ensure that each input field has a valid autocomplete attribute that corresponds to its purpose:
*For example, use autocomplete=”name” for a name field or autocomplete=”email” for an email address field.
Verify Labels: Ensure that each input field has a visible label associated with it:
- Use elements correctly linked to their corresponding input fields using the for attribute.
Use Browser Tools: Utilize browser developer tools to inspect the HTML structure and confirm that the autocomplete attributes are correctly implemented.
Test with Assistive Technologies: Use screen readers or other assistive technologies to navigate through the form and confirm that they announce the purpose of each input field correctly.
Common mistakes to avoid
Inadequate Autocomplete Values: Not using appropriate values for the autocomplete attribute can lead to confusion about what information is expected in each field.
Missing Labels: Omitting visible labels for input fields can make it difficult for users to understand their purpose, especially if they rely on assistive technologies.
Using Placeholder Text as Labels: Relying solely on placeholder text instead of proper labels can be problematic because placeholders disappear when users start typing, making it hard for users to remember what information is required.
Dynamic Fields Without Proper Identification: For dynamically generated fields, ensure they are properly labeled and have appropriate autocomplete attributes set after they are created.
References
WCAG 1.4.3 - Contrast (Minimum)
Compliance level - AA
Design-oriented
Testing for compliance
Identify Text Elements: List all text elements on your webpage, including headings, paragraphs, buttons, and images of text.
Check Contrast Ratios: Use a contrast checker tool or manually calculate the contrast ratio using the formula: Contrast Ratio = ( L1 + 0.05 ) / ( L2 + 0.05) where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color.
Measure Relative Luminance: Determine the relative luminance values for both foreground (text) and background colors:
- For sRGB colorspace, convert RGB values to relative luminance using: L = 0.2126 * R + 0.7152 * G + 0.0722 * B
- R, G and B are defined as:
- If RsRGB <= 0.04045, then R = RsRGB / 12.92;
- else R = (( RsRGB + 0.055 ) / 1.055 ) ^ 2.4
- If GsRGB <= 0.04045, then G = GsRGB / 12.92;
- else G = (( GsRGB + 0.055 ) / 1.055 ) ^ 2.4
- If BsRGB <= 0.04045, then B = BsRGB / 12.92;
- else B = (( BsRGB + 0.055 ) / 1.055 ) ^ 2.4
- RsRGB, GsRGB, and BsRGB are defined as:
- RsRGB = R8bit / 255
- If RsRGB <= 0.04045, then R = RsRGB / 12.92;
- R, G and B are defined as:
- For sRGB colorspace, convert RGB values to relative luminance using: L = 0.2126 * R + 0.7152 * G + 0.0722 * B
GsRGB = G8bit / 255
BsRGB = B8bit / 255
Note: ^ character denotes the exponentiation operator. (Formula taken from sRGB encoding.)
- Ensure that you measure under normal usage conditions, considering any specified background color.
Review Exceptions: Confirm that any text exempt from contrast requirements falls into one of the specified categories (decorative, inactive UI components, or logos).
Review Contrast Ratio: The following contrast ratio is to be maintained:
- Normal Text: For text that is less than 18 points (not bold) or less than 14 points (bold), a contrast ratio of at least 4.5:1 is required.
Large Text: For text that is at least 18 points (not bold) or at least 14 points (bold), a lower contrast ratio of 3:1 is required.
Common mistakes to avoid
Inadequate Contrast Ratios: Failing to achieve the minimum contrast ratios for both normal and large text can lead to readability issues.
Not Specifying Background Colors: If no background color is specified when a text color is defined, it can lead to unknown contrast levels, making it impossible to evaluate compliance.
Using Background Images Without Sufficient Contrast: Relying on background images without ensuring they provide adequate contrast with foreground text can violate this criterion.
Overlooking Decorative Text: Assuming all text has a contrast requirement without considering if it serves a functional purpose can lead to unnecessary violations.
References
WCAG 1.4.4 - Resize Text
Compliance level - AA
Developer-oriented
Testing for compliance
Resize the Text: Use the browser’s zoom functionality (usually Ctrl + “+” or Ctrl + “-“) to increase the size of the text up to 200%. Alternatively, adjust the text size in browser settings.
Check for Content Loss: As you resize, observe if any text, images, or controls become clipped, truncated, or obscured. Ensure that all content remains visible and usable.
Evaluate Layout Changes: Confirm that the layout adjusts appropriately when text is resized:
Containers should expand to accommodate larger text.
No functionality should be lost (e.g., buttons should still be clickable).
Test Across Different Browsers: Perform tests in multiple browsers and devices to ensure consistent behavior across platforms.
Common mistakes to avoid
Fixed Width Containers: Using fixed widths for containers can lead to clipping when text is resized. Always use relative units (like percentages or ems) instead of fixed pixel sizes.
Inadequate Responsive Design: Failing to implement responsive design principles can cause layout issues when text is resized.
Ignoring Text-Based Controls: Ensure that all text-based controls (like form fields and buttons) resize appropriately along with the text.
Viewport Units Misuse: Incorrectly using viewport units (vw, vh) can lead to unexpected results when resizing text.
References
WCAG 1.4.5 - Images of Text
Compliance level - AA
Content-orientedDesign-oriented
Testing for compliance
Identify Text Elements: Review your web page to identify all instances where text is presented as an image.
Check Alternatives: For each image of text, determine if the same visual effect can be achieved using actual text with CSS styling.
Customization Options: Verify if users can customize any images of text (e.g., changing colors or sizes) to meet their individual needs.
Document Findings: Create a report detailing which instances comply with the criterion and which do not, along with recommendations for improvement.
User Testing: Conduct usability testing with individuals who have visual impairments to gather feedback on their experiences with text versus images of text.
Common mistakes to avoid
Using Images Instead of Text: Do not use images for headings, navigation items, or quotes when they can be expressed as styled text using CSS.
Neglecting Customization: Failing to provide options for users to customize images of text may lead to accessibility issues.
Misunderstanding Exceptions: Ensure clarity on when it is appropriate to use images of text—only in cases where customization is possible or when the presentation is essential.
References
WCAG 1.4.10 - Reflow
Compliance level - AA
Developer-oriented
Testing for compliance
Zoom the content up to 400% using browser zoom functionality and check that all content is still visible and usable.
Verify that horizontal scrolling is not required to view or interact with any part of the content at 400% zoom on a viewport that is 1280 CSS pixels wide (equivalent to 320 CSS pixels when zoomed to 400%).
Ensure that users can scroll in only one direction (vertically) to read or interact with the content.
Common mistakes to avoid
Check that all content, including text, images, videos, tables, and interactive elements, adjusts properly and remains fully accessible without overlapping, truncation, or clipping.
Ensure that text is readable and reflows correctly without being cut off, hidden, or requiring horizontal scrolling.
Handle carousels properly as they require horizontal scrolling which is not permitted as per this success criteria.
References
WCAG 1.4.11 - Non-text Contrast
Compliance level - AA
Design-oriented
Testing for compliance
Identify all elements that trigger additional content on hover or focus, such as tooltips, pop-ups, drop-down menus, expandable sections, or other dynamic content.
Verify that all user interface components (e.g., buttons, form fields, links, sliders, checkbox, dropdown) have a contrast ratio of at least 3:1 against their adjacent colors.
Check graphical elements such as icons, images of text, infographics, charts, and diagrams for sufficient contrast (3:1) against their backgrounds.
Ensure that any meaningful visual distinction (e.g., lines on a graph, segments in a pie chart) is accessible by meeting the contrast ratio requirement.
Common mistakes to avoid
- Test all component states (e.g., default, hover, active, focus, disabled, error states) to ensure they maintain the minimum contrast requirement.
References
WCAG 1.4.12 - Text Spacing
Compliance level - AA
Developer-oriented
Testing for compliance
Identify Text Elements: Review your web pages to locate all text elements that may require adjustment in spacing.
Test Across Multiple Pages: Ensure that you test multiple pages of your website, not just one, to confirm that the adjustments do not lead to any loss of content or functionality.
User Testing: Conduct user testing with individuals who have visual impairments or dyslexia to gather feedback on their experience with the adjusted text spacing.
Common mistakes to avoid
WCAG 1.4.13 - Content on Hover or Focus
Compliance level - A
Design-orientedDeveloper-oriented
Testing for compliance
Check for Dismissibility:
- Verify that any additional content (e.g., tooltips, pop-ups) can be dismissed without moving the mouse or keyboard focus.
Ensure that keyboard interaction (e.g., pressing the Esc key) closes the hover content.
Check for Persistence: Verify that the additional content remains visible as long as the trigger (hover or focus) is active, or until the user dismisses it.
Check for Hover: Verify that any content triggered by hover remains visible when the pointer is moved over the content itself.
Verify that the additional content of hover does not obscure or cover other important content, such as buttons or input fields, making them inaccessible.
Common mistakes to avoid
Confirm that any text within hover/focus-triggered content is legible and does not require zooming or panning to read.
Ensure the hover content does not automatically disappear after a short duration or due to a timeout unless it is no longer valid.
Check that content triggered by focus can be accessed and read using screen reader controls without requiring a mouse.
References
WCAG 2.4.5 - Multiple ways
Compliance level - AA
Content-oriented
Testing for compliance
Check that there are least two ways to locate a page: Ensure that any page on your site can be found using at least two of the methods among navigation menus, search, sitemap, table of contents, etc.
Test each navigation method individually: Test all the navigation methods available on your site, including search, navigation menus, sitemap, etc. individually. For example, to test search, use the search tool on your site to look for the page using relevant keywords. Verify that the search results include the intended page.
Use assistive technology to navigate: Test with a screen reader or keyboard to ensure that users relying on assistive technologies can find web pages using multiple methods.
Review user journey on different devices: Test the available methods of accessing pages on different devices, including desktops, tablets, and mobile devices.
Common mistakes to avoid
WCAG 2.4.6 - Headings and Labels
Compliance level - AA
Content-oriented
Testing for compliance
Review Headings and Labels: Go through your web pages and identify all headings and labels present.
Evaluate Descriptiveness: For each heading or label, assess whether it clearly conveys the content’s topic or purpose. Check whether the heading provide enough context, and would it still make sense if it is read out of context (e.g., in a table of contents)?
Check Consistency: Ensure that similar sections across different pages use consistent headings to help users predict content structure.
User Testing: Conduct testing with users who rely on screen readers to verify that they can navigate the content effectively using the provided headings and labels.
Document Findings: Create a report that includes which headings and labels meet the criteria and which do not, along with suggestions for improvement.
Common mistakes to avoid
Vague Headings: Using generic terms like “Click Here” or “Read More” that do not provide context about the content can confuse users.
Inconsistent Labeling: Using different terms for similar sections or components across various pages can lead to confusion about their purpose.
Neglecting Context: Failing to consider how headings will be understood when read independently can hinder navigation for users relying on assistive technologies.
References
WCAG 2.4.7 - Focus Visible
Compliance level - AA
Design-orientedDeveloper-oriented
Testing for compliance
Ensure that every interactive element (links, buttons, form controls, menu items, etc.) shows a visible focus indicator when navigated using the keyboard (typically the Tab key).
Ensure that custom-built interactive components (e.g., custom dropdowns, sliders, carousels, or toggle switches) also show a visible focus indicator.
Check that when focus moves to form fields (text inputs, checkboxes, radio buttons, dropdowns, etc.), a visible focus indicator is shown.
Verify that the focus indicator has sufficient contrast against the surrounding elements and background. The general recommendation is to maintain contrast ratio of at least 3:1.
Common mistakes to avoid
If you use your own focus indicator, with some customisation, rather than default focus indicator of browser then verify that focus indicator for each control receive visible.
Ensure that the focus indicator is not hidden behind other elements or obscured in any way, and it remains visible during navigation.
References
WCAG 3.1.2 - Language of Parts
Compliance level - AA
Developer-oriented
Testing for compliance
Identify Parts: Identify passages or phrases in the content that are in a different language than the main page.
Specify Language: Verify that the language of each identified passage is specified using the appropriate language attribute (e.g. lang=”fr” for French).
Confirm Specified Language: If the language of a passage is unknown to the author, confirm that no language is specified for that content.
Use Assistive Technology: Test the page with a screen reader or other assistive technology to ensure the language changes are recognized.
Common mistakes to avoid
Always Specify Language: Failing to specify the language for any passages or phrases in a different language than the main page.
Using Incorrect Language: Using incorrect language codes or markup for specifying the language, or specifying the language for passages where the language is unknown to the author.
References
WCAG 3.2.3 - Consistent Navigation
Compliance level - AA
Content-orientedDesign-oriented
Testing for compliance
Identify the primary navigation components: Identify all the primary navigation elements on your website or application, such as:
- Main navigation menus (e.g., top or side menus)
Breadcrumbs
Header and footer links
Site search options
Buttons or tabs used for site navigation
Navigate across multiple pages: Visit several different pages on the website and compare the placement, order, and function of the navigation elements across each page.
Check for consistent structure: Ensure that the structure of the navigation is the same on all pages. Specifically:
- The order of items in the menu (e.g., if the first item is “Home” on the homepage, it should still be “Home” on all other pages).
Navigation should always appear in the same location on the screen (e.g., top menu stays at the top on every page).
Test with assistive technologies: Ensure that the screen reader announces navigation elements in a predictable order and that menus are presented consistently across different pages.
Ensure responsiveness on different devices: Test the site on different screen sizes (desktop, tablet, mobile) to ensure that the navigation structure remains consistent even when the layout changes.
Common mistakes to avoid
Inconsistent navigation order or structure: One of the most common mistakes is having a different order of navigation links on different pages.
Inconsistent placement of navigation elements: Moving navigation elements to different positions on different pages (e.g., having a menu on the left on some pages and on the top on others) can disrupt users’ expectations. Placement should be consistent across all pages.
Changes in functionality: Avoid changing the functionality of navigation components. For example, if a menu opens via a click on one page but opens via a hover on another, it creates inconsistency.
Overly complex navigation menus: Using different navigation structures or presenting additional, complex navigation menus on some pages but not others can overwhelm users.
References
WCAG 3.2.4 - Consistent Identification
Compliance level - AA
Content-orientedDesign-oriented
Testing for compliance
Identify interactive elements: Start by identifying all interactive components that perform similar functions across the website or application. These might include buttons, links, icons, form controls, navigation menus, etc.
Check consistency of labelling and design: Review each interactive component on different pages or sections to ensure they are consistently labeled and designed. For example, a “Search” button should always be labeled as “Search” on every page, not as “Go” on one page and “Find” on another.
Ensure consistent placement and behaviour: Check if components that perform the same function appear in the same location across pages.
Test with assistive technologies: Use a screen reader (e.g., NVDA or JAWS) to verify that the components are consistently identified for users relying on assistive technologies. Ensure that the same interactive components are announced with the same labels across different pages.
Review dynamic or state changes: Ensure that interactive components retain their consistent identification when they change states.
Test across devices and viewports: Even if the layout changes due to responsive design, the functionality and labeling of similar components should remain consistent.
Common mistakes to avoid
Inconsistent labelling of similar elements: One of the most common mistakes is using different labels for the same function across the site.
Inconsistent icons or visual design: Using different icons or visual designs for the same function can be misleading.
Inconsistent interaction behaviour: Interactive elements that function differently across pages can frustrate users. For example, if a “Learn More” link opens a new page in one instance and opens a modal window in another, this inconsistency can create confusion.
Failure to use consistent alt text or aria-labels: Inconsistencies in accessibility labels can cause issues for screen reader users.
Inconsistent feedback for similar actions: If similar actions provide different types of feedback (e.g., one form shows a success message after submission, while another form redirects to a new page), this can disrupt the user experience.
References
WCAG 3.3.3 - Error Suggestion
Compliance level - AA
Content-oriented
Testing for compliance
Identify forms and input fields: Locate all forms and input fields where users must enter data.
Submit incorrect or incomplete input: Enter incorrect or invalid data deliberately (e.g., an invalid email address, missing required fields, incorrect date formats) to trigger form validation errors.
Check for error suggestions: Verify that suggestions are provided to help the user correct their mistakes. These suggestions should be specific and helpful. For example: Instead of simply saying “Invalid email address,” the message should suggest, “Please enter a valid email address, such as example@domain.com.”
Test error suggestions with assistive technologies: Use a screen reader (e.g., NVDA, JAWS) to confirm that error suggestions are announced when errors are detected.
Common mistakes to avoid
Vague or unclear suggestions: Offering vague suggestions such as “Correct your input” or “Please fix the error” doesn’t provide the user with enough information to resolve the issue. The suggestion must be specific and clearly explain what is needed.
Suggestions that are too technical: Using overly technical language in error suggestions can confuse users.
Suggestions that are not accessible to screen readers: If error suggestions are not programmatically associated with the input field (e.g., through ARIA live regions or other techniques), they may not be detected by screen readers.
Placing suggestions too far from the input field: Suggestions should be placed adjacent to or below the relevant input field.
Not testing across devices: Failing to test how error suggestions appear on different devices can lead to issues where suggestions are not displayed properly on smaller screens.
References
WCAG 3.3.4 - Error Prevention (Legal, Financial, Data)
Compliance level - AA
Content-orientedDesign-oriented
Testing for compliance
Identify relevant forms and processes: Look for forms or processes that involve:
- Legal agreements (e.g., contracts, terms of service)
Financial transactions (e.g., purchasing items, making donations, or paying bills)
Critical user data (e.g., applications, personal information, medical records)
Simulate user error: Enter incorrect or incomplete data to check if the system provides adequate guidance to prevent errors.
Verify input review mechanisms: Either the submissions should be reversible, or the information should be checked and the user given an opportunity to correct errors, or the user should have the ability to review and correct the information provided before submission.
Check for additional verification steps: In some processes, especially for legal or financial transactions, the system should require additional verification steps like entering a password, verifying an email address, or providing a second factor of authentication before completing the transaction.
Test with assistive technologies: Use screen readers or other assistive technologies to ensure that users receive the same instructions, review options, and error prevention mechanisms in an accessible way.
Common mistakes to avoid
No opportunity to review the input: Failing to provide users with a summary or review step before submitting legal, financial, or critical data.
No confirmation prompt: Ensure that a confirmation page or pop-up prompts users to confirm a critical action before proceeding.
No cancel or undo option: Always provide an option to cancel or go back.
Inconsistent error handling for critical fields: Always provide clear feedback when input errors occur and offer suggestions for correction.
Poorly defined validation rules: Input fields with unclear or overly strict validation rules may confuse users, leading to more errors. Make sure validation rules are clear and comprehensible.
Insufficient or confusing instructions: Ensure all instructions are clear, visible, and accessible to screen readers.
References
WCAG 4.1.3 - Status Messages
Compliance level - AA
Developer-oriented
Testing for compliance
Identify components with dynamic status messages: Look for UI components that generate status messages, such as:
- Form validation messages (e.g., “Field is required”, “Form submitted successfully”)
Error messages (e.g., “Incorrect password”)
Success messages (e.g., “Your order has been placed”)
Loading indicators or progress updates (e.g., “Loading…”, “Please wait…”)
Alerts or notifications (e.g., “New message received”)
Messages conveying search results (e.g., “4 results returned”)
Test with screen readers: Use a screen reader (e.g., NVDA, JAWS, VoiceOver) to check whether the status message is announced when it appears on the page. This should happen automatically without the user needing to navigate to the message. Also test with keyboard-only navigation.
- Trigger an event that generates a status message (e.g., submit a form with errors)
Ensure that the screen reader announces the message clearly and in context
The screen reader should not lose focus from the current field or interactive element
Check timing of announcements: Ensure that the timing of announcements is appropriate for the context.
Common mistakes to avoid
Status messages not announced by assistive technologies: A common failure is when status messages are not conveyed to users who rely on screen readers or other assistive technologies. This often happens if the status message is not coded with an ARIA live region (aria-live) or lacks sufficient accessibility attributes.
Interrupting user focus: Focusing on the status message or moving the user’s focus away from their current task can be disruptive. The status message should be announced without shifting focus.
Missing or incorrect ARIA live attributes: Incorrect use of aria-live properties can lead to poor accessibility.
Relying on colour alone for status message differentiation: Users with visual impairments or colour blindness may not be able to perceive status messages that rely solely on colour.
Delay or failure to update messages: Ensure messages are displayed immediately when triggered and announced promptly.
References
- Status Messages (Level AA)
- Failure of Success Criterion 4.1.3 due to providing status messages that cannot be programmatically determined through role or properties
WCAG 2.2 A
WCAG 3.2.6 - Consistent Help
Compliance level - A
Content-orientedDesign-oriented
Testing for compliance
Identify pages or steps where help is available: Locate all pages or stages in a process where help is provided. Look for help mechanisms such as help links or tooltips, contact information or support links, live chat buttons or help icons and FAQs, user guides, or tutorials.
Ensure help mechanisms are consistent: Check that the help options provided on one page or step are available in the same manner on other related pages or steps. These mechanisms should be available in the same “relative order”, i.e. in the same order when the content is ordered when the page is serialised.
Check for the same functionality: Ensure that the help mechanisms provide consistent functionality. For example, if a help link opens a support form in a modal window on one page, it should work the same way on other pages.
Common mistakes to avoid
Inconsistent placement of help mechanisms: A common mistake is placing help links or buttons in different locations across pages or steps, which can confuse users.
Inconsistent labelling: Using different labels for the same help functionality can lead to confusion.
Missing help on critical pages: Sometimes, help options are available on the homepage or primary sections but are omitted from critical steps.
Different help mechanisms for similar tasks: Offering different types of help (e.g., a live chat on one page and only an FAQ link on another) for similar processes can confuse users.
Help functionality changes without notice: Help mechanisms that change behaviour or appearance can frustrate users.
Help only accessible via complex interactions: Making help options difficult to find or interact with can lead to accessibility issues.
References
WCAG 3.3.7 - Redundant Entry
Compliance level - A
Content-oriented
Testing for compliance
Identify forms with repeat information: Locate forms or processes that may ask users to provide the same information in multiple steps. For example, checkout processes where billing and shipping addresses are required separately.
Test if the system can pre-fill previously entered information: Complete the form or process up to the point where redundant information may be required. Check if the system can automatically fill in fields based on the information provided earlier.
Check for consistency across pages: In multi-step forms or processes, check if data entered in one step carries over to subsequent steps where relevant.
Test with assistive technologies: Confirm that the option to re-use previously entered data is accessible and clearly communicated via assistive technology.
Simulate different scenarios: Test various scenarios. For example, submitting without re-entering redundant data, or changing data once filled automatically.
Common mistakes to avoid
Forcing users to re-enter the same data: A common mistake is not providing pre-fill options or forcing users to repeatedly input the same information in different sections of a form.
No option for “same as” functionality: Not offering an option to select “Same as billing address” or similar functionality in forms is a common problem.
Incorrect or missing auto-fill for account users: Always pre-fill relevant fields based on user data if available.
Pre-filled data that isn’t editable: Always allow users to review and adjust the pre-filled data.
Inconsistent pre-fill behaviour: Make sure that data provided in one step is available in all relevant subsequent steps.
Poor communication for assistive technology users: If form elements that prevent redundant entry are not properly labeled or announced to screen reader users, they may miss that option.
References
WCAG 2.2 AA
WCAG 2.4.11 - Focus Not Obscured
Compliance level - AA
Developer-oriented
Testing for compliance
Keyboard Navigation: Use the keyboard (tab / arrow keys) to navigate through interactive elements on the page.
Focus Visibility: Ensure that when an element receives focus, it is not entirely obscured by other content. The focused element should be at least partially visible.
Dynamic Content: Check if any dynamic content (like pop-ups or menus) appears over focused elements and whether this obscures them.
Visual Indicators: Confirm that the focus indicator (like a border or highlight) remains visible when an element is focused.
Common mistakes to avoid
Ignoring Dynamic Content: Check for elements that can obscure focused items when they are opened or activated by the user.
Overlooking Focus Indicators: Ensure that focus indicators are not only present but also visually distinct and adequately sized to be noticed.
Assuming User Control: Ensure content that users can reposition be tested based on its default state, as obscuring during focus can still occur.
References
WCAG 2.5.7 - Dragging Movements
Compliance level - AA
Developer-oriented
Testing for compliance
For any functionality that requires dragging, ensure that there are alternative ways to perform the same task using simpler actions such as:
Keyboard input: Use arrow keys, Tab key, or other keyboard commands to achieve the same result
Text-based input: Use a text-based input to set a value that the dragging-based input tries to set
Single-pointer activation: Instead of dragging, allow the user to click or tap on a start point and then click or tap on the destination or control points
Menu-based alternatives: Allow the user to select an alternative from a menu-based widget
One can either manually inspect all elements that require dragging or check the event listeners and handlers for dragging functionality, i.e., verify that
mousedown,touchstart,pointerdown, and similar drag-related events are complemented by alternatives for non-dragging interactions likekeydownorclick.
Common mistakes to avoid
Relying solely on dragging for interactions: Users should be able to interact using keyboard or single-tap/click mechanisms.
Complex, unintuitive alternatives: Offering an alternative interaction that is overly complex or difficult to use is not compliant. For example, providing a complex set of keyboard shortcuts to achieve dragging without clear instructions can be problematic.
Lack of visual feedback: When providing an alternative to dragging (such as keyboard interaction), it’s important to give clear visual feedback, such as highlighting the item that is being moved or changed.
References
- Dragging Movements (Level AA)
- Failure of Success Criterion 2.5.7 Dragging Movements due to not providing a single pointer method for the user to operate a function that does not require a dragging movement
WCAG 2.5.8 - Target Size (Minimum)
Compliance level - AA
Design-orientedDeveloper-oriented
Testing for compliance
Identify Interactive Elements: Review your web page to locate all interactive elements such as buttons, links, and form controls.
Measure Target Sizes: Use a browser’s developer tools or a design tool to measure the dimensions of each interactive element. Ensure that each target is at least 24 x 24 px.
Check Spacing: For any targets smaller than the minimum requirement:
- Visually assess the spacing between adjacent targets.
Document Findings: Record which interactive elements meet the size requirement and which do not, noting any exceptions that apply.
Common mistakes to avoid
Ignoring Small Targets: Failing to address small interactive elements can lead to accessibility issues for users with limited precision in their movements.
Inadequate Spacing: Not providing sufficient spacing between targets can result in accidental activations, frustrating users.
Misunderstanding Exceptions: Be aware of the exceptions where smaller targets may be acceptable (e.g., inline text links or default browser controls) and ensure they are appropriately documented.
References
WCAG 3.3.8 - Accessible Authentication (Minimum)
Compliance level - AA
Content-orientedDeveloper-oriented
Testing for compliance
Ensure authentication does not rely solely on cognitive function tests, such as:
- Recalling passwords
Solving puzzles, CAPTCHA, or recognition-based tasks (e.g., selecting images that match a certain condition).
Recalling codes from memory
Verify the availability of at least one non-cognitive-based authentication method. If there is an alternative mechanism that does not require cognitive test, then there is no violation for this criteria.
- For instance: Check if options like one-time passcodes (OTP) sent via email or SMS, biometric logins (fingerprint, face recognition), or hardware tokens are available.
Confirm that password and passcode fields allow users to copy and paste login credentials or authentication codes.
Ensure compatibility with password managers and browser autofill functionality for login fields.
Provide a way to show password using some show/hide option for password field.
Object recognition in a CAPTCHA (such as identifying fire hydrant in group of images) is a cognitive function test; however, it is accepted at the AA level.
Common mistakes to avoid
If CAPTCHA is used, verify that there is an accessible alternative (e.g., audio CAPTCHA or simpler alternatives).
If time-based authentication (like OTP codes) is used, ensure adequate time is provided to enter the code.
If there is more than one step in the authentication process, such as with multi-factor authentication, all steps need to be compliant.
References
Did this page help you?
YesNo
We're sorry to hear that. Please share your feedback so we can do better
Submit
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
This page has exactly what I am looking for
This content & code samples are accurate and up-to-date
The content on this page is easy to understand
Other (please tell us more below)
Any additional feedback?
Submit
Thank you for your valuable feedback
Is this page helping you?
Yes
No
We're sorry to hear that. Please share your feedback so we can do better
SubmitSkip
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
This page has exactly what I am looking for
This content & code samples are accurate and up-to-date
The content on this page is easy to understand
Other (please tell us more below)
Any additional feedback?
SubmitSkip
Thank you for your valuable feedback!
Talk to an Expert
DownloadCopyCheck Circle
Select your framework and language to proceed
Appium
- \ \ Maestro](/content/docs/app-automate/maestro/index.html)
- \ \ Espresso](/content/docs/app-automate/espresso/index.html)
- \ \ XCUITest](/content/docs/app-automate/xcuitest/index.html)
- \ \ Flutter](/content/docs/app-automate/flutter/index.html)
- \ \ Detox](/content/docs/app-automate/detox/index.html)
- \ \ Mobilewright](/content/docs/app-automate/mobilewright/index.html)
- \ \ Smart TV](/content/docs/app-automate/smart-tv/index.html)
Select your framework and language to proceed
Selenium
Playwright
- \ \ Cypress](/content/docs/automate/cypress/index.html)
- \ \ JS Testing API](/content/docs/automate/javascript-testing/index.html)
- \ \ Puppeteer](/content/docs/automate/puppeteer/index.html)
Are you sure you want to change your preference to ?
Your previous selection was .
Proceed with change
Revert
×