Website Accessibility for UK Businesses: WCAG 2.2 in Plain English

95% of websites fail basic accessibility. Is yours one of them?

The WebAIM Million is an annual audit of the top one million website homepages. The 2025 report found that 95.9% of them had detectable accessibility errors. Not exotic, edge-case problems either. The average homepage had 56 distinct failures against the Web Content Accessibility Guidelines.

Most of those failures come down to the same handful of issues repeated over and over. Missing text alternatives for images. Poor colour contrast. Forms that screen readers cannot interpret. Links and buttons you cannot operate from a keyboard.

I have spent years as a sysadmin and DevOps engineer, so I have seen first-hand how these things get deprioritised. Accessibility gets filed under "nice to have" until something forces the conversation. The problem is that by the time something forces it, you are already on the back foot.

This post explains what WCAG 2.2 is, what UK law actually says, and what you should fix first. No jargon, no fearmongering. Just what a small business owner needs to know.

What is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines. Version 2.2 is the current standard, published in October 2023 by the W3C, the body that governs web standards.

WCAG is a set of testable criteria for making websites usable by people with disabilities. That includes people who are blind or have low vision, people with motor impairments who cannot use a mouse, people with cognitive disabilities, and people who are deaf or hard of hearing.

The guidelines are organised around four principles, each covering a different aspect of the user experience. I will come back to those in a moment.

One thing to understand up front: WCAG is a technical standard, not a law. No UK statute says "thou shalt comply with WCAG 2.2." But WCAG is the standard that courts, regulators, and accessibility professionals all reference when deciding whether a website is accessible. So in practice, it is the benchmark you are measured against.

The four WCAG principles, in plain English

WCAG is built on four principles with the handy acronym POUR. Every guideline and success criterion falls under one of these.

Perceivable

People need to be able to perceive your content. That sounds obvious, but it has specific implications. If you have an image that conveys information, someone who cannot see that image needs a text alternative. If you have a video, someone who cannot hear it needs captions. If your text is light grey on a white background, someone with low vision may not be able to read it at all.

Perceivable means the information is presented in ways that users can actually take in, regardless of which senses they rely on.

Operable

People need to be able to operate your site. Not everyone uses a mouse. Some people navigate with a keyboard alone, using Tab to move between links and buttons and Enter to activate them. Some use speech recognition software. Some use switch devices that work with a single button.

If your navigation menu only opens on a mouse hover, keyboard users are stuck. If your form fields cannot be reached by tabbing through them, keyboard users cannot fill them in. Operable means the interface works regardless of how someone interacts with it.

Understandable

Content and interface must be understandable. That means writing in plain language where possible, keeping form inputs predictable, and not designing interactions that confuse people.

If a form submits without warning when a user tabs out of a field, that is an understandability failure. If error messages do not explain what went wrong ("Invalid input" with no further detail), that is an understandability failure. If your site's navigation layout changes between pages without reason, that confuses people with cognitive disabilities.

Robust

Content must be robust enough to work with the tools people actually use. Some users rely on assistive technologies like screen readers, screen magnifiers, or voice control software. These tools read the underlying code of your site, not just what is visible on screen.

If your HTML is sloppy, if interactive elements are built from generic <div> tags instead of proper buttons, or if custom widgets do not follow established patterns, assistive technology may not be able to make sense of it. Robust means your site is built to a standard that these tools can reliably interpret.

The three compliance levels

WCAG criteria are grouped into three conformance levels: A, AA, and AAA. Each level builds on the one before it.

Level A: the bare minimum

Level A is the lowest tier. It covers things like having text alternatives for images, making sure you can navigate by keyboard, and not building content that flashes in a way that could trigger seizures.

Failing Level A means your site is effectively unusable for some disabled users. Most well-built sites pass most Level A criteria without trying. But the WebAIM Million shows that even Level A failures are common, with missing alt text and empty buttons topping the list.

Level AA: the standard target

Level AA is the level that UK accessibility regulations reference. It is the level most organisations aim for. It includes everything in Level A plus requirements like:

