Accessibility testing has a slightly dangerous reputation for being more complete than it really is.
Run Axe. Check contrast. Tab through the page. Fire up a screen reader. Fix the errors. Get the audit. Tick the box.
Job done?
Not quite.
The more useful way to think about accessibility testing is as a stack of evidence. Code can tell you one thing. Automated tools can tell you another. Manual inspection adds context. Assistive technology testing tells you how the interface behaves outside the happy path. And real disabled people tell you the bit that matters most: whether they can actually use the thing.
That distinction matters because technically accessible and genuinely usable are not synonyms.
Across See Me Please testing, we repeatedly see issues that pass automated checks but still create significant friction for disabled users, particularly around date pickers, comparison tables, error recovery, button purpose and page structure.
What is accessibility testing?
Accessibility testing is the process of checking whether a digital product can be perceived, understood, navigated and operated by people with disabilities. A robust approach combines automated testing, manual checks, keyboard testing, assistive technology testing and usability testing with disabled people.
In other words, accessibility testing is not one test. It is a collection of different methods that answer different questions.
W3C recommends evaluating accessibility early and throughout design and development, rather than leaving it until the end. GOV.UK similarly recommends accessibility testing as part of the delivery process, not as a final gate before launch.
That matters because the later a problem is found, the more expensive and awkward it usually becomes to fix. By the time an inaccessible date picker reaches production, it may already sit inside a shared component library, several customer journeys and three teams’ roadmaps.
Accessibility has a habit of arriving shortly before launch wearing a clipboard.
It works much better when it is already in the room.
When should accessibility testing happen?
Accessibility testing should begin during design and continue throughout development, release and ongoing product change. Testing early makes barriers easier to fix, while regular retesting helps catch accessibility issues introduced by new features, content and interface changes.
W3C recommends evaluating accessibility early and throughout the development process. DWP guidance also notes that interface changes can introduce new accessibility problems, so testing should not be treated as a one-off exercise.
Accessibility is not a certificate you obtain at 4:37 pm on launch day.
A mature accessibility practice tests prototypes, components, production code and significant updates. It also retests after fixes because a technically correct change can still create a strange or difficult experience in context.
Can automated accessibility testing find every issue?
No. Automated accessibility testing is valuable, fast and scalable, but it cannot identify every accessibility barrier. Automated tools are strongest at finding machine-detectable problems in code, while many issues involving context, meaning, interaction and usability require human judgement.
DWP notes that even strong automated testing tools identify only a portion of known accessibility issues when used on their own. Harvard similarly points out that automated tools cannot understand context or judge the quality of content.
That is not an argument against automation. It is an argument against asking automation to do a job it cannot do.
A scanner can tell you an image has alt text.
It cannot reliably tell you whether “image123-final-final-v2.jpg” is a useful description of what the image actually communicates.
It can detect that a form field has a label. It cannot necessarily tell you whether a human being understands what you are asking them to enter.
It can identify a technically valid heading structure. It cannot tell you whether the page still feels like someone emptied a filing cabinet into a browser.
Automation answers an important question:
Can a machine identify a known accessibility problem here?
It does not fully answer:
Can a person use this?
What is the difference between accessibility testing and usability testing?
Accessibility testing checks whether disabled people can access and operate a digital product and whether it meets relevant technical requirements. Usability testing examines how effectively, efficiently and confidently people can complete real tasks. The two overlap, but passing technical accessibility checks does not guarantee a usable experience.
This distinction is one of the most important things teams can understand.
A blind user may technically be able to complete an insurance quote but spend twelve minutes hunting through headings because the page structure makes no sense.
A person with low vision may eventually discover more products hidden horizontally in a comparison table, but only after being told they exist.
A neurodivergent participant may complete a form successfully while being overwhelmed by the density of instructions, interruptions and error messages.
An older user may be able to activate every control yet remain uncertain about what will happen next.
None of those experiences becomes good simply because the user eventually reaches the confirmation page.
Accessibility asks whether the door can be opened.
Usability asks what happens once someone walks through it.
Should accessibility testing include disabled users?
Yes. Disabled users should be included in accessibility testing because lived experience reveals barriers, workarounds and usability problems that standards, automated tools and expert reviews can miss. Testing with disabled people is particularly valuable when evaluating real tasks, complex interactions and whether a fix has genuinely improved the experience.
W3C recommends involving people with disabilities in accessibility evaluation throughout development. GOV.UK guidance also recommends testing services with disabled users.
There is an important distinction here.
Testing with assistive technology is useful.
Testing with people who rely on that assistive technology every day is different.
A sighted developer learning NVDA can catch real problems and build valuable understanding. But they do not instantly acquire the strategies, expectations, speed or lived experience of a blind person who has used a screen reader for years.
Knowing how to turn VoiceOver on does not award you an honorary lived experience.
When disabled people join the research, the question changes from:
Does this meet the requirement?
to:
What is this actually like to use?
That is a much more useful product question.
Which assistive technologies should you test with?
Assistive technology testing should reflect the users, platforms and devices relevant to the product. Common examples include screen readers such as NVDA, JAWS, VoiceOver and TalkBack, screen magnification and zoom, keyboard-only navigation, and voice control or speech input.
DWP identifies screen readers, voice control software and screen magnification as important assistive technology categories. Harvard and Canadian accessibility guidance also recommend screen reader, keyboard and mobile assistive technology testing.
The exact mix depends on your product and audience, but one principle is fairly universal: do not test only in the way the team itself uses the product.
A visually beautiful custom dropdown can become dozens of poorly announced options for a screen reader user.
A carousel that clearly continues sideways on a large monitor may simply appear to end for someone using heavy magnification.
A drag-and-drop interaction can be delightful until you cannot use a mouse.
Assistive technology exposes what the interface becomes when people interact with it differently.
Does WCAG compliance mean a website is usable?
No. WCAG conformance is an essential foundation for digital accessibility, but it does not guarantee that a website or app is easy, efficient or intuitive for disabled people to use. Technical compliance and lived usability are related, but they are not the same measure.
WCAG gives teams a shared technical standard and a critical foundation. W3C provides formal methods for evaluating conformance, and public sector guidance in the UK requires organisations to meet defined WCAG criteria.
You should absolutely test against it.
The problem begins when organisations quietly translate:
“We conform to WCAG”
into:
“Therefore disabled people will have a good experience.”
That second sentence requires evidence of its own.
Across See Me Please testing, we repeatedly see issues that are technically valid or invisible to automated checks but still create meaningful friction. Date pickers can be operable but exhausting. Comparison tables can be technically structured yet difficult to compare. Error messages can exist but still leave people unsure how to recover. Buttons can have labels without communicating useful purpose. Pages can contain headings without providing a structure that helps someone navigate.
Compliance tells you whether something passes. Lived experience tells you whether it works.
The See Me Please accessibility testing stack
We think of accessibility testing as five layers. Each layer answers a different question, and together they give teams a much more useful picture of accessibility.
1. Code
Is the underlying implementation technically accessible?
Semantic HTML, programmatic relationships, accessible names, roles, states and other foundations matter. If the underlying implementation is broken, assistive technology often has very little to work with.
2. Automation
Can known machine-detectable failures be identified quickly?
Automated testing is excellent for scale and consistency. It should be built into design systems, development workflows and CI pipelines wherever practical.
3. Human review
Does the interface make sense when somebody applies judgement?
Manual testing helps evaluate keyboard behaviour, focus order, headings, content, labels, error handling, interaction patterns and all the small contextual decisions machines struggle to judge.
4. Assistive technology
Does the product behave correctly through the technology people actually use?
This includes screen readers, magnification, keyboard navigation, voice control and relevant mobile accessibility features.
5. Lived experience
Can disabled people complete the task comfortably, confidently and independently?
This is where teams learn not only whether something technically works, but what it is actually like to use.
The layers are not competing methodologies. They are complementary evidence.
Remove one and you create a blind spot.
Accessibility testing checklist
A robust accessibility testing programme should include automated testing, manual WCAG checks, keyboard testing, assistive technology testing, testing across browsers and devices, and usability testing with disabled people.
As a practical checklist, teams should ask:
- Have we run automated accessibility checks?
- Have we manually reviewed keyboard access, focus order, labels, headings, errors and content?
- Have we tested relevant journeys with screen readers and other assistive technologies?
- Have we checked zoom, magnification and responsive behaviour?
- Have we tested across the browsers, devices and operating systems our customers use?
- Have disabled users completed realistic tasks?
- Have we retested important fixes?
- Are accessibility checks built into ongoing delivery rather than saved for launch?
The bit we care about at See Me Please
At See Me Please, we spend a lot of time watching people encounter things nobody deliberately designed.
Nobody designed the date picker to make someone give up.
Nobody designed the comparison table so a person using magnification would miss half the products.
Nobody deliberately made the button meaningless to a screen reader.
Nobody put “exclude disabled customers” into the acceptance criteria.
Most barriers are considerably more mundane than that.
They survive because everybody building the product sees roughly the same interface, uses roughly the same interaction patterns and knows roughly how the thing is supposed to work.
Then someone different uses it.
And suddenly a tiny design decision becomes very visible.
That is why we are big fans of standards, automated tools, manual testing and expert accessibility reviews. They are all necessary parts of a mature accessibility practice.
We just do not think the story should end there.
An audit can tell you what failed.
A person can show you what that failure feels like, what it prevents them from doing, what they expected instead and whether your fix actually made things better.
That insight tends to travel much further through a product team than row 187 of a spreadsheet.
Accessibility is hard to explain.
It is very easy to observe.
And sometimes thirty seconds of watching somebody use your product teaches a team more than thirty pages of findings ever could.
The strongest accessibility programmes do not choose between standards and humans.
They use the standards to find problems, and people to understand them.
Sources
W3C Web Accessibility Initiative, Evaluating Web Accessibility Overview
https://www.w3.org/WAI/test-evaluate/
DWP Accessibility Manual, How to do accessibility testing
https://accessibility-manual.dwp.gov.uk/best-practice/how-to-do-accessibility-testing
GOV.UK Service Manual, Testing for accessibility
https://www.gov.uk/service-manual/helping-people-to-use-your-service/testing-for-accessibility
Digital NSW, Accessibility testing
Harvard University, Accessibility Testing Tools and Practices
https://accessibility.huit.harvard.edu/testing
Government of Canada, Accessibility Testing 101
