What Is WCAG? The Web Content Accessibility Guidelines Explained

WCAG — the Web Content Accessibility Guidelines — is the global standard for making websites usable by people with disabilities. This guide breaks down what WCAG is, how its principles and conformance levels work, what changed in WCAG 2.2, and what non-compliance can cost your organization.

Nearly 94.8% of the top one million websites fail basic accessibility standards, averaging around 51 detectable errors per homepage. Meanwhile, more than 5,100 ADA digital accessibility lawsuits were filed in the United States in 2025 alone — and the legal and reputational costs of ignoring accessibility are rising fast. Whether you run an e-commerce store, a SaaS platform, or a government portal, one document sits at the center of almost every accessibility conversation: WCAG, the Web Content Accessibility Guidelines. If you have ever wondered exactly what WCAG is, why it exists, and what it actually requires of you, this guide is the plain-English explanation you have been looking for. <h2>The Origins of WCAG: Where the Standard Comes From</h2> WCAG is published by the Web Accessibility Initiative (WAI), a program of the World Wide Web Consortium (W3C) — the same international body that standardizes HTML, CSS, and most of the foundational technologies of the web. The guidelines exist because the web, by its very nature, carries a promise of universal access. In practice, without deliberate design choices, that promise falls apart for millions of users. The roots of web accessibility guidelines trace back to 1995, when Gregg Vanderheiden compiled the first web accessibility guideline just after Tim Berners-Lee mentioned disability access in a keynote at the Second International Conference on the World-Wide Web. Over the following years, more than 38 different web access guidelines emerged from various authors and organizations, eventually converging into the Unified Web Site Accessibility Guidelines at the University of Wisconsin–Madison. Version 8 of that document, published in 1998, became the starting point for WCAG 1.0, which became an official W3C Recommendation on 5 May 1999. WCAG 2.0 arrived in December 2008 and was significant enough to be adopted as an ISO standard — ISO/IEC 40500:2012 — in October 2012. WCAG 2.1, published in June 2018, extended the 2.0 criteria with 17 new success criteria focused on mobile usability, low vision, and cognitive accessibility. And the current version, WCAG 2.2, was published as a W3C Recommendation on 5 October 2023 and has since been approved as ISO/IEC 40500:2025. W3C encourages everyone to use the latest version, and for good reason: content that meets WCAG 2.2 automatically meets WCAG 2.1 and WCAG 2.0 as well. It is worth being clear about what WCAG is and is not. It is a technical standard — a precise, testable specification developed through a rigorous multi-stakeholder W3C process in cooperation with individuals and organizations around the world. It is not a legal document in itself, but it has been incorporated by reference into laws and regulations across dozens of jurisdictions, making it the de facto rulebook for digital accessibility worldwide. <h2>Who WCAG Is Designed to Help</h2> WCAG addresses accessibility barriers for people with a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. That is a remarkably broad population. The World Health Organization estimates that about 1.3 billion people — roughly 16% of the global population — live with some form of disability that affects their daily life and online access. Any one of these individuals could be a potential customer, citizen, student, or employee trying to use your website right now. But the benefits of WCAG compliance extend well beyond users with permanent disabilities. The guidelines also help older individuals with age-related limitations — reduced vision, hearing loss, slower motor response — and often improve usability for everyone. Consider captions on video: they were designed for deaf users, but they also benefit viewers watching in noisy environments, non-native speakers following along, and anyone who prefers reading to listening. Similarly, keyboard navigability helps power users who find the mouse slow, and sufficient color contrast helps anyone squinting at a bright screen outdoors. WCAG also covers content across virtually every kind of digital device — desktops, laptops, kiosks, and mobile devices — and is intentionally technology-neutral. The success criteria are written as testable statements that do not prescribe a specific technology, which means they remain relevant as HTML, JavaScript frameworks, and assistive technologies continue to evolve. <h2>The POUR Principles: The Conceptual Foundation of WCAG</h2> Every success criterion in WCAG — all 86 of them in version 2.2 — is organized under four top-level principles, collectively known by the acronym POUR. These principles provide the conceptual foundation of the entire standard. Understanding them gives you an intuitive mental model for accessibility, even before you read a single specific criterion. <ul> <li>Perceivable: Information and user interface components must be presentable to users in ways they can perceive. In practice, this means content cannot be invisible to all of a user's senses. If a user cannot see an image, there must be a text alternative they can hear via a screen reader. If a video has a spoken narration, there must be captions for users who cannot hear. Practical requirements under this principle include alt text for images, captions for video, sufficient color contrast between text and background, and the ability to resize text without loss of content.</li> <li>Operable: User interface components and navigation must be operable. No interaction can require input that a user cannot perform. The most common implication: all functionality must be achievable with a keyboard alone, not only with a mouse. This principle also covers giving users enough time to read and interact with content, avoiding content that could trigger seizures, and providing multiple ways to navigate a site.</li> <li>Understandable: Information and the operation of the user interface must be understandable. The content cannot be so complex or confusing that users cannot make use of it as intended. This covers readable language (including specifying the page language in code so screen readers use the right pronunciation), predictable page behavior, clear instructions, and helpful error messages that tell users what went wrong and how to fix it.</li> <li>Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. A robust site uses clean, valid semantic markup so that screen readers, Braille displays, and other assistive tools can parse and convey the content correctly — both now and as technology evolves.</li> </ul> <blockquote>Think of POUR as four filters through which every element of your website must pass. If a component fails even one of the four filters, it is likely a barrier for some of your users.</blockquote> These four principles have remained stable across every version of WCAG — 2.0, 2.1, and 2.2 — even as the specific success criteria beneath them have grown and evolved. That stability makes POUR a durable lens for evaluating accessibility regardless of which version a particular law references. <h2>Conformance Levels: A, AA, and AAA Explained</h2> Beneath the four POUR principles sit 13 guidelines, and beneath those guidelines sit the 86 testable success criteria — the actual, specific requirements you must meet to claim WCAG conformance. Each success criterion is assigned one of three conformance levels. <ul> <li>Level A is the minimum. These are the most critical requirements, representing barriers so severe that certain users simply cannot access content at all. Examples include providing text alternatives for non-text content and ensuring all functionality is keyboard accessible. Level A alone is not sufficient for most regulatory purposes, but failing it means fundamental failure.</li> <li>Level AA is the mid-range standard and the one required by the vast majority of laws and regulations globally. It satisfies all Level A criteria plus additional requirements such as ensuring text-to-background color contrast ratios of at least 4.5:1, providing consistent navigation across pages, and offering captions for pre-recorded video. Most global accessibility laws — including Section 508 in the US, EN 301 549 in Europe, and AODA in Ontario, Canada — require Level AA conformance. This is the target almost every organization should prioritize.</li> <li>Level AAA is the highest standard and includes criteria that are aspirational rather than universally achievable. The W3C itself acknowledges that it is not possible to satisfy all AAA criteria for all types of content, so these criteria are not typically set as a general policy requirement. Examples include sign language interpretation for all audio content and a reading level no more difficult than lower secondary education.</li> </ul> One important nuance: conformance levels are cumulative. Achieving Level AA means you also satisfy all Level A criteria. Achieving Level AAA means you satisfy A and AA as well. And crucially, conformance is all-or-nothing at each level — you cannot claim AA conformance if even a single AA criterion is unmet on a given page. <blockquote>For most organizations, WCAG 2.2 Level AA is the right target. It is the level embedded in law, the level courts use as a benchmark, and the level that meaningfully opens your digital experience to the widest possible audience.</blockquote> <h2>What Changed in WCAG 2.2: The Nine New Success Criteria</h2> WCAG 2.2, published in October 2023, added nine new success criteria on top of everything in WCAG 2.1. These additions were driven by ongoing research into where disabled users — particularly those with cognitive disabilities, motor impairments, and low vision — still encountered frequent barriers that the earlier guidelines did not adequately address. WCAG 2.2 does not remove or change any existing WCAG 2.1 requirements; it simply extends them. Of the nine new criteria, four are at Level AA (and therefore legally relevant for most organizations), two are at Level A, and three are at Level AAA. Here is what each AA-and-below criterion actually means in practice: <ul> <li>2.4.11 Focus Not Obscured — Minimum (AA): When a keyboard user navigates to an interactive component, that component must not be entirely hidden by other author-created content. This is a direct response to a common modern design pattern: sticky headers, cookie banners, and fixed footers that slide over page content and silently swallow keyboard focus, leaving users stranded with no visible indication of where they are on the page.</li> <li>2.5.7 Dragging Movements (AA): Any functionality that requires a dragging action — think drag-and-drop file uploads, sortable list items, or custom sliders — must have a single-pointer alternative that does not require dragging. For a user with hand tremors or limited fine motor control, maintaining continuous pressure while moving a pointer across the screen can be nearly impossible. Providing click-to-select-then-click-to-place alternatives, or up/down arrow buttons on sortable lists, resolves this.</li> <li>2.5.8 Target Size — Minimum (AA): Interactive targets such as buttons and links must be at least 24×24 CSS pixels. Small tap targets are a well-documented usability problem for mobile users with motor impairments, older users, and really anyone typing on a phone while multitasking.</li> <li>3.3.8 Accessible Authentication — Minimum (AA): Authentication processes cannot require users to solve a cognitive function test — such as a traditional CAPTCHA requiring character recognition or puzzle solving — unless an alternative is provided. This is a significant criterion for any site that uses standard CAPTCHA challenges in login or registration flows. Solutions include password manager support, email or SMS magic links, biometric authentication, or object-recognition alternatives.</li> <li>3.2.6 Consistent Help (A): If a site provides a help mechanism (such as a live chat button, FAQ link, or support phone number) on multiple pages, that mechanism must appear in the same relative location across pages. Users with cognitive disabilities who need help benefit greatly from knowing exactly where to find it without having to search each time.</li> <li>3.3.7 Redundant Entry (A): Information previously entered by a user in a multi-step process must be auto-populated or selectable rather than requiring re-entry. This reduces friction for users with cognitive or motor disabilities for whom form completion is especially taxing.</li> </ul> WCAG 2.2 also formally removed one criterion from 2.1: 4.1.1 Parsing. This criterion originally required strictly valid HTML to ensure assistive technologies could parse markup correctly. It has been retired because modern browsers and assistive technologies now handle malformed markup robustly through their own error-correction mechanisms, making the criterion no longer practically meaningful for accessibility. <h2>WCAG and the Law: What Non-Compliance Actually Costs</h2> WCAG is a technical standard, not a law. But it has been woven into the legal fabric of digital accessibility in most major jurisdictions, which means non-conformance carries real legal exposure. In the United States, while neither the ADA nor Section 508 explicitly name WCAG 2.2 by text, WCAG is consistently used as the technical benchmark in litigation and enforcement. The Department of Justice published a Final Rule in 2024 setting WCAG 2.1 Level AA as the official standard for Section 508 compliance and ADA Title II compliance for state and local governments. ADA Title III — which applies to public accommodations including most private businesses operating online — is actively enforced through private lawsuits. In 2024, over 4,000 ADA lawsuits related to digital properties were filed in federal and state courts, and the trend continued upward into 2025. ADA first-violation civil penalties were adjusted for inflation in 2024 and can now reach $115,231, rising to $230,464 for repeat offenses. In Europe, the picture is equally significant. The European Accessibility Act (EAA) became legally applicable in EU member states on 28 June 2025, requiring websites, apps, e-books, e-commerce platforms, and PDFs to conform to WCAG 2.1 AA criteria. The European Standard EN 301 549 currently references WCAG 2.1, with the next version expected to update to WCAG 2.2. For organizations with a footprint in Europe, EAA compliance is no longer optional. The litigation data also exposes a particularly painful pattern for smaller businesses: the idea that staying small keeps you safe is a myth. In 2023, 77% of ADA digital accessibility lawsuits targeted companies with under $25 million in annual revenue. E-commerce remains the most-sued sector by a wide margin. And critically, being sued once provides no protection against being sued again — nearly half of all digital accessibility lawsuits in recent years targeted companies that had already faced at least one prior claim. <h2>The Most Common WCAG Failures (And How to Spot Them)</h2> Given that nearly 95% of websites fail basic accessibility standards, it is worth knowing which specific failures are most prevalent. The annual WebAIM Million report, which audits the homepages of the top one million websites, consistently identifies the same handful of issues appearing on the vast majority of pages: <ul> <li>Low color contrast: Low-contrast text affected 79.1% of home pages in the 2025 analysis, averaging nearly 30 instances per page. This is simultaneously the most common failure and one of the easiest to detect with automated tools. Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text) to meet Level AA.</li> <li>Missing alternative text: Missing alt text affects 55.5% of pages. For screen reader users who are blind or have low vision, an image without alt text is simply invisible — the assistive technology will either skip it silently or read out a meaningless filename. Linked images without alt text completely break navigation.</li> <li>Missing form labels: Form inputs without associated labels mean that a screen reader user cannot tell what information a field is asking for. This creates an impenetrable barrier at any checkout, registration, or contact form.</li> <li>Empty links: Links with no descriptive text — often icon-only links or image links without alt text — leave keyboard and screen reader users with no context about where the link goes.</li> <li>Missing document language: Failing to declare the language of a page in the HTML means screen readers may read content using the wrong language's pronunciation rules, making the text incomprehensible.</li> </ul> What is striking about this list is that none of these are exotic edge cases requiring advanced engineering. They are straightforward markup and design decisions. The fact that they persist across the vast majority of the web reflects a structural gap in how accessibility is (or is not) integrated into typical web development workflows, not a fundamental technical barrier. <h2>How to Approach WCAG Compliance as an Organization</h2> Getting from where most websites are today to genuine WCAG 2.2 Level AA conformance requires a systematic approach. It is not a one-time project — it is an ongoing process, because content changes, frameworks update, and third-party components get swapped in and out. Here is how to structure the effort effectively. Start with a baseline audit. Before you can fix anything, you need to know what is broken. Automated scanning tools can identify a meaningful subset of issues — color contrast problems, missing alt text, absent form labels — quickly and at scale. However, automated tools have well-known limits; they can detect roughly 30–40% of WCAG issues. The rest require manual testing: navigating your site using only a keyboard, testing with actual screen readers such as NVDA or JAWS on Windows and VoiceOver on macOS and iOS, and ideally involving users with disabilities in your testing process. Prioritize by impact and frequency. Not all issues carry equal weight. A missing alt text on a decorative icon is far less critical than a broken keyboard trap that leaves a user unable to escape a modal dialog, or a login form that is entirely unusable with a screen reader. Focus your first remediation sprint on the barriers that block core user journeys — checkout, account creation, search, contact — before addressing cosmetic or lower-impact items. Build accessibility into the development workflow, not onto the end. The most expensive accessibility work is remediation after launch. Integrating accessibility checks into your design system, component library, code review process, and CI/CD pipeline catches issues at the point where they are cheapest to fix. Establish a clear owner for accessibility within your team and provide role-specific training for designers, developers, and content editors. Maintain an accessibility statement. Publishing a clear, honest accessibility statement on your website — describing which standard you target, how users can report barriers, and how you respond to reports — demonstrates good faith and is actually required by law in some jurisdictions, including under the EU Web Accessibility Directive. It also creates a feedback loop that helps you catch issues you missed in testing. Use overlay widgets as enhancements, not a substitute for code-level accessibility. Accessibility overlay widgets and SDKs — including Accsible — can be valuable tools for surfacing user-controlled preferences such as text sizing, contrast modes, and keyboard navigation enhancements. But the data is clear: widgets deployed in place of foundational accessibility work do not prevent lawsuits. The legal protection comes from your underlying code meeting WCAG criteria, not from a widget installed on top of an inaccessible foundation. Use overlays to supplement genuine remediation, not to replace it. <h2>The Road Ahead: WCAG 3.0 on the Horizon</h2> Even as organizations are still working to meet WCAG 2.2, the W3C Accessibility Guidelines Working Group is developing WCAG 3.0, a more substantial restructuring of web accessibility guidance. The first public working draft was released in early 2021, and as of late 2025 the working draft continues to undergo significant development. No part of WCAG 3.0 is an official recommendation yet, and no fixed release date has been defined. WCAG 3.0 is expected to depart meaningfully from the A/AA/AAA conformance model, introduce a scoring-based approach, and cover a broader range of digital content types including native mobile applications and emerging technologies. For now, organizations should focus on WCAG 2.2 Level AA — it is the current enforceable standard and will remain so for the foreseeable future. Organizations that build solid WCAG 2.2 foundations now will be far better positioned to adapt when WCAG 3.0 eventually becomes a recommendation. <h2>Key Takeaways</h2> <ul> <li>WCAG 2.2 is the current global standard for web accessibility, published by the W3C and approved as ISO/IEC 40500:2025. Content meeting WCAG 2.2 automatically satisfies 2.1 and 2.0 — aim for the latest version.</li> <li>Level AA is the target that matters. Nearly all global accessibility laws — ADA, Section 508, EAA, EN 301 549, AODA — reference WCAG Level AA as the required conformance level. Focus your efforts there first.</li> <li>The most common failures are fixable. Low color contrast, missing alt text, absent form labels, and empty links account for the majority of accessibility errors across the web. These are solvable with relatively little effort and significant impact.</li> <li>Automated testing is necessary but not sufficient. Tools can detect around 30–40% of WCAG issues. Pair automated scanning with keyboard testing, screen reader testing, and ideally user testing with people who have disabilities to get a complete picture.</li> <li>Accessibility is an ongoing process, not a one-time project. Content changes, third-party components change, and standards evolve. Build accessibility into your design, development, and content workflows so it is maintained continuously, not fixed reactively after a complaint or lawsuit.</li> </ul>

WcagStandardsAccessibilityGuideComplianceAda