Shipping websites for UK clients? A WCAG 2.2 AA checklist for what the Equality Act expects

If you build websites for UK businesses, sooner or later a client asks: "Do we legally have to make the site accessible?"

The short answer: the Equality Act 2010 applies to anyone providing services to the public in England, Scotland and Wales, of any size. The Equality and Human Rights Commission (EHRC) names websites and internet services as one of the areas where providers must avoid discrimination and make reasonable adjustments.

The Act doesn't name a technical standard. In practice the benchmark everyone works to is WCAG 2.2 Level AA, the level the UK public sector has to meet. This post turns that into things you can check in code and in a browser. (It's general information, not legal advice.)

The legal bit, in developer terms

Three points matter for the work you ship:

• The duty is anticipatory. A business can't wait for a disabled customer to complain. It has to think ahead about what people with a range of impairments might need. For you, that means accessibility goes into the acceptance criteria, not a post-launch ticket.
• "Reasonable" depends on size and resources. A two-person shop and a national retailer aren't held to identical expectations. But the EHRC notes that many adjustments aren't particularly expensive, especially when they're built in from the start.
• Public sector sites have stricter rules. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require WCAG 2.2 AA and a published accessibility statement. If your client is a council, NHS body or some charities, those rules apply on top.

The WCAG 2.2 criteria that older UK sites usually fail

WCAG 2.2 added criteria that sites built against 2.0 or 2.1 often miss. Check these first.

Focus Not Obscured (Minimum), 2.4.11

Sticky headers and cookie banners (very common on UK sites because of PECR consent) often cover the focused element when someone tabs through the page.

/* Keep focused elements clear of a 72px sticky header */
html { scroll-padding-top: 80px; }
/* Never remove the focus ring without replacing it */
:focus-visible { outline: 3px solid #1d4ed8; outline-offset: 2px; }

Test it by tabbing through every page with the cookie banner still open.

Target Size (Minimum), 2.5.8

Pointer targets need to be at least 24 × 24 CSS pixels, or have enough spacing around them (there are exceptions, such as links inside a sentence). Icon-only buttons in headers and carousels are the usual offenders.

.icon-button {
  min-width: 24px;
  min-height: 24px;
  /* 44px is a more comfortable target on touch screens */
}

Accessible Authentication (Minimum), 3.3.8

Logging in shouldn't require a cognitive test. In practice that means:

<!-- Let password managers and paste work -->
<input type="email" name="email" autocomplete="username">
<input type="password" name="password" autocomplete="current-password">

Don't block paste on password fields, and don't use a puzzle CAPTCHA without an accessible alternative.

Dragging Movements, 2.5.7

Sliders, sortable lists and map pins need a single-pointer alternative, such as buttons or an input.

The checklist I run on every UK client site

These catch most of the common problems before a proper audit:

• Keyboard only: every link, menu, form, modal and checkout step works with Tab, Shift+Tab, Enter, Space and Esc, in a logical order, with a visible focus indicator.
• Contrast: normal text is at least 4.5:1, large text at least 3:1. Colour is never the only signal, for example red borders on form errors need text too.
• Images: meaningful images have short, accurate alt; decorative ones get alt="".
• Forms: a visible <label> for every field (placeholder text is not a label), required fields marked in text, and errors that say what went wrong and how to fix it, tied to the field with aria-describedby.
• Structure: a unique <title> per page, one <h1>, a logical heading order, and link text that makes sense out of context ("Read the delivery policy", not "click here").
• Zoom and reflow: at 400% zoom (or a 320px-wide viewport) content reflows without sideways scrolling.
• Media: captions on pre-recorded video, transcripts for audio.
• Motion: carousels can be paused, nothing flashes, and prefers-reduced-motion is respected.
• PDFs: important documents are accessible, or the same content exists as an HTML page.

Testing: automated tools are only the start

The W3C is clear that no tool alone can tell you whether a site meets accessibility standards. A realistic test plan:

• Automated scan (axe DevTools, Lighthouse, WAVE) on key templates to catch missing labels, contrast and ARIA errors quickly. Add @axe-core/playwright or similar to CI so regressions fail the build.
• Keyboard pass through the main journeys: find a product or service, submit the contact form, book or check out.
• Screen reader pass with NVDA on Windows and VoiceOver on macOS/iOS.
• Zoom and mobile pass at 200% and 400%, and on a real phone.
• Feedback from disabled users where the budget allows. The W3C recommends involving them throughout a project.

Re-test after redesigns, new features and plugin or theme updates. Accessibility breaks quietly.

Give the client an accessibility statement

Private businesses aren't legally required to publish one, but it's good practice and easy to ship. The W3C suggests at minimum:

• a commitment to accessibility;
• the standard you work to (WCAG 2.2 AA);
• contact details for people who hit a problem or need content in another format.

Add known limitations, what was tested and with which assistive technologies, and the review date. Keep it honest: describe what you tested, not "this site is fully accessible".

FAQ

Does the Equality Act apply to small business websites?

The EHRC says it applies to service providers whatever their size. What counts as a reasonable adjustment depends on the organisation's size, nature and resources.

Is WCAG 2.2 AA a legal requirement for UK private businesses?

The Act doesn't name a standard. WCAG 2.2 AA is the public sector requirement and the usual benchmark for showing a site was built and tested with accessibility in mind.

Can an accessibility overlay make a site compliant?

An overlay doesn't fix the underlying markup, and the W3C's position is that no automated tool alone can determine conformance. Fix the code.

What about Northern Ireland?

Northern Ireland has its own disability discrimination law, and the Equality Commission for Northern Ireland is the regulator there.

If you need a second pair of eyes on a client site before launch, my team at Dzimark runs a website accessibility audit against WCAG 2.2 AA with manual keyboard and screen reader testing.

Originally published on the Dzimark blog.