Accessibility Review & WCAG Audit Services

What an accessibility review is

An accessibility review assesses how well a product or website can be used by people with disabilities, measured against the Web Content Accessibility Guidelines (WCAG). It combines automated tools - which catch a useful share of issues quickly - with manual testing using a keyboard and screen readers, and a design review of colour, structure and content.

The aim isn't a certificate. It's a clear picture of where people are blocked, why, and what to fix first - ideally at the level of shared components and colours, so one fix resolves many pages.

Accessibility reviews are technical and design assessments, not legal advice. Confirm your obligations with your legal or compliance advisers.

Why reviews are increasingly requested

Accessibility has moved from a nice-to-have to a procurement and regulatory question:

Driver	What it means
US ADA Title II web rule	State and local government web content and apps must meet WCAG 2.1 AA; compliance dates are April 26, 2027 and April 26, 2028 depending on size
US HHS Section 504 rule	HHS-funded organisations must meet WCAG 2.1 AA, now by May 11, 2027 (15+ employees) or May 2028
European Accessibility Act	Applies to many consumer-facing products and services from 28 June 2025
India's GIGW 3.0	Government websites and apps must conform to WCAG 2.1 Level AA
Enterprise procurement	Buyers ask for conformance reports and remediation plans during vendor review

Even organisations not directly covered are often asked by customers who are.

What the review covers

Layer	Method	Typical issues found
Automated scan	Accessibility checkers across key templates	Contrast, missing alt text, missing labels, empty links and buttons, missing language
Keyboard testing	Complete key tasks without a mouse	Unreachable controls, keyboard traps, invisible focus, illogical focus order
Screen-reader testing	Key tasks with common screen readers	Unlabelled controls, missing headings, tables without headers, unannounced changes
Visual and design review	Colour, typography, layout, zoom and reflow	Low contrast, colour-only meaning, text that breaks at 200% zoom
Content review	Headings, link text, alt text, errors, documents	Vague links, poor error messages, inaccessible PDFs
Component review	Your design system's core components	Issues that repeat across every screen built from a component

Automated tools matter because the common failures are so widespread: WebAIM's 2026 analysis found detectable WCAG failures on 95.9% of the top million home pages, with 96% of detected errors in six categories. But many criteria need human judgement, which is why manual testing is always part of the review.

Most common detectable accessibility failuresShare of the top one million home pages, 2026

Low-contrast text83.9%

Missing image alt text53.1%

Missing form input labels51%

Empty links46.3%

Empty buttons30.6%

Missing document language13.5%

Source: WebAIM Million, 2026 report

View as table

Failure	Share of home pages
Low-contrast text	83.9%
Missing image alt text	53.1%
Missing form input labels	51%
Empty links	46.3%
Empty buttons	30.6%
Missing document language	13.5%

Prioritising fixes

Every finding is mapped to the WCAG success criterion it affects and rated by severity and reach:

Blocker - prevents a user group from completing a key task (for example, a form that can't be submitted by keyboard).
Serious - causes significant difficulty or errors.
Moderate - makes tasks harder but has workarounds.
Minor - small issues with limited impact.

Findings are then grouped by where the fix belongs: a shared component or colour token (fix once, resolve many pages), a template, a specific page, or content. Component-level fixes usually come first because they have the widest reach.

The process

How I run an accessibility review

01
Scope
Agree the standard (usually WCAG 2.1 or 2.2 AA), key journeys, templates and platforms.
02
Automated baseline
Scan representative pages and templates.
03
Manual testing
Keyboard and screen-reader testing of key journeys; zoom and reflow checks.
04
Design and content review
Colour, structure, errors, status and documents.
05
Prioritise
Severity, reach and where each fix belongs.
06
Report and plan
Findings mapped to WCAG, a remediation plan and a readout with your team.

After the review

Remediation support - design fixes for components and patterns, and answers for engineers during implementation. See WCAG-informed design.
Re-testing - confirm fixes on the affected journeys.
Documentation - input for your accessibility statement and conformance report.
Prevention - accessibility criteria added to your design system and definition of done, so issues don't return.

What you get

01

Findings report

Each issue with location, WCAG criterion, severity and evidence.

02

Remediation plan

Fixes grouped by component, template, page and content, in priority order.

03

Component fixes

Design specifications for fixing shared components.

04

Executive summary

Where you stand, in plain language, for leadership and procurement.

05

Re-test

Verification of fixes on key journeys.

06

Conformance input

Material for your accessibility statement and conformance report.

Frequently asked questions

Is an automated scan enough?

No. Automated tools find a useful share of issues quickly, but many WCAG criteria require manual testing and human judgement - especially keyboard use, screen-reader experience and content quality.

Which screen readers do you test with?

The common combinations your users are likely to have, typically including NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android where mobile matters.

Can you produce a VPAT or accessibility conformance report?

I can provide the review findings and input needed for a conformance report. The final report is usually issued by your organisation, reflecting your product's current state.

Do you test documents like PDFs?

Yes, if they're part of how people use your service. Important documents are reviewed and fixes or accessible alternatives recommended.

How often should we review accessibility?

After major redesigns or releases, and at least annually. Adding accessibility checks to your design system and release process catches regressions between reviews.