What an accessibility audit delivers
An accessibility audit produces three things a client can actually use: a conformance verdict against a named standard, a prioritised remediation list mapped to specific WCAG success criteria, and defensible evidence that the audit was conducted thoroughly enough to hold up under legal or regulatory review. The third deliverable is what distinguishes an accessibility audit from a casual accessibility review — the audit exists partly to protect the client from claim-based litigation and public-sector procurement rejection.
The most common client misconception is that an accessibility audit produces a fix. It does not. It produces the evidence base and the prioritised list against which fixes are made. The remediation work — often 3 to 10 times the effort of the audit itself — is a separate engagement. Framing the audit as the first step of a longer relationship, rather than a standalone deliverable, avoids the disappointment of clients who expect the audit to solve their accessibility problem in isolation.
WCAG 2.2 as the 2026 baseline
WCAG 2.2 became the operational standard in October 2023, adding nine new success criteria to the WCAG 2.1 baseline. In the UK the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 reference WCAG 2.2 AA as the required standard for all public-sector digital services. In the private sector, WCAG 2.2 AA is now the de-facto standard cited in most disability-discrimination litigation and in most enterprise procurement questionnaires.
The nine additions worth flagging in every 2026 audit: Focus Not Obscured (Minimum) 2.4.11 — focus indicators must not be hidden by sticky headers or overlays. Focus Appearance 2.4.13 — focus indicators must meet specific size and contrast thresholds. Dragging Movements 2.5.7 — any drag-based action must have a single-pointer alternative. Target Size (Minimum) 2.5.8 — pointer targets must be at least 24×24 CSS pixels. Consistent Help 3.2.6 — help mechanisms must appear in the same relative order across pages. Redundant Entry 3.3.7 — users should not be asked to re-enter information already provided. Accessible Authentication (Minimum) 3.3.8 and (Enhanced) 3.3.9 — authentication must not rely solely on cognitive function tests. The full WCAG 2.2 changes summary covers each in depth.
The practical implication for audit methodology: any accessibility audit template that predates late 2023 is missing these criteria and is producing false-pass verdicts on modern sites. Update the audit template before the next engagement.
Scoping the audit
Full-site audits rarely make sense on any site above 200 pages. The pragmatic approach is template-level auditing: identify the 8 to 20 unique page templates that account for 95% of the site's traffic, audit those exhaustively, then spot-audit page-level exceptions. A template-level audit of a 5,000-page ecommerce site typically covers homepage, category, product, search results, basket, checkout (each step), account dashboard, order history, order detail, help centre, and 4-6 content templates. That's the audit surface; individual product or content pages within each template are represented by 2-3 samples.
Component-library audits are the highest-leverage scope when the site is built on a design system. Auditing the source components — buttons, form fields, modals, disclosures, tabs, carousels, tooltips — resolves the majority of issues across every consuming page in one pass. Components are the highest ROI accessibility investment on any codebase that reuses them.
Cross-device scope needs explicit agreement. Desktop-only audits are cheaper but miss touch-target sizing, gesture alternatives, mobile-specific focus management, and the interaction patterns that WCAG 2.2 introduced specifically to address mobile. The mobile UX audit reference covers the mobile-specific accessibility layer separately.
Methodology — three-layer
Robust accessibility audits combine three layers of testing. Skipping any layer produces predictable blind spots.
Layer 1 — Automated scanning
Automated tools (axe-core, WAVE, Lighthouse, Pa11y, Siteimprove) catch roughly 30-40% of WCAG failures on a typical site. The value of automated scanning is coverage speed and consistency, not comprehensiveness. Run automated scans across every template as the first pass; the failures raised are baseline issues that would otherwise consume manual audit hours.
Common false negatives: alt text that is technically present but meaningless ("image", "photo", filename), reading order that scans correctly to a machine but confuses AT users, form errors that meet contrast ratios but are announced unclearly by screen readers, focus indicators that meet contrast but fail visibility due to size or shape. Automated scanners cannot evaluate these.
Layer 2 — Manual heuristic review
The core of the audit. Every WCAG success criterion in scope is evaluated manually against each template, with pass/fail evidence recorded. Manual review catches the 60-70% of failures automated tools miss, particularly around cognitive load, reading order, meaningful alt text, error recovery, and context-dependent success criteria. Budget 3 to 6 hours per template for a thorough manual pass.
Manual review is where audit quality is made or lost. The auditor's calibration — knowing what "meaningful" alt text sounds like, recognising a focus trap in a modal, spotting a live region that fires too aggressively — is the value the client is buying. Junior auditors miss patterns that senior auditors catch instantly. If a firm is quoting a full-site audit for £2,000, they are almost certainly running automated scans with light manual review, not full manual audit.
Layer 3 — Assistive-technology testing
The audit is not complete until the site has been tested with actual assistive technology across representative combinations. Minimum coverage in 2026: NVDA on Windows with Chrome and Firefox, VoiceOver on macOS with Safari, VoiceOver on iOS with Safari, TalkBack on Android with Chrome, keyboard-only navigation across all three desktop browsers, voice control (Voice Control on macOS, Dragon on Windows, Voice Access on Android). Skip any of these and the audit misses failures that AT users will encounter within minutes.
AT testing is where audits differentiate on quality. Automated + manual is the standard; AT-inclusive is the credible-defence standard. For any client with regulatory or reputational exposure, AT testing is not optional.
The 40-point core checklist
The full WCAG 2.2 AA checklist has 50 success criteria. Not all apply to every site — some are relevant only to media, others only to authentication flows. The 40-point core below is the recurring set most audits find failures on, grouped by category. This is a curated subset; the full list is captured in the 60-point audit checklist tool.
Perceivable (12 checks)
Alt text on informative images. Decorative images marked as such (empty alt or role="presentation"). Colour contrast ≥ 4.5:1 for body text, 3:1 for large text and UI components. Text resize to 200% without loss of content. Reflow at 320px width without horizontal scroll. No information conveyed by colour alone. Audio and video have captions/transcripts. Auto-playing audio has controls. Text spacing overrides don't break layout. Content on hover/focus is dismissible, hoverable and persistent. Reading order matches visual order. Meaningful sequence preserved when CSS is disabled.
Operable (14 checks)
Every action available to keyboard. No keyboard traps in modals, custom widgets, or embedded content. Focus visible at all times (2.4.7). Focus indicator meets 2.4.13 appearance requirements. Focus not obscured by sticky elements (2.4.11). Skip links present and functional. Page titles unique and descriptive. Link text meaningful out of context. Multiple ways to navigate to any page. Section headings hierarchical and skimmable. Pointer targets ≥ 24×24 CSS pixels (2.5.8). Drag actions have single-pointer alternatives (2.5.7). Motion-based inputs have alternatives. No content flashes more than 3 times per second.
Understandable (8 checks)
Language of page and language of parts programmatically set. Focus and input do not trigger unexpected context changes. Consistent navigation across pages. Consistent identification of functional components. Help mechanisms in consistent order (3.2.6). Form errors identify the field and describe the error. Error suggestions provided where possible. Redundant entry not required (3.3.7).
Robust (6 checks)
Valid HTML that parses without errors affecting AT. Name, role, value programmatically determinable for all UI components. Status messages announced to AT via appropriate ARIA live regions. Focus management on route change in single-page applications. Custom components conform to WAI-ARIA authoring practices. Authentication does not require cognitive function tests without alternatives (3.3.8, 3.3.9).
Prioritisation framework
An unprioritised audit report is a wall of failures that clients cannot act on. Prioritisation is where the audit's value shows up. Use a three-axis prioritisation: user impact, legal exposure, and effort to fix.
User impact ranks each failure by the size of the affected user population and the severity of the barrier. A missing alt text on a decorative image affects nobody; a keyboard trap in checkout affects every AT user attempting to purchase. High impact issues are the ones that would generate complaints if audited by the affected users.
Legal exposure ranks each failure by regulatory and litigation risk. WCAG 2.2 AA non-conformance on a public-sector site is a direct PSBAR breach. Non-conformance on a private-sector site is a discrimination claim risk under the Equality Act 2010, particularly if the site is the primary route to a service. Colour contrast failures and missing alt text on informative content are the failures most frequently cited in claim-based complaints.
Effort to fix is honest engineering estimation. Design token changes (contrast ratios) are hours of work per component; focus management rewrites in SPA route transitions are weeks; component library rewrites are months. Effort estimation surfaces which findings deliver disproportionate value per fix hour.
The prioritisation output is a two-quadrant matrix — high impact / low effort as the "fix this week" bucket, high impact / high effort as the "roadmap into next quarter" bucket. This shape of output is the difference between an audit report that gets acted on and one that sits in a shared drive.
Reporting the findings
A shippable accessibility audit report has five sections. Executive summary, conformance verdict, prioritised findings, evidence appendix, and remediation guidance.
The executive summary is one page, written for a non-technical stakeholder. It names the audit scope, the WCAG conformance level tested, the pass/fail verdict at that level, the count of high-impact findings, and the recommended remediation timeline. The rest of the report exists to support this page.
The conformance verdict is a table listing every WCAG success criterion in scope, with pass, fail, or not applicable status. This is the section that provides the legally-defensible evidence base. Do not shortcut it.
The prioritised findings section is where clients spend most of their time. Each finding names the failing success criterion, the affected page or component, the user impact, the effort estimate, and specific remediation guidance. Screenshot evidence is included per finding. This section should be scannable — clients often triage the top 20 findings, then delegate the rest.
The evidence appendix captures the raw audit trail: automated scan outputs, manual review notes per template, AT testing logs. Rarely read; essential to have.
The remediation guidance section is the bridge to the follow-up engagement. For each high-priority finding, it names the design or engineering change required, the WCAG success criterion it addresses, and any dependencies. This is where the audit hands off to the remediation phase. The worked audit report example shows the full five-section structure applied to a real audit.
UK pricing benchmarks (2026)
Independent consultants: £2,500 to £6,000 for a template-level audit of 10-15 templates covering WCAG 2.2 AA, with automated + manual review but limited AT testing. £5,000 to £10,000 for the same scope with full AT testing across 6+ combinations.
Boutique agencies: £8,000 to £20,000 for full audits including component library review, AT testing across representative combinations, and remediation guidance workshops with the client's design and engineering teams. This is the sweet spot for most mid-market clients.
Enterprise accessibility consultancies: £25,000 to £75,000 for full-programme audits including retest cycles, VPAT preparation, remediation coaching, and ongoing accessibility governance setup. Appropriate for FTSE-listed clients, financial services, healthcare, and any organisation with regulatory reporting obligations.
Retest cycles after remediation: £500 to £2,000 per pass depending on scope. Budget at least one retest pass per audit engagement; complex remediations often need two or three.
Common audit failure modes
Five patterns recur in accessibility audits reviewed peer-to-peer.
Automated-only audits presented as full audits. The client receives a Lighthouse or axe-core export dressed up as an accessibility report. The audit misses 60-70% of actual failures, produces false confidence, and rarely stands up if formally challenged. If the fee is under £2,000 for a site with more than 20 pages, this is almost certainly what was delivered.
No AT testing. The audit was conducted entirely against WCAG success criteria with no verification that the site is actually usable with assistive technology. WCAG conformance and AT usability are correlated but not identical; sites that pass every automated and manual check still frequently fail AT users on reading order, focus management, and live-region etiquette.
Findings not prioritised. The report lists 200 failures without prioritisation. The client's engineering team triages the first 20, gets fatigued, and ships fixes for a semi-random subset. High-impact failures often sit unfixed while low-severity items are addressed for visibility.
WCAG 2.1 template still in use. The audit template was built for WCAG 2.1 and hasn't been updated. The nine WCAG 2.2 success criteria are not evaluated. The audit produces a pass verdict against a standard that hasn't been current since 2023.
No remediation guidance. The audit tells the client what's failing but not what to change. The client's engineering team, with no accessibility specialism, guesses at fixes and introduces new failures. Remediation guidance is where audit expertise converts into client capability; skipping it is a false economy.
When to run one
Before any major site relaunch or template migration — an accessibility regression during a redesign is common and expensive to unwind. Annually for public-sector sites subject to PSBAR. Annually for any site with a documented accessibility policy referencing WCAG conformance. Before responding to procurement questionnaires that require accessibility conformance evidence. After receiving an accessibility complaint or claim. Before onboarding to any market with disability-discrimination legislation the client hasn't previously operated under.
Continuous auditing — via automated scanning integrated into CI/CD — catches regressions between the annual manual audits. Neither approach replaces the other. Continuous scanning is the smoke alarm; manual audits are the fire inspection.
Frequently asked questions
- Is WCAG 2.2 legally required in the UK?
- For public-sector digital services under PSBAR 2018, yes — WCAG 2.2 AA became the referenced standard on the regulatory update following its October 2023 W3C publication. For private-sector sites, it is not directly required by statute but is the standard cited in Equality Act 2010 discrimination cases and in most enterprise procurement.
- Should I audit against AA or AAA?
- AA for almost all engagements. AAA adds significant effort — colour contrast increases to 7:1, no timing on user-controlled actions, sign-language interpretation on video — and is impractical to achieve on most transactional sites. AAA is appropriate for content aimed specifically at disability audiences or where the client has an explicit AAA commitment.
- Do accessibility overlays replace audits?
- No. Overlay products (accessiBe, UserWay and similar) claim to remediate accessibility issues automatically. Independent testing consistently finds they miss the majority of real accessibility issues and introduce new ones. They also do not produce audit-quality evidence for regulatory or litigation defence. Overlays are marketed as replacements for accessibility work; they are not.
- What tools do you use for audits?
- Automated: axe DevTools, WAVE, Lighthouse, Pa11y. Colour contrast: the contrast checker on this site or Colour Contrast Analyser. Screen readers: NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android). Keyboard-only: browser DevTools with tab-key testing. Reading order: browser accessibility trees plus manual tab traversal.
- How does an accessibility audit fit alongside a UX audit?
- They are complementary but distinct engagements. Run the UX audit first if the goal is conversion improvement and general experience quality; run the accessibility audit if the goal is conformance and legal defensibility. Many mid-market clients run both, with the accessibility audit as an annual conformance exercise and the UX audit tied to specific product initiatives. The UX audit hub covers the broader audit context.