Start your 7-day free trial, card not charged until it ends

Accessibility

Website Accessibility Monitoring: WCAG 2.2 in Plain English and Why Audits Go Stale

· 9 min read

An accessibility audit is a photograph of a moving object. What WCAG 2.2 asks in plain English, where the law stands, and how monitoring stops the quiet regressions.

By the TLDTrack team, part of FullyCoded, a working UK web agency.

Accessibility is usually handled as a project. An audit is commissioned, a report lands, the worst findings get fixed, and the site is declared accessible, in the past tense, as of a date. Then the site carries on changing: new pages, new images, a theme update, a brand refresh, a hurried campaign landing page. Every one of those edits can quietly reintroduce exactly the barriers the audit removed, and nobody is looking any more, because accessibility was "done".

For the people affected, screen-reader users, keyboard-only users, people with low vision or colour-blindness, people who find cluttered interfaces hard to parse, the site is only as accessible as it is today, not as it was on audit day. This guide covers what WCAG 2.2 actually asks in plain English, where the law stands, why one-off audits decay, and what continuous accessibility monitoring can honestly do about it.

What WCAG 2.2 AA asks, in plain English

The Web Content Accessibility Guidelines organise everything under four principles. Level AA is the target that laws, contracts and procurement teams reference, and in practice it asks for things like:

  • Perceivable. Images carry meaningful alternative text; text has enough contrast against its background; content survives being zoomed or reflowed on a small screen; video has captions.
  • Operable. Everything works with a keyboard alone, with a visible focus indicator showing where you are; nothing traps the keyboard; targets are big enough to hit; users get enough time.
  • Understandable. Form fields are properly labelled; error messages say what went wrong and how to fix it; navigation stays consistent; logging in does not require a cognitive puzzle like transcribing distorted text.
  • Robust. The underlying markup is sound enough that assistive technology can parse it: real buttons, real headings, real landmarks, not styled lookalikes.

WCAG 2.2, current since late 2023, added nine criteria to 2.1, mostly around focus visibility, target size, dragging alternatives and accessible authentication. If your last audit was against 2.1, the gap is modest but real.

Where the law stands

In the UK, the Equality Act 2010 requires service providers to make reasonable adjustments so disabled people are not at a substantial disadvantage, and websites count as services. The Act never names WCAG, but WCAG AA is the benchmark used in practice when disputes arise. UK public-sector sites are under explicit regulations requiring accessibility and a published statement. In the EU, the European Accessibility Act has applied to most consumer-facing digital services, e-commerce included, since June 2025, and it reaches businesses selling into the EU from outside it. In the US, ADA claims against inaccessible websites are routine enough to be an industry. And beneath all of it sits the commercial layer: tenders and enterprise procurement increasingly ask for your conformance status in writing.

Why the audit you paid for goes stale

An audit is a snapshot of the site the auditor tested. The site your visitors use is the one your team has edited every week since. Content churn adds images without alt text and PDFs nobody checks. A theme or plugin update swaps a compliant component for a broken one. A brand refresh changes every colour on the site, and contrast that passed by a comfortable margin now fails by a hair, everywhere at once. Campaign pages ship in a hurry with a designer's contrast and a developer's deadline.

It is the same drift problem we describe for legal teams: approval happens once, publishing happens continuously, and the gap between them is where the risk lives. The audit is not wasted, it sets the baseline, but a baseline without monitoring is a photograph of a moving object.

What automated checks can and cannot do

Honesty matters here, because the accessibility field has a vendor problem. Automated rule engines (the axe-core family and its relatives) are genuinely good at the mechanical failures: missing alternative text, insufficient contrast, unlabelled form fields, broken heading and landmark structure, missing document language, duplicate IDs that confuse assistive tech. These are objective, testable, and a large share of the barriers real users hit.

What rules cannot judge is quality and sense: whether the alt text means anything, whether the reading order is coherent, whether the error message actually helps, whether a custom widget behaves the way its ARIA roles promise. TLDTrack layers an AI judgement pass over the rule engine to cover part of that contextual ground, flagging alt text that describes nothing and link text that says "click here" into the void, but the honest position is that a full conformance claim still needs a human with assistive technology in the loop. The right mental model: automation for coverage and regressions, humans for judgement, monitoring so the humans review a short queue instead of rediscovering the site.

Making it continuous

  • Scan the whole site for a baseline, then fix the blockers first: keyboard traps, contrast failures, unlabelled forms, the things that stop a visit dead.
  • Re-scan weekly and alert on new issues only. The trend matters more than the raw count, and new-issue alerting keeps the queue short and the team listening.
  • Watch the templates. Most sites render thousands of pages from a handful of templates, so one template fix clears hundreds of instances, and one template regression creates them. Template-level alerts are the highest-leverage rule you can set.
  • Publish an accessibility statement with a feedback route, and treat what comes in as monitoring you did not have to build.

Where this fits

TLDTrack's accessibility scanning runs axe-core rules plus the AI judgement pass against WCAG 2.2 AA, on a weekly cycle, with alerts when new issues appear, so the audit you paid for stays true between audits. It sits in the same monitoring stack as the compliance checks, content and visual monitoring, one more layer from the complete monitoring guide. Accessibility drift is invisible to the people who built the page and vivid to the people it excludes; monitoring is how you keep standing in the second group's shoes after the audit team has gone home.

01 · Questions

Frequently asked questions

Are accessibility overlay widgets enough to make my site compliant?

No. Overlays bolt a toolbar on top of the page without fixing the underlying markup, so most barriers remain for people using real assistive technology, and some overlays actively interfere with it. Legal exposure has continued for sites relying on them. The dependable route is the unglamorous one: fix the site itself, then monitor so it stays fixed.

What is the difference between WCAG levels A, AA and AAA?

A is the floor: failures at level A tend to make content unusable for someone. AA is the standard target, the level referenced by UK public-sector regulations, the European Accessibility Act's underlying standards and most contracts, covering things like contrast, focus visibility and labelled forms. AAA is aspirational for most sites and not usually demanded in full. When someone says "WCAG compliant" without qualification, they almost always mean 2.2 AA.

Can automated testing make my site fully compliant on its own?

No, and be wary of anything that claims otherwise. Automated rules reliably catch the mechanical failures, missing alt text, contrast, unlabelled fields, broken structure, and an AI layer can judge some contextual quality on top. But a genuine conformance claim still needs a human with assistive technology. The honest division of labour: automation for coverage and catching regressions weekly, humans for judgement, so your audits confirm a monitored state rather than rediscover the site.
Mark Grice, founder of TLDTrack

Mark Grice, founder of TLDTrack. Runs FullyCoded, a Cornwall web agency, and built this to keep 500+ client sites in front of him every day.

What happens next

Put this on autopilot

Do it yourself

Start your free trial

TLDTrack runs every check in this guide automatically across all your client sites and alerts you the moment something changes. Your card is not charged for 7 days.

Start your free trial

Talk it through

Arrange a call with Mark

If you would rather talk through how this works across every site you look after, we can go through it together.

Book a call

See every check TLDTrack runs