Skip to content
Rivl
7 November 2026Performance10 min

Web accessibility compliance for business websites

Accessibility arrives as a line in a procurement questionnaire, and the honest answer is usually that nobody has checked. The standard being asked about is public, short enough to read, and more specific than the question implies.

The question almost never arrives from a user. It arrives from a buyer, as a row in a vendor questionnaire asking whether the site conforms to WCAG at Level AA, with a yes or no box next to it. The honest answer at that moment is usually that nobody has looked.

What makes this worth an hour of your time is that the standard being referenced is not vague. It is a published W3C document with numbered criteria, each tagged with a conformance level, and you can read the part that applies to you in an afternoon. The vagueness is all in the questionnaire, not in the standard.

The sections of this note in order: which version of the standard binds you, why Level AA is the line, the nine criteria WCAG 2.2 added, the criterion that was removed, where the legal exposure comes from, what to fix first, and the honest limits.
The fourth row is the one that keeps turning up as a finding in audits that should no longer report it.

Which version binds you, and what it is

The current standard is the Web Content Accessibility Guidelines 2.2, published as a W3C Recommendation dated 12 December 2024. Recommendation is the final stage on the W3C track, so this is a settled document rather than a draft, and it is the version a current questionnaire is most likely to mean.

One structural fact removes most of the confusion about versions: the document states that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and 2.1. The versions are additive. If a buyer asks for 2.1 AA and you meet 2.2 AA, you can answer yes without qualification, and if they ask for 2.2 and you only ever tested against 2.0, you have a gap that is specific and countable rather than a general worry.

Level AA is the line, and it is not a judgement call

The standard defines, in its own words, "three levels of conformance": A as the lowest, then AA, then AAA as the highest. Every success criterion carries exactly one level, and the levels nest, so AA includes everything at A.

The part people get wrong is the arithmetic. Conformance to a level is not a score or an average. It means satisfying every criterion at that level and below. One failed Level A criterion means the site does not conform at AA, no matter how much of the rest passes. That is why a report full of green rows can still end in a no, and why the useful output of an audit is a list of failures rather than a percentage.

AA is the level nearly every buyer and policy asks for. AAA is not the ambitious version of the same thing, it contains criteria the W3C itself does not expect whole sites to meet, so a questionnaire demanding AAA across a site is usually a questionnaire written by someone who has not read the standard.

The nine criteria 2.2 added

WCAG 2.2 added nine success criteria to 2.1. These are the ones a site last tested against 2.1 has never been checked for, so this table is the shortest useful version of your gap:

CriterionLevelWhat it is about
2.4.11 Focus Not Obscured (Minimum)AAThe focused element cannot be entirely hidden behind sticky headers or cookie bars
2.4.12 Focus Not Obscured (Enhanced)AAAThe stricter version of the same thing
2.4.13 Focus AppearanceAAAHow visible the focus indicator itself has to be
2.5.7 Dragging MovementsAAAnything you drag needs a single pointer alternative
2.5.8 Target Size (Minimum)AAControls need to be big enough to hit
3.2.6 Consistent HelpAHelp and contact routes appear in the same relative order across pages
3.3.7 Redundant EntryADo not make someone type the same information twice in one process
3.3.8 Accessible Authentication (Minimum)AALogin cannot depend on a cognitive test such as remembering or transcribing
3.3.9 Accessible Authentication (Enhanced)AAAThe stricter version of the login rule

Read down the Level column and the practical news is better than expected. Six of the nine are A or AA, which is the band that matters, and three of those six are about ordinary interface habits rather than assistive technology: a focus ring that a sticky header does not cover, buttons large enough to press, and not asking for the same postcode twice. The two authentication criteria are the ones most likely to need a real decision, because they bear on login flows that were designed around a security argument.

The nine success criteria WCAG 2.2 added, each with its conformance level: focus not obscured at AA and AAA, focus appearance at AAA, dragging movements at AA, target size at AA, consistent help at A, redundant entry at A, and accessible authentication at AA and AAA.
Six of the nine sit at A or AA, which is the band a buyer actually asks about.

