Design System Accessibility Checklist: WCAG 2.2 and Component Testing

A design system can provide tested keyboard behavior, focus styles, accessible names, and documented color pairings. Review these at the token and component layers, then test the pages that use them; component checks alone do not establish conformance.

Why Accessibility Belongs at the System Layer

Shared components can reduce repeated accessibility work. Their behavior still depends on how teams compose them, label them, and manage surrounding content.

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. Define focus indicator color and width. If targeting AAA, check the area and focused-to-unfocused contrast requirements in WCAG 2.2 Focus Appearance.
• Typography tokens have readable defaults. Choose sizes for the typeface and context, then test text resizing and reflow. Treat a 16px body-text default as a design choice, not proof of WCAG conformance.
• 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. Check WCAG 2.5.8: the AA baseline is 24 by 24 CSS pixels, with spacing and other exceptions. The enhanced AAA criterion uses 44 by 44 CSS pixels, also with exceptions.

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 checks cover only some requirements; manual testing is needed to assess interaction and reading order.
• 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. This leaves each consuming team to implement and test the behavior.

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. Record test results and known limitations so consuming teams know what has been checked.

Discuss design system accessibility with LinkIT.