Cloud 9 Creative

Website accessibility guidelines: WCAG 2.2 testing for UK teams

by | Sep 18, 2026 | AI

Hands testing website accessibility with keyboard

Website accessibility guidelines are defined by WCAG, the W3C’s Web Content Accessibility Guidelines, built around four principles: perceivable, operable, understandable and robust. Meeting them means testing with both automated tools and manual checks, then publishing an accessibility statement that tells users what you’ve done and what’s still outstanding. Skip any one of those three, and compliance is theoretical rather than real.

TL;DR:

  • Most fixes, like improving contrast and adding alt text, can be completed within a week to address high-priority accessibility issues.
  • Automated testing tools identify only about half of real accessibility problems, so manual testing with screen readers and keyboard navigation remains essential.
  • Public sector websites in the UK must meet WCAG 2.2 AA standards and publish an accessibility statement, but private companies also benefit from following WCAG for legal safety.
  • Building accessibility into design and development workflows from the start reduces costs and rework compared to retrofitting after launch.
  • Ongoing testing, monitoring, and scheduling regular audits are necessary for maintaining compliance as new content and technologies change.
Cloud9
Make Your Website More Accessible
Cloud9 brings website design and ongoing digital support together, helping established businesses build clearer, more usable online experiences.

Explore Cloud9

Table of Contents

What does website accessibility guidelines mean under WCAG?

WCAG sorts every guideline under one of four principles, and each principle solves a different kind of exclusion.

  • Perceivable means people can actually take in the content, whatever their senses allow. A video without captions fails this instantly for anyone who’s deaf or in a quiet office watching without sound.
  • Operable means every function works without a mouse. Someone using only a keyboard or a switch device needs to reach every link, button and form field.
  • Understandable means content and behaviour are predictable. Error messages that just say “invalid input” fail this; ones that name the field and the fix pass.
  • Robust means the code works reliably across browsers, devices and assistive technology, now and as those technologies change.

Each guideline carries testable success criteria at three conformance levels: A (minimum), AA (the level most organisations target) and AAA (the highest, rarely mandated in full). WCAG 2.2 is the current-recommended reference, and every 2.x version is backwards compatible, so work done against WCAG 2.0 or 2.1 still counts towards 2.2 conformance.

How do WCAG 2.2, EN 301 549 and WCAG-EM fit together?

WCAG itself has moved through several versions since 2.0 launched in 2008, adding criteria for mobile interaction, cognitive load and, in 2.2, target size and focus visibility. Nothing gets removed between versions, only added, which is why a site built to 2.1 doesn’t need a rebuild to claim 2.2 conformance.

  • WCAG 2.0/2.1/2.2: successive layers of the same standard, each backwards compatible with the last.
  • EN 301 549: the European standard for ICT accessibility, used heavily in public procurement, and it references WCAG directly for its web content requirements rather than reinventing them.
  • WCAG-EM: the WCAG Evaluation Methodology, a formal process for auditing a whole site rather than a single page, used when a procurement process or legal audit demands documented proof.

If you’re bidding for public sector work or need a defensible conformance statement, WCAG-EM is the framework to reach for. For everyday development, the checklist below matters more.

What’s on a practical accessibility checklist?

Fixing accessibility issues works better as a triage exercise than a single overhaul. Some fixes take minutes; others need a design system change.

  1. Perceivable: write meaningful alt text for every image, caption every video, keep text contrast at 4.5:1 minimum for body copy, and let text reflow and resize without breaking layout.
  2. Operable: make sure every interactive element is reachable by keyboard alone, keep a visible focus indicator on the active element, add a skip link past repeated navigation, and avoid session timeouts that cut users off mid task.
  3. Understandable: label every form field explicitly, tie error messages to the specific field and the specific problem, and keep navigation patterns consistent across pages.
  4. Robust: build with semantic HTML first, whether that’s a <button> instead of a styled <div>, or a proper <nav> instead of a generic wrapper. Reach for WAI-ARIA only when native HTML genuinely can’t express the pattern, and test the result with a real screen reader, not just an automated pass.

Prioritise in three tiers: quick wins (alt text, contrast, labels) you can fix this week, medium-term fixes (keyboard traps, focus order) that need a sprint, and architectural changes (a component library rebuilt around semantic markup) that belong on a roadmap rather than a hotfix.

Pro Tip: Fix contrast and keyboard access before anything else. Both affect every page on the site, and both are usually the fastest wins on the list.

Illustration of contrast and keyboard access checks

How do you test a website for accessibility?

No single tool catches everything, which is why a testing routine, not a one-off scan, is the goal.

