A credible website accessibility audit defines scope, samples representative pages and complete journeys, combines automated checks with human evaluation, tests keyboard and assistive-technology use, records evidence against WCAG 2.2, and produces prioritised remediation. An automated scan is useful evidence. It is not a complete audit.

Commission an audit when your product, procurement or risk team needs a clear picture of barriers before money is spent on fixes, or when you supply digital services to the public sector. The output should help you decide what to fix first, what sits outside scope, and what still needs retesting. It should not be sold as a certificate, a legal guarantee or proof that every user can complete every task.

This is different from a UX audit. A UX audit looks at usability, conversion friction, analytics and journeys. An accessibility audit evaluates access barriers against published criteria, with evidence you can act on. The two often sit next to each other on the same product. They answer different questions.

What scope and sampling should cover

A useful audit starts by saying what is in and what is out. Without that, a long findings list is hard to trust.

Expect the written scope to cover:

Product boundary. Marketing site, authenticated app, both, or a named subdomain set.
Conformance target. Usually WCAG 2.2 Level AA where that target applies; Level AA includes the Level A and AA success criteria.
Representative templates. Home, listing, detail, forms, account, error and content patterns that actually recur.
States and content types. Empty, loading, error, success, logged-in versus logged-out, media, tables, documents if they are part of the service.
Technologies in play. Front-end stack, CMS, third-party widgets, PDFs or other documents only when they are required to use the service.
Complete processes. Search to result, enquire, buy, book, apply, renew, reset password, or the important tasks people need to complete.

Sampling is normal. The W3C WCAG Evaluation Methodology (WCAG-EM) frames evaluation as five steps: define scope, explore the product, select a representative sample, evaluate the sample, and report findings. It supports conformance evaluation. It does not add WCAG requirements. It applies to websites and other digital products and assumes relevant expertise.

Do not read “sample” as “we clicked the homepage.” A representative sample should reflect real templates and end-to-end journeys. Do not read it as “every URL was tested” either. If the supplier claims whole-site coverage, ask how that claim was made and what was excluded.

What automated checks are good for

Automated tools are good at repeatable, machine-detectable failures across a broad set of pages: missing alternative text attributes, empty buttons, some contrast failures, broken ARIA references, missing page language, and similar patterns. They help you widen coverage and catch regressions when the same checks run again after fixes.

They cannot prove every WCAG success criterion. They cannot tell you whether a real person can complete a task with a keyboard or a screen reader. They also produce noise: warnings that need human triage, and passes that still hide broken journeys.

Treat the scanner report as one evidence stream. Keep humans in charge of severity, false positives and release judgement. That is the same split we use in AI agent QA: agents and automation can widen repeatable coverage overnight; people still triage evidence and own sign-off. Automated QA does not prove accessibility on its own, and it does not replace research with disabled users when that research is in scope.

What human evaluation should include

Manual evaluation is where most of the audit value sits. The exact matrix depends on scope, but a serious review usually includes:

Keyboard-only use. Tab, shift-tab, enter, space and arrow keys where components require them. No keyboard trap.
Focus order and visibility. Logical sequence, visible focus, and no surprise jumps when dialogs or menus open.
Zoom and reflow. Content usable at higher zoom and narrower viewports without loss of meaning or action.
Forms. Labels, instructions, error identification, error recovery and accessible name calculation.
Structure. Headings, landmarks, lists and reading order that match the visual hierarchy.
Text alternatives. Images, icons, controls and status messages that need a text equivalent.
Colour and contrast. Information not conveyed by colour alone; contrast checked in context, not only by a single hex pair.
Content clarity. Link purpose, consistent navigation, and language that does not block understanding of the task.
Media. Captions, transcripts or alternatives where video or audio is in scope.
Dynamic states. Live regions, disclosures, tabs, carousels, filters and client-rendered updates.
Assistive technology checks selected for scope. Screen reader and other AT passes on the journeys that matter, on an agreed browser and AT set.

One device, browser and assistive-technology combination is not universal coverage. The report should say what was used, on which journeys, and what was left out.

WCAG 2.2 is designed to be tested with a combination of automated testing and human evaluation. That pairing is the method, not a nice-to-have.

How WCAG 2.2 is framed in an audit

WCAG 2.2 first became a W3C Recommendation on 5 October 2023. The current revised Recommendation is dated 12 December 2024. It sets testable, technology-independent success criteria organised under four principles:

