What WCAG 2.2 AA actually means for your website

Accessibility usually arrives as a question from a procurement form, and the answer is expected to be one word. Here is what is actually behind it.

What WCAG is

The Web Content Accessibility Guidelines, from the W3C. Version 2.2 is current. It sets out criteria across four principles: content should be perceivable, operable, understandable and robust.

There are three conformance levels:

• A: the minimum. Falling short here excludes people outright.
• AA: the level nearly everyone means. UK public sector regulations require it, and most procurement asks for it.
• AAA: stricter, and not realistic as a blanket target for a whole site. Even the W3C says so.

When somebody asks whether your site is accessible, they almost always mean AA.

Where the UK law sits

For public sector bodies, the 2018 accessibility regulations require WCAG 2.1 AA as a minimum, plus a published accessibility statement.

For private businesses, there is no regulation naming WCAG. The Equality Act 2010 creates a duty to make reasonable adjustments, and websites have been the subject of claims. WCAG is the practical yardstick for whether you have made them.

We are not lawyers and this is not advice. If you are being asked to certify compliance, involve one.

What automated tools find

Run a checker and you will get a list. That list is worth having and it is roughly a third of the picture.

What tools find reliably: missing alt attributes, insufficient colour contrast, missing form labels, invalid markup.

What they cannot judge: whether alt text describes the image usefully, whether the focus order makes sense, whether a custom dropdown can be operated at all, whether an error message explains anything, whether a heading structure reflects the page.

A site can pass every automated check and still be unusable with a keyboard.

The failures we see most

Focus order and focus states. Tab through your site. If you cannot see where you are, or the order jumps around, that is the most common failure on the web and almost nobody reports it.

Custom components. Dropdowns, modals, tabs and carousels built from divs with click handlers. They work with a mouse and are invisible to assistive technology.

Contrast in states. The resting state passes and the hover, disabled or placeholder state does not.

Forms. Labels that are placeholders, errors signalled only by colour, and messages not tied to the field they describe.

About overlay widgets

The products promising compliance from one line of script do not deliver it. The accessibility community is close to unanimous, many screen reader users actively block them, and several vendors have been the subject of legal action themselves.

They do not fix the underlying markup. They add a layer on top of it.

What to do

Get a manual audit alongside the automated one: a keyboard pass and a screen reader pass through the journeys that matter. Fix in order of who is blocked and how badly. Publish a statement that reflects the real position rather than a claim you cannot support.

Then keep it. Most regressions come from content and design decisions, not code, so the people making those are the ones worth training.

Our builds go out at WCAG 2.2 AA as standard, which is why we are comfortable auditing other people’s.