Skip to content
wcagc
←Back to blog
accessibility auditWCAGmanual testingEAA

What a real accessibility audit includes (beyond a scan)

An accessibility audit is more than a scan: defined scope, sampled pages, manual expert testing, and a written report. What a real audit covers.

P

Pavel Charkasau

An accessibility audit is a structured evaluation of how well a website meets the Web Content Accessibility Guidelines — not a PDF of scanner output. A real audit runs the five steps the W3C sets out in its evaluation methodology, WCAG-EM: define the scope, explore the product, select a representative sample of pages, evaluate that sample, and report the findings (W3C WAI). An automated scan is one input into step four. It clears the machine-checkable failures fast, and that is roughly 30–57% of the issues depending on how you count. The rest is a person tabbing through the page with a keyboard and a screen reader, checking the things a rule can't decide: whether the focus order makes sense, whether the alt text describes the image, whether the checkout actually finishes. It ends in a written report that says what was tested, what passed, what failed, and what a fix looks like. If someone hands you a scan and calls it an audit, you got a scan.

What is an accessibility audit?

An accessibility audit is an expert review that measures a digital product against a defined conformance target, usually WCAG 2.1 or 2.2 Level AA, and documents where it stands.

The W3C describes its methodology, WCAG-EM, as "an approach for determining how well a digital product conforms to Web Content Accessibility Guidelines (WCAG)," one that "can be applied to all digital products, including websites, mobile applications, and kiosks" (W3C WAI). It works for both self-assessment and third-party review. What it is not is a single tool run. The same page says a successful evaluation "requires knowledge of WCAG, accessible design, assistive technologies, and how people with different disabilities use digital products." A machine has none of that knowledge. It has a rule set.

So the word "audit" carries weight. It implies scope, method, a competent reviewer, and a record you can defend later. A scanner gives you a list of code-level violations, which is useful and necessary. It just isn't the whole thing.

How is an audit different from an automated scan?

A scan reads structure; an audit judges whether a person can use the page. That's the difference in one line.

An automated scanner parses your rendered HTML, CSS, and ARIA, and flags any failure it can confirm from the code alone: a missing alt attribute, a contrast ratio below the threshold, a form field with no programmatic label so a screen reader reads "edit text" and nothing else. It runs in seconds and it runs the same way every time. That makes it the right tool for the repetitive, objective half of the work, and for catching regressions on every deploy.

But the W3C is direct about the ceiling: "no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is accessible" (W3C WAI). The honest coverage number bears this out. Counting by success criteria, a machine can confidently evaluate only the ones that turn on code, which lands in the 20–30% range the field used for years. Counting by volume of individual issues, the number rises: Deque's analysis of more than 2,000 audits (roughly 13,000 pages and nearly 300,000 issues via axe-core) found automated testing fully covered about 57% of the issues found (Deque). Both figures are true. Neither one gets the remaining criteria tested. An audit exists to test the rest.

What are the steps of an accessibility audit?

Five, in order, from the W3C's WCAG-EM methodology (W3C WAI):

  1. Define the scope. Which product, which conformance target (A, AA, AAA), and what counts as "done." A checkout audit at WCAG 2.2 AA is a different job from a marketing-site audit at 2.1 AA. Pin it down first.
  2. Explore the product. Find the key views, the core functionality, the content types, and the technologies in play — so the sample you pick next actually represents the site.
  3. Select a representative sample. You rarely test every page. WCAG-EM gives structured and random sampling guidance so the pages you do test stand in fairly for the ones you don't.
  4. Evaluate the sample. This is where the automated scan runs, and where a human takes over for everything the scan can't reach. Both feed the same result set: pass, fail, or not applicable against each criterion, with the evidence recorded.
  5. Report the findings. Aggregate the results, write the conformance statement, and, where the scope calls for it, calculate an overall score.

Step four is where most of the money and most of the judgment go. The scan is minutes. The manual pass is where an experienced reviewer earns the fee.

What does the manual part of an audit test?

The criteria that depend on meaning, sequence, and whether a task completes — none of which a machine evaluates.

A concrete list of what a reviewer checks by hand:

  • Keyboard operability. Can you reach every control with Tab, operate it with Enter or Space, and escape a modal — without a mouse? A scanner can't press a key.
  • Screen-reader output. Put NVDA or VoiceOver on the page and listen. Does the error announce anything? Does a custom dropdown say "button" or say nothing? Is "chart-final-v2.png" the alt text on a revenue graph?
  • Reading and focus order. The DOM order a screen reader follows should match the visual order. A scanner confirms headings exist; it can't tell you the focus jumps from the logo to the footer and skips the form.
  • Meaningful alt text and labels. Presence is machine-checkable. Quality is not. "Submit" versus "Submit your loan application" is a human call.
  • Whether the flow finishes. Most scanners see the marketing homepage. The barriers live behind the login — the onboarding wizard, the cart, the account settings.