Perceivable. Users can perceive the information and interface.
Operable. Users can operate the interface.
Understandable. Users can understand the information and how to use the interface.
Robust. Content can be interpreted by a wide range of user agents, including assistive technologies.

Conformance levels are A, AA and AAA. Level AA is a common conformance target where WCAG applies; it includes the Level A and AA success criteria. AAA is a stricter set of criteria for some content. It is not a claim of complete accessibility for every user, and an audit that “hits AAA on three pages” is not a site-wide AAA result.

Public-sector buyers in the UK should read the current GOV.UK guidance on accessibility requirements for public sector websites and apps. Covered bodies should meet WCAG 2.2 AA and publish an accessibility statement, subject to that guidance’s exemptions and legal boundaries. GOV.UK separately notes reasonable-adjustment duties for UK service providers and advises legal advice when applicability is unclear. Those public-sector rules are a specific regime. They do not automatically govern every private-sector site. This article is not legal advice.

An audit records evidence against criteria. It does not certify legal compliance, create compliance, or guarantee that every future release stays accessible.

What the audit report should contain

If you are buying the work, judge the report before you judge the slide theme. The W3C accessibility evaluation report template is a practical baseline. W3C is clear that conformance evaluation needs semi-automated tools plus manual evaluation by an experienced reviewer. Useful report fields include scope, dates, included and excluded URLs, reviewer expertise, tools and versions, manual reviews, detailed WCAG results, evidence, recommended action and monitoring.

Use this buyer checklist:

Scope and exclusions. What was tested, what was out of bounds, and why.
Dates. When evaluation happened, and any caveat that the product may have changed since.
Sample. Templates, journeys, states and documents included; how the sample was chosen.
Methods, tools and versions. Automated tools, browsers, devices and assistive technologies, with versions.
Reviewer expertise. Who evaluated the sample and what relevant experience they brought.
Findings with criterion, evidence, location and severity. Each issue tied to a WCAG success criterion where claimed, with URL or component location, screenshot or clip, and a severity the team can use.
Remediation guidance. Enough direction for design and engineering to act, not only a fail label.
Ownership and priority. Who should fix what first, grouped so a sprint backlog can form.
Retest status. What was rechecked after fixes, what remains open, and what was not retested.
Limitations. Sample limits, environment limits, and any criteria or journeys left unevaluated.

W3C also publishes an open-source WCAG-EM Report Tool to follow the methodology, record outcomes and download an evaluation report. Using the tool does not make an evaluator W3C-accredited.

Questions to ask a supplier before you commission

Ask these before the statement of work is signed:

Which WCAG version and level are you evaluating against, and what is explicitly out of scope?
How will you choose the representative sample, and which complete journeys are included?
Which automated tools, browsers, devices and assistive technologies will you use, at which versions?
Who does the manual evaluation, and what is their relevant experience?
How will each finding be evidenced: criterion, location, screenshot or clip, and severity?
Will the report give remediation guidance and a prioritised backlog, or only raw fails?
How do you handle third-party widgets, PDFs, authenticated areas and role-based views?
What is included in retesting after fixes, and what counts as out of scope for retest?
Will you involve disabled users in this engagement, or is that a separate research piece?
What limitations will appear in the report so we do not over-claim the result internally?

If answers stay vague on sample, evidence or retest, you are buying a scan with a narrative attached.

What drives cost

Price follows scope. Common cost drivers:

Number of templates and complete journeys
Authenticated areas, roles and permission matrices
Native apps, hybrid apps or documents in scope
Breadth of the assistive-technology and browser matrix
Depth of evidence required for each finding
Depth of remediation guidance and the work needed to turn findings into a usable backlog
Retesting rounds after fixes

Ask suppliers to price against those drivers. Do not treat a homepage-only scan and a multi-role product audit as the same product. This article does not publish a Code23 accessibility-audit rate or a market price band.

How this fits Code23 product design

On Code23 product work, accessibility checks sit inside design QA against the live build, alongside usability review. UX audit work produces a friction map and a prioritised backlog engineering can ship. Automated and agent-assisted passes can widen repeatable coverage. Humans still triage evidence and own sign-off.

We do not sell a separately priced accessibility-audit package on this page, and we do not claim accreditation, certification or legal compliance from an audit alone. If you need the evaluation framed so design and engineering can act, start from product design. If you also need conversion and journey friction mapped, keep the UX audit guide next to this one.

Sources

Next step

If you need accessibility evaluation tied to a live product backlog, start with product design. We can scope representative journeys, run accessibility checks with human review against the build, and turn findings into a prioritised fix list your team can ship.