Accessibility
An accessibility audit that ends in fixes, not a colour coded spreadsheet.
Most accessibility reports are an automated scan exported to a document, which finds roughly a third of the problems and none of the ones that actually stop somebody using your site. This is a WCAG 2.2 AA audit done with a keyboard and a screen reader as well as a scanner, delivered as a ranked list with the fix for each, and implemented on the codebase where we have access.
Why now
The legal position moved, and a lot of businesses have not noticed.
Not legal advice, and worth taking your own. But the timeline is a matter of public record and it is more advanced than most people assume.
The Equality Act already applied
The duty to make reasonable adjustments for disabled people has covered services delivered online for years. Nothing about it is new, and it is the reason the question was never really optional in the UK.
The European Accessibility Act is in force
It has applied since June 2025, so this is a current obligation rather than a deadline to plan for. It covers ecommerce, banking, ticketing, ebooks and transport among others, and it reaches UK businesses through who they sell to rather than where they are.
Public sector duties are separate
UK public sector bodies carry their own regulations, including a published accessibility statement that has to be accurate. An out of date statement is its own problem, and they are frequently years stale.
The commercial argument, which is usually the stronger one
Around one in five people has a disability, and a checkout that cannot be completed with a keyboard loses that order in the same way a broken payment form does. Accessibility work overlaps heavily with plain usability: clearer labels, honest error messages, sensible focus order and readable contrast improve conversion for everybody, not only for the users the standard was written for.
The problem with most audits
A scanner finds about a third of it.
This is the single most useful thing to understand before buying an accessibility audit from anybody, including us.
What a scanner does find
- Contrast ratios below the threshold
- Images with no alt attribute at all
- Form inputs with no associated label
- Missing document language and page titles
- Landmark and heading structure that is absent
What only a person finds
- Alt text that exists and describes the wrong thing
- A focus order that jumps around the page
- A modal you can open with a keyboard and not escape
- An error that says invalid input and nothing more
- A custom dropdown a screen reader announces as a div
On overlay widgets
If you have been sold a script that promises compliance once installed, it is worth knowing that these have been the subject of a large number of US lawsuits brought against sites that had one running. They cannot repair semantics they did not author, and they can actively interfere with the assistive technology a user has already configured to their own preferences. Run the free scanners by all means. Do not buy the widget.
Scope
What the audit actually covers.
Tested against WCAG 2.2 at level AA, which is the level almost every legal framework points at, including EN 301 549 in the EU.
Keyboard only
Every journey that matters completed without a mouse: navigation, search, filters, forms and checkout. Focus visible at all times, no traps, and a skip link that goes somewhere useful.
Screen reader
The same journeys with a screen reader running, because a page can pass every automated check and still be incomprehensible when read aloud in order.
Structure and semantics
Headings that describe the document rather than the styling, landmarks, lists that are lists, and tables with real headers. The part that also happens to help a crawler.
Forms and errors
Labels bound to inputs, errors announced and specific, required fields marked in more than colour, and a checkout that survives a mistake without losing what was typed.
Media and motion
Captions on video, alternatives for audio, nothing that autoplays and traps attention, and reduced motion respected for users who have asked their device for it.
Components and templates
Audited at the template rather than the page, because a broken accordion appears on four hundred URLs and gets fixed once. The same logic as everything else here.
Worth saying
What this does not include.
A compliance certificate. Nobody can issue one that means anything. Accessibility is a property of a site at a moment, and it degrades the next time somebody publishes a page with an unlabelled image. What you can have is an accurate statement of where you stand and a plan, which is what regulators and courts actually look for.
Legal advice. We can tell you which WCAG criteria a page fails and what it costs a user. Whether that creates liability for your organisation is a question for a solicitor, and we will say so rather than guess.
Testing with disabled users. Genuine user testing with people who rely on assistive technology daily is more valuable than any audit, ours included, and it is a specialist service we do not provide. For a large public facing service it is worth budgeting for alongside this rather than instead of it.
A one off fix that stays fixed. If your team publishes content, accessibility needs a habit rather than a project. Part of the useful output here is the short list of rules your editors need, which is usually about six things and not a training course.
FAQ
Questions about accessibility
Is my website legally required to be accessible?
This is not legal advice and you should take your own, but the shape of it is worth knowing. In the UK the Equality Act 2010 requires reasonable adjustments for disabled people, and it has always applied to services delivered online rather than only to buildings. UK public sector bodies carry a separate, more specific duty with a published accessibility statement.
If you sell into the EU, the European Accessibility Act has applied since June 2025, so it is a live obligation rather than something coming. It reaches a lot of ordinary commerce: ecommerce, banking, ticketing, ebooks and transport among others. Plenty of UK businesses are inside its scope because of who they sell to rather than where they are.
What standard do you test against?
WCAG 2.2 at level AA, which is what almost every legal framework points at in practice. The EU standard EN 301 549 wraps WCAG for European purposes, and UK public sector regulations reference it too, so testing to AA covers the substance of both.
Level AAA exists and is not a sensible target for a whole site. Parts of it are impossible for some content types, and the standard itself says so.
Can a plugin or overlay make my site compliant?
No, and this is the single most expensive misconception in the field. Overlay widgets that promise compliance in a line of JavaScript do not deliver it: they cannot fix semantics they did not author, they frequently interfere with the screen readers real users already have configured, and they have been the subject of a large number of US lawsuits against sites that had one installed.
Accessibility plugins for WordPress can genuinely help with specific, narrow things such as skip links or a sensible focus outline. What none of them can do is fix a heading order that carries no meaning, an image with no alternative text, or a form that cannot be completed with a keyboard. Those are in your markup, and they get fixed in your markup.
How much of this can automated testing find?
Somewhere around a third of issues, and the figure is worth taking seriously in both directions. Automated tools are excellent at contrast ratios, missing alt attributes, form labels and landmark structure, and you should absolutely run them because they are free and fast.
What they cannot judge is whether alt text is accurate, whether a focus order makes sense, whether an error message actually tells someone what to do, or whether a custom component behaves the way a screen reader user expects. That is manual work with a keyboard and a screen reader, and it is where the real findings come from.
Does accessibility help SEO?
Partly, and it is worth being precise rather than selling it as a ranking hack. Genuine overlap exists: honest heading structure, descriptive link text, alt attributes, semantic landmarks and captions are all things both a screen reader and a crawler read. Fixing them tends to help both.
But contrast ratios, focus indicators and keyboard traps do not affect rankings at all, and anyone telling you an accessible site ranks better as a rule is overselling. Do it because it is the right thing and because of the legal position. Treat the SEO benefit as a genuine side effect rather than the reason.
What do I actually get?
A prioritised list of real issues, each with the WCAG criterion it fails, where it occurs, what it costs a user in practice, and the specific fix. Ranked by user impact and legal exposure rather than by how many instances a crawler counted.
Where we have access to the codebase we implement the fixes rather than handing them over, which is the same arrangement as the rest of the work here. Where we do not, findings are written so your developers can act on them without a translation layer.
Keep reading
Related
Book me
Want to know where your site actually stands?
Send the domain and the journey that matters most, usually checkout or enquiry. You get a straight answer on the serious failures, whether an overlay has made things worse, and what a fix would take.