Who the rules actually apply to
Three separate regimes matter for UK organisations, and they overlap. The Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and that duty is anticipatory — you are expected to have thought about access before a disabled customer arrives, not to fix things once someone complains. It applies to almost any business providing goods or services to the public, and it has no exemption for small companies.
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 are much more specific. Public sector organisations must meet WCAG 2.2 AA and publish an accessibility statement. If you sell software to councils, the NHS, universities, or central government, this lands on you through procurement even though you are not a public body yourself.
The European Accessibility Act applied from 28 June 2025 and covers a defined list of products and services including e-commerce, consumer banking, e-books, and transport services. Brexit did not remove it from the picture: if you sell into the EU market, you can be in scope regardless of where the company is registered.
What WCAG 2.2 AA actually requires
WCAG organises requirements under four principles: content must be perceivable, operable, understandable, and robust. AA is the level everyone means when they say "WCAG compliant" — A is too minimal to satisfy the regulations and AAA is not expected across a whole site.
WCAG 2.2 added criteria that catch patterns which were common in modern web apps. Focus Not Obscured means a sticky header or cookie banner must not hide the element a keyboard user has tabbed to. Target Size sets a 24 by 24 CSS pixel minimum for most interactive controls. Dragging Movements requires a non-drag alternative for anything you can drag. Accessible Authentication rules out cognitive function tests such as transcribing a code from memory unless an alternative exists. Consistent Help and Redundant Entry deal with support links moving around and forms asking for the same information twice.
None of these are exotic. They are the things a design system gets right once and then stops getting wrong.
What it costs
| Scope | Typical cost | Timeline |
|---|---|---|
| Automated scan plus manual spot check, brochure site | £1,500 – £4,000 | 1–2 weeks |
| Full WCAG 2.2 AA audit, web application | £5,000 – £12,000 | 2–4 weeks |
| Audit plus remediation, mid-size application | £15,000 – £45,000 | 6–12 weeks |
| Design system rebuild with accessibility built in | £30,000 – £80,000+ | 3–6 months |
Automated tools find roughly a third of issues. They are good at colour contrast, missing alternative text, and malformed ARIA, and useless at whether your alternative text is meaningful or your tab order makes sense. Any audit priced as a tool run and a PDF export is not an audit. Budget for manual keyboard testing and screen reader testing on at least one combination of NVDA or JAWS on Windows and VoiceOver on macOS or iOS.
The failures we find most often
Issues that show up in almost every first audit:
<label>, so screen readers announce the field as unlabelled<div> elements with no keyboard handling and no ARIA rolesEvery one of these is a fifteen-minute fix during development and a multi-day regression exercise once it is spread across forty templates.
Running this as a programme, not a project
Start with an audit against WCAG 2.2 AA that produces a prioritised list, not a raw scanner dump. Fix the blockers first: anything that makes a task impossible rather than awkward. Then publish an accessibility statement that honestly records what conforms, what does not, and when you expect to fix it. A statement admitting known gaps with a remediation date is treated far better than silence or an unsupported claim of full compliance.
The part teams skip is regression prevention. Add automated accessibility checks to CI so contrast and labelling failures break the build, add keyboard navigation to your manual test script, and put accessibility acceptance criteria into ticket templates. Without that, the site drifts back out of conformance within two release cycles and you pay for the same audit again next year.
AyTech note: Accessibility law is fact-specific and this guide is general information, not legal advice. If you are responding to a complaint, a procurement requirement, or an enforcement notice, take advice from a solicitor who works in this area.
Need a practical technical plan?
AyTech can review your requirements, map the risks, and turn the idea into a scoped delivery plan.
Web application services