# Design System Accessibility Checklist for WCAG 2.2 Compliance

> A practical design system accessibility checklist covering WCAG 2.2 requirements for tokens, components, focus management, and testing at the system level.

- **Published:** 2025-04-10
- **Author:** Clixo
- **Reading time:** 6 min read
- **Tags:** accessibility, design systems, wcag, component library
- **Canonical URL:** https://clixo.sh/blog/design-system-accessibility-checklist-wcag

Accessibility is not something you add to a design system after it is built. If your tokens, components, and documentation ship without it baked in, every product team that consumes your system inherits the debt — and fixing it downstream is always harder and more expensive than fixing it at the source.

This checklist covers what a design system needs to be accessible by default, organized by layer.

## Why Accessibility Belongs at the System Layer

When accessibility lives in the design system, it compounds positively. A button that handles focus states, keyboard interaction, and screen reader announcements correctly does so everywhere it is used — across every product, every team, every release. When accessibility is left to individual engineers, it is implemented inconsistently, tested inconsistently, and fixed inconsistently.

The right time to make a component accessible is when you build it the first time.

```mermaid
flowchart TD
  A["Token Layer"] --> B["Component Layer"]
  B --> C["Documentation Layer"]
  C --> D["Testing Layer"]
  D --> E{Sign-off complete?}
  E --> |yes| F["Promote to stable tier"]
  E --> |no| G["Block from stable"]
```

## Design System Accessibility Checklist

### Token Layer

- [ ] **Color contrast ratios are documented on each color token.** Every semantic color token used for text or interactive elements should document its contrast ratio and the surfaces it meets WCAG AA (4.5:1 for normal text, 3:1 for large text and UI components).
- [ ] **No accessibility decision relies on color alone.** Tokens that encode state (error, success, warning) pair color with shape, icon, or text rather than relying solely on hue.
- [ ] **Focus ring tokens are defined.** A dedicated token for focus indicator color and width exists and meets WCAG 2.2 Focus Appearance requirements (minimum 3:1 contrast against adjacent colors).
- [ ] **Typography tokens meet minimum size requirements.** Body text defaults to at least 16px. Tokens never set text below 12px for anything a user reads.
- [ ] **Motion tokens respect `prefers-reduced-motion`.** Animation and transition tokens have a corresponding zero-duration variant applied via media query.

### Component Layer

- [ ] **All interactive components are keyboard operable.** Tab, Enter, Space, Escape, and arrow keys behave as specified by the ARIA Authoring Practices Guide for each pattern.
- [ ] **Focus is managed on all dynamic components.** Modals trap focus. Menus return focus to the trigger on close. Toast notifications do not steal focus.
- [ ] **All form inputs have associated labels.** The association is programmatic (`for`/`id` or `aria-labelledby`), not just visual proximity.
- [ ] **Error messages are associated with their inputs.** `aria-describedby` connects the error text to the field so screen readers announce it on focus.
- [ ] **Icon-only interactive elements have accessible names.** Buttons and links that use only icons carry `aria-label` or a visually hidden text equivalent.
- [ ] **Images have alt text guidelines.** The system documents when `alt=""` is appropriate (decorative) and when descriptive text is required.
- [ ] **ARIA roles and attributes are used correctly.** Components use semantic HTML where it exists. ARIA is additive, not a replacement for native semantics.
- [ ] **Status messages are announced without focus.** Toasts, inline alerts, and loading states use `role="status"` or `role="alert"` so screen readers announce changes without requiring focus to move.
- [ ] **Touch targets meet minimum size.** Interactive elements are at least 44x44px on touch surfaces (WCAG 2.5.8 Target Size).

### Documentation Layer

- [ ] **Each component documents its keyboard interaction model.** Which keys do what, in which order, in which states.
- [ ] **Each component documents its screen reader behavior.** What is announced, when, and in which tested combinations of browser and screen reader.
- [ ] **Color usage guidelines specify accessible pairings.** Documentation does not leave it to each engineer to verify contrast; the system specifies which token combinations are approved for text on which background tokens.
- [ ] **Known limitations are documented.** If a component pattern has an accessibility gap in a specific browser or assistive technology, that is written down — not left for consuming teams to discover in production.

### Testing Layer

- [ ] **Automated accessibility tests run in CI.** Tools like axe-core integrated with Storybook or Playwright catch regressions before they merge.
- [ ] **Visual regression tests include focus states.** Focus indicators are tested, not just resting states.
- [ ] **Manual keyboard and screen reader tests are included in the component review checklist.** Automated tools catch roughly 30-40% of accessibility issues. Manual testing covers the rest.
- [ ] **New components require an accessibility sign-off before reaching stable tier.** Accessibility review is part of the contribution process, not a post-release audit.

### Theming and Dark Mode

- [ ] **Dark mode tokens maintain contrast ratios.** A component tested only in light mode may fail contrast in dark mode. Audit both.
- [ ] **High-contrast mode is tested.** Windows High Contrast Mode and forced-colors CSS media queries are verified to not break component layouts.

## Common Accessibility Gaps in Design Systems

**Delegating a11y to consuming teams.** The system ships with no focus states defined, no ARIA attributes on compound components, and no keyboard model documented — and expects teams to add it. They will not, or they will add it inconsistently.

**Treating color contrast as a checkbox.** Auditing only the default light theme misses dark mode failures, disabled state failures, and interactive state failures.

**Skipping screen reader testing.** Automated tools cannot catch incorrect ARIA usage, missing live region announcements, or broken focus management. Those require a human with a screen reader.

**Not updating accessibility docs when components change.** The keyboard model documented six months ago may not match the component that shipped last week.

## Using This Checklist

Review this list at two points: when a component enters the beta tier and again before it moves to stable. Any unchecked item should block promotion to stable. The checklist is not a burden — it is the record of what your system guarantees to every team that depends on it.

[Clixo builds accessible design systems from the token layer up, so compliance is a property of the system, not the team.](https://clixo.sh/services)

---

Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh)
[Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)