Design System Accessibility Checklist for WCAG 2.2 Compliance

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.

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.