Automated scanners are fast and consistent, but they typically catch only 30 to 50% of real accessibility issues because they can’t judge whether an interaction actually makes sense to a person using it. That’s a limitation worth planning around rather than a reason to skip automated tools altogether.

  • Automated: run Lighthouse, Axe DevTools or WAVE on every page template, not just the homepage.
  • Manual: complete key journeys (checkout, sign up, contact form) using only a keyboard, then again with a screen reader such as NVDA or VoiceOver.
  • Chrome DevTools: its accessibility panel exposes the accessibility tree and flags contrast issues directly alongside the elements causing them.
  • User testing: where possible, involve people who actually use assistive technology day to day. Nothing else surfaces the same gaps.

For a formal evaluation, WCAG-EM’s five steps give you a repeatable structure: define the scope, explore the site’s page types, select a representative sample, evaluate that sample against WCAG, then report findings. A solid conformance statement documents all four, plus any known limitations still outstanding.

Do UK websites legally have to be accessible?

WCAG is a technical standard, not a law in itself, but it’s the yardstick regulators and procurement teams almost always point to. Gov recommends WCAG 2.2 AA for government services, and public sector bodies in the UK operate under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which sets out specific duties.

Whatever sector you’re in, three practical steps reduce both legal and reputational risk:

  • Publish an accessibility statement naming your conformance target and known gaps.
  • Keep a remediation plan with dates, not vague intentions.
  • Give users a clear route to report accessibility problems and get a response.

None of this substitutes for legal advice specific to your organisation, but it’s the baseline most guidance converges on.

How do you build accessibility into a project from the start?

Retrofitting accessibility after launch costs more in time and rework than designing for it from the brief onward, which is why the checkpoints below sit at each stage rather than at the end.

  1. Planning: write accessibility requirements into the brief and acceptance criteria, not as a bolt on but as a condition of sign off.
  2. Design: audit the design system’s components (buttons, forms, navigation) against WCAG once, so every page built from them inherits the fix.
  3. Development: add accessibility checks to code review, the same way you’d review for security or performance.
  4. Release: run automated checks in continuous integration so a regression fails the build, not just the audit.
  5. Maintenance: schedule manual audits and user testing on a recurring basis, since new content and features reintroduce old problems.

Assign a named owner for accessibility rather than treating it as everyone’s job and no one’s responsibility. Realistic timelines matter too. Fixing contrast across a design system is a day’s work; rebuilding a component library around semantic markup is a quarter’s.

Pro Tip: Put accessibility criteria in the same acceptance checklist as browser testing. Teams that treat it as a separate, optional step are the ones that drop it under deadline pressure.

A managed approach to WCAG compliance

Most organisations don’t lack the will to fix accessibility. They lack the joined-up capacity: someone to audit, someone to prioritise the fixes, someone to keep monitoring after launch. Cloud9 folds accessibility work into site builds, ongoing website care and mobile-first design checklists, so fixes don’t sit in a report nobody actions. A managed setup also means audits repeat on a schedule rather than once, which matters given how quickly new content reintroduces old problems.

— Rob

Get an accessibility audit built into your website care

Cloud9 replaces the usual scramble of hiring an auditor, briefing a developer and hoping the fixes actually land, with one team that does the audit, prioritises the fixes and keeps monitoring afterwards. That’s the real gap in most accessibility projects: not the audit itself, but who’s still watching three months later.

Cloud9

Through Website as a Service, accessibility checks sit alongside hosting, security and ongoing content updates rather than as a separate one-off invoice. A typical engagement starts with an audit against WCAG 2.2, moves to a prioritised fix list split into quick wins and structural changes, and continues with managed hosting and website care so new pages get checked before they cause a regression. If your site needs a fuller rebuild rather than incremental fixes, web design and development covers that too. Get in touch for an accessibility audit or a Website as a Service assessment, and find out what’s actually fixable this quarter versus what belongs on next year’s roadmap.

Sources

FAQ

Public sector websites and apps must meet WCAG 2.2 AA under the 2018 accessibility regulations, including publishing an accessibility statement. Private organisations aren’t bound by that specific instrument but face broader equality duties, so following WCAG remains the safest practical benchmark.

WCAG 2.2 itself isn’t a law, it’s a technical standard, but UK public sector regulations and GOV.UK guidance both point directly to it as the required benchmark for government services.

What are the new WCAG guidelines for 2026?

WCAG 2.2 remains the current published version and the recommended reference going into 2026; there’s no newer numbered version superseding it at this time. Because 2.x versions are backwards compatible, sites already meeting 2.1 don’t need rework to progress towards 2.2.

Do websites legally have to be accessible?

Public sector sites in the UK have specific statutory duties under the 2018 regulations. Private sector obligations are less prescriptive but still shaped by equality law, which is why most organisations treat WCAG conformance as the practical standard to meet regardless of sector.

How much does an accessibility audit cost?

Pricing depends on site size and scope, so it isn’t published as a flat rate. Current details are available directly through Cloud9’s services page.