Accessible design: the practical requirements

Accessible design is not a separate category of design. It is design that works for people using a keyboard, a screen reader, a magnifier, a phone in bright sunlight, or an old device on a bad connection — which is a lot more people than most teams assume.

Colour and contrast

• Body text: at least 4.5:1 against its background.
• Large text (24px, or 19px bold): at least 3:1.
• Interface components and meaningful graphics: at least 3:1 against adjacent colours.
• Never use colour as the only way information is conveyed. Required form fields marked only in red fail for a substantial number of users.
• Check link text against surrounding body text, not just against the background — links distinguished only by colour need a 3:1 difference or another cue such as an underline.

Keyboard operation

Every interactive element must be reachable and operable with a keyboard alone, in a logical order, with a clearly visible focus indicator. Removing focus outlines because they look untidy is the single most damaging accessibility decision made in web design, and it happens constantly.

Test it yourself: put the mouse away and try to complete your main conversion flow using only Tab, Shift-Tab, Enter and Space. Most teams discover something broken within thirty seconds.

Images and media

• Alt text describes the function of the image in context. A product photo needs the product name; a decorative flourish needs an empty alt attribute so screen readers skip it.
• Do not begin alt text with "image of". The screen reader already announces that it is an image.
• Text inside images is invisible to screen readers and to search engines, and it cannot be resized. Use real text over a background instead.
• Video needs captions. Audio-only content needs a transcript.
• Nothing should auto-play with sound, and anything that moves for more than five seconds needs a pause control.

Forms

• Every input needs a visible label, programmatically associated with it. Placeholder text is not a label — it disappears when typing starts.
• Errors must be described in text, adjacent to the field, and announced to assistive technology.
• Do not rely on colour alone to indicate an error state.
• Group related fields with fieldsets and legends. Radio buttons without a group label are ambiguous when read aloud.
• Give inputs the correct type and autocomplete attributes. It helps everyone and it is one line of markup.

Structure

• One h1 per page, then a heading hierarchy that does not skip levels. Screen reader users navigate by headings more than any other method.
• Use real semantic elements — buttons, links, lists, landmarks — rather than styled divs with click handlers.
• A link should navigate; a button should act. Swapping them breaks keyboard and screen reader expectations.
• Provide a skip link to the main content so keyboard users are not forced through the whole navigation on every page.
• Set the page language attribute, and mark any passage in a different language inline.

How to check

1. 1Run an automated tool. It catches perhaps a third of issues, which is a useful third.
2. 2Navigate the site by keyboard only.
3. 3Zoom to 200% and confirm nothing is cut off or overlapping.
4. 4Turn on a screen reader and attempt one real task. It is uncomfortable the first time and extremely informative.
5. 5Check contrast on every text and background pairing in the design system, once, at design time.