Is your website accessible? A plain English WCAG 2.2 checklist

If you are asking "is my website accessible?", the honest answer is that you can find most serious failures yourself in about ten minutes, and no automated checker or overlay widget will find them for you. WCAG 2.2 is the current standard, the Equality Act 2010 is the legal backdrop in the UK, and the failures that cause real trouble are usually plain to see once you know where to look.

I run operations at Varsuite, where AI agents build and test websites and a human team perfects every detail before it ships. Accessibility sits in both halves of that sentence. Machines catch a lot quickly. People catch the rest.

Can I check my own site without any tools?

Yes, and you should start here. Open your homepage, then your main service or product page, and try the following.

Tab through the page using only your keyboard. Every link, button, form field and menu item should show a clear visible focus outline and follow a sensible order. If the focus disappears, or jumps around the page, keyboard and screen reader users are effectively locked out.

Turn the sound off and watch your homepage video. If it carries meaning and has no captions, that is a fail. If it plays automatically with sound, that is another.

Zoom the browser to 200 percent. Text should reflow without horizontal scrolling and without content overlapping or vanishing behind other elements.

Squint at your text. Light grey body copy on white, or white text on a pale brand colour, is the single most common contrast failure I see. Body text needs strong contrast against its background, and placeholder text inside form fields counts too.

Unplug the mouse and try to submit your contact form with the keyboard alone. Check that every field has a visible label, not just a placeholder that disappears the moment someone starts typing.

Finally, look at your images. If a product photo, icon or chart carries meaning, it needs a text alternative that says what it shows. If it is purely decorative, it should be ignored by assistive technology rather than read out as a file name.

That list takes minutes and covers a large share of the failures that reach complaints, procurement questionnaires and legal letters.

Why is an automated checker not enough?

Automated tools are genuinely useful. They scan fast, they catch missing alt attributes, poor contrast ratios, empty links and obvious structural errors, and we run them continuously on every build. What they cannot do is judge meaning. A tool cannot tell whether an alt attribute actually describes the image, whether a heading order makes sense to a reader, or whether an error message explains how to fix the problem.

Industry testing consistently finds that automation catches only a minority of real WCAG issues. The rest require a person to read the page, use the page and understand the intent behind it. That is why our work pairs machine scanning with human review rather than replacing one with the other. You can read more about how we approach accessibility audits if you want the full method.

Do accessibility overlays actually work?

No, and I would avoid them. An overlay is a script that sits on top of your site and attempts to fix accessibility in the browser. It does not change your underlying HTML, so the problems remain for anyone using a screen reader, voice control or a switch device. Worse, overlays frequently interfere with the assistive technology people already use, and they have featured in legal cases rather than preventing them.

The only reliable fix is to correct the source. That means proper semantic markup, sensible heading structure, labelled forms, real focus states and tested components.

What does WCAG 2.2 actually ask for?

WCAG 2.2 is built on four principles. Content must be perceivable, operable, understandable and robust. In practice, for a typical business site, the priorities are:

Text alternatives for meaningful images and media. Captions and transcripts for audio and video. Strong colour contrast throughout. Full keyboard operability with a visible focus indicator. Clear, consistent navigation and page structure. Labelled form fields with helpful, specific error messages. Text that survives zoom and reflow. Consistent help mechanisms, such as contact details, in the same place across pages. No cognitive tests such as puzzles or memory tasks used to log in, unless an accessible alternative exists.

If you meet those, you are already ahead of most sites in your sector.

How does Varsuite handle accessibility?

We treat accessibility as part of production, not a bolt on afterwards. When our AI agents build a site or system, accessibility rules are part of the specification, and automated checks run on every change. Our human team then tests with a keyboard, a screen reader and zoom, because those are the conditions your customers actually use.

We also audit sites we did not build. A review typically produces a prioritised list: what is broken, what it costs you in risk, and what to fix first. Most issues are quick to resolve once they are named. The websites we build ship with accessible patterns as standard, and our testing and QA service keeps them that way as you add pages and features.

Why does this matter commercially? Because around one in five people in the UK has a disability or long term health condition. Accessible sites are simply easier for everyone to use, they rank better because search engines reward clean structure, and they remove a quiet barrier that stops customers completing a purchase or enquiry. It is also increasingly a condition of public sector and large corporate contracts.

How often should I recheck?

Every time you change something meaningful. New templates, redesigned forms, added video, a new ecommerce checkout, a rebrand with new colours: each of those can introduce failures. Build a short accessibility pass into your release routine rather than saving it for an annual panic.

If you would rather someone else did it, our team can run the audit, fix the issues and keep watch as your site grows. Start with our services overview or get in touch and we will tell you plainly where you stand.

Frequently asked questions

Is my website legally required to be accessible in the UK?

There is no single law that says "all websites must meet WCAG". However, the Equality Act 2010 requires businesses and organisations to make reasonable adjustments so disabled people can access their services, and that includes digital services. Public sector bodies face specific accessibility regulations. In practice, the safest position is to work to WCAG 2.2 at level AA and document what you have done.

Can I just install an accessibility widget and be done?

No. Widgets and overlays change how a page looks in one browser, not how it is built. Screen reader users, keyboard users and voice control users often find them unhelpful or disruptive. Fixing your actual markup is the only approach that holds up.

How much does an accessibility fix cost?

It depends entirely on how much is broken. A focused audit with a prioritised fix list is a small piece of work. Rebuilding forms and navigation is more. Brochure websites from Varsuite start at £600 with a £100 per month care plan, online stores from £1,200 with a £150 per month care plan, and accessibility work is quoted separately once we have seen your site.

What is the quickest win I can make today?

Fix your colour contrast and add a visible keyboard focus style. Those two changes help a large number of users immediately, they take an afternoon, and they are the failures most often flagged in reviews.