The criterion that was removed, and why audits still report it

WCAG 2.2 removed one criterion, 4.1.1 Parsing, and marks it "Obsolete and removed". It was the rule that produced findings about duplicate IDs and unclosed tags, which is to say it produced a great deal of audit noise and not much benefit to anyone using the site.

Two things follow. If a tool hands you a 4.1.1 finding against the current standard, that tool is reporting against an older version, and this is a quick way to date an audit you have been sent. But the document is careful here, and so should you be: authors required by policy to conform to WCAG 2.0 or 2.1 may still need to test and report 4.1.1. If a contract names 2.0, the removed criterion is still live for that contract.

Where the legal exposure actually comes from

This is the part worth being accurate about, because it is where confident advice is usually wrong. WCAG is a technical standard published by an industry consortium. It is not legislation anywhere. It acquires force when a law, a regulation or a contract points at it, and what points at it depends entirely on where you sell and who you sell to.

In practice, for most businesses, the binding instrument is the contract rather than the statute. The procurement questionnaire is the enforcement mechanism you will actually meet, which is the same pattern as the compliance gates that sit in front of enterprise deals generally, described from the sales side in why the enterprise gate is further back than the meeting. An accessibility answer is a procurement artefact before it is a legal one.

W3C's own guidance on accessibility statements is the useful thing to read next, and its minimum list is short. A statement should contain a commitment to accessibility for people with disabilities, the standard applied such as WCAG 2.2, and contact information in case users encounter problems. It recommends naming your known limitations, which is the part organisations resist and the part that makes the document credible. The guidance is explicit that a statement is primarily for users of your content rather than a technical assessment, and that it should use plain language: "videos do not have captions" rather than a criterion number.

What to fix first

If you are starting from nothing, this order gets the most conformance for the least work, and it is roughly the order of how often each thing is broken.

  • Check keyboard focus against your own sticky header and cookie banner. Tab through a form and watch whether the focused field disappears under something. This is 2.4.11, it is AA, and site chrome added after launch breaks it constantly.
  • Measure your touch targets. 2.5.8 is AA and fails most often on icon-only buttons and dense table actions, both of which are cheap to pad.
  • Find every drag interaction and add a non-drag route to the same outcome. Sliders, kanban boards and map pins are the usual offenders under 2.5.7.
  • Walk your own signup and login as though you could not transcribe a code from one place to another. 3.3.8 does not ban security, it bans making the login a memory or transcription test with no alternative.
  • Write the accessibility statement last, once you know your limitations, and name them. A statement claiming full conformance that a buyer can falsify in one minute is worse than no statement.

Everything on that list is verifiable by you, with a keyboard and a browser, which puts it in the same category as the checks in a security checklist you can verify yourself. The pattern is the same one as with speed: there is a published threshold, it can be measured rather than argued about, and the argument usually continues anyway. That is the honest reading we gave the speed numbers in what Core Web Vitals actually measure, and the diagnostic order for the mobile case is in why a site is slow on mobile.

The honest limits

Three, and they are the reason this note does not end with a recommendation to buy anything.

First, automated testing finds a minority of the criteria. A large share of WCAG is about whether something makes sense to a person, and no scanner judges whether your alt text describes the image or whether your headings describe the content. A clean automated report is evidence that the machine-checkable subset passes, and it is routinely presented as more than that.

Second, this note does not tell you which law applies to you, and that is deliberate rather than an omission. W3C's own statement guidance recommends referencing applicable national or local laws, and it names the EU Web Accessibility Directive as one instrument with its own specific statement requirements. Which instrument reaches your business depends on your market and your customers, and that is a question for someone who can read your contracts, not for an article.

Third, conformance is a property of a site at a moment, not a certificate. The 2.4.11 failure above is the clearest example: it is usually introduced by a marketing banner added months after a successful audit. Whatever you fix this month, the thing that keeps it fixed is checking the focus ring after every change to the layout, and nothing you can buy removes that.

Describe it. We build it.

Seven or twelve days, pay on delivery, a year of maintenance included. Bring the problem, not a spec.

Book a meeting

Read next