Web accessibility ensures that everyone, including people with disabilities, can use and interact with websites and applications. The Web Content Accessibility Guidelines (WCAG) provide a global standard for making web content accessible to people with visual, auditory, motor, or cognitive disabilities.
This article highlights the key requirements of the Web Content Accessibility Guidelines (WCAG) so you can ensure compliance with them.
What is WCAG?
WCAG stands for Web Content Accessibility Guidelines. It is a set of technical standards created by the World Wide Web Consortium (W3C) to make digital content more accessible. These guidelines apply to websites, web apps, and digital documents.
At the core of WCAG are four principles, known as POUR. They define how content should work for all users:
- Perceivable: Content must be presented in ways users can perceive, regardless of their sensory abilities. For example, images need alt text, and video needs captions.
- Operable: Users must be able to navigate and use the interface. This includes keyboard access, skip links, and avoiding flashing content that could trigger seizures.
- Understandable: Content and navigation must be clear and predictable. This means using plain language, consistent menus, and clear input errors.
- Robust: Content must work well with current and future user tools, including assistive technologies like screen readers.
Note: WCAG is technology-agnostic. The principles apply even if your site is built with plain HTML or advanced JavaScript frameworks.
WCAG Versions: 2.0, 2.1, and 2.2
WCAG has three versions: 2.0, 2.1, and 2.2. Each new version builds on the previous one without removing existing requirements. If you follow WCAG 2.2, you also meet the criteria in 2.1 and 2.0 unless a requirement is specifically excluded.
WCAG 2.0 (Published in 2008)
WCAG 2.0 introduced the foundational structure and principles that are still used today. It focused on making web content accessible for users with visual, auditory, motor, and cognitive disabilities, mainly on desktop environments.
Key requirements in WCAG 2.0 include:
- Provide alt text for non-text content such as images, video, and audio
- Make content adaptable and avoid fixed layouts
- Ensure sufficient color contrast between text and background
- Enable keyboard-only navigation
- Allow users enough time to read and use the content
- Avoid content that causes seizures, like flashing elements
- Provide clear navigation and consistent layout
Read More: Building Responsive Layouts with CSS
- Ensure compatibility with assistive technologies
WCAG 2.1 (Published in 2018)
WCAG 2.1 added 17 new success criteria to address mobile accessibility, low vision, and cognitive disabilities. It builds directly on WCAG 2.0, so all 2.0 requirements still apply.
Additional requirements in WCAG 2.1 include:
- Content must support both portrait and landscape orientation
- Inputs should not rely only on motion or gestures like shaking or tilting
- Text spacing must support user-defined styles without breaking the layout
- Content must remain visible and readable, even when zoomed up to 400%
- Interactive elements, such as buttons, must be clearly labeled and match the accessible name
- Keyboard users should be able to move around and leave any part of the page
- Users should be able to click or tap without needing tiny or exact movements
WCAG 2.2 (Published in 2023)
WCAG 2.2 added 9 more success criteria focused on improving accessibility for users with cognitive disabilities, as well as better keyboard support and simplified authentication. It includes all 2.0 and 2.1 requirements unless otherwise stated.
Additional requirements in WCAG 2.2 include:
- Focus indicators must be clearly visible and not hidden under overlays
- Drag-and-drop interactions must have keyboard-accessible alternatives
- Users should not be required to remember information during login (no cognitive tests)
Read More: How to Reduce Cognitive Overload in Design
- Accessible authentication should support copy-paste or password managers
- Targets (like buttons or links) must be large enough (at least 24×24 CSS pixels)
- Help and instructions should be easily accessible
Read More: Must-have Chrome extensions for WCAG Testing
WCAG Conformance Levels
WCAG has three levels of conformance: A, AA, and AAA. Each level builds on the previous one, adding more accessibility requirements.
Level A
This is the minimum level. It removes basic barriers so content is accessible in the most essential ways.
Examples of Level A requirements:
- Text alternatives for images
- Keyboard access to all content
- Avoid using content that flashes more than three times per second
Level AA
This is the most commonly required level for legal and usability standards. It improves accessibility for a wider range of users.
Examples of Level AA requirements:
- Minimum contrast between text and background
- Visible focus indicators for keyboard users
- Clear labels and instructions for form fields
- Content adapts to different screen sizes and zoom settings
Level AAA
This is the highest level. It includes stricter requirements, but it’s not always realistic for all content types. Most organizations are not expected to meet this unless required by policy.
Examples of Level AAA requirements:
- Sign language interpretation for videos
- No time limits on content unless necessary
- Expanded contrast requirements for low-vision users
- Simpler, easier-to-read language in text content
Note: WCAG 2.1 Level AA is the most commonly required standard under accessibility laws such as the ADA, Section 508, and EN 301 549.
WCAG Checklist for Level A and AA (2.0, 2.1, 2.2)
To meet accessibility standards and comply with common legal requirements, your website must follow all Level A and AA success criteria from WCAG 2.0, 2.1, and 2.2. The checklist below breaks them down by version. Each entry includes a brief summary and a best practice to help you implement it correctly.
WCAG 2.0 Checklist (Levels A and AA)
WCAG 2.0 introduced the foundational accessibility structure. These requirements apply to all websites and form the baseline for every later version.
| Criterion | Level | Summary | Best Practices |
|---|---|---|---|
| Text alternatives | A | Provide text for images and non-text content | Use descriptive alt text; use alt=”” for decorative images |
| Time-based media | A | Make audio and video accessible | Add captions, transcripts, and audio descriptions where needed |
| Adaptable | A | Structure content to support adaptation | Use headings, landmarks, and semantic HTML |
| Distinguishable (contrast) | AA | Ensure text stands out clearly from the background | Maintain a 4.5:1 contrast ratio (3:1 for large text) |
| Keyboard accessible | A | All content must be operable via keyboard | Avoid mouse-only interactions; test navigation using Tab and Enter |
| No keyboard traps | A | Users should not get stuck using a keyboard | Provide a visible and movable keyboard focus |
| Enough time | A | Users must have enough time to read or interact | Avoid automatic timeouts or give options to extend time |
| Seizures | A | Do not use content that causes seizures | Avoid flashing content above 3 times per second |
| Navigable (headings/links) | AA | Make it easy to navigate and understand the structure | Use proper heading order, link text, and skip links |
| Input assistance | A/AA | Help users avoid and correct mistakes | Label form fields, show errors clearly, and allow easy correction |
| Consistent navigation | AA | Use consistent layouts and navigation across pages | Reuse menus and controls in the same order |
| Compatible | A | Ensure compatibility with assistive tech | Use valid HTML, proper ARIA labels, and standard form controls |
WCAG 2.1 Checklist (Levels A and AA)
WCAG 2.1 expanded on 2.0 by addressing mobile accessibility, low vision, and cognitive needs. These criteria improve usability across devices and interaction types.
| Criterion | Level | Summary | Best Practices |
|---|---|---|---|
| Orientation | AA | Content must work in both portrait and landscape modes | Avoid forcing a specific orientation |
| Text spacing | AA | Allow user-adjusted text spacing | Ensure the layout doesn’t break with increased spacing or line height |
| Reflow | AA | Content should be usable when zoomed to 400% | Use responsive design and fluid layouts |
| Non-text contrast (focus, icons) | AA | Visual indicators must have enough contrast | Ensure 3:1 contrast for focus styles, controls, and graphics |
| Label in name | A | Labels must match visible text for screen readers | Ensure the accessible name includes the visible label |
| Pointer gestures | A | Avoid relying on complex gestures | Offer simple alternatives like taps or buttons |
| Pointer cancellation | A | Actions must be reversible or cancellable | Confirm with the user before completing a destructive action |
| Motion actuation | A | Don’t force actions using motion input | Let users disable or use other input options |
| Character key shortcuts | A | Avoid single-key shortcuts unless the user turns them off | Provide toggles or customizable shortcuts |
| Focus order | A | Logical navigation order using keyboard | Match the visual and keyboard tab order |
| Focus visible | AA | Highlight the focused element | Use strong borders or background changes, not just color |
WCAG 2.2 Checklist (Levels A and AA)
WCAG 2.2 introduced additional requirements to help people with mobility challenges. It also improves keyboard focus and input accessibility.
| Criterion | Level | Summary | Best Practices |
|---|---|---|---|
| Focus appearance | AA | Focus indicators must be visible and clearly styled | Use thick borders or high-contrast outlines |
| Focus not obscured (min/complete) | A/AA | Focus should not be hidden behind other content | Avoid sticky headers or overlays that block focused elements |
| Dragging movements | AA | Provide alternatives to drag-and-drop | Support keyboard interactions or simple click actions |
| Target size (min) | AA | Touch targets must be at least 24×24 CSS pixels | Add padding or spacing between interactive elements |
| Consistent help | A | Offer help or guidance consistently across pages | Place tooltips, contact links, or help text in the same location |
| Accessible authentication (min) | AA | Don’t require users to memorize or solve puzzles | Allow copy-paste, password managers, and email sign-ins |
| Redundant entry | A | Don’t ask users to re-enter the same information | Auto-fill or pre-populate previously entered data |
How to Ensure Your Website Meets WCAG Compliance
To ensure WCAG compliance, include accessibility in your design and development process from the start. Test regularly across real devices, browsers, and assistive technologies to catch issues early and keep up with evolving standards.
BrowserStack lets you test your website on 3,500+ real devices and browsers, helping you identify issues that appear in specific combinations of screen sizes, operating systems, and browsers. You can test for WCAG compliance at any level (A, AA, or AAA) based on the latest WCAG 2.2 guidelines
Key features of BrowserStack Accessibility that support WCAG testing:
- Real Device Cloud: Test on real Android and iOS devices, desktops, and tablets to validate accessibility across screen sizes, browsers, and OS versions.
- Cross-Browser Compatibility: Ensure your site works as expected on Chrome, Firefox, Safari, and Edge to maintain consistent accessibility across browsers.
- Workflow Analyzer: Test entire user flows to identify missing alt text, poor color contrast, and non-compliant elements throughout the website
- Screen Reader Support: Test with screen readers like NVDA, JAWS, and VoiceOver to confirm your content is accessible for blind or low-vision users.
- Automated Tests: Integrate accessibility tests into your CI/CD pipelines to automatically trigger scans after every build and catch issues before they reach production.
Conclusion
WCAG compliance helps you make your website accessible to everyone, including users with disabilities. Follow WCAG 2.0, 2.1, and 2.2 to meet legal requirements and support a wider range of users. Additionally, include accessibility checks in every release cycle and fix issues based on the latest standards to ensure compliance with WCAG.
BrowserStack lets you test your website for WCAG compliance across levels A, AA, and AAA. You can run accessibility tests on 3,500+ real devices and browsers, catch layout and interaction issues early, and maintain conformance as your site evolves.
Featured Article
