Skip to main content

Accessibility Testing

Making software usable by people with disabilities, and meeting the obligations that increasingly come with it. Automated tools find about a third.

Why This Reaches Your Desk

Three routes, and increasingly the third.

Because people cannot use it. Around one in five people has a disability, and a form that cannot be completed with a keyboard excludes them entirely.

Because a customer requires it. Public sector contracts routinely do, and larger private buyers increasingly ask during procurement. An unanswerable accessibility question can lose a bid.

Because of the obligations. UK public sector bodies have direct duties, the European Accessibility Act extends requirements to a range of private services, and the Equality Act applies to services generally. The direction of travel is one way.

The Standard, Briefly

WCAG, usually version 2.1 or 2.2, at level AA. That is what contracts and regulations reference.

AA is the practical target. A is insufficient for most obligations, and AAA is aspirational and rarely required outside specific contexts.

It covers four principles: content must be perceivable, interface operable, information understandable, and the whole thing robust enough to work with assistive technology.

What Automated Tools Actually Catch

Roughly a third of issues, and it is worth knowing which third.

Found automatically: missing image descriptions, insufficient colour contrast, missing form labels, absent page language, invalid markup structure.

Not found automatically: whether an image description is meaningful rather than merely present, whether the keyboard order makes sense, whether an error message is announced to a screen reader, whether a custom component behaves as its role implies, whether the page is understandable when read aloud.

That second list is where real exclusion happens. A site can pass every automated check and remain unusable.

The Test That Finds Most Problems

Unplug the mouse.

Try to complete your main task using only the keyboard. Tab through it. Can you reach everything, is it visible which element has focus, can you escape from menus and dialogues, does the order make sense, can you submit the form?

That single exercise finds a large share of real issues, takes ten minutes, and requires no tools or expertise. Custom dropdowns, modals and date pickers are where it usually fails.

What Moves The Price

How many distinct templates or screens, rather than how many pages.

How much custom interface there is. Standard HTML elements are accessible by default. Custom-built dropdowns, tabs and modals have to be made accessible deliberately.

Whether testing includes assistive technology, which is slower and finds what automation cannot.

Whether remediation is included or only the audit.

Whether you need a formal accessibility statement, which public sector work requires.

Where This Goes Wrong

Treating it as a checklist at the end. Retrofitting accessibility into a finished interface is substantially more expensive than designing for it, particularly around custom components and focus handling.

An overlay widget. Sold as instant compliance, widely criticised by disability organisations, and it does not fix the underlying issues.

Automated pass declared as compliance. Covers a third.

Ignoring documents. PDFs and downloads are in scope and are frequently the least accessible thing you publish.

Questions To Ask Whoever Tests It

  • What proportion is manual? Automated-only is a third of the picture.
  • Is testing done with a screen reader, and which one?
  • Does the quote include fixing, or only finding?
  • Will we get an accessibility statement? Required for public sector.
  • Are documents and PDFs in scope?

A Brief You Can Send Anyone

What needs testing: [site, application, or both]
Rough template count: [not page count]
Why now: [contract, regulation, complaint, or principle]
Target: [WCAG 2.2 AA unless told otherwise]
Custom components: [dropdowns, modals, date pickers, charts]
Documents in scope: [PDFs, downloads]
Deadline: [and who set it]

How We Approach It

Automated scanning for the mechanical third, keyboard and screen reader testing for the rest, prioritised by what actually blocks somebody from completing a task rather than by the number of findings.

Building it in during design is dramatically cheaper than adding it afterwards, so if there is a build coming, that is the moment.

The wider testing picture is on the testing page.

Portrait of Alexander De Sousa, founder of Digital Royalty
Founder-led
“I’ve put everything I know into how this company works — the standards, the method, the care on every project. It runs through the whole team, and I hold us all to it.”

Alexander De Sousa · Founder LinkedIn

Featured on BBC Radio Solent

Get started

Tell us what you need

A few quick questions, then a straight answer from a real person — usually within a few hours.

Tell us what you're working on

Whether it's a new site, a platform, or a process that shouldn't be manual any more — we'll tell you honestly if we can help.