Accessibility: build it into the system once

Accessibility means everyone can use the product, whatever their sight, hearing, movement or cognition. In a design system it pays off twice: fix contrast, focus and keyboard behaviour once in a component, and every screen built with it inherits the fix.

It also helps far more people than the label suggests. Captions help in a noisy room, good contrast helps in bright sunlight, and keyboard shortcuts help power users. Accessibility is mostly good design, written down precisely.

WCAG and the four principles

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the shared standard. The current version is WCAG 2.2. Every guideline sits under one of four principles, known as POUR:

Each success criterion has a level: A is the minimum, AA is what most laws and companies target, and AAA is the strictest. Aim for AA.

A designer’s checklist

Most of WCAG is about content and code, but a large part is decided in design. These are the criteria a designer controls most directly, at level AA unless noted:

Designing for the keyboard

Many people navigate entirely by keyboard, or with switches and other devices that act like one. A few rules cover most of what design needs to specify:

• Tab order follows visual order. If the order isn’t obvious from the layout, annotate it in the design file.
• Modals manage focus. When a modal opens, focus moves into it and stays there; Esc closes it; on close, focus returns to the control that opened it.
• A skip link. A “Skip to content” link as the first focusable element lets keyboard users jump past the navigation.
• A focus state for every interactive component. Design it as a real state next to hover and pressed, not as an afterthought left to the browser.

.button:focus-visible {
  outline: 2px solid var(--focus-ring);
  outline-offset: 2px;
}

Designing for screen readers

A screen reader reads the interface aloud, using the names, roles and states the code exposes. Design decides much of what it says:

• Icon-only buttons need a name. Annotate it in the design, for example “accessible name: Delete database”, so it isn’t left to guesswork in build.
• Images need a purpose. Decide whether an image carries information, and needs alt text, or is decorative and should be skipped.
• Native elements first. The first rule of ARIA is not to use it when a native HTML element does the job. A real <button> is focusable and works with Enter and Space for free; a <div> with a click handler is neither.

<!-- Works by keyboard and is announced as a button -->
<button type="button" aria-label="Delete database">
  <svg aria-hidden="true">…</svg>
</button>

<!-- Avoid: not focusable, no role, no keyboard support -->
<div class="icon" onclick="remove()">…</div>

Tools

Baking it into the system

Accessibility is a feature of the component, not a pass at the end of a page. A design system makes it part of every layer:

• Tokens: colour pairs that are checked for contrast before anyone uses them.
• Components: focus states, keyboard behaviour and accessible names designed and built in.
• Documentation: an accessibility section on every component page.
• Process: an accessibility review before each release.

Next in the series

Reduced motion came up in the checklist, and motion deserves its own part. Part 10 covers motion and micro-interactions: durations, easing, what animation is for, and how to keep it helpful rather than distracting.