To make a website WCAG compliant, pick a target (in 2026, WCAG 2.2 Level AA), define which pages and processes are in scope, audit a representative sample with automated checks, manual review and screen readers, fix the failures at their source, retest, then publish an accessibility statement and keep every release passing the same checks.
This guide covers the standard itself (versions, conformance levels, the four principles and what WCAG 2.2 added), the five-step process built on the W3C's own evaluation methodology, the laws in the EU, US, Canada and UK that point to WCAG, and why an overlay widget does not get you there. Code-level fixes, such as colour contrast and target sizes, are covered in our guide to improving website accessibility, and the design rules behind them in our web design guide; here they stay brief.
What WCAG is and who publishes it
The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative, and written by the Accessibility Guidelines Working Group. The W3C's WCAG overview lists the versions in force, all of them W3C Recommendations:
| Version | Published | What changed |
|---|---|---|
| WCAG 2.0 | December 11, 2008 | 12 guidelines with testable success criteria |
| WCAG 2.1 | June 5, 2018 | 1 guideline and 17 success criteria added |
| WCAG 2.2 | October 5, 2023, updated December 12, 2024 | 9 success criteria added, 4.1.1 Parsing made obsolete |
| WCAG 3 | Working Draft only (latest: September 10, 2026) | New structure and conformance model; not a standard to target |
The versions are backwards compatible: content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, and a newer version does not deprecate an older one. The W3C encourages using the latest. WCAG is also an ISO standard. ISO/IEC 40500:2012 was WCAG 2.0; its replacement, ISO/IEC 40500:2025, is identical to the October 2023 version of WCAG 2.2, and the W3C expects the December 2024 update to follow as ISO/IEC 40500:2026 by late 2026.
WCAG 2.2 is organized in four layers. At the top are four principles; under them sit 13 guidelines; each guideline has testable success criteria, and each criterion has a level: A, AA or AAA. Supporting documents (Understanding, Techniques) explain how to meet the criteria, but only the criteria decide conformance. The W3C's explanation of the four principles reads, in short:
| Principle | What it requires | Example success criteria |
|---|---|---|
| Perceivable | Information and interface components can be presented in ways users can perceive | Text alternatives, captions, contrast |
| Operable | Interface components and navigation can be operated | Keyboard access, visible focus, target size |
| Understandable | Information and the operation of the interface are understandable | Page language, consistent navigation, form errors |
| Robust | Content works reliably with a wide range of user agents, including assistive technology | Name, role and value of controls, status messages |
WCAG 3 is a draft, not a target
WCAG 3 (the W3C Accessibility Guidelines 3.0) will have a different structure, a new conformance model and a scope beyond web content. According to the W3C's WCAG 3 introduction, as of September 2026 it is an incomplete draft that will change substantially, it is not expected to become a finished standard for a few more years, and WCAG 2 will not be deprecated for several years after that. The W3C's advice is plain: the best way to prepare for WCAG 3 is to meet WCAG 2.2 now.
WCAG conformance levels: A, AA and AAA
The levels are cumulative. Counting the success criteria in WCAG 2.2, 86 are in force (4.1.1 Parsing is marked obsolete and removed): 31 at Level A, 24 at Level AA and 31 at Level AAA.
| Level | A page conforms when it meets | Criteria in WCAG 2.2 | Typical use |
|---|---|---|---|
| A | All Level A criteria | 31 | The minimum; not enough for the rules below |
| AA | All Level A and AA criteria | 55 (31 + 24) | The level laws, policies and contracts ask for |
| AAA | All Level A, AA and AAA criteria | 86 | Selected criteria for specific content or audiences |
Level AA is the usual target for two reasons. Every rule in the law section below references it, and the W3C itself says it is not recommended to require AAA as a general policy for whole sites, because some content cannot satisfy every AAA criterion. Adopting individual AAA criteria where they fit is still worthwhile.
"Compliant" is the word laws and contracts use; WCAG's own word is "conform", and conformance has five requirements, not one:
- Conformance level: every criterion at the chosen level is met in full, or a conforming alternate version is provided.
- Full pages: conformance applies to whole pages, including each responsive variation; you cannot exclude a part of a page.
- Complete processes: if one page in a process fails (a checkout, a sign-up), no page in that process conforms.
- Only accessibility-supported ways of using technologies: the features you rely on must work with users' browsers and assistive technology.
- Non-interference: anything that is not accessibility supported must not block the rest of the page. Four criteria (audio control, no keyboard trap, three flashes, and pause, stop, hide) apply to all content, even content you do not rely on.
A formal conformance claim is optional. If you make one, WCAG requires its date, the guideline version and URL, the level, the pages covered and the web technologies relied upon. Pages with user-generated or syndicated content can use a statement of partial conformance, or claim conformance if non-conforming third-party content is monitored and repaired within two business days.
The WCAG 2.2 AA checklist, guideline by guideline
The 55 Level A and AA criteria are spread across the 13 guidelines. This is the map an auditor works through; the W3C's filterable How to Meet WCAG quick reference lists every criterion with its techniques and is the checklist to test against.
| Guideline | A and AA criteria | What gets checked |
|---|---|---|
| 1.1 Text alternatives | 1 | Every meaningful image, icon and chart has a text alternative |
| 1.2 Time-based media | 5 | Captions, audio description or a media alternative for audio and video |
| 1.3 Adaptable | 5 | Headings, lists, tables and form fields exposed in code, not just by styling |
| 1.4 Distinguishable | 9 | Contrast of text (4.5:1) and controls, resizing, reflow, text spacing |
| 2.1 Keyboard accessible | 3 | Everything works with a keyboard, with no traps |
| 2.2 Enough time | 2 | Time limits can be extended; moving content can be paused |
| 2.3 Seizures and physical reactions | 1 | Nothing flashes more than three times a second, or it stays under the flash thresholds |
| 2.4 Navigable | 8 | Page titles, skip links, focus order, visible focus not hidden by sticky bars |
| 2.5 Input modalities | 6 | Pointer gestures, dragging alternatives, targets of at least 24 by 24 CSS pixels |
| 3.1 Readable | 2 | The page language and changes of language are declared |
| 3.2 Predictable | 5 | Consistent navigation, labels and help; no surprise context changes |
| 3.3 Input assistance | 6 | Labels, error messages and suggestions, no repeated entry, accessible sign-in |
| 4.1 Compatible | 2 | Controls expose name, role and value; status messages reach screen readers |
What WCAG 2.2 added
WCAG 2.2 adds nine success criteria to WCAG 2.1. Six are at Level A or AA, so they are part of an AA target:
| Criterion | Level | What it asks |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A focused element is at least partly visible, not hidden under a sticky header or banner |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | A focused element is fully visible |
| 2.4.13 Focus Appearance | AAA | The focus indicator is large enough and has 3:1 contrast between states |
| 2.5.7 Dragging Movements | AA | Anything done by dragging can also be done with a single pointer |
| 2.5.8 Target Size (Minimum) | AA | Pointer targets are at least 24 by 24 CSS pixels, or spaced so they cannot be confused |
| 3.2.6 Consistent Help | A | Help mechanisms repeated across pages stay in the same relative order |
| 3.3.7 Redundant Entry | A | Information already entered in a process is filled in or selectable, not asked again |
| 3.3.8 Accessible Authentication (Minimum) | AA | Sign-in needs no cognitive test, such as recalling a password, without an alternative |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | As above, without the object recognition and personal content exceptions |
The one removal is 4.1.1 Parsing. It was written for assistive technology that parsed HTML itself, which it no longer does, so WCAG 2.2 marks it obsolete. If a policy still names WCAG 2.0 or 2.1, the specification notes that you may need to keep testing and reporting 4.1.1.
In practice, the new AA criteria catch patterns that passed older audits: cookie banners and sticky headers that cover the focused link, sortable lists that only work by dragging, small icon buttons packed together, and sign-in forms that block pasting or rely on a puzzle CAPTCHA. The W3C notes that letting password managers fill the field, and allowing copy and paste, are ways to meet 3.3.8.
Step 1: define the scope and the target
An audit can only find what it looks at, so start with an inventory, not a scan.
- List everything the site includes: domains and subdomains, page templates, web applications behind a sign-in, PDFs and other documents, and third-party parts such as chat, payment, booking, maps and embedded video.
- Name the processes: sign-up, sign-in, search, checkout, booking, contact and any multi-step form. Each is tested end to end, because of the complete processes requirement.
- Set the target: WCAG 2.2 Level AA unless a law or contract names something else, and note anything it adds (EN 301 549, for example, also covers documentation and support services).
- Agree an accessibility support baseline: the browsers and assistive technology the site must work with, for example NVDA or JAWS with Chrome, Edge or Firefox on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android.
Third-party content is in scope. WCAG-EM calls this the principle of product enclosure: excluding parts of a site conflicts with WCAG's full pages and complete processes requirements. If your booking widget fails, your booking process fails.
Step 2: audit a sample with WCAG-EM
The W3C's WCAG Evaluation Methodology is the reference process for auditing a whole site. Version 2.0, published as a W3C Group Note on July 23, 2026, extends the 2014 version from websites to apps and other digital products. It works in five steps: define the evaluation scope, explore the site, select a representative sample, evaluate the sample, and report the findings.
The sample has three parts. A structured sample covers the common views, the essential functionality, each type of page and each technology relied upon. A random sample adds 10% on top of it (WCAG-EM's example: 80 structured samples plus 8 random ones), picked in an unpredictable way across the whole site. Finally, every complete process is included from its first step to its last. On a small site, test every page instead.
Each page in the sample is then checked against every success criterion at the target level, with three kinds of evidence:
- Automated scans with tools such as axe, Lighthouse or WAVE. They are fast and repeatable, but the W3C's guidance on evaluation tools is explicit that tools cannot check everything, can produce false or misleading results and cannot determine accessibility on their own. Our automation testing guide shows which new WCAG 2.2 criteria have no automated rule at all.
- Manual review of each criterion: keyboard-only navigation, visible and unobscured focus, text alternatives read in context, contrast measured on real colours, zoom and reflow, error handling in forms, and reading order.
- Assistive technology testing with the screen readers and browsers in the baseline, plus voice control and magnification where the audience needs them. WCAG-EM strongly recommends involving people with disabilities as well, because they find barriers expert review misses.
The W3C's open-source WCAG-EM Report Tool walks through the same steps and exports a report. Record each failure with the criterion, the page, the component and a reproducible description; that record becomes the fix list.
Important
An audit of a sample does not prove that a whole site conforms. WCAG-EM says a conformance claim cannot be made for an entire website from a sample alone, because unexamined pages can still fail. Report it as an evaluation of the sample, dated, and make the fix and maintenance process do the rest.
Step 3: fix at the source, then retest
Sort the audit's findings before anyone opens an editor:
- Blockers in complete processes first: a keyboard trap in checkout, an unlabelled sign-in field or a CAPTCHA with no alternative stops a person from finishing at all.
- Then by reach: a failure in the header, navigation, a form component or a page template repeats on every page that uses it.
- Then content: text alternatives, captions and transcripts, heading structure, link text and documents.
Fix code where it is defined, not where it shows up. If the site has a design system or component library, a missing label or a focus style fixed in the component is fixed on every page at once; a fix typed into one page template is lost on the next redesign.
Content fixes need people and workflow rather than code: authors who write alternative text and meaningful link text, a captioning step for every video, and accessible source files for PDFs, or HTML pages instead of PDFs where possible. A CMS can help by making the alternative text field required and offering only heading levels the template supports.
Then retest. WCAG-EM's advice for a re-run is to keep part of the earlier sample for comparison and replace about half of it with fresh pages to widen coverage. Every fixed defect should also get an automated regression test where one is possible, so the same failure cannot return unnoticed.
Step 4: publish an accessibility statement and an ACR
An accessibility statement is for your users. The W3C's statement guidance and generator says it should contain at least a commitment to accessibility, the standard applied (such as WCAG 2.2) and contact details for reporting problems. It advises adding known limitations, the measures you take, technical prerequisites and the environments you tested, all in plain language: "videos do not have captions" rather than "Success Criterion 1.2.2 was not met". Link it from the footer of every page. Public sector bodies in the EU and UK are required to publish one.
An Accessibility Conformance Report (ACR) is for buyers, who use it to assess a product's accessibility before they buy, and the usual format is the Voluntary Product Accessibility Template (VPAT) from ITI. As of September 2026 the current version is VPAT 2.5Rev (April 2025), in four editions:
| Edition | Standard it reports against |
|---|---|
| VPAT 508 | The Revised Section 508 Standards (US federal) |
| VPAT EU | EN 301 549 (European Union) |
| VPAT WCAG | WCAG 2.0, 2.1 and 2.2 |
| VPAT INT | All three of the above in one report |
Each criterion is marked Supports, Partially Supports, Does Not Support or Not Applicable, with remarks. Once filled in with real test results, the template becomes the ACR. Section508.gov recommends that vendors produce an ACR for any ICT marketed to the US federal government. Base it on your audit, name the product version and date it, and describe partial support precisely, naming the features affected.
Step 5: keep conformance with every release
An audit is a snapshot, and the next release can undo it. Conformance lasts only when it is part of how the site is built:
- An accessible design system: components with documented keyboard behaviour, visible focus styles, programmatic labels and states, and colour tokens already checked for contrast, so new pages start from parts that pass.
- Automated checks on every change: an accessibility scan on each pull request that fails the build on new violations, alongside the unit and end-to-end tests.
- Manual testing each release: a keyboard and screen reader pass on every journey the release changes, because many criteria need a person to judge them.
- Content rules: guidance for authors, required alternative text fields, and captions as a publishing step rather than an afterthought.
- A feedback route: the contact in your accessibility statement goes to a team that triages reports like bugs.
- A re-audit on a schedule and after any redesign, re-platforming or new major feature.
This is how our web design and development service works: semantic HTML, keyboard paths, contrast and focus are checked against WCAG 2.2 AA in every pull request, with automated and manual checks in every release. For an existing site, its website audit reports accessibility findings against WCAG 2.2 AA before anything is redesigned.
Which laws point to WCAG, and at which level
This section summarizes published rules as of September 2026 and is general information, not legal advice.
| Jurisdiction | Rule | Who it covers | Technical standard | Key dates |
|---|---|---|---|---|
| European Union | European Accessibility Act (2019/882) | Listed products and consumer services, including e-commerce and banking | EN 301 549 (v3.2.1 uses WCAG 2.1 AA) | Applies from June 28, 2025 |
| United States | ADA Title II web rule | State and local governments | WCAG 2.1 AA | April 26, 2027 (50,000+ people); April 26, 2028 (smaller, special districts) |
| United States | Section 508 (Revised 508 Standards) | Federal agencies' ICT, including what they buy | WCAG 2.0 A and AA | Final rule January 18, 2017 |
| Canada | Accessible Canada Act | Federally regulated entities | CAN/ASC-EN 301 549:2024 (voluntary standard) | Barrier-free Canada by January 1, 2040 |
| Ontario | AODA, Ontario Regulation 191/11 | Designated public sector organizations; organizations with 50+ employees | WCAG 2.0 AA, except 1.2.4 and 1.2.5 | All public websites since January 1, 2021 |
| United Kingdom | Public sector accessibility regulations | Public sector websites and mobile apps | WCAG 2.2 AA, plus an accessibility statement | In force since September 23, 2018 |
European Union
The European Accessibility Act, Directive (EU) 2019/882, applies to covered products placed on the market and services provided to consumers after June 28, 2025. Its services include e-commerce, consumer banking, e-books and passenger transport. Microenterprises providing services (fewer than 10 employees and no more than EUR 2 million in turnover or balance sheet) are exempt. The Act does not mention WCAG: products and services that meet a harmonized standard cited in the Official Journal are presumed to conform, and the reference standard for that is EN 301 549. AccessibleEU reported that EN 301 549 v4.1.1, published in September 2026, adopts WCAG 2.2 and adds its six new A and AA criteria, but until the Commission cites it in the Official Journal, the legal reference remains v3.2.1 (2021), based on WCAG 2.1 AA. Public sector websites fall under the separate Web Accessibility Directive (2016/2102).
United States
The Department of Justice published its ADA Title II rule on April 24, 2024. It requires web content and mobile apps of state and local governments to meet WCAG 2.1 Level AA. The original deadlines were extended by an interim final rule published on April 20, 2026: entities with a total population of 50,000 or more now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028.
Federal agencies follow Section 508. The Revised 508 Standards, issued by the U.S. Access Board on January 18, 2017, require electronic content and software to conform to WCAG 2.0 Level A and AA, which they incorporate by reference.
For businesses open to the public (ADA Title III), the Justice Department's 2022 guidance on web accessibility says they have flexibility in how they comply but must make what they offer online accessible, and it points to WCAG and the Section 508 Standards as helpful technical guidance.
Canada and Ontario
The Accessible Canada Act, assented to on June 21, 2019, applies to areas under federal jurisdiction and aims for a Canada without barriers by January 1, 2040, with information and communication technologies among the areas it names. Accessibility Standards Canada published CAN/ASC-EN 301 549:2024 in May 2024, an identical adoption of EN 301 549:2021; like its other standards, it is voluntary unless a regulation makes it mandatory.
In Ontario, the AODA's web requirements apply to designated public sector organizations and to businesses and non-profits with 50 or more employees. Since January 1, 2021, their public websites and web content published after January 1, 2012 must meet WCAG 2.0 Level AA, except live captions (1.2.4) and pre-recorded audio description (1.2.5).
United Kingdom
The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 came into force on September 23, 2018. GOV.UK's guidance says a public sector website or app meets them by meeting WCAG 2.2 AA and publishing an accessibility statement, and the Government Digital Service monitors a sample of sites every year. All UK service providers also have a duty to make reasonable adjustments under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland.
Elsewhere, the W3C keeps a list of web accessibility laws and policies by country. Because WCAG versions are backwards compatible, a site built and tested to WCAG 2.2 AA also covers rules written for 2.1 AA or 2.0 AA; keep 4.1.1 Parsing in your test plan where a rule names the older versions.
Why an accessibility overlay will not make your site compliant
An accessibility overlay is a script from a third party, added with one line of JavaScript, that changes the page in the visitor's browser after it loads. Some add a toolbar for contrast, text size and similar settings; others try to repair the page's code automatically. The Overlay Fact Sheet, signed by accessibility practitioners including contributors to the WCAG, ARIA and HTML specifications, explains why neither makes a site conform:
- The toolbar settings duplicate what people with disabilities already have in their operating system, browser or assistive technology, which works on every site rather than one.
- Automated repair is unreliable for exactly the failures that block people: text alternatives for images, form labels and error handling, focus control and keyboard access.
- Component-based front ends (React, Angular, Vue) change the page after the overlay has run, so its repairs miss what renders later.
- Conformance means every success criterion is met on every page in scope. A tool that can repair only some issues cannot meet that bar, and the Fact Sheet concludes that no overlay can make a site fully compliant or remove legal risk.
Regulators have acted on the marketing. On January 3, 2025 the US Federal Trade Commission announced a complaint and proposed order against accessiBe, and on April 22, 2025 it approved the final order. The company had claimed its accessWidget plug-in could make any website WCAG compliant; the FTC's complaint alleged that it did not, and that the company formatted third-party articles and reviews to look independent. The order requires accessiBe to pay $1 million and bars it from claiming that its automated products can make any website WCAG compliant, or keep it compliant over time, unless it has evidence to support the claim.
Warning
A script that promises compliance on its own is the claim the FTC acted against. Spend the budget on fixing the source and on the testing that proves it, and remove an overlay if it interferes with users' own assistive technology.
