The assembly hierarchy
Accessibility responsibility does not merely accumulate as things get bigger. It changes character at each level of assembly, and the obligations at one level cannot be discharged by work at another.
Six levels
Naming the levels explicitly is worth doing, because the argument that follows depends on which level a claim is made at, and most claims in circulation do not say.
| Level | Example | Dominant responsibility |
|---|---|---|
| 0. Primitive | button, input, heading, link | Native semantics, accessible name, state, target size, focus appearance |
| 1. Simple component | search field, alert, card, field group | Relationships among primitives, label association, reading order |
| 2. Composite component | combobox, tablist, data grid, date picker, menu | Internal focus model, keyboard grammar, owned roles, state announcement |
| 3. Region | header, primary navigation, form, results panel | Landmark identity, heading level, region-scoped status |
| 4. Page | the assembled document | Landmark set, heading outline, focus sequence, reflow, duplication, conflict arbitration |
| 5. Process | registration, checkout, application flow | Continuity, state retention, error recovery, consistent navigation, end-to-end conformance |
Where the attention goes, and where it does not
Two observations follow from the table, and they are the reason it is worth drawing.
The first is a distribution problem. Most component libraries stop at level 2, because level 2 is where a reusable artefact can honestly be delivered: a combobox can be built once and used everywhere. Most automated tooling operates at level 4, because a rendered page is what a rule engine can be pointed at. Levels 3 and 5, regions and processes, are the least served by either, and they are exactly where composition failures concentrate. A landmark collision is a level 3 event. A lost form state after a session timeout is a level 5 event. Neither is visible to a component test or to a page scan.
The second is a conformance point rather than a convenience. WCAG’s provision for complete processes means that where a series of pages is needed to complete an activity, all pages in the series must conform for any of them to be claimed as conforming. So level 5 is not a testing nicety layered on top of the real work. It is a level at which conformance is defined, and a component-level claim can never discharge a level 5 obligation. No amount of green at level 2 adds up to a conforming checkout.
Why the level of a claim has to be stated
Once the levels are named, the ordinary sentence “the component is accessible” can be seen for what it is: a claim with its scope removed. It might mean that the primitive has a correct accessible name, that the composite implements its keyboard grammar, or that somebody once used it in a page that passed a scan. Those are three different assertions supported by three different kinds of evidence, and collapsing them is how a team ends up surprised.
This is the reason the design system I am building records the level and the environment of every piece of evidence, rather than a single flag. A claim without a level cannot be checked, and cannot be safely inherited by whoever assembles the next thing.
References
- W3C Web Accessibility Initiative. Understanding Conformance: complete processes. Understanding/conformance
- W3C. Accessible Rich Internet Applications (WAI-ARIA) 1.2: managing focus in composite widgets. TR/wai-aria-1.2