What conformance actually claims
Conformance is a claim about whole pages and complete processes, not a score a tool hands you — and WCAG deliberately refuses to say which screen readers count, which is why “accessibility supported” is the phrase that decides whether your claim survives an auditor.
The review gate in your document-extraction work is the most defensible accessible thing you have shipped: per-field confidence, a source crop, the raw OCR text, and an explicit approve-or-correct before anything downstream fires. Labels are wired, focus order follows the document, nothing depends on colour alone. If someone asked whether it was accessible you would say yes, and you would be broadly right.
Now imagine the question arrives in the form it actually arrives in at a firm applying one standard across ninety-odd portfolio companies: at what level, against which version, over what scope, and which technologies are you relying on? Every one of those has a defined answer in the specification. If the response is “it’s accessible, we use semantic HTML and we run axe in CI,” the honest reading is that no claim has been made at all. That is the entire distance this course is trying to close, and this lesson is the part where the words get pinned down.
Conformance is a property of pages, not of components
WCAG 2.1 defines five conformance requirements, and they all have to be satisfied together: Conformance Level, Full pages, Complete processes, Only Accessibility-Supported Ways of Using Technologies, and Non-Interference. The first is the one everybody quotes and the second is the one that quietly invalidates most of what gets said in a design-system review.
The Full pages requirement is unambiguous: “Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded.” A component does not conform. A design system does not conform. A React library published to a private registry does not conform, no matter how good it is. Only a page conforms, and only if every part of it does.
Complete processes extends that across navigation: “When a web page is one of a series of web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all web pages in the process conform at the specified level or better.” An extraction flow that runs upload → processing → review gate → confirmation is a process in exactly this sense. A perfect review gate sitting downstream of an upload step with an unlabelled file input means the process does not conform, and the review gate’s quality does not offset it.
This is not pedantry, it is the thing that determines what you are allowed to write down. For a component you build and hand to ninety products you will never see running, the correct artifact is not a conformance claim. It is a statement of which success criteria the component satisfies in isolation, which ones it can only help the consuming page satisfy, and which ones it hands back to the integrator. That distinction is why the running artifact in this course is called a conformance note and not a conformance claim.
“Accessibility supported” is where the claim gets soft
The fourth conformance requirement is the one that catches people who have read the criteria but not the conformance chapter. You may only rely on ways of using a technology that are accessibility supported, and the term has two conditions that both have to hold: the way the technology is used has to be supported by users’ assistive technology, and the technology has to have accessibility-supported user agents available to users.
Then comes the sentence that decides how much of this is your problem: “The Accessibility Guidelines Working Group and the W3C do not specify which or how many assistive technologies must support a web technology in order for it to be classified as accessibility supported.” The Working Group explicitly defers that judgement to “the community and to entities closer to each situation”.
Read that as a delegation, because that is what it is. An ARIA pattern that announces correctly in NVDA with Chrome and silently does nothing in VoiceOver with Safari is either accessibility supported or it isn’t, and the specification will not tell you which. Somebody has to decide, write the decision down, and defend it. In a company applying one standard to a portfolio, that somebody is the person who owns the standard. This is the single largest piece of judgement the spec hands to you rather than resolving, and it is why the later screen-reader lesson exists at all: you cannot decide what is accessibility supported for a pattern you have never heard announced.
Two things the specification says that people get backwards
First, conformance claims are optional. “It is not required to make any conformance claim in order to conform.” Content either satisfies the criteria or it does not; the claim is a separate act of publishing. But once you do make one, the required components are specified: the date, the scope of pages covered, the conformance level achieved, the guidelines version referenced, and “the documented set of accessibility-supported content technologies relied upon”. That last one is where most published accessibility statements quietly fail, because nobody ever wrote down which browser and screen-reader combinations the claim assumes.
Second, and worth memorising because it is the sentence that keeps you honest in front of a stakeholder who wants a green checkmark: “Although content may satisfy all success criteria, the content may not always be usable by people with a wide variety of disabilities. Therefore, usability testing is recommended, in addition to the required functional testing.” The specification itself declines to claim that conformance equals accessibility. Anybody selling you the opposite is selling you something.
2.1 versus 2.2, and which one you are actually held to
WCAG 2.2 is a W3C Recommendation dated 12 December 2024; WCAG 2.1 remains a W3C Recommendation, republished 06 May 2025. Both are live documents. 2.2 is backwards compatible — “Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1” — so meeting the newer one satisfies the older, but not the other way round.
2.2 added nine success criteria and removed one. The additions, with their levels, are:
- Level A: 3.2.6 Consistent Help, 3.3.7 Redundant Entry
- Level AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum)
- Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 3.3.9 Accessible Authentication (Enhanced)
And the removal: “4.1.1 Parsing is obsolete and removed from WCAG 2.2.” If you are still running a rule that flags duplicate id attributes as a WCAG failure, it stopped being one.
Where people get burned
2.4.13 Focus Appearance is Level AAA. It is the most frequently misquoted criterion in the 2.2 set, because it reads like a hardening of 2.4.7 Focus Visible (AA) and because it went through drafts as an AA candidate. Citing it as AA in a review is the kind of error that costs you the room — the whole value of naming a number is that the number is right. When you want a citable requirement about how a focus indicator looks at AA, the one that exists is 1.4.11 Non-text Contrast, not 2.4.13.
Here is the part that decides what you write in the note. The current W3C Recommendation is 2.2, but the standards that organisations are actually held to lag it, and they do not lag it uniformly. The US Department of Justice’s 2024 rule under Title II of the ADA names WCAG 2.1 Level AA as the technical standard, with compliance dates of 26 April 2027 for public entities serving populations of 50,000 or more and 26 April 2028 for smaller entities and special district governments. Meanwhile the Revised Section 508 Standards, effective 18 January 2017, still incorporate “Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0”.
Three different numbers, all current, all defensible in the right context: 2.0 AA for federal procurement, 2.1 AA for state and local government under Title II, 2.2 as the W3C’s live Recommendation. “We are WCAG compliant” names none of them and therefore means nothing. “We target WCAG 2.1 Level AA, and we track the four Level AA criteria 2.2 added” is a position somebody can audit, disagree with, or adopt. That sentence is the deliverable.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Someone says “our component library is WCAG AA compliant.” Name the two things wrong with that sentence, in the specification’s own terms.
Check your answer
One: a library cannot conform. Conformance is for full pages only and cannot be achieved if part of a page is excluded, so the subject of the sentence is wrong before you get to the claim.
Two: “WCAG AA” names no version. A conformance claim has to reference the guidelines version, and 2.0 AA, 2.1 AA and 2.2 AA are three different sets of criteria that are currently all in force somewhere. Without the version the level is unresolvable.
If you want a third, ask what technologies the claim relies on. The documented set of accessibility-supported technologies relied upon is a required component of a claim, and almost nobody who says this sentence has one.
Hands on
Open the conformance note with a scope, not a score
Done when: CONFORMANCE.md has a header block naming the artifact, the version and level targeted, the scope in the specification’s own vocabulary, the accessibility-supported set relied upon, and one sentence saying why this is a note rather than a claim — with no findings in it yet.
- Create
learning/accessibility/CONFORMANCE.mdif the seeded file is not already there, and put the review gate at the top by name. Not “the app” — the specific component and the specific screens it appears on. - Write a Target line naming a version and a level together, in the form the DOJ rule uses. If you choose 2.1 AA, say in one clause why, and name whether you are also tracking the four Level AA criteria that 2.2 added.
- Write a Scope line using the specification’s vocabulary. State whether the review gate sits inside a complete process, and if it does, name the other steps in that process by name — those pages are inside the scope whether you have looked at them or not.
- Write an Accessibility supported line listing the browser and screen-reader combinations the note assumes. Guessing is not allowed here: list only combinations you could actually check, and if that list is currently empty, write “none verified” rather than an aspiration. An empty list is a finding.
- Close the header with one sentence stating that this document is a component conformance note and not a conformance claim, and why. Quote or paraphrase the Full pages requirement so the reason is checkable rather than asserted.
- Bring the header into the chat. I will push on any line where a version is missing, a level is stated without a version, or the accessibility-supported list contains a combination you have not actually put a screen reader in front of.
What this does not cover
Everything above is about the shape of the claim and none of it is about the content. You now have a note with a scope and a target and no findings, which is the correct order — a finding without a stated scope is unactionable — but it is also an empty document. What follows is the set of numbered criteria that actually fail in component code, each with the place it predictably fails, so the note can start acquiring rows. After that comes the honest rating of what axe and Lighthouse can and cannot see, which is what tells you how much of that list you will have to check by hand.
Two things this lesson deliberately left as delegated judgement rather than resolving: what counts as accessibility supported for a given pattern, which the screen-reader lesson comes back to with actual keystrokes, and what to do when the pattern in question is a token stream that no version of WCAG was written with in mind. That one waits for the third module, and it is the reason this course exists.
Read this next — primary source
Understanding ConformanceW3C Web Accessibility Initiative, part of Understanding WCAG 2.1 — free, informative (non-normative)
This lesson takes the five conformance requirements, the definition of accessibility supported, and the components of a conformance claim. The full document goes considerably further: it works through statements of partial conformance for third-party content you do not control, the mechanics of conforming alternate versions, what counts as a complete process, and the long discussion of who bears the burden of deciding whether a technology is accessibility supported. If you are going to be the person other teams route this question to, that discussion is the part you need in full rather than in summary.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.