Accessibility

Accessibility work that starts with real users, not a badge

Around 95% of the top million home pages still have detectable WCAG failures. Most of them are fixable in a day. We audit against WCAG 2.2 AA principles, reproduce each issue, and order the fixes by who they affect.

Accessibility is not a separate project bolted onto a finished site. It is the consequence of ordinary engineering decisions: using real headings, labelling form fields, keeping contrast above a threshold, making sure a keyboard can reach everything, and not shipping a custom control that only works with a mouse.

We audit against WCAG 2.2 AA principles and report in plain English. Each issue is reproduced with the page, the element and the assistive technology or input method affected. We do not claim a site is “fully compliant” — that requires a formal conformance evaluation, and any agency claiming it without one is selling confidence rather than evidence.

Offer

Three ways to engage

An audit

A sample of key templates and user journeys, tested with keyboard, screen reader and zoom. You get a prioritised issue list, reproduction steps and a remediation estimate.

Remediation

We fix the issues in your existing codebase, starting with the ones that block a task — forms, navigation, checkout, booking — rather than the cosmetic ones.

An accessible build

New sites are built to WCAG 2.2 AA principles from the first commit: semantic HTML, visible focus, reduced-motion support, labelled controls, and automated checks in the build.

Principles

What AA actually asks for

PrincipleWhat it means in practiceCommon failure
PerceivableText alternatives, captions, sufficient contrast, content that works at 200% zoomGrey text on a dark background; images with no alt text
OperableEverything reachable and usable by keyboard, no traps, enough timeA menu that only opens on hover; a custom dropdown with no focus state
UnderstandableClear labels, consistent navigation, errors explainedA form that says “invalid input” without saying which field or why
RobustValid, semantic markup that assistive technology can parseDivs pretending to be buttons; duplicate IDs; broken ARIA

Honesty

What we will not claim

  • “Fully compliant”Unless a formal conformance evaluation has been completed against the agreed scope, we will not use the phrase. We will describe what was tested and what was found.
  • “Zero issues”Automated tools catch perhaps a third of problems. Manual testing with a keyboard and a screen reader is the only way to find the rest.
  • “Accessibility is a one-off”Every new page and feature can introduce a regression. The build needs checks, and someone needs to own them.

Legal context, without the scare tactics

Legal context, without the scare tactics

Questions

The things people ask first

Is my site legally required to be accessible?

Public sector sites have specific regulations. Private businesses have duties under the Equality Act not to discriminate, and the practical expectation is reasonable adjustment. The safest position is a site that works for disabled users, not a legal argument after a complaint.

How long does an audit take?

A five-page marketing site is typically two to three days. A booking journey or an ecommerce checkout takes longer because there are more states to test.

Will accessible design look plain?

No. Contrast, focus states and larger tap targets can be designed well. The constraint is real, but it produces clearer interfaces rather than uglier ones.

Can you audit a site you did not build?

Yes. We have no interest in finding work for ourselves; if the issues are small, we will tell you and give you the list to take to your developer.

Let’s find out whether technology is the answer

Tell us what you are trying to achieve. We will tell you honestly whether we can help, what it would take, and roughly what it would cost — before anyone signs anything.