Here's the opinion I'll stand behind: a clean scan on your homepage tells you almost nothing about whether someone can finish a purchase with a screen reader. The gap between "the scan is green" and "a keyboard user checked out" is the entire reason audits exist. A scanner narrows that gap. A person closes it.

Should real users be involved in an audit?

Not required, but it catches things conformance testing misses. This is a separate layer from the expert review.

The W3C recommends involving people with disabilities in evaluation and is careful about what it adds: "Evaluating with users with disabilities and with older users identifies usability issues that are not discovered by conformance evaluation alone" (W3C WAI). It's equally careful about what it doesn't replace: "Involving users with disabilities in evaluation has many benefits. Yet that alone cannot determine if a website is accessible. Combine user involvement with evaluating conformance to WCAG" (W3C WAI).

So the two are complementary, not interchangeable. Conformance testing tells you whether the page meets the standard. User testing tells you whether a real person with a real assistive-tech setup can get through their task without giving up. A page can pass every checkable criterion and still be miserable to use, and that's the signal user involvement surfaces. Most audits at least draw on combined expertise, with reviewers of different specialisms checking the same views, even when a full user study is out of budget.

What's in an accessibility audit report?

A defensible record of what was tested, by whom, against what, with results and fixes. The W3C's own report template lists the sections (W3C WAI):

  • Executive summary. The conformance picture in plain terms.
  • Background. The methodology and the dates.
  • Scope of review. Which pages were assessed, and which were excluded.
  • Reviewers. Who did the work and what they know.
  • Review process. The tools, the methods, the WCAG level tested.
  • Results and recommended actions. Findings organised by success criterion, each with a suggested fix.
  • References and appendices. The standards cited and the supporting evidence, including validator output.

The part that matters most is the honest one: what you did not test. A report that says "we sampled 12 of 400 templates, at AA, and did not test the native mobile app" is worth more than one that implies full coverage it never had. That scope-of-review section is where credibility lives. Skip it and the report reads as a claim rather than a record.

How does an audit support EAA and EN 301 549 compliance?

It produces the evidence the law expects you to keep. Under the European Accessibility Act, in-scope products and services have had to meet WCAG-level requirements since 28 June 2025, with the technical bar set by EN 301 549, which incorporates WCAG 2.1 Level AA for the web. EN 301 549 Annex C is a clause-by-clause table where each requirement gets marked met, not met, or not applicable — and an audit is how you fill it in honestly. "Partially met" is the right entry when a scan covered a criterion but manual testing hasn't confirmed the rest.

The accessibility statement the EAA expects documents your level of conformance and your known limitations. It's not a guarantee, and treating a clean scan as one is exactly the overreach that cost an overlay vendor $1 million at the US Federal Trade Commission (FTC). An audit gives you something you can put your name to: here's what we tested, here's what passed, here's what's left. Run a scan to clear the machine-checkable volume, then test the rest by hand, and you'll have a statement you can defend instead of one you're hoping nobody checks.

Frequently asked questions

What is an accessibility audit?

An accessibility audit is a structured expert review that measures a website against a WCAG conformance target and documents where it stands. It follows the W3C's WCAG-EM steps (scope, explore, sample, evaluate, report) and combines an automated scan with manual testing by a person using a keyboard and a screen reader (W3C WAI).

Is an accessibility scan the same as an audit?

No. A scan is an automated check of machine-decidable rules (contrast, missing labels, empty controls), and it covers roughly 30–57% of issues depending on how you count. An audit uses that scan as one input and adds the manual evaluation of everything a machine can't test, ending in a written report (Deque).

How long does an accessibility audit take?

It depends on scope and sample size, not on a fixed number. The automated scan is minutes; the manual evaluation of a representative sample of key pages and flows is where the time goes. A tightly scoped audit of a few critical journeys is far quicker than a full-site review across many templates.

Do I need an accessibility audit for the EAA?

You need evidence that in-scope products meet the requirements and an accessibility statement documenting your conformance and known limitations. An audit against EN 301 549 is how most teams produce that evidence and fill in the Annex C conformance table honestly.

Who should perform an accessibility audit?

Someone with knowledge of WCAG, assistive technologies, and how people with disabilities use the web — the W3C names all three as requirements. That can be an in-house specialist or a third party, and many audits draw on combined expertise so different reviewers cover different criteria (W3C WAI).

Get the automated baseline, then audit the rest

The scan is where an audit starts, not what an audit is. Run a free scan to clear the machine-checkable failures on your key pages, mapped to WCAG, and use our WCAG checklist to track the criteria a machine can't reach. Fix the code-level issues first, then put a person with a keyboard and a screen reader on your critical flows — and you'll have a real audit trail, plus the evidence to write an accessibility statement that says exactly what you checked.

Pavel Charkasau, founder, wcagc.com. Last updated 15 August 2026.

Sources