A customer’s procurement questionnaire asks whether your website meets WCAG. A contract renewal adds a clause that names it. A letter arrives that cites it. Each time, the same short phrase hides three separate questions: which document, which version and level, and what passing actually means. The web accessibility guidelines these requests refer to are one W3C standard, the Web Content Accessibility Guidelines, and all three questions have answers in its own text and in the rules that adopt it.
This article settles those three questions from the documents themselves, and shows what the most common failures look like on live small-business websites.
WCAG is one standard, and only its success criteria are testable
The current version is WCAG 2.2, a W3C Recommendation first published on October 5, 2023 and republished with corrections on December 12, 2024. Its status section says what kind of document it is:
W3C recommends the wide deployment of this specification as a standard for the Web.
The standard is built in layers, and only one layer is testable. At the top sit four principles, named in the Recommendation as Perceivable, Operable, Understandable and Robust. Under them sit thirteen guidelines, and the Recommendation is explicit that the guidelines themselves are not the test:
The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.
The testable layer is the success criteria, and each one carries a level: A (lowest), AA, or AAA (highest). W3C does not print totals, so we counted them in the December 12, 2024 text. WCAG 2.2 has 86 success criteria with a level: 31 at Level A, 24 at AA and 31 at AAA. An 87th heading, 4.1.1 Parsing, is marked obsolete and removed. In WCAG 2.2, Level AA means the 55 criteria at A and AA together. A rule that names an older version asks for fewer: 50 in WCAG 2.1, and 38 in WCAG 2.0.
View the data as a table
| Principle | Guidelines | Level A | Level AA | Level AAA | Total |
|---|---|---|---|---|---|
| Perceivable | 4 | 9 | 11 | 9 | 29 |
| Operable | 5 | 14 | 6 | 14 | 34 |
| Understandable | 3 | 7 | 6 | 8 | 21 |
| Robust | 1 | 1 | 1 | 0 | 2 |
| All | 13 | 31 | 24 | 31 | 86 |
Level AAA is not the next step after AA for a whole site. The Recommendation itself advises against it: “It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.” Aim for AA across the site, and treat AAA criteria as improvements where your content allows them.
The supporting material around the criteria, the Understanding documents and the techniques, is informative and adds no requirements. The techniques come in two kinds, in the Recommendation’s words: “those that are sufficient for meeting the success criteria and those that are advisory”. W3C also documents failures, each a named pattern that breaks a criterion. These are the pages most useful to a site owner, because they describe code rather than principles. F65 is an image with no alt attribute and no other text alternative. F78 is a stylesheet that removes the visible focus outline. A developer can search a codebase for either one. Our guide to accessible UI components under WCAG 2.2 names the W3C-documented failures for components such as dialogs, tabs, form fields and data tables.
When someone tells you to “meet WCAG”, ask them to put three things in writing: the version, the level, and the pages in scope. Every later conversation about the site starts from those three.
Conformance has five requirements, and one failed criterion fails the page
WCAG does not grade a site on a curve. For Section 508, which uses WCAG 2.0, the General Services Administration states the consequence on Section508.gov: “A page that fails to meet even one of the 38 applicable WCAG success criteria does not conform to the standards.” WCAG 2.2 sets the same all-or-nothing bar. Its Section 5.2 opens: “In order for a web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied:” There are five of them.
- Conformance level. The level is met in full. For Level AA, “the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.”
- Full pages. Conformance “is for full web page(s) only, and cannot be achieved if part of a web page is excluded.” Every responsive variation of the page counts as part of it.
- Complete processes. When a page is one step in a sequence, every step has to conform. The Recommendation’s own example is a store: all pages “from start to finish (checkout) conform in order for any page that is part of the process to conform.”
- Only accessibility-supported ways of using technologies. In the Recommendation’s words: “Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.”
- Non-interference. Content that does not conform must not block the rest of the page, and four criteria apply to everything on it regardless: 1.4.2 Audio Control, 2.1.2 No Keyboard Trap, 2.3.1 Three Flashes or Below Threshold, and 2.2.2 Pause, Stop, Hide.
The word in the questionnaire, compliance, is not WCAG’s word. In the full text of WCAG 2.2, words beginning with “conform” appear more than 150 times; “compliance” appears once, inside the title of a cited ISO standard. Compliance belongs to the regulations, which tell an entity to “comply with Level A and Level AA success criteria and conformance requirements specified in WCAG 2.1.”
A conformance claim is optional: the Recommendation states that “Conformance claims are not required.” Where content outside your control keeps a page from conforming, the Recommendation suggests a Statement of Partial Conformance. What a claim or a certificate can and cannot prove is covered in what each accessibility proof means.
When you scope work or write a statement, describe it in pages and processes rather than as “the website”. A checkout that conforms on four steps and fails on the fifth does not conform on any of them. Our post on the hidden costs of partial WCAG compliance sets out what partial conformance costs in litigation and maintenance.
The federal rules that adopt WCAG name a version, and none names WCAG 2.2
The rules point at specific versions, and two of them moved their dates in 2026. The Department of Justice extended the ADA Title II web rule by interim final rule, or IFR, on April 20, 2026. The Department of Health and Human Services did the same for its Section 504 rule on May 11, 2026. Both rules cover mobile apps as well as websites.
| Rule and who it binds | What it requires | When |
|---|---|---|
| ADA Title II, 28 CFR 35.200: state and local governments | WCAG 2.1, Level A and AA, the June 5, 2018 edition, for web content and mobile apps | April 26, 2027 for a population of 50,000 or more; April 26, 2028 for smaller entities and special district governments |
| HHS Section 504, 45 CFR 84.84: recipients of HHS financial assistance | WCAG 2.1, Level A and AA, for web content and mobile apps | May 11, 2027 with fifteen or more employees; May 10, 2028 with fewer |
| Section 508, 36 CFR part 1194, E205.4: federal agencies, for the ICT they develop, buy, maintain or use | WCAG 2.0, Level A and AA | Required since January 18, 2018 |
| ADA Title III: businesses open to the public | No technical standard in any regulation | None |
The new dates do not pause the obligation, and they may not be the last change. DOJ’s extension says at 91 FR 20908 that a notice of proposed rulemaking, or NPRM, on the rule’s substance may come first:
While this IFR is limited to extending the 2024 final rule’s compliance dates, the Department plans to engage in future rulemaking processes related to the substantive requirements of the 2024 final rule. During the extension period, the Department will consider issuing an NPRM providing members of the public with an opportunity to comment on the substance of the 2024 final rule and any changes proposed by the Department. If the Department does not issue such an NPRM and if circumstances suggesting further delays of this deadline do not exist, the Department fully anticipates implementing the regulation at the new deadline. Regardless of the compliance dates, covered entities have an ongoing obligation to ensure that their services, programs, and activities offered using web content and mobile apps are accessible to individuals with disabilities in accordance with their existing obligations under title II of the ADA.
HHS says the same at 91 FR 25501, adding that its proposal may include “any changes that would affect the web content and mobile app accessibility requirements.” A contract signed today against WCAG 2.1 AA should allow for both the dates and the details to move. The timing for state and local governments and HHS recipients is set out in what the 2026 extension changed.
The Title II and Section 504 requirements both apply unless the entity “can demonstrate that compliance with this section would result in a fundamental alteration” of its services or “in undue financial and administrative burdens”. 28 CFR 35.201 also exempts five kinds of content from the Title II rule: archived web content, preexisting conventional electronic documents, content posted by a third party, individualized password-protected documents, and preexisting social media posts.
Two of the exemptions are narrower than they sound. The document exemption does not reach documents “currently used to apply for, gain access to, or participate in the public entity’s services, programs, or activities”, so an old application form in PDF is inside the rule. The third-party exemption ends where the third party is posting “due to contractual, licensing, or other arrangements with the public entity”, so content a vendor posts under contract is covered.
Title III has no web regulation. DOJ withdrew its last rulemaking on the subject on December 26, 2017, and its March 2022 guidance leaves the method to the business: “Businesses and state and local governments have flexibility in how they comply with the ADA’s general requirements of nondiscrimination and effective communication. But they must comply with the ADA’s requirements.” The same page calls WCAG and the Section 508 Standards “helpful guidance”, and its disclaimer says it has “no legally binding effect”.
A business can still be bound by a sector rule that names a version: the Department of Transportation’s rule for airline websites, 14 CFR 382.43, names WCAG 2.0 Level AA. No requirement in the Code of Federal Regulations names WCAG 2.2. It appears only in DOJ’s guidance appendix to the Title II rule, which says an entity could meet the rule by conforming to WCAG 2.2 Level AA as an equivalent alternative, with the burden of showing it on the entity. W3C states that “Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1.”
Washington and New York have gone further. Washington’s IT standard has required WCAG 2.2 Level AA for state agencies’ technology since July 1, 2026, and New York’s IT policy requires WCAG 2.2 Level AA of state websites, including those built under contract, by January 1, 2027, as set out in what WCAG 2.2 AA adds and which rules require it.
View the data as a list
- WCAG 2.0, 38 criteria at Level A and AA. Named by Section 508.
- WCAG 2.1, 50 criteria at Level A and AA. Named by ADA Title II and HHS Section 504.
- WCAG 2.2, 55 criteria at Level A and AA. Not named by any federal rule; Washington’s state standard and New York’s IT policy require it, and W3C recommends the latest version.
- 4.1.1 Parsing. In 2.0 and 2.1, removed in 2.2; a contract that names 2.0 or 2.1 may still expect it to be tested and reported.
One detail matters if your contract names an older version. WCAG 2.2 removed 4.1.1 Parsing, which asks for complete start and end tags, correct nesting, no duplicate attributes and unique IDs. The Recommendation notes that authors required by policy to conform with 2.0 or 2.1 “may need to continue to test and report 4.1.1.” The current edition of WCAG 2.1 adds that 4.1.1 “should be considered as always satisfied for any content using HTML or XML”, but the regulations incorporate the 2018 and 2008 texts, which do not carry that note, although the Access Board’s Section 508 testing baseline applies the WCAG 2.0 errata and treats 4.1.1 as passed.
Europe reaches the same standard by another route. The European Accessibility Act has applied since June 28, 2025 to consumer services that include e-commerce, with an exemption for service providers that are microenterprises: fewer than 10 employees and no more than EUR 2 million in annual turnover or balance sheet. The Act presumes conformity only for harmonized standards cited in the Official Journal, and none had been cited under it as of October 9, 2026. EN 301 549 version 3.2.1, which maps to WCAG 2.1 Level AA, is the version cited for public-sector websites under the Web Accessibility Directive. Version 4.1.1, published in September 2026, is updated for WCAG 2.2.
Build and test to WCAG 2.2 Level AA, and keep 4.1.1 in the test plan for any contract that names 2.0 or 2.1. One target then covers every rule in the table. Each rule’s clause wording, and the VPAT edition that matches it, are in our guide to which WCAG version each US rule requires.
The failures found most can be measured in a browser
WebAIM’s annual scan of the top one million home pages measures the problem directly. The 2026 report, run in February 2026, found that “95.9% of home pages had detected WCAG 2 failures”, with an average of 56.1 detected errors per page. Six kinds of failure made up 96% of everything detected, and they have been the same six for seven years. WebAIM does not map them to success criteria; the mapping below comes from the criteria and W3C’s techniques.
| Failure WebAIM detects | Home pages with it | WCAG criterion |
|---|---|---|
| Low contrast text | 83.9% | 1.4.3 Contrast (Minimum), AA |
| Missing alternative text for images | 53.1% | 1.1.1 Non-text Content, A |
| Missing form input labels | 51% | 4.1.2 Name, Role, Value, A; also 1.3.1 and 3.3.2 |
| Empty links | 46.3% | 2.4.4 Link Purpose (In Context), A; 4.1.2 |
| Empty buttons | 30.6% | 4.1.2 Name, Role, Value, A |
| Missing document language | 13.5% | 3.1.1 Language of Page, A |
These are the failures a machine can find. WebAIM states the limit in its methodology: “Absence of detected errors does not indicate that a page is accessible or conformant.” What a scanner can and cannot see is the subject of what an ADA compliance checker actually tells you.
Low contrast leads the list, and it is the easiest of the six to see for yourself. Success criterion 1.4.3 requires “a contrast ratio of at least 4.5:1” for text, and 3:1 for large-scale text, which W3C puts at 18 point, or 14 point bold, approximately 24px and 18.5px. The navigation below, on a live small-business site, sets its links in orange on light gray, and they measure 2.17:1.
The ratio is a hard threshold. W3C’s Understanding document for 1.4.3 says the computed values “should not be rounded (e.g., 4.499:1 would not meet the 4.5:1 threshold).” WCAG uses three thresholds: 3:1 for large text and for interface components and graphics, 4.5:1 for body text at Level AA, and 7:1 for body text at Level AAA.
View the data as a table
| Ratio | What it is enough for | Criterion |
|---|---|---|
| Below 3:1 | Nothing that the criteria cover | 1.4.3, 1.4.11 |
| 3:1 | Large-scale text; interface components and graphics | 1.4.3 (AA), 1.4.11 (AA) |
| 4.5:1 | Body text at Level AA; large-scale text at AAA | 1.4.3 (AA), 1.4.6 (AAA) |
| 7:1 | Body text at Level AAA | 1.4.6 (AAA) |
The same criterion covers text that does not look like content. The Understanding document says it “applies to text in the page, including placeholder text”, the gray hint inside an empty form field. The form below shows no visible labels. Each field has a label hidden from view for screen readers, so the placeholder is the only text a sighted visitor sees, and it measures 2.67:1, below even the line for large text.
W3C’s forms tutorial says that “placeholder text is not a replacement for labels”, that it “disappears from form fields when users start entering text”, and that hiding labels while showing placeholders “makes it very hard for users to review the form.” For how to label a field properly, see the guide to accessible forms. Sign-in forms also answer to success criterion 3.3.8, new in WCAG 2.2; our guide to accessible authentication explains it.
Measure placeholder text from the rendered pixels. The tutorial notes that browsers “use a combination of color and opacity” to draw it, and a checker that reads only the CSS color misses the opacity. It gives a style that passes on white, ::placeholder { color: #767676; opacity: 1; }, which measures 4.54:1.
One criterion new in WCAG 2.2 shows that a small target is not always a failure. 2.5.8 Target Size (Minimum), Level AA, asks for pointer targets of “at least 24 by 24 CSS pixels”, with five exceptions. The first is spacing: a smaller target passes when a 24-pixel circle centered on it touches no other target and no other undersized target’s circle. The Facebook icon below is 27.5 by 18 CSS pixels, but its 24-pixel circle touches no other target or circle, so it passes. Like every criterion new in 2.2, 2.5.8 sits outside the US rules in the table above and inside the 2.2 target this article recommends. All five exceptions, and the thresholds for four more criteria, are worked through in WCAG 2.2 thresholds and exceptions.
Open your own home page and measure three things before anything else: a paragraph of body text, an empty form field, and the smallest button or icon together with the space around it. Those cover the failure WebAIM detects most and two cases a body-text check misses.
Keyboard focus has to stay visible, and stay in sight
The focus indicator is the outline a browser draws around the link or control that keyboard input will reach. 2.4.7 Focus Visible, Level AA since WCAG 2.0, requires it: “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.” W3C’s Understanding document gives the reason: “The purpose of this success criterion is to help a person know which element has the keyboard focus.” Its summary adds: “Without a focus indicator, sighted keyboard users cannot operate the page.”
One line of styling is enough to break it. W3C’s failure technique F78 describes it as “styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator”. A design that removes the browser’s outline has to draw its own, and the replacement is held to contrast too. The Understanding document notes that focus indicators “are also subject to Success Criterion 1.4.11 Non-text Contrast (Level AA)”, which asks for 3:1 against adjacent colors. 1.4.11 is a WCAG 2.1 criterion, so it is inside Title II and Section 504 and outside Section 508.
WCAG 2.2 adds a second condition for the same moment. 2.4.11 Focus Not Obscured (Minimum), Level AA, requires that a focused component “is not entirely hidden due to author-created content.” Like 2.5.8, it is new in 2.2 and outside every rule in the table. Its Understanding document lists the content that can overlap focused items as “sticky footers, sticky headers, and non-modal dialogs”, and gives a direct example: “A notification implemented as sticky content, such as a cookie banner, will fail this success criterion if it entirely obscures a component receiving focus.”
A live page with no visible focus is shown in what an ADA compliance checker actually tells you, with the reason no automated scan flags it. Test both criteria with the cookie banner still open and the page scrolled halfway down. Tab through the whole page, and stop at every point where you lose the outline or the focused item slides under a sticky bar. Then ask your developer to search the stylesheets for outline rules that remove focus styling without drawing a replacement.
A first pass finds the failures a scan cannot
W3C publishes Easy Checks, a page that “helps you start to assess the accessibility of a web page.” The same page adds: “A web page could seem to pass these checks, yet still have significant accessibility barriers.” Used that way, a short list built on it shows where to start before anyone is paid to test.
| Check | How to run it | Criterion |
|---|---|---|
| Keyboard | Put the mouse aside and press Tab through every link and control. You must always see where you are, reach everything, and be able to leave every widget. | 2.1.1, 2.1.2, 2.4.7 |
| Zoom | Set the window 1280 pixels wide and zoom to 400%. Text should reflow into one column without sideways scrolling. | 1.4.10 |
| Contrast | Measure body text, links, buttons and placeholder text with a contrast checker that reads rendered pixels. | 1.4.3, 1.4.11 |
| Images | Read each informative image’s alt text. It should say what the image tells a sighted visitor. | 1.1.1 |
| Forms | Type into each field. A visible label should remain once the placeholder is gone, and errors should be described in text. | 3.3.1, 3.3.2 |
| Scan | Run an automated checker on the same pages, and treat what it finds as a starting list. | Several |
The zoom check comes from W3C’s own note to the reflow criterion, which explains that “320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom.” The keyboard check is one no scanner can run, because it depends on what a person sees and reaches, and judging alt text or reflow needs a person too. DOJ’s guidance makes the same point about automated tools: “A “clean” report does not necessarily mean everything is accessible.”
For images, the hard part is writing alt text that carries meaning, which is covered in how to write alt text. Record each failure with its page address and criterion number, and keep a screenshot of it. That record is what a fix is planned from.
Where this guide stops
WCAG 3.0 is not a standard. The current document is a Working Draft dated September 10, 2026, and it says: “It is inappropriate to cite this document as other than a work in progress.” W3C’s introduction to WCAG 3 advises: “The best way to prepare for WCAG 3 in the future, is to meet WCAG 2.2 success criteria now.” Our note on WCAG 3.0 draft status for buyers covers which version to name in a contract instead.
The 2026 date extensions are under challenge. National Federation of the Blind v. Department of Justice was filed on May 21, 2026, and the court record on CourtListener, current to July 2026, shows a briefing schedule and no ruling. Until a court or a new rule says otherwise, the dates in the Code of Federal Regulations are the operative ones.
A first pass is not a conformance claim, and nothing in this article is legal advice. Whether a business open to the public is exposed under Title III, and what a demand letter requires, are questions for counsel.
Your next step
- Write down what you are held to. Find the version, the level and the scope in your contract or your regulator’s rule.
- Run the first pass on the pages that carry a process. Start with the home page, the contact form and any checkout or application, because a process conforms only if every step does.
- Decide what has to be defensible. A first pass shows where to start; a claim to a buyer or a regulator needs every criterion at your level tested on your own pages. That is what ADACP’s WCAG audits and testing is for; its web accessibility services then recommend a compliance path for your version and level.