Can you evidence that your platform is accessible?

Why an automated scan isn't enough

Automated tools reliably catch somewhere under a third of WCAG failures. They will not tell you that your keyboard focus order jumps across a three-column layout, that your date picker is unusable with a screen reader, that your error messages announce nothing, or that your "skip to content" link goes to the wrong place after the last redesign.

Those are the failures that matter, both to a user and to a regulator. They require a person testing by hand.

What the audit covers

• Automated scan across a representative page sample, as a baseline only
• Manual testing against WCAG 2.2 AA success criteria
• Keyboard-only navigation of every interactive component
• Screen reader testing (NVDA, VoiceOver) on key journeys
• Forms, error handling, validation messaging and focus management
• Colour contrast, text resizing, reflow and zoom behaviour
• Multilingual specifics — language attributes, direction, translated alternatives
• Editorial patterns that reintroduce failures: how your content team creates links, headings, tables, images and documents
• Attached documents (PDF and Word), which are where public-sector sites most often fail

What you receive

Findings report	Every issue mapped to the specific WCAG 2.2 criterion, severity-ranked, with location, reproduction steps and a screenshot or recording.
Remediation plan	Grouped by fix, not by page — so one theme change closes forty findings instead of forty tickets. Effort estimate per group.
Accessibility statement	Draft statement in the format your obligation requires, with the non-conformances honestly listed.
Editor guidance	A short internal guide so your content team stops reintroducing the same failures.
Duration	2–4 weeks depending on site size and number of templates.

Then remediation, then a re-check

Most clients take the report and have me fix it, because the person who found the issue fixes it fastest. Some hand it to their own team, which is a perfectly good outcome. Either way, compliance is not a one-off: templates change, editors publish, and a site drifts back out of conformance within a year. An annual re-audit keeps the statement truthful.

Relevant experience

I brought a public-facing EU agency platform serving over 500,000 users to WCAG 2.2 compliance, working with stakeholders against audit and regulatory standards — then wrote the accessibility compliance guidance that every subsequent Drupal project at that organisation now follows. Before that, seven years of Czech government platforms carrying statutory accessibility obligations.

Accessibility here is not a side service. It's a standing requirement of the work I already do, which is why the audit reads like something written by someone who then has to fix it.