If your website, app, portal, or document cannot be used by people with disabilities, it is not really usable for everyone. But that’s easily fixable.
WCAG gives teams a practical way to find and fix those gaps before they become customer, compliance, or legal problems.
Key Takeaways:
- WCAG, short for Web Content Accessibility Guidelines, is the global benchmark for web accessibility and digital accessibility. The current stable version is WCAG 2.2, published on October 5, 2023, while WCAG 2.1 level AA remains the most widely referenced legal target.
- WCAG success criteria are testable requirements organized under four principles: Perceivable, Operable, Understandable, and Robust, often called POUR.
- WCAG underpins major accessibility requirements, including the ADA Title II final rule from April 2024, Section 508, and the European Accessibility Act deadline of June 28, 2025.
- Following WCAG guidelines reduces accessibility issues across websites, mobile apps, documents, digital services, and time-based media such as audio and video.
- This guide explains WCAG versions, WCAG levels, accessibility conformance, legal requirements, and practical next steps for teams that want accessible content and lower legal risk.
Introduction to WCAG and Web Accessibility
WCAG is the primary international standard for web accessibility across websites, web applications, mobile applications, documents, and other digital assets. It helps organizations build digital content that people can perceive, navigate, understand, and use reliably.
And “Web content” includes more than text on a web page. It covers images, PDFs, forms, social media posts, audio track content, visual content, video-only material, prerecorded video-only content, interactive widgets, and user interface components within websites and apps.
The WCAG content accessibility guidelines are developed by the World Wide Web Consortium through the Web Accessibility Initiative, with input from accessibility experts, governments, companies, researchers, and disability advocates. The work is maintained through groups such as the accessibility guidelines working group.
Accessibility itself supports people with visual, auditory, physical, speech, cognitive, and neurological disabilities. There are 1.3 billion people worldwide who live with disabilities, highlighting the need for web accessibility to ensure everyone can access online content.
But accessibility also helps older users, mobile users, people with temporary injuries, users on slow networks, and people using mobile devices in difficult conditions. Accessible sites expand market reach by making digital content usable for millions of customers. Compliance with WCAG standards can improve overall user experience and benefit all users, not just those with disabilities.
💡 Read also: Digital Accessibility After 2025. What Does It Mean for Business Today?
As of now, the stable WCAG 2.x family includes WCAG 2.0 from 2008, WCAG 2.1 from 2018, and WCAG 2.2 from 2023. WCAG 3.0 is in draft as of 2026 and is not yet a formal standard for WCAG compliance.
Who WCAG Is For and How It Is Structured
WCAG is a technical standard for developers, designers, content authors, product managers, QA testers, accessibility specialists, procurement teams, and policy makers. It is not just for engineers. Anyone who creates or approves digital content can create or remove accessibility barriers.
WCAG 2.x is organized into:
| Layer | What it means |
| Principles | The four principles: Perceivable, Operable, Understandable, Robust |
| Guidelines | Broad accessibility goals under each principle |
| Success criteria | Specific testable success criteria used for WCAG conformance |
| Techniques | Practical ways to meet the requirements |
Each success criterion has a conformance level: A, AA, or AAA. Each criterion is written so it can be tested by people, tools, or both.
Automated accessibility testing tools can help organizations assess their site’s conformance with WCAG guidelines, identifying common violations and providing a baseline understanding of accessibility issues.
However, tools do not catch everything. Keyboard traps, confusing error messages, inaccessible authentication, and missing context often require manual review and testing with assistive technologies.
WCAG itself is not an introductory tutorial. Teams often use the W3C’s Understanding WCAG and “Techniques for WCAG” documents to interpret WCAG success criteria in real projects. WCAG 2.1 includes a customizable quick reference that provides all guidelines, success criteria, and techniques for authors to use while developing and evaluating web content.
JSON and other machine-readable formats also exist for tools and automation, but most teams begin with the human-readable accessibility guidelines and build processes from there.
Core WCAG Principles and User Interface Implications
WCAG’s accessibility standards are based on four principles, often referred to as ‘POUR’: Perceivable, Operable, Understandable, and Robust. These principles apply to any user interface, including websites, SaaS products, intranets, government portals, mobile apps, and customer dashboards.
Perceivable
The Perceivable principle states that information and user interface components must be presented in ways that users can consume with any sense available to them, such as providing text alternatives for non-text content.
In practice, this means:
- Add alt text for meaningful images.
- Provide synchronized captions for videos.
- Offer audio description when important visual information is not spoken.
- Use adaptable layouts that work when zoomed or reflowed.
- Maintain sufficient color contrast for text, buttons, icons, and form controls.
For example, a product demo should not rely only on visual content. If a presenter says “click this button here” while pointing at the screen, users who cannot see the screen need text, narration, or audio description that identifies the control.
Operable
The Operable principle requires that user interface components and navigation must be operable, meaning all functionality should be accessible via keyboard and other input methods, not just a mouse.
Operable user interface components include menus, modals, forms, filters, tabs, sliders, maps, and checkout flows. Users should be able to move through the same page with a keyboard, switch device, voice control, touch, or other input modalities.
This principle covers:
- Keyboard access with no keyboard traps.
- Clear focus indicators.
- Enough time to complete tasks.
- No seizure-inducing flashes.
- Logical headings, landmarks, skip links, and navigation patterns.
Implementing WCAG guidelines helps prevent digital exclusion for users relying on assistive technologies such as screen readers and alternative input devices.
Understandable
The Understandable principle emphasizes that information and the operation of the user interface must be understandable, with clear instructions and intuitive navigation.
This includes:
- Consistent menus and layouts.
- Predictable behavior when controls receive focus.
- Plain language where possible.
- Helpful form labels and error messages.
- Error prevention for legal, financial, or high-impact transactions.
For users with cognitive disabilities, a confusing authentication flow, unclear form error, or unexpected page change can block access as completely as a missing button.
Robust
The Robust principle states that content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
Robust content depends on semantic HTML, proper labels, correct heading structure, accessible names, and careful ARIA use. Screen readers, screen magnifiers, switch devices, browser extensions, and other assistive technologies need a reliable structure to interpret a page.
To implement WCAG guidelines effectively, developers should incorporate accessibility standards from the beginning of the coding process, ensuring that accessibility is a fundamental aspect of web development.
Accessibility is much harder when it is treated as cleanup after launch. It is easier, cheaper, and more reliable when an accessible design is built into components from the start.
WCAG Versions: 1.0, 2.0, 2.1, 2.2, and the Road to WCAG 3
WCAG has evolved from early HTML-focused guidance into one of the most important web accessibility standards used globally. Each newer version reflects changes in technology, user behavior, and accessibility knowledge.
WCAG 1.0
WCAG 1.0 was published on May 5, 1999. It focused on the web of that era, especially HTML pages, images, tables, and early multimedia.
It is now superseded in most regulations, but it established the foundation for later accessibility standards.
WCAG 2.0
WCAG 2.0 was published on December 11, 2008. It introduced the POUR framework and 12 guidelines, making the standard more technology-neutral and easier to apply beyond simple HTML pages.
WCAG 2.0 became the basis for many early legal references, public-sector standards, and procurement requirements. It also became the ISO/IEC 40500:2012 standard (with the same rules, but mandatory in some cases), which helped establish it as a global technical guideline.
WCAG 2.1
WCAG 2.1 was published on June 5, 2018. It added success criteria for mobile accessibility, low vision, and cognitive disabilities.
Important WCAG 2.1 additions include requirements for orientation, reflow, non-text contrast, text spacing, pointer gestures, motion actuation, and input purpose. These changes made WCAG requirements more relevant to modern responsive sites and mobile devices.
Many legal frameworks still reference WCAG 2.1 or WCAG 2.0. For this reason, WCAG 2.1 level AA remains the practical minimum for most organizations in 2026.
WCAG 2.2
WCAG 2.2 was published as a W3C Recommendation on October 5, 2023. It is backward-compatible with WCAG 2.1 and WCAG 2.0, except that one success criterion, 4.1.1 Parsing, was removed because it became obsolete for modern browsers and assistive technology.
In October 2025, WCAG 2.2 was approved as ISO/IEC 40500:2025, strengthening its role in procurement, policy, and accessibility conformance.
The new success criteria in WCAG 2.2 include requirements related to:
- Focus not being hidden behind sticky headers or overlays.
- Focus appearance.
- Dragging movements.
- Target size.
- Consistent help.
- Redundant entry.
- Accessible authentication.
The level AA success criteria added in WCAG 2.2 are especially practical for real products. They address common issues such as small buttons, drag-and-drop features with no alternative, and login flows that rely on memory tests or inaccessible CAPTCHAs.
WCAG 3.0
WCAG 3.0 is under active development by the accessibility guidelines working group. Drafts have been published from 2021 through 2025, with the latest Working Draft dated September 4, 2025.
WCAG 3.0 is not yet normative and should not be used as a formal WCAG conformance target in 2026. It is expected to use more flexible scoring, broader outcomes, and wider coverage beyond traditional web pages.
Organizations should monitor WCAG 3.0, but new projects should target WCAG 2.2 Level AA where feasible, while ensuring compliance with legal requirements that may still reference WCAG 2.1 Level AA.
Conformance Levels and WCAG 2.1 / 2.2 Success Criteria
WCAG defines three levels of conformance: A (lowest), AA, and AAA (highest), with each level building on the previous one. Each higher conformance level includes all lower-level success criteria.
WCAG 2.1 contains 78 success criteria distributed across Levels A, AA, and AAA.
Level A
Level A is the basic level. It removes the most severe accessibility barriers.
Examples include:
- Text alternatives for non-text content.
- Keyboard access for core functionality.
- Basic alternatives for time-based media.
- Avoiding content that causes seizures.
- Clear page titles and labels.
If a site fails Level A, essential tasks may be impossible for many users.
Level AA
Level AA is the most commonly referenced level in legal requirements and is often the target for organizations aiming for compliance with accessibility standards.
Level AA includes requirements for:
- Stronger color contrast.
- Reflow at smaller viewport widths.
- Visible focus.
- Consistent navigation.
- Error identification.
- Captions for live audio in synchronized media.
- Better support for mobile accessibility.
Level AA is also the most common target in contracts, accessibility conformance reports, and web accessibility standards used by government agencies and enterprise buyers.
Level AAA
While Level AAA is the highest conformance level, it is not generally recommended as a requirement for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
AAA may include:
- Extended audio description.
- Sign language interpretation.
- Higher contrast thresholds.
- More restrictive reading-level requirements.
- More complete media alternative options.
Some organizations aim for selected AAA requirements on critical pages, such as healthcare, education, or public safety content.
Example: How media requirements escalate
Here is how accessibility requirements become stronger across levels for a training video:
| Level | Example requirement |
| A | Provide captions for prerecorded video with audio and a media alternative for audio-only or video-only content where required |
| AA | Provide live captions for webinars, livestreams, and town halls |
| AAA | Add extended audio description, sign language interpretation, and more complete text alternatives where appropriate |
This layered structure is why many teams target level AA first, then selectively add AAA improvements where they create meaningful user value.
Time Based Media and Other Common Accessibility Issues
Audio and video are frequent sources of accessibility issues under WCAG 2.0, WCAG 2.1, and WCAG 2.2. They are also common in training portals, product pages, help centers, online courses, and public-sector websites.
According to research by WebAIM Million report, approximately 96% of the top one million home pages contained detectable WCAG failures in 2025, indicating a significant gap between available digital content and its usability for people with disabilities.
Web accessibility is essential to bridge the gap between the volume of digital content available and the volume of content that’s usable for people with disabilities, ensuring online experiences work for everyone.
Captions for prerecorded content
Synchronized captions should include spoken words and meaningful sounds, such as alarms, laughter, music cues, or off-screen announcements.
Examples include:
- Training videos.
- Product demos.
- Customer onboarding videos.
- Internal HR explainers.
- Course lectures.
Captions help deaf and hard-of-hearing users, but they also help users in noisy spaces, quiet offices, or mobile situations where audio is inconvenient.
Captions for live content
At Level AA, live captions are required for many live audio and video experiences, such as:
- Webinars.
- Town halls.
- Livestreamed events.
- Public meetings.
- Live training sessions.
Common approaches include CART captioning, professional live captioners, and automated captioning with human review where accuracy matters.
Audio description
Audio description explains important visual information that is not available in the audio track.
For example, if a safety video shows a warning label, a form field, or a physical action without saying it aloud, blind and low-vision users may miss critical information.
At AAA, extended audio description may be needed when there is not enough space in the original audio to describe important visual details.
Media alternatives
A media alternative can include a full transcript, structured text version, or equivalent explanation of complex time-based media.
This helps users who are deafblind, users who prefer reading, users searching for specific information, and users who need translation or review.
Other common accessibility issues
Beyond media, the most frequent failures include:
- Low color contrast.
- Missing alt text.
- Inaccessible forms.
- Inaccessible PDFs.
- Buttons without accessible names.
- Menus that do not work with a keyboard.
- Modal dialogs that trap focus.
- Inaccessible websites built with custom controls and no semantic structure.
Accessibility testing tools can identify many common problems, but manual testing is still needed for complex workflows, user interface behavior, and assistive technology support.
WCAG and the Law: ADA, European Accessibility Act, and Global Regulations
WCAG is not a law by itself. It becomes powerful because laws, regulations, contracts, courts, and procurement policies use WCAG as the benchmark for equal access.
Many countries mandate WCAG adherence to avoid legal compliance issues and lawsuits related to accessibility. Conformance with WCAG standards is often required for compliance with various legal mandates, including the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act.
ADA and US regulations
In the United States, the Department of Justice issued a final rule updating Title II of the Disabilities Act for state and local government websites and mobile apps. The Federal Register published the final rule on April 24, 2024.
The rule requires state and local governments’ web content and mobile apps to conform to WCAG 2.1 Level AA. This applies to public services such as city websites, permit systems, public school portals, transit apps, emergency information, and online forms.
In April 2026, the U.S. Department of Justice issued an interim final rule extending compliance deadlines by one year, but the standard remained WCAG 2.1 Level AA.
Private companies are not directly covered by Title II, but ADA Title III litigation often uses WCAG 2.0 or WCAG 2.1 AA as the practical benchmark, although Title III itself does not formally mandate a specific WCAG version.
Accessibility-related lawsuits have increased significantly, with more than 11,000 ADA Title III lawsuits filed in 2021 across a range of accessibility issues, including digital accessibility, highlighting the legal risks of non-compliance with WCAG standards.
Many courts have referenced WCAG standards in legal cases, using them as a benchmark for determining website accessibility compliance under the ADA. The lack of a defined standard for website accessibility increases the likelihood of successful prosecution in accessibility-related cases, as many plaintiffs cite WCAG violations as evidence of inaccessibility.
Section 508
Section 508 applies to US federal agencies and many contractors. The Section 508 Refresh adopted WCAG 2.0 Level AA for federal digital content, software, and electronic information.
Although the formal baseline is WCAG 2.0 Level AA, many agencies increasingly look toward WCAG 2.1 and WCAG 2.2 best practices, especially for mobile applications, authentication, and modern web apps.
European Accessibility Act
The European Accessibility Act required many products and services to meet accessibility standards by June 28, 2025. This includes e-commerce, banking services, e-books, transport services, telecom, and other digital services.
The EAA uses the EN 301 549 norm, which currently references WCAG 2.1 Level AA for web content. A newer version of EN 301 549 is expected to reference WCAG 2.2 AA, so organizations in the EU should track the new success criteria now.
Other jurisdictions
Other countries also use WCAG in public-sector or anti-discrimination frameworks, including:
- The UK Public Sector Bodies Accessibility Regulations.
- Canada’s Accessible Canada Act and provincial accessibility laws.
- Australia’s public-sector accessibility rules.
- Israel’s WCAG-based requirements.
The practical takeaway is simple:
align with WCAG 2.1 Level AA now, adopt relevant WCAG 2.2 improvements, and keep evidence of accessibility conformance through audits, issue logs, and conformance reports.
Practical Steps to Achieve WCAG Conformance
WCAG can seem overwhelming, but the implementation path is straightforward when broken into stages. The goal is to move from awareness to repeatable practice.
1. Audit and baseline
Start by auditing your digital assets against WCAG 2.1 Level AA or WCAG 2.2 Level AA.
Use a mix of:
- Automated scanning.
- Manual expert review.
- Keyboard-only testing.
- Screen reader testing.
- Mobile testing.
- User testing with people with disabilities.
Automated tools are useful for baseline findings, but they cannot prove full WCAG compliance. They will be perfect for starting the review, but should not be the end.
2. Prioritize high-impact issues
Fix blockers first, especially on high-traffic, revenue-critical, or legally sensitive pages.
Prioritize:
- Navigation that cannot be used by keyboard.
- Forms that screen readers cannot understand.
- Missing captions.
- Low contrast in core flows.
- Checkout or application steps with inaccessible controls.
- Login flows that block password managers or require cognitive tests.
These issues affect real tasks and create the highest legal risk.
3. Build accessibility into design and development
To implement WCAG guidelines effectively, developers should incorporate accessibility standards from the beginning of the coding process, ensuring that accessibility is a fundamental aspect of web development.
This means:
- Use accessible design patterns.
- Define color palettes that pass contrast requirements.
- Build tested components for buttons, modals, menus, tabs, and forms.
- Include keyboard behavior in acceptance criteria.
- Add accessibility checks to code review.
- Test with real input methods, not only a mouse.
Shift-left accessibility prevents teams from repeatedly fixing the same defects after release.
4. Govern content
Content teams create many accessibility issues without realizing it.
Give authors simple checklists for:
- Headings.
- Link text.
- Alt text.
- Tables.
- Plain language.
- Document accessibility.
- Captions and transcripts.
- Social media posts.
For example, “click here” links are less useful than descriptive links. A PDF uploaded without tags can block users even if the surrounding page is accessible.
5. Monitor and train
Accessibility is not a one-time project. It needs ownership.
Set up:
- Annual comprehensive audits.
- Regression testing after releases.
- Accessibility checks in CI pipelines.
- Training for designers, developers, QA, and content authors.
- A clear issue owner and escalation path.
- A process for user feedback and remediation.
Organizations aim for sustainable accessibility when they treat WCAG standards like security, privacy, or performance: part of normal product quality.
FAQ
Is WCAG mandatory for private companies, or only for governments?
Many explicit WCAG references appear in public-sector rules such as the ADA Title II, Section 508, and EU public-body requirements. However, private organizations are often effectively required to follow WCAG through anti-discrimination laws, procurement contracts, settlements, and case law.
In the US, many ADA Title III lawsuits against retailers, restaurants, hotels, and service providers cite WCAG 2.0 or WCAG 2.1 Level AA as the expected standard. Similar patterns exist in Canada, the EU, and the UK.
Even when WCAG is not named directly in a statute, adopting WCAG is the safest path to reduce legal risk and improve customer experience.
Which WCAG version should new projects target in 2026?
New projects should use WCAG 2.1 Level AA as the minimum benchmark because it is the most widely referenced in laws and existing standards today.
Teams should also adopt relevant new success criteria from WCAG 2.2, especially focus appearance, focus not obscured, dragging movements, target size, redundant entry, and accessible authentication.
WCAG 3.0 should inform long-term planning, but it should not be used as a formal conformance target in 2026 because it is still a draft.
Does conforming to WCAG guarantee that every user will have a perfect experience?
No. WCAG conformance significantly reduces barriers, but it cannot guarantee a perfect experience for every person, disability, device, browser, and assistive technology combination.
WCAG sets minimum testable requirements. Strong teams go further with user research, usability testing with people with disabilities, feedback loops, and continuous improvement.
Accessibility is an ongoing practice, not a one-time compliance checkbox.
How often should we review our site or app against WCAG?
Stable sites should receive at least one comprehensive WCAG review each year.
High-change environments, such as SaaS products, e-commerce stores, universities, and content-heavy portals, should test more often. Each major release, redesign, CMS migration, or component library update should trigger targeted WCAG regression testing.
Lightweight automated checks can also be added to continuous integration pipelines to prevent common accessibility issues from reaching production.
Do WCAG success criteria apply to native mobile apps as well as websites?
Yes. WCAG 2.1 and WCAG 2.2 success criteria are technology-agnostic and apply to web content and mobile applications.
5 min
