What is an accessibility audit?

An evaluation of a product against a named standard, almost always WCAG level AA, that lists each failure with where it is, which criterion it breaks, how severe it is, and what fixing it involves. The output is a working document for engineering, not a score.

How is an accessibility audit different from a UX audit?

A UX audit asks whether the product works well. An accessibility audit asks whether it works at all for people using assistive technology, measured against a standard with pass and fail criteria. They overlap in findings and differ completely in method: one is judgement against heuristics, the other is testing against a specification.

Can accessibility be audited automatically?

Only partly. Automated scanners reliably catch contrast failures, missing alternative text and some structural problems, which is a minority of the success criteria. Keyboard traps, focus order, whether a label actually describes its field, and whether a screen reader announces a state change all need a person.

How long does an accessibility audit take?

For a typical B2B SaaS product, evaluating the main flows rather than every screen, a week or two of specialist time is realistic. Auditing an entire application is rarely the right scope — pick the paths that carry the product's value and the ones a customer cannot avoid.

Do you need an audit before writing a VPAT?

You need testing, and an audit is the structured form of it. A VPAT written without testing is a guess published under your company's name, and it is read by the buyer's accessibility team against the actual product. The audit is what makes the report defensible.

Accessibility Audit

A structured evaluation of a product against WCAG, producing a list of failures with severity, location and a route to fixing each one.

Process & Methods

An accessibility audit evaluates a product against a named standard — in practice WCAG level AA — and produces a list of failures each team member can act on.

The output is not a score. A percentage tells nobody what to do on Monday.

What a usable audit contains

The criterion each failure breaks. "Contrast fails" is a complaint. "1.4.3 Contrast (Minimum): secondary text at 3.1:1 on card surfaces, needs 4.5:1" is a ticket.

Where it is, specifically enough to find: the screen, the component, the state.

Severity by user impact, not by how hard it is to fix. A keyboard trap in the main workflow blocks somebody entirely; a missing alt attribute on a decorative image does not. Sorting by effort produces a list that fixes the easy things and leaves the blockers.

What fixing it involves. The person reading this is usually an engineer who did not write the criterion and should not have to interpret it.

What was tested and what was not. Scope stated plainly, because an audit of four flows is not an audit of the product and a buyer will ask which it was.

Automated tools do a minority of the work

Scanners catch contrast, missing alternative text, some ARIA misuse, and structural problems. That is genuinely useful and it is a fraction of the success criteria.

What needs a person:

Keyboard traps — anywhere focus goes in and does not come out. Custom modals and dropdowns are where these live.

Focus order that follows the visual layout rather than the DOM accident.

Whether a label describes its field. A scanner confirms a label exists. It cannot tell you the label says "Field 3".

Whether state changes are announced. An error that appears silently passes an automated check and fails a person.

Whether the alternative text is true. "Image" is present, and useless.

A clean scanner report is the floor, not the result.

Scope it by path, not by screen

Auditing an entire application is rarely right, and quoting for it is how these engagements become unaffordable and get cancelled.

Take the paths that carry the product's value and the ones a customer cannot avoid: sign-up, the primary workflow, settings, billing, and whatever the sales demo shows. Those are also the flows a buyer's own accessibility team will check.

For a typical B2B SaaS product on that scope, a week or two of specialist time is realistic.

It is what makes a VPAT defensible

A VPAT written without testing is a guess published under your company's name, and it is read against the product by people who do this professionally.

The audit is the evidence behind the report. Saying in the report that an independent evaluation produced the findings is an advantage, because the document is otherwise a self-declaration and every buyer knows it.

In practice

A company runs an automated scan, fixes the 40 issues it reports, and declares the product accessible.

The first customer accessibility review finds that the main table cannot be operated by keyboard at all, because the rows are divs with click handlers. No scanner flagged it — the markup is valid, the contrast passes, the alt text exists. It simply cannot be used without a mouse.

That single finding outweighs all 40. It is also the cheapest class of defect to avoid and the most expensive to retrofit, because by then the component is used on nine screens.

Where teams get it wrong

A score instead of a list. Nobody can act on 78%.
Severity sorted by effort. Blockers left because they are hard.
Scanner output treated as an audit. A minority of the criteria.
Auditing every screen. Unaffordable, so it does not happen.
Auditing after launch. Retrofitting costs several times building it in.
Scope left unstated. The buyer will ask.

Learn more

Accessibility as a B2B SaaS deal blocker →UX Audit service →