Most UK businesses building or rebuilding a website treat accessibility as a nice-to-have that gets cut when the deadline tightens. That is a legal miscalculation, not just a UX one. The Equality Act 2010 applies to any organisation providing a service to the public, and a website counts as a service. There is no size threshold that exempts a small business.
This is not a call to panic. It is a case for understanding what the law actually asks for, what the accepted technical benchmark is, and where to put engineering effort if you cannot fix everything before launch.
What the Equality Act actually says
The Equality Act 2010 does not mention websites, HTML, or WCAG by name. It requires service providers to make “reasonable adjustments” so disabled people are not put at a substantial disadvantage compared with everyone else. That wording is broad by design, and it leaves organisations without a checklist to tick off. In practice, when a case does reach court, the reference point judges and regulators use to decide whether a reasonable adjustment was made is the Web Content Accessibility Guidelines.
So the legal question and the technical question converge on the same document, even though the law itself does not name it. That is useful: it means building to WCAG 2.2 AA is a defensible, well-documented target rather than a guess at what a court might later decide was reasonable.
WCAG 2.2 AA, without the jargon
WCAG is organised around four principles: content must be perceivable, operable, understandable, and robust. Level AA is the middle tier of conformance, above the minimum (A) and below the strictest (AAA), and it is what UK courts and public sector regulations reference. In engineering terms, most of AA compliance reduces to a short list of concrete, testable requirements rather than abstract principles.
- Every interactive element (links, buttons, form fields) is reachable and operable by keyboard alone, in a sensible order.
- Text has sufficient colour contrast against its background, including text placed over images.
- Form fields have programmatic labels, not just placeholder text, and validation errors are announced, not only shown in red.
- Images convey their meaning through alt text; decorative images are marked as such so screen readers skip them.
- Video content has captions, and autoplaying media can be paused.
- Focus states are visible, so a keyboard user can always see where they are on the page.
- Page structure uses real headings and landmarks, so assistive technology can build an accurate map of the page.
None of this is exotic. Most of it is what semantic HTML gives you for free if a project has not been built out of un-labelled divs and click handlers standing in for buttons.
Where the cost actually is
The expensive part of accessibility work is almost never the visible layer. Contrast ratios and alt text are quick to fix once someone is looking for them. The expensive part is component architecture: a design system built on custom dropdowns, modals, and tab panels that were never given the keyboard behaviour and ARIA roles those patterns require. Retrofitting that after launch means touching every screen that uses the component, not just the component itself.
This is why accessibility is cheaper as a build-in decision than a retrofit. If the base component library handles focus management and keyboard interaction correctly from the start, every screen built on top of it inherits that behaviour. If it does not, every screen built on top of it inherits the defect, and someone eventually has to pay to unwind it, usually after a complaint, which is the most expensive time to discover it.
Mistakes worth flagging early
A few patterns show up repeatedly in codebases that were not built with accessibility in mind, and they are worth checking for specifically rather than trusting a general impression that the site looks fine.
- Treating an automated scanner result as a compliance certificate. Automated tools catch a meaningful fraction of issues, such as missing alt attributes, contrast failures, and missing form labels, but they cannot judge whether a screen reader user can actually complete a checkout flow or understand what a custom widget does. Manual keyboard and screen reader testing is not optional if the goal is genuine usability, not just a clean scan.
- Adding ARIA attributes as decoration rather than behaviour. An aria-label on an element that still cannot be reached by keyboard does not help anyone; it can make things worse by promising assistive technology support that the component does not deliver.
- Treating accessibility as a design-only concern. Contrast and typography choices matter, but the largest defects are usually in interaction logic: focus not moving into a modal when it opens, focus trapped or lost when it closes, live regions that never announce state changes.
- No accessibility statement. Publishing a short, honest statement of the current conformance level and known gaps is itself a reasonable adjustment, and it is far better evidence of good faith than silence if a complaint ever arrives.
If you cannot fix everything before launch
Full AA conformance across a large site is a programme of work, not a sprint. If the choice is between delaying launch indefinitely and shipping with a prioritised backlog, prioritise by impact and reversibility. Fix what blocks a task outright before fixing what merely degrades the experience, and fix what is expensive to retrofit before fixing what is cheap to adjust later.
A missing skip link is an inconvenience. A checkout form that cannot be submitted without a mouse is a barrier to the core service. They are not the same priority, even though both appear on the same audit report.
A decision checklist
- Can every core task, such as sign up, search, checkout, and contact, be completed using only a keyboard?
- Has the component library, not just the page templates, been checked against WCAG 2.2 AA, since defects there propagate everywhere?
- Has someone tested with an actual screen reader, not only an automated scanner?
- Is there a published accessibility statement describing current conformance and known gaps?
- If gaps remain, are they prioritised by how badly they block a task, not by how easy they are to fix?
If the answer to the first two questions is no, that is where an engineering review should start, before the next feature gets built on the same foundation.