The criteria that actually bite
A handful of numbered criteria account for most of what fails in a component library, and each fails in a specific predictable place — which is what lets you end an argument with 1.4.11 instead of an opinion about whether the border looks a bit light.
Take the review gate apart and look at it as an auditor would. The per-field confidence chip is a soft grey pill on a white card. The approve and correct actions are 20-pixel icon buttons sitting next to each other in a dense table row. The focus ring went away three years ago when somebody added a CSS reset. When a correction fails validation, the field border turns red.
Every one of those is a numbered success criterion with a level, and each one fails in a place you can predict without opening the page. That predictability is the whole point of this lesson: a small set of criteria accounts for most of what breaks in component code, and knowing which number covers which failure converts “that contrast looks a bit light to me” into “that fails 1.4.11 at AA, and here is the ratio.” The second sentence ends the meeting.
Contrast is two criteria, and the second one is the one you miss
1.4.3 Contrast (Minimum), Level AA requires “a contrast ratio of at least 4.5:1” for the visual presentation of text and images of text, dropping to 3:1 for large-scale text — defined as at least 18 point, or 14 point bold, which the Understanding document notes is roughly 24px and 18.5px. There are three exceptions and they are worth memorising because they get misapplied in both directions: Large Text, Incidental, and Logotypes. Incidental covers text that is part of an inactive control, pure decoration, invisible, or part of a picture with significant other visual content.
That exception has a consequence people find surprising: “User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements.” A greyed-out disabled button does not fail 1.4.3. This is a genuine exemption and you should know it, and you should also know that invoking it as a defence for a design where users cannot tell what the disabled control says is technically correct and practically hostile. Conformance is a floor.
1.4.11 Non-text Contrast, Level AA is the one that catches the confidence chip, the input border and the focus ring. It requires a ratio of at least 3:1 against adjacent colours for “visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author”, plus parts of graphics required to understand content.
The load-bearing word is states. The Understanding document spells it out: “any visual information necessary to indicate state, such as whether a component is selected or focused must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio.” A confidence chip whose entire meaning is carried by a pale fill is conveying state at a ratio nobody measured. So is a checkbox whose only unchecked-state indicator is a hairline border.
One nuance that saves arguments in the other direction: “This success criterion does not require that controls have a visual boundary indicating the hit area.” A borderless text button is not automatically a failure. The boundary is only required when nothing else identifies that a control is there — and then the boundary itself has to meet 3:1.
Focus visible is one line of CSS away at all times
2.4.7 Focus Visible, Level AA is short: “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.” Notice what it does not say. It sets no minimum size, no minimum contrast, no shape. It is a binary: is there an indicator or isn’t there.
The quantification you are looking for lives elsewhere, and knowing where is the citation skill. At AA it is 1.4.11 — the Understanding document for 2.4.7 explicitly routes you there, noting that focus indicators typically use non-text content such as borders and outlines and are therefore subject to it. At AAA it is WCAG 2.2’s 2.4.13 Focus Appearance, which is where the two-pixel perimeter and change-of-contrast rules live. If someone asks you for the AA rule about how thick a focus ring must be, the honest answer is that there is no such rule — there is a contrast rule and a presence rule, and the thickness rule is AAA.
WCAG 2.2 adds one more that agentic surfaces walk straight into. 2.4.11 Focus Not Obscured (Minimum), Level AA: “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” Written for sticky headers and cookie banners; it applies just as cleanly to a persistent status bar reporting an agent run, which is exactly the kind of chrome that gets added late and pinned to the bottom of the viewport without anybody tabbing through the page afterwards.
Target size: the criterion whose level changed underneath everyone
This is the cleanest example in the whole standard of why a version number is not optional. In WCAG 2.1, target size is 2.5.5 Target Size, Level AAA, requiring “at least 44 by 44 CSS pixels”. In WCAG 2.2 a new and weaker criterion arrives at AA: 2.5.8 Target Size (Minimum), Level AA, requiring “at least 24 by 24 CSS pixels” with five exceptions.
Work through what that means for your 20-pixel icon buttons. If the stated target is WCAG 2.1 Level AA — which is what the DOJ Title II rule names — there is no target-size obligation at all, because the only target-size criterion in 2.1 is AAA. If the stated target is 2.2 Level AA, the same buttons are now in scope at 24 pixels and probably fail. Same buttons, same product, opposite answers, and the only thing that moved was the version in your conformance note. Anyone who cannot hold both of those facts at once will give the wrong answer roughly half the time.
The exception that rescues most dense tables is Spacing, and it is worth quoting exactly because people paraphrase it into something false: “Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target.” The test is a circle centred on the bounding box, not a padding measurement, and it fails as soon as two small buttons sit shoulder to shoulder — which is precisely how approve-and-correct pairs get laid out in a table row.
An error the user cannot read is not identified
3.3.1 Error Identification is Level A, not AA, which matters because Level A failures are the ones that are hardest to defend in any conversation about priority. The text: “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”
In text. A red border is not text. An exclamation icon is not text. The Understanding document is comfortable with both of those existing — “It is perfectly acceptable to indicate the error in other ways such as through the use of an image, color, or other visual indicator, in addition to the text description” — as supplements, never as substitutes. It also does not dictate placement: errors listed before the form, shown inline, or presented in a dialog all satisfy it.
Two neighbours complete the family. 3.3.2 Labels or Instructions, Level A — “Labels or instructions are provided when content requires user input” — and 3.3.3 Error Suggestion, Level AA, which requires that where a correction is known it is offered, unless doing so would jeopardise security or the purpose of the content.
Now the part specific to your work. A field extracted at 41% confidence is not an input error — the user has not entered anything yet, nothing was automatically detected as wrong, and 3.3.1 does not apply. It is a status message, which puts it under 4.1.3 Status Messages, Level AA, defined as a change in content conveying “information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.” A correction the user typed and the app rejected is an input error, and 3.3.1 does apply. Same panel, two different criteria, two different levels, and getting the distinction right is what stops a remediation ticket being written against the wrong requirement.
Where people get burned
The criterion custom components fail most often is not on this list, because it fails invisibly. 4.1.2 Name, Role, Value, Level A requires that name and role can be programmatically determined and that states and values can be programmatically set, and carries an explicit note that it is “primarily for web authors who develop or script their own user interface components” because standard HTML controls already meet it when used to specification. Everything in this lesson is visible in a screenshot. 4.1.2 is not visible anywhere, which is why it belongs to the module on ARIA patterns rather than to this one.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
In one sentence each, give the number, name and level for: text contrast, non-text contrast, focus presence, focus obscuring, target size at AA, error identification, and status messages.
Check your answer
- 1.4.3 Contrast (Minimum), AA — 4.5:1 for text, 3:1 for large-scale text.
- 1.4.11 Non-text Contrast, AA — 3:1 for information identifying components and their states, and for parts of graphics required to understand content.
- 2.4.7 Focus Visible, AA — an indicator exists; no size or contrast is specified here.
- 2.4.11 Focus Not Obscured (Minimum), AA — WCAG 2.2 only; the focused component is not entirely hidden by author-created content.
- 2.5.8 Target Size (Minimum), AA — WCAG 2.2 only, 24×24 CSS pixels with five exceptions. In WCAG 2.1 the equivalent is 2.5.5 Target Size at 44×44, and it is AAA.
- 3.3.1 Error Identification, A — the item in error is identified and the error described in text.
- 4.1.3 Status Messages, AA — status messages are programmatically determinable through role or properties without receiving focus.
If you produced the names and numbers but hesitated on the levels, the levels are the half that does work in a prioritisation meeting. A Level A failure and a Level AAA aspiration get funded very differently.
Hands on
Give the conformance note its first real rows
Done when: CONFORMANCE.md has a findings table with at least six rows, each carrying a criterion number, exact name, level, a one-line plain-English test, a verdict of met / failed / not applicable, and — for every failure — a remediation cost in engineering hours or days.
- Add a findings table under the header block you already wrote, with columns for criterion, level, test, verdict and remediation cost. The criterion column carries the number and the exact name, spelled the way the specification spells it.
- Work the review gate against the criteria in this lesson, one at a time. Actually measure the contrast ratios rather than eyeballing them — a ratio you guessed is a row you will have to redo the first time somebody checks it.
- Include at least one not applicable row and say why in the test column. Target size against a 2.1 AA target is the obvious candidate, and writing it down as deliberately out of scope rather than silently omitting it is what makes the note trustworthy.
- For the confidence chip specifically, decide whether it is a status message under 4.1.3 or an error under 3.3.1, and record the reasoning in one clause. If some states of that chip are one and some are the other, that is two rows.
- Put a remediation cost on every failure — hours or days, your own honest estimate. A finding without a cost is an opinion; a finding with a cost is something a portfolio company can schedule.
- Bring the table into the chat. I will check every level against the specification and challenge any verdict that rests on a ratio you did not measure.
What this does not cover
Some of what you just did by hand, a scanner would have done in two seconds; some of it no scanner will ever do. Which half is which is the next thing worth knowing, because it decides how much of a ninety-company portfolio you can cover with CI and how much needs a human with a checklist. The tooling lesson rates axe and Lighthouse honestly, including the vendor’s own coverage number and the admission Google ships inside Lighthouse’s own interface.
Two things this lesson set up and deliberately did not deliver. 4.1.2 Name, Role, Value is the criterion your custom components most likely fail, and it needs the ARIA-patterns module rather than a screenshot. And 4.1.3 Status Messages, introduced here as the home of the confidence chip, turns out to be the criterion an entire streaming interface hangs from — the announcing-the-stream lesson is where that gets difficult, because a criterion written for a shopping cart update has to be made to govern a thousand token deltas a minute.
Read this next — primary source
Understanding Success Criterion 1.4.11: Non-text ContrastW3C Web Accessibility Initiative — free, informative (non-normative)
This is the criterion most component authors have never read in full, and the Understanding document is where the reasoning lives rather than the rule. It works through which part of a control the 3:1 applies to, why a boundary is only required when nothing else identifies the control, how states like focused and selected are covered, and a long set of worked examples with diagrams showing which of two visually similar designs passes. Once you have read it you can adjudicate a design review on this criterion without hedging, which is exactly the skill this course is after.
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.