Accessibility audits

Since 2025 I have audited large web applications for the banking and retail clients of an accessibility consultancy, across Europe: storefronts, account areas behind a login, employee portals and survey platforms. The clients are not named here. The work is: an audit against WCAG 2.1 and 2.2 at level AA, a report that leadership and engineers can both act on, a phased remediation plan, and retests until every problem is fixed.

How a finding is written

Every finding carries the success criterion, a severity, who owns the fix, who it affects, what the defect is, its impact, the expected behaviour, the fix, and the evidence. Severity says how badly it blocks somebody. Ownership says who can actually change it: the client’s theme, an app vendor, or the platform itself, because a finding filed against the wrong owner is a finding that never closes. The report ends with a remediation roadmap by phase and, where a platform owns a defect, a support ticket the client can send as written.

What works well is recorded too

Each report lists the behaviours that already work and should be preserved, so a fix does not quietly take one away. Suggestions that go beyond what the standard requires are kept apart from defects, and labelled as suggestions.

The toolkit

I built the tooling I use: scans of every page of a site with two checkers, axe-core and IBM Equal Access, PDF checks, a linter that refuses a report with a finding missing any of its fields, a glossary generator, and a renderer that produces the client document from the markdown source. Screen reader testing is done by hand with NVDA and VoiceOver, because the tools miss much of what matters.

Training

Alongside the audits I have run sessions for design, engineering and marketing teams on accessibility standards and on embedding them in design system components, which is where most of the fixes end up living.