The Web Content Accessibility Guidelines (WCAG) are the global benchmark for web accessibility. Understand what WCAG 2.1 and 2.2 require, which conformance level applies to your site, and how to meet the standard.
Web Content Accessibility Guidelines (WCAG) are the internationally recognized standards for making web content accessible to people with disabilities. Published by the World Wide Web Consortium (W3C), WCAG provides technical specifications that developers and designers follow to build websites that work for everyone, including people with visual, auditory, motor, or cognitive impairments.
WCAG is not a law in itself, but accessibility laws around the world build on it. The European Accessibility Act (through EN 301 549) and Section 508 point to WCAG as the technical standard, and in ADA Title IIIcases it’s the common benchmark.
WCAG defines three levels of conformance, each building on the previous. Understanding these levels is essential for knowing what your site actually needs to achieve.
The most basic accessibility requirements. Meeting only Level A leaves significant barriers in place for users with disabilities.
Most laws refer to Level AA, so Level A alone is not enough. It is a starting point, not a destination.
The industry standard and the level most accessibility laws refer to. Addresses the major barriers that prevent people with disabilities from using the web.
Every website should target Level AA. It’s the level the EAA standard, ADA cases and most other regulations refer to.
The highest level of accessibility. Not required by law and not achievable for all content types, but represents best-in-class practice.
Government sites, educational institutions, and organizations serving vulnerable populations. Not typically required.
For legal compliance and best practice, WCAG 2.2 Level AA is the target to aim for:
All WCAG guidelines are organized around four fundamental principles, known by the acronym POUR. Every success criterion falls under one of these principles.
Information and user interface components must be presentable to users in ways they can perceive.
User interface components and navigation must be operable by all users.
Information and the operation of the interface must be understandable.
Content must be robust enough to work with current and future technologies.
WCAG 2.2, published in October 2023, builds on WCAG 2.1 by adding 9 new success criteria and removing one outdated requirement. Conforming to WCAG 2.2 means conforming to WCAG 2.1 as well: every other 2.1 criterion carries over, and the W3C considers the removed one met for HTML.
New success criteria in WCAG 2.2. The additions focus primarily on mobile usability, cognitive accessibility, and authentication. Here is what changed:
The short answer is WCAG 2.2. It is backward compatible with 2.1, so meeting it satisfies both versions simultaneously. The new AA-level criteria address real barriers that affect real users, and the regulatory landscape is already moving in that direction.
These failures come up again and again. The first five are among the six most common errors on the top 1 million home pages, according to the WebAIM Million 2025 report.
Images lack alternative text, making content invisible to screen readers. Images lack alternative text, making content invisible to screen readers. Found on 55.5% of home pages.
Text does not have sufficient contrast against its background. Affects readability for users with low vision or color blindness. The most common failure of all, found on 79.1% of home pages.
Links with no text, or containing only an image without alt text. Screen readers cannot describe the link purpose to users. Found on 45.4% of home pages.
Form inputs without associated labels make it impossible for screen readers to identify the purpose of each field. Found on 48.2% of home pages.
Page language not specified in HTML, preventing screen readers from applying correct pronunciation rules. Found on 15.8% of home pages.
Headings that skip levels or are chosen for visual size rather than document structure. Breaks navigation for assistive technology users.
ARIA attributes that are absent, used incorrectly, or conflict with native HTML semantics. Causes unpredictable behavior in assistive technologies.
Links using generic text like “click here” or “read more” without surrounding context. Screen reader users navigating by link list cannot determine where links lead.
No visible indication when elements receive keyboard focus. Users navigating without a mouse cannot track their position on the page.
Prerecorded videos without captions or transcripts. Deaf and hard-of-hearing users cannot access the audio content.
Scanluma automates part of WCAG 2.1 and 2.2 testing, with 50+ checks against Level A and AA in every scan.
Scanluma runs 50+ automated checks against WCAG 2.1 and 2.2, Levels A and AA, on your homepage (Pro: plus up to 10 subpages).
Each issue explains in plain language what goes wrong and shows the exact HTML element affected. No guesswork about what to change or where.
Automated scans, weekly on Free and weekly or daily on Pro, catch new issues as content and code change, so they don’t pile up.
Scanluma runs 50+ automated checks across all four POUR principles, for example:
A structured, prioritized approach in four steps. How long it takes depends on your site and who does the work.
Add your website and start your first scan with Scanluma. Review the report to see the issues the automated checks found and their severity. Then test the key pages yourself with a keyboard and a screen reader, because automated checks don’t catch everything.
Address Level A violations first. Focus on the barriers that block access entirely: missing alt text, unlabeled form fields, and keyboard accessibility failures.
Work through the Level AA criteria. This includes color contrast, text resizing, enhanced navigation features, and the new WCAG 2.2 additions such as touch target sizing and focus visibility.
Run a new scan to confirm the automated issues are gone, and repeat your manual checks. On Pro, keep the PDF report for your records. Then publish an accessibility statement on your website.
WCAG 2.1 (2018) builds on 2.0 by adding 17 new success criteria covering mobile and cognitive accessibility. WCAG 2.2 (2023) adds 9 more criteria, primarily around mobile usability, focus visibility, and authentication. Each version is backward compatible, so meeting WCAG 2.2 means automatically meeting 2.1 and 2.0. WCAG 2.2 is the current version and the recommended target for any new compliance work.
No. Level AAA is not required by law and is not achievable for all content types. WCAG 2.1 Level AA is the level the EAA standard, ADA cases and most other regulations refer to. Some organizations voluntarily pursue Level AAA improvements, but there is no legal obligation to do so.
No. Automated tools like Scanluma detect part of WCAG failures quickly and consistently, such as missing alt text, low contrast and missing form labels. Other criteria need human judgment, such as whether alt text is meaningful or whether a page works well with a keyboard. Use automated scans as a baseline and add manual testing.
Test initially to establish a baseline, then again whenever you make significant content or design changes. Every Scanluma plan scans automatically, weekly on Free and weekly or daily on Pro, catching new issues before they pile up and keeping your progress visible over time.
Section 508 was updated in 2017 to align with WCAG 2.0 Level AA. While not identical, meeting WCAG 2.1 Level AA generally satisfies Section 508 requirements for web content. Section 508 also includes requirements for software and hardware that go beyond websites.
Partial compliance is not recognized as formal conformance. To claim WCAG 2.1 Level AA compliance, all Level A and AA criteria must be met. That said, fixing the most critical issues is always better than fixing nothing. Prioritize barriers that affect the most users, such as missing alt text, low color contrast, and keyboard accessibility failures.
Yes. PDFs and downloadable documents available on your website must also meet accessibility standards, including proper structure, alt text for images, and screen reader compatibility. Scanluma focuses on web content. Separate tools are needed to audit PDF accessibility.
It depends on the number of issues, the size and complexity of your site and the development time available. Start with Level A barriers that block access entirely, then work through Level AA.
Get your website monitored against WCAG 2.1 and 2.2. Every issue shows the exact element and what needs to change.
Start monitoring free →