Website accessibility in the UK is no longer a nice-to-have for the public sector alone. If your site is hard to use with a keyboard, a screen reader or on a small phone in bright sunlight, you are quietly turning away customers and exposing your business to legal risk. This guide explains what the Web Content Accessibility Guidelines (WCAG) actually ask of you, where UK law sits, and how to make sensible progress without boiling the ocean.
What WCAG actually means
WCAG is the international standard that defines what an accessible website looks like. The current version most teams work to is WCAG 2.2, and its requirements are grouped under four principles, often shortened to POUR.
- Perceivable — people must be able to perceive your content. Think text alternatives for images, captions for video and sufficient colour contrast.
- Operable — everything must work without a mouse. A keyboard user should be able to reach and activate every link, button and form field.
- Understandable — content and controls should behave predictably, with clear labels and helpful error messages.
- Robust — the underlying code should be clean enough for assistive technology, such as screen readers, to interpret reliably.
Conformance levels: A, AA and AAA
WCAG defines three tiers. Level A is the bare minimum, Level AAA is the gold standard that few sites meet in full, and Level AA is the sweet spot that most organisations and regulators treat as the real target. When someone says "we need to be WCAG compliant", they almost always mean WCAG 2.2 AA.
The UK legal context
Two strands of law and regulation matter here, and it is worth being honest about both.
The Equality Act 2010
The Equality Act applies to almost every business that provides goods or services to the public. It requires "reasonable adjustments" so that disabled people are not put at a substantial disadvantage. A website that a blind or partially sighted customer cannot use to buy from you, or book with you, can fall foul of this. The Act does not name WCAG explicitly, but in practice WCAG 2.2 AA is the recognised benchmark for what "reasonable" looks like online.
The public sector regulations
If you work with, or are, a public sector body, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 are stricter still. They mandate WCAG 2.2 AA and require a published accessibility statement. Even if you are a private SME, expect public sector clients to ask whether your product meets this bar before they buy.
The honest position: most UK SMEs are not going to be sued tomorrow, but accessibility failures are a slow, compounding liability — and a genuine commercial leak.
Why accessibility is good business, not just compliance
It is easy to frame accessibility as a box-ticking chore. We would rather you saw it as one of the highest-return improvements you can make to a website.
- A bigger audience. A significant share of UK adults have a disability of some kind, and many more have temporary or situational limitations — a broken arm, a noisy train, a cracked screen. Accessible design serves all of them.
- Better SEO. The discipline behind accessibility — semantic HTML, descriptive link text, alt attributes, logical heading order — is the same discipline that search engines reward. Accessible sites tend to be more crawlable.
- Cleaner code and easier maintenance. Sites built accessibly are usually built well, which makes them cheaper to extend later.
- Stronger brand trust. An accessible site signals that you take all of your customers seriously.
Where to start: a practical first pass
You do not need to fix everything at once. A focused first pass usually clears the most damaging issues quickly.
Quick wins you can check today
- Colour contrast. Run your brand colours through a contrast checker. Pale grey text on white is the single most common failure we see.
- Keyboard navigation. Put your mouse away and try to use your homepage and a key form using only the Tab, Enter and arrow keys. If you get stuck, so do your users.
- Image alt text. Every meaningful image needs a short, descriptive alternative. Decorative images should have empty alt text so screen readers skip them.
- Form labels. Every input needs a properly associated label, not just placeholder text that vanishes when you start typing.
- Headings. Use one logical heading structure per page rather than choosing heading sizes for visual effect.
Where it gets specialist
Dynamic components — modals, custom dropdowns, carousels, drag-and-drop, single-page app routing — are where accessibility gets genuinely technical, often requiring ARIA roles and careful focus management. This is the point at which a thoughtful build or a proper audit pays for itself. Our web design and development service bakes WCAG 2.2 AA in from the wireframe stage rather than bolting it on at the end, which is always cheaper than retrofitting.
A word on testing
Automated tools are a useful first sweep, but they only catch a fraction of the issues that matter. Plenty of failures are invisible to a scanner: alt text that is technically present but meaningless, a focus order that jumps around the page illogically, or a colour combination that passes a contrast check yet is still hard to read for someone with a visual impairment. Real accessibility testing combines automated scans with manual checks — navigating by keyboard, listening to the page with a screen reader, and zooming to 200 per cent to see whether the layout holds together. There is no substitute for actually trying to use the thing the way a disabled person would.
Common failures we see again and again
Across the audits we run, the same handful of problems crop up repeatedly. Carousels that auto-advance and cannot be paused. PDFs uploaded as scanned images with no readable text underneath. "Click here" links that tell a screen reader user nothing about where they lead. Forms that flag an error in red with no text explanation, which is useless to anyone who cannot perceive colour. Video embedded without captions. None of these are exotic edge cases — they are everyday oversights, and every one of them is straightforward to put right once you know to look for it.
Writing an accessibility statement
Once you have done the work, it is worth publishing an accessibility statement — a short page explaining how accessible your site is, which standard you aim for, any known limitations, and how someone can get help or report a problem. For public sector bodies this is a legal requirement, but for private businesses it is simply good practice. It demonstrates intent, gives disabled users a clear route to ask for an alternative, and shows that you take the matter seriously rather than hoping nobody notices. An honest statement that admits a couple of known issues is far better than silence or empty claims of full compliance.
Keeping a site accessible over time
Accessibility is not a one-off project. Every new page, blog post, PDF and third-party widget can introduce regressions. The practical answer is a light, repeatable routine: a checklist for content authors, automated checks in your build pipeline, and a periodic manual review. It also helps to train whoever adds content — a marketing assistant who learns to write good alt text and descriptive links protects your compliance far more reliably than any tool. Ongoing website support and maintenance is the cheapest way to stop a compliant site quietly drifting out of compliance as your team adds content.
Conclusion: small steps, real impact
Improving website accessibility in the UK is not about chasing a perfect AAA score overnight. It is about removing the avoidable barriers that cost you customers and expose you to risk — contrast, keyboard access, alt text, labels — and then building a habit that keeps things that way. If you are not sure where your site stands, we are happy to take a look and tell you plainly. Have a word with us about our design and support services, and we will give you an honest read on what is worth fixing first.