Study: AudioEye detects up to 2.5x more issues than other tools
Get ReportGuide
A Complete Guide to WCAG Standards and Compliance
WCAG is the international standard for making websites accessible to people with disabilities. This guide breaks down what WCAG is, how its principles and conformance levels work, and what you need to meet today’s requirements. You’ll also learn about common accessibility barriers and practical steps to maintain ongoing compliance.
)
On this page
There are approximately 1.3 billion people worldwide living with a disability(opens in a new tab), and many of them navigate the internet using assistive technologies that most websites simply don't support. Whether it's low vision, hearing loss, cognitive differences, or motor limitations, inaccessible content shuts out a significant portion of your audience, creates legal risk, and undermines the user experience for everyone.
That's where the Web Content Accessibility Guidelines (WCAG)(opens in a new tab) come in. Developed by the World Wide Web Consortium (W3C), WCAG provides the global standards for building accessible, inclusive digital experiences.
In this guide, we'll walk you through WCAG 2.2, the principles behind its success criteria, and how these guidelines support the creation of more accessible, compliant, and user-friendly content.
What is WCAG Compliance?
WCAG, or the Web Content Accessibility Guidelines, are the international standards for digital accessibility published by the World Wide Web Consortium (W3C). WCAG compliance means voluntarily following these guidelines to ensure that websites, apps, and digital content are accessible to people with disabilities. Most digital accessibility laws, including the Americans with Disabilities Act(opens in a new tab) (ADA) and Section 508, use WCAG 2.2 Level AA as their technical compliance benchmark.
Get a free accessibility scan to see where your site stands→
What Is WCAG?
WCAG is an internationally recognized standard created by the W3C's Web Accessibility Initiative (WAI) to make digital content accessible to people with disabilities. WAI is the W3C division responsible for developing accessibility guidelines, and it publishes three complementary standards: WCAG for web content, ATAG(opens in a new tab) (Authoring Tool Accessibility Guidelines) for tools used to create web content, and UAAG(opens in a new tab) (User Agent Accessibility Guidelines) for browsers and assistive technologies.
Together, these guidelines form the W3C's complete accessibility framework, though WCAG is the most widely adopted and legally referenced of the three.
The guidelines consist of success criteria (SC), which are pass-or-fail statements that address accessibility barriers, including mistakes that prevent websites from working well with assistive technologies. These include problems like:
Text that doesn’t have sufficient contrast with its background (low-contrast text).
Missing or inaccurate alternative text (alt text) for images.
Missing captions or transcripts for videos.
Missing form labels for input fields.
Improper use of semantic HTML.
“Empty” and redundant hyperlinks.
Following WCAG not only allows you to address the issues mentioned above but also makes your content more useful for people with:
Vision disabilities
Hearing disabilities
Cognitive differences and disabilities
Attention disorders
Temporary and situational disorders (e.g., people who browse the internet with their sound turned off).
WCAG Versions: 2.0, 2.1, and 2.2
WCAG has evolved through several versions to keep pace with changing technology and user needs. The table below summarizes the key differences:
WCAG 2.2 is the current W3C recommended standard and the benchmark for accessibility compliance and best practices. It's fully backward-compatible, meaning that every criterion from 2.0 and 2.1 carries forward, so adopting 2.2 also meets all prior requirements.
WCAG 2.0, while technically still valid, is increasingly considered outdated. It predates widespread mobile use and doesn't account for many accessibility challenges that have emerged since 2008. Organizations still referencing 2.0 as their compliance target should plan to update to 2.2.
WCAG 3.0 is currently in development. It proposes a more flexible, outcome-based model (a significant departure from the pass/fail structure of 2.x), but it is not yet an official standard.
For a comprehensive list of all WCAG 2.2 success criteria, check out this WCAG checklist.
What’s New in WCAG 2.2
WCAG 2.2 adds nine new success criteria and removes one, with a focus on improving usability for people with motor disabilities, cognitive disabilities, and low vision:
2.4.11 Focus Appearance (AA) Interactive elements must have a visible focus indicator that meets minimum size and contrast requirements, so keyboard users can clearly see which element is selected.
2.4.12 Focus Appearance (Enhanced) (AAA) A stricter version of 2.4.11 that requires the focus indicator to be even larger and higher-contrast, providing a stronger visual cue for users with low vision.
2.5.7 Dragging Movements (AA) Any action that requires dragging, like sliders or sortable lists, must also be achievable with a single pointer action, such as a click or tap, so users who can't perform drag gestures aren't locked out.
2.5.8 Target Size (Minimum) (AA) Clickable and tappable targets must be at least 24x24 CSS pixels, reducing the risk of mis-taps for users with motor impairments or those on touch devices.
3.2.6 Consistent Help (A) If a help mechanism, such as a contact link, chat widget, or support phone number, appears across multiple pages, it must appear in the same location on each page so users can reliably find it.
3.3.7 Redundant Entry (A) Users should not be required to re-enter information they've already provided in the same session, reducing cognitive load during multi-step processes like forms and checkouts.
3.3.8 Accessible Authentication (Minimum) (AA) Authentication processes, like logging in, cannot rely solely on cognitive function tests such as solving puzzles or transcribing characters, unless an alternative or assistance is provided.
3.3.9 Accessible Authentication (Enhanced) (AAA) A stricter version of 3.3.8 that removes the allowance for object-recognition and personal-content-based alternatives, requiring login flows to be fully accessible without exception.
Removal of SC 4.1.1 Parsing WCAG 2.2 removes the Parsing criterion, which required valid, well-formed HTML. Modern browsers handle malformed markup gracefully, making this criterion redundant, and its removal has no impact on practical accessibility.
The Four Principles of WCAG (POUR)
WCAG outlines four guiding principles for digital accessibility: perceivable, operable, understandable, and robust. Together, these principles form the POUR framework and help businesses create content accessible to everyone.
Below, we've outlined each principle with correlating WCAG 2.2 success criteria and examples.
Perceivable:
All information and UI components must be presentable to all users. Nothing should be invisible to any of their senses. Here are a few ways to make content perceivable:
Provide text alternatives for non-text content (SC 1.1.1): Offer text descriptions for images, graphs, or videos so users who can't see these elements still have access to the same information. This also increases compatibility with screen readers.
Add captions to video content (SC 1.2.2, SC 1.2.4): Incorporate captions into pre-recorded and live videos for people who are Deaf or hard of hearing.
Add audio descriptions for pre-recorded video (SC 1.2.5): Include narrations describing visual elements for users who are blind or have low vision.
Ensure adequate color contrast (SC 1.4.3, SC 1.4.6): Maintain sufficient color contrast between text and background, especially for users with color vision deficiency and other vision impairments.
Operable:
Users must be able to navigate and interact with your content using the technologies they rely on every day, without being required to do something they cannot do.
Make all functionality keyboard accessible (SC 2.1.1): Users should be able to operate all digital content with a keyboard alone (without a mouse).
Avoid flashing content (SC 2.3.1): Avoid content that flashes more than three times per second to reduce seizure risk and support users with neurocognitive conditions.
Avoid time limits (SC 2.2.1): Allow sufficient time for users to read and use content. If time limits are necessary, notify users in advance.
Meet minimum touch target sizes (SC 2.5.8): New in WCAG 2.2, clickable and tappable targets must be at least 24x24 CSS pixels to reduce mis-taps for users with motor impairments.
Support alternatives to dragging (SC 2.5.7): New in WCAG 2.2, any drag-based functionality must have a single-pointer alternative for users who cannot perform drag gestures.
Understandable:
Content and UI should be easy to understand for people of all abilities, following best UX design practices.
Use language tags (SC 3.1.1, SC 3.1.2): Specify the page language so that screen readers apply the correct pronunciation rules and browsers display the appropriate characters.
Use consistent navigation (SC 3.2.3, SC 3.2.6): Keep navigation elements in the same order across all pages. A new success criterion in WCAG 2.2, SC 3.2.6 requires help mechanisms like contact links or chat widgets to appear in a consistent location across pages.
Provide instructions and labels (SC 3.3.2): Write clear, simple instructions when user input is required and use appropriate labels for assistive technologies.
Reduce redundant data entry (SC 3.3.7): Also one of the new success criteria in WCAG 2.2, this criterion mandates that users should not be asked to re-enter information already provided in the same session.
Robust
Content must work across current and future technologies, including browsers and assistive tools.
Establish the name, role, and value of each element (SC 4.1.2): Ensure each UI element can be programmatically determined so screen readers can present it correctly.
Create accessible status messages (SC 4.1.3): Status messages, such as form confirmations or cart updates, must be communicated to screen reader users automatically without requiring navigation to a new element.
WCAG Conformance Levels: A, AA, and AAA
In addition to the four principles, WCAG success criteria are organized into three levels of conformance: Level A, Level AA, and Level AAA:
Each conformance level includes all success criteria from the previous level. In other words, Level AA includes all Level A success criteria, while Level AAA includes all Level AA and A success criteria.
It’s important to note that most organizations should target WCAG 2.2 Level AA. This is the level specified by the ADA, Section 508, EN 301 549, and more.
Check your site’s WCAG 2.2 Conformance Now →
Who Needs to Meet WCAG?
An important thing to note: WCAG itself is a technical standard, not a law. But it is directly referenced by accessibility laws worldwide, which means a wide range of organizations have a legal obligation to meet it. Whether WCAG applies to you depends on where you operate, who you serve, and how your organization is funded.
The table below summarizes compliance requirements by jurisdiction. We’ll discuss in more detail how WCAG maps to specific laws below.
The laws covered in the table vary in scope and specificity. Some incorporate WCAG by reference, meaning its success criteria appear within the text of the law. Others, like the ADA, do not name WCAG explicitly but have established WCAG 2.2 Level AA as the de facto standard through litigation and DOJ guidance.
The EAA and UK regulations are worth noting for any organization with an international digital presence. The EAA came into force in June 2025 and extends to non-EU businesses that sell products or services to EU customers, making it relevant well beyond Europe's borders.
The EAA measures compliance against the POUR principles, rather than directly referencing WCAG. However, WCAG 2.1 Level AA is the recognized technical benchmark for those requirements. More simply, organizations that follow WCAG are well-positioned for EAA compliance.
Not sure if WCAG applies to your organization?
The safest assumption is that it does. Even where legal obligations are narrow or still developing, WCAG 2.2 Level AA is widely recognized as the global baseline for accessible digital experiences.
How Does WCAG Affect Accessibility Laws?
As mentioned above, WCAG is not a law, but a voluntary set of standards.
Although WCAG is not legally enforceable, it serves as the basis for many non-discrimination laws. Some of those incorporate WCAG by reference, meaning the success criteria from WCAG appear within the text of the law, word for word.
Other laws, such as the ADA, do not have specific technical standards but have established WCAG Level AA conformance as a reasonable level of accessibility through substantial legal precedent.
Below, we’ll explain how WCAG conformance impacts compliance with key digital accessibility laws. For additional examples, check out our International Accessibility Law Repository.
The Americans with Disabilities Act (ADA)
The ADA is a U.S. civil rights law that prohibits discrimination against people with disabilities in areas like employment, government services, transportation, and places of public accommodation, which includes the internet. This means that websites, mobile apps, and online services must be accessible to people with disabilities.
Title III of the ADA specifically applies to places of public accommodation and applies to:
Private businesses
Non-profit organizations
Other agencies that operate as “places of public accommodation.”
The ADA itself does not include specific standards for compliance. Instead, it enforces the guidelines included in WCAG 2.2 Level AA. Put simply, to be considered ADA-compliant, your digital content must meet WCAG standards.
DOJ Final Rule on Title II
In April 2024, the DOJ issued a final rule establishing WCAG 2.1 Level AA as the explicit standard for state and local government websites and mobile apps, the first time a specific WCAG version was formally codified in ADA rulemaking.
Deadlines are phased: governments serving 50,000 or more people must comply by April 2026, and smaller governments by April 2027. The rule strengthens the case for WCAG 2.1 AA as the minimum bar for Title III private sector compliance as well. Organizations aiming for stronger conformance, or preparing for future rulemaking, are increasingly adopting WCAG 2.2 as their baseline.
Section 508 of the Rehabilitation Act
The Rehabilitation Act of 1973 prohibits federal agencies from discriminating against people with disabilities. It also requires federal agencies to make their electronic information technology accessible, including web pages, digital documents (such as PDFs), and software.
Of course, that’s much easier with clear technical standards.
In 1998, Congress amended the Rehabilitation Act to create those standards. Over time, Congress has approved additional updates to make sure that the requirements of Section 508 are appropriate for current technologies.
Section 508 applies to:
Federal agencies in the United States.
State, county, and municipal authorities that receive financial assistance from the U.S. government.
Universities, museums, galleries, medical centers, and other organizations that receive federal funding.
Any contractor, regardless of size or services offered, that wants to work with the U.S. government.
In 2018, Section 508 was “refreshed” to incorporate WCAG 2.0 Level AA success criteria. As of the time of this writing, Section 508 does not require conformance with WCAG 2.2.
However, WCAG 2.2 includes all of the success criteria from WCAG 2.0, and following the additional criteria can significantly benefit users. That’s extremely important for organizations that serve the public.
Learn more about Section 508 →
The European Accessibility Act (EAA) and EN 301 549
The EAA came into force in June 2025, establishing binding accessibility requirements for digital products and services sold within the EU. The EAA measures compliance against the POUR principles rather than referencing WCAG directly. In practice, EN 301 549, a European standard harmonized with the EAA, maps directly to WCAG 2.1 Level AA and serves as the recognized technical benchmark for demonstrating conformance.
The EAA applies to:
Businesses based in the EU offering digital products or services
Non-EU businesses that sell products or services to EU customers
Key product and service categories, including e-commerce, banking, e-books, transport services, and consumer electronics
The territorial scope of the EAA is notable. Any organization with EU customers, regardless of where it is headquartered, must meet the standard for those users. Organizations that were already targeting WCAG 2.1 AA for ADA or Section 508 compliance will find significant overlap with EAA requirements, though some EN 301 549 provisions extend beyond WCAG into areas like hardware and documentation.
Learn more about the difference between EAA and WCAG →
The Accessibility for Ontarians with Disabilities Act (AODA)
The AODA(opens in a new tab) (opens in a new tab)enforces digital accessibility for government bodies, nonprofits, and commercial organizations with 50 or more employees in Ontario. It requires WCAG 2.0 Level A and AA conformance. While WCAG 2.2 is not explicitly required, it is strongly recommended given the AODA's built-in process for updating its standards over time.
The AODA applies to:
Government bodies in Ontario
Non-profit organizations in Ontario
Commercial organizations in Ontario with 50 or more employees
Jurisdiction Summary
Common Accessibility Barriers WCAG Addresses
WCAG addresses a broad range of issues that impact how people with disabilities interact with websites, apps, and digital content. Beyond the barriers mentioned above (e.g., poor color contrast or missing alt text), WCAG also addresses several additional problems that directly impact usability and access. This includes:
Each of these barriers maps to one or more specific WCAG success criteria. Addressing them systematically, rather than in isolation, is what separates a surface-level accessibility pass from a genuinely inclusive digital experience.
How to Achieve WCAG 2.2 Compliance
Meeting WCAG 2.2 is not a one-time task. It requires an ongoing process of testing, fixing, and monitoring to stay ahead of new barriers and keep pace with updated standards. Here's how to get started.
Step 1: Audit Your Current Site
Before you can fix accessibility issues, you need to know where they exist. A WCAG audit evaluates your site against all applicable success criteria, identifying failures, partial passes, and areas of risk.
Automated testing can surface a significant portion of common issues quickly, but a thorough audit uses both automated scanning and expert and assistive technology testing to catch barriers that automated tools miss.
Download our free WCAG 2.2 Checklist to get started.
Step 2: Fix Identified Issues
Once you have audit findings, prioritize fixes by conformance level and user impact. Level A failures should be addressed first, as they represent the most fundamental barriers.
From there, work through Level AA issues, which represent the legal compliance threshold for most organizations. Where possible, fixes should be validated with assistive technology users, not just retested with automated tools.
Step 3: Monitor for New Barriers
Accessibility is not a state you achieve once. Every content update, new feature, or third-party integration is an opportunity to introduce new barriers. Continuous monitoring ensures that your site stays compliant as it evolves, flagging new issues before they affect users or create legal exposure.
Your Path to WCAG Conformance Starts with AudioEye
Meeting WCAG 2.2 requires regular testing, accurate fixes, and ongoing monitoring. AudioEye's Accessibility Platform combines powerful automation with human-assisted AI and expert legal support to make conformance reliable at every stage.
Active Monitoring that continuously monitors your site for accessibility issues
Automatic Fixes that resolve common accessibility issues automatically
Expert legal support, custom fixes, and expert training
Whether you’re a start-up, growing organization, or an enterprise brand, AudioEye provides the tools and expertise to help you maintain accessibility, reduce legal risk, and keep your digital content aligned with the latest accessibility standards.
AUDIOEYE DEMO
Accessibility is a journey, and we're here to help guide you down that path.
Get started with a free accessibility scan that identifies common accessibility issues on your site. Or book a demo to learn more about AudioEye.
Frequently Asked Questions
Website Accessibility Checker
Check your website’s conformance in seconds. Find out if your site is accessible for people with disabilities and meets the ADA, WCAG, and other requirements.