• Colour contrast ratios of at least 4.5:1 for normal text
• Resizable text that still works when zoomed to 200%
• Visible focus indicators so keyboard users can see where they are
• Consistent navigation across pages
• Error prevention for forms that submit legal or financial commitments

If you are going to aim for one level, make it AA. It is what the public sector is required to meet, what most accessibility statements reference, and what most audits will check against.

Level AAA: the highest tier

Level AAA is the most demanding level. It includes requirements like sign language interpretation for video content, enhanced colour contrast ratios of 7:1, and the ability to reflow content into a single column without horizontal scrolling.

Here is the thing: W3C explicitly states that AAA conformance is not a general requirement because not all content can meet every AAA criterion. A news site with video interviews, for instance, cannot realistically provide sign language for every single video. AAA is something you aim for on specific pages or for specific content types, not across a whole site.

For most small businesses, AA is the realistic target. AAA is worth knowing about but not something to lose sleep over.

What UK law actually says

This is where a lot of blog posts start fearmongering. I want to be honest about what the law requires and what it does not.

The Equality Act 2010

The Equality Act 2010 is the primary piece of anti-discrimination legislation in the UK. It requires that providers of goods, services, and facilities make "reasonable adjustments" for disabled people. That includes businesses providing services through a website.

The key word is "reasonable." The Act does not specify WCAG by name. It does not say you must hit Level AA. It says you must not place a disabled person at a substantial disadvantage compared to a non-disabled person, and you must take reasonable steps to remove that disadvantage.

In practice, if someone cannot use your website because it lacks basic accessibility, and you have done nothing about it, you could face a discrimination claim. But the Act also recognises that what is reasonable depends on the size and resources of the organisation. A multinational retailer is held to a different standard than a sole trader with a five-page brochure site.

The Public Sector Bodies Accessibility Regulations 2018

These regulations are more specific. They require public sector bodies, including government departments, councils, universities, and some other organisations, to make their websites and mobile apps accessible. They explicitly reference WCAG 2.1 Level AA (now updated to 2.2 AA) as the standard.

If you run a private business, these regulations do not apply to you directly. But they matter for two reasons. First, they establish WCAG AA as the de facto UK standard. Second, they have pushed the public sector to improve, which sets expectations that private sector sites will follow.

The honest reality for private businesses

Here is what I want to be straight with you about.

There is no UK law that says "private businesses must comply with WCAG 2.2 Level AA." The Equality Act creates a general obligation not to discriminate, but it does not mandate a specific technical standard. Enforcement against private businesses for website accessibility is rare. There have been some high-profile cases, but they tend to involve large organisations, not small businesses.

So the legal risk for a typical small business is low in practical terms. But that does not mean you should ignore accessibility. Here is why I think you should care anyway.

Why accessibility matters beyond the law

Legal compliance is the floor, not the ceiling. There are practical reasons to make your site accessible that have nothing to do with avoiding lawsuits.

First, accessibility overlaps heavily with good UX and SEO. Many WCAG criteria are also things that improve your site for everyone and that search engines reward. Descriptive headings, meaningful link text, fast-loading pages, and mobile-friendly layouts all show up in both accessibility guidelines and Google's ranking factors. I cover some of these overlaps in my post on common website mistakes businesses make.

Second, you are excluding customers. There are over 16 million disabled people in the UK according to Scope. If your site is unusable for a portion of them, that is real money left on the table. The Click-Away Pound report estimated that businesses lose billions in revenue from disabled customers abandoning inaccessible sites.

Third, accessibility improves your site's technical health. Many of the same issues that fail accessibility checks also drag down your performance scores. Poor contrast, missing labels, and unstructured content are accessibility problems, but they also show up in audits like Lighthouse. I explain how that scoring works in my guide to what is a good Lighthouse score.

The five most common accessibility failures

The WebAIM Million 2025 report breaks down the most common failure types. Here are the five I see most often, with plain English explanations.

1. Missing or poor alt text

Alt text is a short text description attached to an image. If the image does not load, or if a user is reading your site with a screen reader, the alt text is what they get instead.

The most common failure is simply having no alt text at all. The second most common is alt text that is useless, like "image.jpg" or "DSC_0042."

