Accessibility

Last updated:

Practical accessibility standards for keyboard use, focus, forms, motion, and building inclusive interfaces from the start.

01 — Foundation

Why accessibility matters

Accessibility is product quality — not a checklist you run before launch.

Accessible work is usable work. It helps people understand content, navigate confidently, complete tasks, and recover from errors — with their own tools and preferences. Good accessibility improves experiences for everyone.

Bad accessibility quietly excludes people while teams celebrate Lighthouse scores. These standards describe practical expectations for modern frontend delivery — real usability, not theoretical perfection.

For forms and validation in UK-facing services, align with the GOV.UK Design System — it is the most thoroughly tested reference for labels, errors, hints, and recovery flows. Our accessible forms pattern maps those expectations to framework-agnostic HTML.

02 — Principles

People first

Success means people can use the product — not only that it passes an audit.

  • understand content and complete tasks without unnecessary friction
  • navigate with keyboard, pointer, voice, or assistive technology
  • recover from errors with clear guidance
  • build accessibility in early — not as a final-phase patch
  • treat compliance as a floor, not the finish line

03 — Early

Build it in from the start

Accessibility added at the end is expensive and incomplete.

Decisions in product, content, design, layout, language, workflows, and performance all affect accessibility before the first component ships.

Consider accessibility when you decide

  • product scope and user flows
  • content structure and plain language
  • interaction design and layout
  • performance budgets and third-party scripts

04 — Semantics

Semantic HTML first

Most accessibility problems get easier when the HTML is correct.

  • buttons for actions, links for navigation
  • visible labels on every form field
  • headings for structure, lists for grouped content
  • tables for tabular data
  • native elements before custom widgets and ARIA patches

Headings and structure

  • one h1 per page with logical nesting
  • no skipped levels used only for visual size
  • headings that describe content — not decoration

05 — Keyboard

Keyboard and focus

Everything important must work without a pointer.

That includes navigation, forms, dialogs, menus, disclosure widgets, tabs, and popovers. Users must tab predictably, see where focus is, activate controls, escape overlays, and recover from mistakes.

Focus management

Especially during dialogs, async updates, overlays, and dynamic content:

  • never remove visible focus styles without a stronger alternative
  • trap focus only when appropriate (modals), and return it on close
  • avoid unexpected focus jumps or stealing focus unnecessarily

Focus visibility

Focus should be obvious — not invisible because outlines were considered ugly.

Bad

*:focus {
    outline: none;
}

This removes critical support unless you replace it with an equally clear :focus-visible treatment.

Good

:focus-visible {
    outline: 3px solid var(--color-focus-ring);
    outline-offset: 3px;
}

Users should never wonder where focus is.

06 — Forms

Forms and errors

Forms reveal accessibility quality immediately. Follow GOV.UK validation where you can.

The GOV.UK validation pattern is the benchmark for error recovery: an error summary at the top, an error message on each invalid field, the same wording in both places, focus moved to the summary, and “Error: ” in the page title. See accessible forms for implementation detail.

Placeholders

A placeholder is optional hint text inside the field that shows an example of the kind of value to enter — a sample email, a date format, a reference number pattern. It is not the field’s name, and it is not the place to explain what the question means or whether the field is required.

In practice placeholders are often abused as cheap labels or descriptions. That fails people who need a persistent label, and it fails reviews that treat placeholders as decoration.

  • Not a label. Labels stay visible (or are exposed to assistive technology) while the user types. Placeholder text disappears as soon as input starts, so anyone who forgets the question mid-task has to clear the field or guess.
  • Not the main hint. Instructions, format rules, and privacy notes belong in visible hint copy linked with aria-describedby — not buried in pale placeholder text.
  • Often not announced reliably. Many screen readers do not treat placeholders like labels; behaviour varies by browser and AT. Do not rely on a placeholder being read out.
  • Often poor contrast. Placeholder styling is usually light grey on white (or faint on dark themes). That fails contrast checks for people with low vision and is easy to miss in bright sunlight.

