A graphic featuring a map of Europe in dark blue with a lighter blue figure in a circle at the centre, symbolising accessibility. The circle is surrounded by a ring of twelve yellow stars, representing the European Union, against a deep blue background.

If your organisation has a shared Design System or component library, that is where accessibility work has the highest return on investment.

Fix an accessibility failure in a Button component once, and it is fixed in every product that uses that component. That is the leverage of working at the design system level rather than the product level.

Why design system accessibility matters more than product audits

Most organisations approach accessibility with product-level audits: audit the website, fix the findings, move on. This works for one-off compliance, but it does not scale.

The more sustainable approach is to make design system components accessible by default, document what correct usage looks like for each one, and build accessibility checks into the contribution process before anything gets published. When you work that way, a fix at the component level propagates everywhere. A bug does too, but that is why the contribution checks matter.

When a Design System has poor accessibility, every product built from it inherits those failures. A button without a focus state. A form input with no error announcement. A modal that does not trap focus. These failures appear everywhere because the component itself is broken.

What a design system accessibility review covers

Component-level testing

Every interactive component is tested for keyboard navigation, screen reader behaviour, ARIA pattern correctness, and visual contrast. This includes primary components (Button, Input, Select, Modal, Alert, Table, Tabs, Accordion) and any custom patterns your system has built.

Token and theming review:

Colour tokens should be checked for contrast compliance across all themes (light, dark, high contrast). Typography tokens should meet minimum size requirements. Motion tokens should respect prefers-reduced-motion.

Documentation audit

Accessible usage notes in component documentation are often missing or vague. Good documentation tells the consumer developer which ARIA attributes to add, what to do for icon-only variants, and what patterns to avoid.

Contribution guidelines

If other teams contribute components to your design system, there should be a checklist or process for accessibility review before components are published.

Common design system accessibility failures

  • Focus indicators styled out globally (often by a CSS reset)
  • Colour contrast only checked for default state, not hover, focus, or selected
  • Form components with label association left to the consumer developer to implement
  • Loading and skeleton states with no accessible text
  • Icon component with no built-in support for accessible names
  • Tooltip components that are not keyboard or touch accessible
  • Animation and transition components without prefers-reduced-motion support

What I produce

A Design System accessibility review produces a component-by-component findings report and code-level remediation guidance

Get in touch to discuss a design system review