Good alt text describes the purpose of the image. If you have a product photo, the alt text should name the product. If the image is purely decorative, like a background pattern, it should have empty alt text (alt="") so screen readers skip it rather than reading a filename aloud.

2. Low colour contrast

This one is everywhere. Light grey text on a white background. Pale blue links on a light grey panel. It looks clean and modern to a designer with perfect vision. To someone with low vision or colour blindness, it may be unreadable.

WCAG AA requires a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text. That is a specific, measurable threshold. You do not need to guess at it. Browser developer tools and free contrast checkers will tell you the exact ratio.

I see this failure on sites built by professional agencies. It is not a small business exclusive problem. But it is one of the easiest things to fix.

3. No keyboard navigation

Try this: unplug your mouse and navigate your own website using only the Tab key. Can you reach every link and button? Can you open your menus? Can you fill in and submit your contact form?

If the answer is no, your site fails a Level A criterion. Keyboard-only navigation is a baseline requirement. People with motor impairments, repetitive strain injuries, or visual impairments often cannot use a mouse. They depend on keyboard access.

Common failures include dropdown menus that only open on mouse hover, custom widgets that are not reachable by Tab, and focus indicators that have been stripped out by CSS, leaving keyboard users with no idea where they are on the page.

4. Tiny tap targets

On mobile, buttons and links need to be large enough to tap accurately. WCAG 2.2 introduced a new criterion (2.5.8 Target Size, Minimum) requiring that tap targets be at least 24 by 24 CSS pixels, unless they are inline links within text.

Tiny tap targets are a problem for everyone, not just disabled users. Anyone who has tried to tap a small "X" to close a popup on a phone knows the frustration. For someone with a motor impairment or a tremor, it can make the site effectively unusable.

5. Forms without labels

A form field that says "Name" as placeholder text inside the input box looks fine to a sighted user. But screen readers often do not read placeholder text as a label. So a blind user tabbing through your form hears "edit text, edit text, edit text" with no indication of what each field is for.

Every form input needs a proper <label> element associated with it. This is a Level A requirement. It is also one of the simplest things to fix in your code, but it is consistently in the top failure list because many form builders and CMS plugins do not do it by default.

What to fix first: a practical checklist

If you have read this far and are wondering where to start, here is a prioritised list. I have ordered these by impact and ease of fixing.

1. Run an automated audit. This will not catch everything, but it will surface the obvious problems. Tools like WAVE, Axe, or Lighthouse will flag missing alt text, contrast failures, and missing form labels. You can run a free audit at wltech.pro that checks your site against these criteria.

2. Fix your alt text. Go through your pages and add descriptive alt text to every meaningful image. Set empty alt text (alt="") on decorative images. This is low effort and high impact.

3. Check your colour contrast. Use a contrast checker on your body text, headings, and links. If any are below 4.5:1, darken the text or lighten the background until they pass. This is usually a quick CSS change.

4. Test keyboard navigation. Put your mouse aside and Tab through your site. If you get stuck anywhere, that is a failure. Make sure every interactive element is reachable and operable from the keyboard.

5. Add proper labels to forms. Check that every input has a <label> element. If your CMS or form builder does not support this, consider switching to one that does.

6. Increase tap target sizes. Review your mobile layout. Make sure buttons and links have at least 24px of tappable space. Add padding if needed.

7. Write an accessibility statement. Even a short one. Acknowledge that you are working towards WCAG 2.2 AA, list what you have done, and provide a contact method for people who have trouble using your site. This shows good faith and gives people a way to raise issues with you directly rather than going straight to a complaint.

The bottom line

Website accessibility is not glamorous. It is not the thing most business owners think about when they commission a website. But 95% of sites are failing basic checks, which means most of your competitors are probably failing too. Fixing your accessibility is a genuine opportunity to serve more customers and improve your site at the same time.

You do not need to do everything at once. Start with the checklist above. Fix the obvious problems. Then iterate. Accessibility is not a one-time project, it is an ongoing practice of building and maintaining a site that works for everyone.

If you want to know exactly where your site stands, run a free audit at wltech.pro. I will check your site against WCAG criteria and give you a plain English report of what needs fixing and why.