Use a visible <label>, add hints where needed, and only then consider a placeholder for a short example — see GOV.UK text input guidance and accessible forms.

<label for="ref">Payment reference</label>
<p id="ref-hint">Use the 8-character code on your invoice, for example AB12CD34.</p>
<input id="ref" name="ref" aria-describedby="ref-hint" placeholder="AB12CD34">

Requirements

  • visible labels — placeholders are not labels
  • clear instructions and identified required fields
  • hints linked with aria-describedby; errors use aria-invalid and include error IDs in aria-describedby
  • errors linked to fields and announced to assistive technology
  • predictable keyboard flow and sensible autocomplete

Error messages

Explain what went wrong, where the problem is, and how to fix it.

Too vague

'Invalid input'

Clearer

'Enter a valid email address'

Plain language reduces cognitive load. Accessibility and clarity are the same work. Compare message quality with GOV.UK error message guidance.

07 — Visual

Colour, motion, and layout

Do not rely on colour alone. Respect how people actually view and move through the UI.

Use text, icons, labels, and structure — not colour alone — to convey meaning. Keep contrast readable for text, links, buttons, focus rings, and error states.

Motion

Animation should support understanding, not compete for attention. Always respect:

@media (prefers-reduced-motion: reduce) {
    * {
        animation-duration: 0.01ms !important;
        transition-duration: 0.01ms !important;
    }
}

Avoid excessive motion, autoplay carousels, parallax, flashing content, and transitions that make the interface feel restless.

Zoom and reflow

Content must stay usable at 200% zoom and beyond. Layouts should adapt; text should remain readable; basic content should not require horizontal scrolling. Accessibility includes responsive resilience — not only screen readers.

08 — Assistive tech

Screen readers and ARIA

Good HTML solves most problems before ARIA becomes necessary.

Screen readers depend on semantics, structure, labels, relationships, and predictable behaviour. Do not use ARIA to rescue poor markup.

No ARIA is better than bad ARIA. Use it only where native HTML cannot provide the required behaviour. Avoid unnecessary roles, duplicate semantics, and broken label relationships.

Skip links

Users should not tab through entire navigation on every page load to reach main content. A skip link is a small change with large usability value — implement it properly and make sure it is visible on focus.

09 — Overlays

Dialogs, performance, and resilience

Heavy, fragile interfaces create accessibility problems.

Dialogs and overlays

Dialogs must trap focus appropriately, restore focus on close, support Escape, and expose correct semantics. Prefer native dialog and popover APIs where they fit — do not build inaccessible overlay systems for sport.

Performance is accessibility

Slow pages, layout shift, and heavy scripts hurt people on older devices, slower networks, and assistive technology — and they increase cognitive load for everyone.

Progressive enhancement

Core tasks should work before JavaScript enhancement: forms submit, navigation exists, content loads. Partial failures should not block essential tasks.

10 — Testing

Test what matters

Automated tools help. They are not enough.

Test manually and often:

  • full keyboard navigation through real flows
  • screen reader spot checks on critical paths
  • zoom to 200% and reduced-motion preferences
  • touch target size and form completion with errors

Plain language, clear labels, and meaningful headings are part of accessibility too. Users should not decode the interface like a riddle.

Anti-patterns to avoid

  • accessibility bolted on at the end of a project
  • invisible focus states
  • placeholders used as labels
  • keyboard traps with no escape route
  • ARIA added everywhere instead of fixing HTML

11 — Review

Before you approve

A short checklist for accessibility in code review.

  • semantic HTML and logical headings
  • complete keyboard access and visible focus
  • labelled forms with understandable errors
  • sufficient contrast and motion that respects user preferences
  • screen reader spot checks on critical flows
  • core tasks work without JavaScript
  • skip link to main content

When in doubt, ask: Can people successfully use this product — not merely technically access it? If the answer is no, the work is not finished.

12 — Topics

Topic guides

Focused guides on keyboard, focus, and assistive technology — go deeper on specific mechanics.

See the full accessibility section for all topic guides, or jump to: