Accessibility and the UK Equality Act: A Developer's Compliance Checklist

A missing focus ring rarely makes headlines. A checkout that cannot be completed with a keyboard can, and that is usually the point where accessibility stops being a design preference and becomes a legal matter.

In the UK, that conversation starts with the Equality Act 2010. It places a duty on service providers to make reasonable adjustments for disabled people, and since most services now run through websites and apps, the digital side of a service is squarely in scope. The duty is anticipatory: you are expected to build for disabled users before anyone complains, not to retrofit after a letter arrives.

What follows is a working checklist for in-house and agency teams shipping UK sites. It is a practical engineering guide rather than legal advice, and if you are dealing with a complaint, a tender questionnaire or a public sector review, get proper advice from someone qualified to give it.

The standard you will be measured against

WCAG 2.2 at level AA is the benchmark. It is not legislation, but it is the technical standard that sits behind the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which require public sector sites to meet WCAG 2.1 AA, publish an accessibility statement and offer a feedback route. Those regulations are monitored by the Government Digital Service.

Private sector sites are not covered by those regulations, but they are covered by the Equality Act as service providers. When a case is assessed, the technical discussion lands on WCAG, so the practical answer is the same either way: aim for 2.2 AA and keep evidence that you did. Note that 2.2 AA includes everything from 2.0 and 2.1 — you do not have to choose between them.

The core checklist

Run through this before you call a build finished. Most of it costs almost nothing at design time and a great deal once a component has been copied into forty places.

• Start with real elements. A native button gives you keyboard support, focus behaviour and screen reader semantics for free. A div with a click handler gives you none of it.
• Order your headings. One h1 per page, no skipped levels, and headings that describe the section rather than shout. Screen reader users navigate by heading list more than by anything else.
• Keep landmarks tidy. Header, nav, main and footer, each appearing once, with a skip link to the main content.
• Make everything reachable by keyboard. Tab through the whole page, including the cookie banner, filters and any modal. Focus must always be visible and never lost behind a sticky header.
• Keep focus order predictable. Follow the visual order and avoid positive tabindex values, which reorder the page in ways nobody can maintain.
• Label every input properly. A persistent, visible label linked to its field. Placeholders disappear the moment someone starts typing, and they are not labels.
• Write error messages that fix the problem. Say which field failed, explain the format expected, and link an error summary to each field. Never rely on a red border alone.
• Check contrast, including states. 4.5:1 for body text, 3:1 for large text and for UI components — input borders, icons, focus rings, and hover, active, disabled and selected states.
• Never use colour as the only signal. Required fields, errors, chart series and links inside paragraphs all need a second cue.
• Test at 200% zoom and 320px width. Content should reflow without horizontal scrolling and without losing function.
• Write alt text with a purpose. Describe the information the image carries, and leave alt empty for decoration. Skip "image of".
• Handle motion and media. Respect prefers-reduced-motion, caption video that contains speech, and never autoplay sound.
• Give people control over time and dragging. Timers need an extension option; anything drag-based needs a single-pointer alternative.
• Size targets sensibly. 24x24 CSS pixels minimum, with more room for anything used on a phone.

Test with tools, then test with a keyboard

Automated scanners are worth having in your CI pipeline. They catch a useful slice of problems — missing alt attributes, contrast failures, unlabelled inputs — quickly and repeatably. They cannot tell you whether a heading makes sense, whether a focus order feels logical, or whether an error message actually helps. For that you need a human at a keyboard.

1. Keyboard only, no mouse, across your five most important journeys.
2. A screen reader: VoiceOver on macOS or iOS, NVDA on Windows. Listen to a form, a menu and a modal.
3. Zoom to 200% and 400%, and check reflow at 320px wide.
4. Forced colours or high contrast mode, to catch anything that depends on your CSS backgrounds.

Third-party widgets are still your barrier

Cookie consent banners, chat widgets, embedded maps, booking engines and payment iframes cause a large share of the accessibility failures users actually hit. If your consent banner cannot be dismissed with a keyboard, the page is unusable no matter how clean your own markup is. Ask vendors for an accessibility conformance report, test the widget yourself before you sign, and have a fallback route — a phone number or a plain HTML form — for anything critical that fails.

Public sector statements and evidence

If you are a public sector body, an accessibility statement is a legal requirement. It should explain how the site meets the standard, list known gaps honestly, and tell people how to request content in another format or raise a complaint. An accurate list of known issues is far more defensible than a claim of full compliance you cannot support.

For everyone else, evidence still matters. Keep audit reports, log what you fixed and when, and note the decisions where you judged a fix disproportionate. If a complaint ever lands, a documented process is worth a great deal more than a last-minute scramble.

Build it into the way you work

One-off audits rot. What holds up is a definition of done that names accessibility, a component library with focus and error states built in, and a design review that checks heading structure and contrast before anyone writes code. Add an automated scan to CI, repeat a manual keyboard pass each release, and give the team an afternoon with a screen reader — it changes how people write markup for good.

Where to start this week

Pick the journeys that matter most: sign-up, search, checkout, contact. Keyboard test them. Fix labels, focus visibility, contrast and error handling first, because those four cover a large share of the problems users report. Then put a scan in CI and book a fuller audit for the next few months. Accessibility work is never finished, but the first fortnight of it removes most of the risk.

If the stakes are legal — a complaint, a tender, a public sector review — get professional advice alongside the technical work. Getting the engineering right makes that conversation much shorter.

Photo: StartupStockPhotos / Pixabay