Accessibility audit (WCAG audit)

Why an accessibility audit matters

If a screen reader user can't get past your signup form, they can't become a customer. Accessibility problems often hide in the places teams test least: custom dropdowns, modals, date pickers and drag-and-drop.

There's a commercial and legal side too. UK public sector services must meet WCAG 2.2 level AA as a minimum, and GOV.UK warns that falling short may break the law. W3C notes that conformance reviews are also used to give information to buyers, which matters if you sell software to large organisations.

What WCAG 2.2 adds

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and adds nine success criteria to WCAG 2.1. One older criterion, 4.1.1 Parsing, was removed as obsolete.

Several of the new criteria hit SaaS products directly. Focused items must not be fully hidden behind sticky headers or cookie banners. Pointer targets should be at least 24 by 24 CSS pixels or have enough space around them. Login shouldn't depend on memorising or retyping things, so password managers and paste need to work.

How an accessibility audit works

W3C's evaluation methodology, WCAG-EM, sets out five steps. Define the scope and target level, explore the product, select a representative sample, evaluate it and report the findings. Sampling is what keeps a large app manageable.

In practice, the auditor runs automated tools first. Then they work through each sample by hand: keyboard only, with a screen reader and zoomed in. They check contrast, labels, headings and error messages, and log each failure against the WCAG success criterion it breaks.

Accessibility audit vs automated scan

An automated scan is a tool such as Axe or WAVE checking your code against rules it can test by machine. It's fast and worth running on every build. But W3C is blunt: no tool alone can determine whether a site meets accessibility standards, and knowledgeable human evaluation is required.

A scanner can tell you an image has no alt text. It can't tell you whether existing alt text makes sense, or whether the tab order through your pricing table is logical. GOV.UK's guidance is to do both, because you'll miss issues with automated testing alone.

What each kind of accessibility check finds

Three kinds of check are often confused. They find different things, and a full picture needs all three.

W3C is direct about the first row: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so." It says the same about the third. Testing with users finds issues a conformance evaluation misses, "yet that alone cannot determine if a website is accessible".

What an accessibility audit report should contain

A report you can act on has the same parts, whoever writes it:

• Scope. Which pages, templates, states and user journeys were reviewed, and which were not.
• Target. The WCAG version and level you are aiming for, usually 2.2 at level AA.
• Sample. How the pages were chosen, so the result can be repeated later.
• Findings. Each failure with a screenshot, where it happens and the success criterion it breaks.
• Fixes. A recommended change for each finding, specific enough for an engineer to build.

Ask for the findings in a form your team can track, not only as a PDF. A failure that has no owner tends to survive the next release.

When you need a formal accessibility audit

Not every team needs a formal conformance audit, and it helps to know which situation you are in.

You need one when someone outside the team will rely on the result: a buyer who asks for evidence of conformance during procurement, a public sector contract with accessibility requirements, or a legal duty in the markets you sell to. In those cases the method, the sample and the report format matter, and the audit should be done by a specialist.

You can start smaller when the goal is to remove barriers from the flows that matter most. An expert review of sign-up, checkout and the main task, by keyboard and with a screen reader, finds a large share of the problems people actually hit. Fix those, add automated checks to your build, and commission the formal audit when you can pass it.

How Gr8r handles accessibility in audits

Our UX audit flags accessibility problems we find in the flows we review. Typical ones are low contrast, unlabelled form fields and controls you can't reach by keyboard. They're ranked by severity alongside the other findings.

That isn't the same as a formal WCAG conformance audit. If you need one for procurement or a legal requirement, we'll tell you plainly.

Our UX audit is free for the first 5 companies that ask. You can request the free UX audit. For how we walk a site screen by screen, see how to do a website UX audit, and for the wider method see UX audit in this glossary.