Under WCAG 2.2, can a design-system component be called AA conformant on its own, and what should its release checklist claim instead?
answer
- what conformance attaches to
- full pages, complete processes
- correct alone, wrong in use
- criteria the component controls
- consumer obligations in the docs
basics
~20 sNo. WCAG conformance is defined for full web pages and complete processes, not for parts of them. A component's checklist should claim it meets the AA criteria it controls when used as documented, and list what consumers must still do.
solid answer
~40 sWCAG 2.2 defines conformance only for web pages, and its full-pages requirement says conformance cannot be achieved if part of a page is excluded - so a component, being a part, cannot conform by itself. What the checklist can honestly claim is that the component **meets the AA criteria it controls** - for example keyboard operation, name, role and value, 4.5:1 text contrast, 3:1 non-text contrast, visible focus and target size - **when used as documented**, verified by an automated scan plus manual keyboard and screen-reader passes on each platform. It must also publish the **consumer's obligations**: supply an accessible name, do not convey meaning by color alone, do not cover its focus with sticky content. A correct component can still produce a failing page if it is used wrongly.
go deeper
Recall that WCAG conformance belongs to full pages and processes, so a component can only meet the criteria it controls and must document what its users still owe.
Explain which AA criteria a component typically owns, with their numbers and thresholds, and how a scan plus keyboard and screen-reader passes verifies them.
Show how you split responsibility between system and consumers in practice: published obligations, interfaces that make misuse hard, and triage when an audit fails a consuming page.
Weigh how the system communicates accessibility to leadership and customers without overclaiming, while still making the library the cheapest route to conforming pages.
## What WCAG attaches conformance to **WCAG** (Web Content Accessibility Guidelines) 2.2 is the W3C standard most organisations use as their accessibility target, usually at **level AA**. It is built from testable **success criteria**, each at level A, AA or AAA. A **conformance claim** says a piece of content meets all criteria at a level. The standard is precise about what can conform. Its conformance requirements say conformance is for **full web pages** only and cannot be achieved if part of a page is excluded, and that when a page is one step of a **process**, every page in the process must conform. It also states that conformance is defined only for web pages, although a claim may cover a series of pages. There is no provision for a button, a dialog or a date picker to conform on its own. WCAG is written for web content; teams commonly apply its criteria to native mobile components too, and the same logic holds there: the unit that succeeds or fails for a user is the screen and the task, not the part. ## Why a component cannot conform alone A component can be flawless in isolation and still sit on a failing page: - An **icon-only button** needs a text alternative; if the component lets consumers omit it, the page fails 4.1.2 Name, Role, Value. - A component with a perfect focus indicator can have that focus **hidden under a sticky header** the product added, failing 2.4.11 Focus Not Obscured (Minimum). - A status chip that relies on **color alone** passes contrast yet fails 1.4.1 Use of Color if the consumer adds no text or icon. - A component placed in a confusing **reading or focus order** by the page layout fails criteria about meaningful sequence and focus order. So 'our library is AA conformant' is a claim the standard does not support, and it misleads product teams into skipping their own checks. ## What the checklist should claim The honest claim splits responsibility: | Criterion (WCAG 2.2) | Level | Component's job | Consumer's job | |---|---|---|---| | 2.1.1 Keyboard | A | every function operable from a keyboard | do not add pointer-only interactions around it | | 4.1.2 Name, Role, Value | A | expose role and state; accept a name | supply a meaningful name | | 1.4.3 Contrast (Minimum) | AA | text meets 4.5:1 (3:1 large) in every supported theme | do not override colors outside tokens | | 1.4.11 Non-text Contrast | AA | control boundaries and states meet 3:1 | keep adjacent backgrounds within the theme | | 2.4.7 Focus Visible | AA | visible focus indicator | do not suppress it | | 2.4.11 Focus Not Obscured (Minimum) | AA | focus indicator present | do not cover focused items with sticky content | | 2.5.8 Target Size (Minimum) | AA | targets at least 24 by 24 pixels or adequately spaced | do not shrink or crowd them | The release checklist records the component column as verified, and the docs publish the consumer column as **usage obligations**. ## How the claim is verified 1. Run an **automated accessibility scanner** on every variant and state. It catches machine-detectable problems such as a missing name or a failing static color pair. 2. Do a **keyboard pass**: reach, operate and leave the component using only the keyboard; check focus is visible at each step. 3. Do a **screen-reader pass** on each platform the component ships to: confirm the announced role, name and state, and that state changes are announced. 4. Check **every supported theme** for contrast, including high-contrast modes. 5. Check **enlarged text and narrow widths**, since resize and reflow are AA criteria too. The automated step is necessary but not sufficient; whether a name is meaningful or a keyboard model makes sense needs a person. ## Wording the claim A good documentation statement reads roughly: 'Tested against WCAG 2.2 AA criteria listed below, with keyboard and screen-reader passes on the supported platforms. The page using this component is responsible for the obligations listed.' It is specific, testable and does not promise page-level conformance. Design the component's interface so correct use is the easy path: make the accessible name a required input for an icon-only button rather than a documentation plea. ## Common mistakes - Advertising the library as 'certified' or 'conformant', which no standard grants to a component. - Treating a clean scan as the whole accessibility item. - Treating target size as an AAA nicety; 2.5.8 is AA in WCAG 2.2 (the 44 by 44 variant, 2.5.5, is AAA). - Publishing no consumer obligations, so teams assume the component makes their page accessible.
- If a consuming team's page fails an audit because of a shared component, whose defect is it?It depends which column the failure sits in. If the component broke a criterion it controls - missing role, failing contrast in a supported theme - it is the system's defect and needs a fix release. If the consumer omitted an obligation, the page team fixes it, but the system should ask why misuse was easy and tighten the interface or docs.
- Why can an automated scanner not close a component's accessibility item on its own?Scanners test machine-detectable rules: a missing name, a failing static color pair, an invalid state. They cannot judge whether a name is meaningful, whether the keyboard model is sensible, or whether a state change is announced at the right moment. A manual keyboard pass and a screen-reader pass on each target platform cover those.
saying these in an interview costs you the question
- Our component library is WCAG AA certified, so every product using it conforms.
- A component that passes an automated scan conforms to WCAG.
- Native mobile components need no accessibility item because WCAG targets web content.
- Consumers carry no accessibility responsibility when they use a checked component.
- Target size is an AAA concern, so a component checklist can ignore it.