The tangible win
After this lesson, you should be able to explain why accessibility belongs in tokens, components, patterns, and documentation—not only in QA.
Backend analogy: invariants
Backend systems protect invariants: a payment cannot be negative, an order cannot ship before it exists, a user cannot access data without permission.
Design systems should protect experience invariants: text must be readable, focus must be visible, controls must have names, errors must be understandable, and keyboard users must be able to complete the task.
Where accessibility lives
| Layer | Constraint | Example |
|---|---|---|
| Tokens | Readable contrast and spacing. | color.text.default must work on color.bg.default. |
| Components | Built-in keyboard and screen reader behavior. | A modal traps focus and returns focus when closed. |
| Patterns | Flows remain understandable and recoverable. | Form errors appear near fields and in a summary. |
| Docs | Usage rules prevent misuse. | Do not use placeholder text as the only label. |
A common mistake
Weak system:
<Button color="lightGray">Continue</Button>This lets a team choose a low-contrast button by accident.
Stronger system:
<Button variant="secondary">Continue</Button>The system owns the contrast rules for secondary. Product teams choose intent, not fragile visual details.
Practice: classify the accessibility issue
A text input has placeholder text but no label. What kind of system failure is this?
System-level accessibility questions
- Can every interactive component be used by keyboard?
- Is focus visible and predictable?
- Do controls have accessible names?
- Do color tokens preserve contrast in supported themes?
- Are errors announced, located, and recoverable?
- Does documentation show correct and incorrect usage?
Read next
Skim the WCAG quick reference for the shape of accessibility requirements, then skim ARIA Authoring Practices to see how common components have expected behavior contracts.