# How to make a website WCAG compliant: the WCAG 2.2 AA process > Make a website WCAG compliant: target WCAG 2.2 AA, audit a sample with W3C's WCAG-EM, fix and retest, publish a statement and keep every release passing. - URL: https://computese.com/how-to-make-website-wcag-compliant/ - Author: Duong Quan Nguyen, CEO, Computese - Published: 2019-08-28 - Updated: 2026-09-25 - Topics: Web development ## In short - A website is WCAG compliant when every page and process in scope meets all Level A and AA success criteria of the version you target. In 2026 that target is WCAG 2.2 AA: 55 success criteria, published by the W3C. - Get there with a process, not a plugin: define the scope, audit a representative sample with W3C's WCAG-EM (automated scans, manual review, screen readers), fix in shared components, retest, then publish an accessibility statement and, for B2B buyers, an ACR. - Laws mostly point at Level AA: WCAG 2.1 AA for US state and local governments (due April 2027 or April 2028), WCAG 2.0 AA for Section 508 and Ontario's AODA, EN 301 549 for the European Accessibility Act, WCAG 2.2 AA for UK public sector sites. - An overlay widget cannot make a site conform. In April 2025 the FTC finalized a $1 million order against accessiBe over claims that its tool could make any website WCAG compliant. - Conformance decays with each release unless accessible components, automated checks on every change and manual testing are part of the definition of done. 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](https://computese.com/how-to-improve-website-accessibility/), and the design rules behind them in our [web design guide](https://computese.com/top-design-tips-for-2024-for-starter/); 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](https://www.w3.org/WAI/standards-guidelines/wcag/) 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](https://www.iso.org/standard/58625.html) 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](https://www.w3.org/WAI/WCAG22/Understanding/intro) 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](https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/), 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](https://www.w3.org/TR/WCAG22/), 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: 1. **Conformance level:** every criterion at the chosen level is met in full, or a conforming alternate version is provided. 2. **Full pages:** conformance applies to whole pages, including each responsive variation; you cannot exclude a part of a page. 3. **Complete processes:** if one page in a process fails (a checkout, a sign-up), no page in that process conforms. 4. **Only accessibility-supported ways of using technologies:** the features you rely on must work with users' browsers and assistive technology. 5. **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](https://www.w3.org/WAI/WCAG22/quickref/) 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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/) 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. 1. **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. 2. **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. 3. **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). 4. **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](https://www.w3.org/TR/wcag-em-2/) 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. ![A site map of many page thumbnails. A few pages of each layout, one page picked at random and an orange chain of linked form pages are pulled out for a magnifying glass to inspect.](https://computese.com/images/blog/how-to-make-website-wcag-compliant/sample.f6652f6051-1536.webp) *The sample decides what an audit can find: every page type, a random draw, and each process from its first step to its last.* Each page in the sample is then checked against every success criterion at the target level, with three kinds of evidence: 1. **Automated scans** with tools such as axe, Lighthouse or WAVE. They are fast and repeatable, but the W3C's [guidance on evaluation tools](https://www.w3.org/WAI/test-evaluate/tools/selecting/) is explicit that tools cannot check everything, can produce false or misleading results and cannot determine accessibility on their own. Our [automation testing guide](https://computese.com/navigating-the-future-unveiling-10-cutting-edge-automation-testing-trends-of-2024/) shows which new WCAG 2.2 criteria have no automated rule at all. 2. **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. 3. **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](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/) 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: 1. **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. 2. **Then by reach:** a failure in the header, navigation, a form component or a page template repeats on every page that uses it. 3. **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. ![A component library cabinet holds interface parts. One button part is orange and has a wrench beside it; thin lines carry it into the same place on five different page layouts, each with a check mark.](https://computese.com/images/blog/how-to-make-website-wcag-compliant/component.0cccf63c56-1536.webp) *Fix the component, not the page: one change in the design system repairs every template that uses it.* 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](https://www.w3.org/WAI/planning/statements/) 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](https://www.itic.org/policy/accessibility/vpat). 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](https://www.section508.gov/sell/acr/) 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](https://computese.com/services/web-design-development/) 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](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng), 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](https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en) 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](https://www.ada.gov/resources/2024-03-08-web-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](https://www.access-board.gov/ict/), 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](https://www.ada.gov/resources/web-guidance/) 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](https://laws-lois.justice.gc.ca/eng/acts/A-0.6/page-1.html), 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](https://accessible.canada.ca/creating-accessibility-standards/canasc-en-301-5492024-accessibility-requirements-ict-products-and-services) 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](https://www.ontario.ca/page/how-make-websites-accessible) 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](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) 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](https://www.w3.org/WAI/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](https://overlayfactsheet.com/en/), 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. ![A server sends a page to a laptop, where a thin orange sheet floats over the page from a corner widget. Through the sheet, an empty form field and an image frame still carry grey crosses.](https://computese.com/images/blog/how-to-make-website-wcag-compliant/overlay.cd6027fa22-1536.webp) *An overlay repaints the page in the browser; the defects are still in the source that every visitor receives.* 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](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million). 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. ## Key terms - **WCAG**: The Web Content Accessibility Guidelines, the W3C standard for accessible web content. Versions 2.0, 2.1 and 2.2 are all W3C Recommendations; WCAG 3 is a working draft. - **Success criterion**: One testable requirement in WCAG, such as 1.4.3 Contrast (Minimum). Conformance is decided by whether each success criterion at the chosen level is met. - **Conformance level**: WCAG's three grades: A (the minimum), AA (all A and AA criteria) and AAA (all criteria). Level AA is the level laws and contracts usually require. - **WCAG-EM**: W3C's WCAG Evaluation Methodology: define the scope, explore the site, select a representative sample, evaluate it and report. Version 2.0 was published in July 2026. - **Assistive technology**: Software or hardware people with disabilities use to operate a computer, such as screen readers (NVDA, JAWS, VoiceOver, TalkBack), screen magnifiers and voice control. - **Accessibility statement**: A public page that says which standard a site aims to meet, where it falls short and how to report a problem. Public sector bodies in the EU and UK must publish one. - **VPAT and ACR**: The Voluntary Product Accessibility Template is ITI's free reporting template; filled in with test results for a product, it becomes an Accessibility Conformance Report (ACR) that buyers review. - **EN 301 549**: The European standard for ICT accessibility requirements. Version 3.2.1 uses WCAG 2.1 AA for web content; version 4.1.1, published in September 2026, uses WCAG 2.2. - **Accessibility overlay**: Third-party JavaScript added to a site that changes the page in the visitor's browser, through a toolbar widget, automated repairs or both. ## Common questions ### Is WCAG compliance a legal requirement? It depends on who you are and where you serve customers. Public bodies in the US, UK, EU and Ontario have explicit web rules, and the European Accessibility Act covers private services such as e-commerce and consumer banking sold to EU consumers. Many other countries' policies reference WCAG too. This is general information, not legal advice. ### Should I target WCAG 2.1 or WCAG 2.2? Target WCAG 2.2 AA. It contains every WCAG 2.1 criterion except the obsolete 4.1.1 Parsing, so content that meets it also meets 2.1 and 2.0. If a contract or law names 2.0 or 2.1, keep testing and reporting 4.1.1 as well. ### Do I need to meet WCAG Level AAA? None of the laws in this guide require it, and the W3C advises against requiring AAA for whole sites because some content cannot meet every AAA criterion. Adopt individual AAA criteria where they fit your content, and claim AA. ### Can an automated checker or an overlay make my site compliant? No. Automated checkers find part of the failures, and the W3C says tools can assist but cannot determine accessibility. Overlays change the page in the browser without meeting every criterion; the FTC's 2025 order bars accessiBe from claiming its tool makes any website WCAG compliant unless it has evidence. ### How long does it take to make a website WCAG compliant? It depends on how many templates, processes and documents are in scope, and whether fixes can go into shared components. The audit comes first; fixes in a design system then repair many pages at once, while PDFs and videos are fixed one file at a time. ### Should I wait for WCAG 3? No. WCAG 3 is a working draft, last published in September 2026, that the W3C expects to take a few more years, and WCAG 2 will not be deprecated for several years after that. The W3C's own advice is that meeting WCAG 2.2 now is the best preparation. ## Sources 1. [WCAG 2 Overview](https://www.w3.org/WAI/standards-guidelines/wcag/), W3C Web Accessibility Initiative 2. [ISO/IEC 40500:2012 Information technology: W3C Web Content Accessibility Guidelines (WCAG) 2.0](https://www.iso.org/standard/58625.html), ISO 3. [Understanding the Four Principles of Accessibility](https://www.w3.org/WAI/WCAG22/Understanding/intro), W3C Web Accessibility Initiative 4. [WCAG 3 Introduction](https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/), W3C Web Accessibility Initiative 5. [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), W3C 6. [How to Meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG22/quickref/), W3C Web Accessibility Initiative 7. [What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/), W3C Web Accessibility Initiative 8. [WCAG Evaluation Methodology (WCAG-EM) 2.0](https://www.w3.org/TR/wcag-em-2/), W3C 9. [WCAG-EM Overview](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/), W3C Web Accessibility Initiative 10. [Selecting Web Accessibility Evaluation Tools](https://www.w3.org/WAI/test-evaluate/tools/selecting/), W3C Web Accessibility Initiative 11. [Generate an Accessibility Statement](https://www.w3.org/WAI/planning/statements/), W3C Web Accessibility Initiative 12. [VPAT](https://www.itic.org/policy/accessibility/vpat), Information Technology Industry Council (ITI) 13. [Accessibility Conformance Report (ACR)](https://www.section508.gov/sell/acr/), Section508.gov (GSA) 14. [Directive (EU) 2019/882 on the accessibility requirements for products and services](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng), EUR-Lex 15. [The European accessibility standard EN 301 549 has been updated](https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en), AccessibleEU, European Commission 16. [Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments](https://www.ada.gov/resources/2024-03-08-web-rule/), U.S. Department of Justice, ADA.gov 17. [Guidance on Web Accessibility and the ADA](https://www.ada.gov/resources/web-guidance/), U.S. Department of Justice, ADA.gov 18. [Information and Communication Technology: Revised 508 Standards and 255 Guidelines](https://www.access-board.gov/ict/), U.S. Access Board 19. [Accessible Canada Act (S.C. 2019, c. 10)](https://laws-lois.justice.gc.ca/eng/acts/A-0.6/page-1.html), Justice Laws Website, Government of Canada 20. [CAN/ASC - EN 301 549:2024 Accessibility requirements for ICT products and services](https://accessible.canada.ca/creating-accessibility-standards/canasc-en-301-5492024-accessibility-requirements-ict-products-and-services), Accessibility Standards Canada 21. [How to make websites accessible](https://www.ontario.ca/page/how-make-websites-accessible), Government of Ontario 22. [Understanding accessibility requirements for public sector bodies](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps), GOV.UK 23. [Web Accessibility Laws & Policies](https://www.w3.org/WAI/policies/), W3C Web Accessibility Initiative 24. [Overlay Fact Sheet](https://overlayfactsheet.com/en/), Overlay Fact Sheet signatories 25. [FTC Approves Final Order Requiring accessiBe to pay $1 Million](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million), U.S. Federal Trade Commission