Accessibility testing with disabled users for NHS and health platforms

Why a checklist is not enough

Automated tools are quick and worth running, but they can only check what a machine can measure: missing alt text, colour contrast, form labels. They cannot tell whether the alt text makes sense, whether a screen reader user can follow the order of a results page, or whether someone with a cognitive impairment understands what a step is asking them to do.

An expert audit against WCAG 2.2 catches far more, and it is how you show conformance. But a service can conform on paper and still be hard to use. Screen reader users skip content by headings, people using voice control need visible labels that match what they say, and magnifier users see one small part of the screen at a time. Those problems show up when you watch them, not when you read the code.

In health, the stakes are higher than in most sectors. A form that defeats someone does not just lose a sale. It sends them to the phone queue, the GP reception desk or nowhere at all.

What the rules expect

NHS trusts and other public bodies are covered by the Public Sector Bodies Accessibility Regulations 2018. Websites and apps must meet WCAG and publish an accessibility statement, and WCAG 2.2 AA is now the level public sector monitoring checks against.

Private health providers and suppliers fall under the Equality Act 2010, which requires reasonable adjustments so disabled people are not put at a substantial disadvantage. Suppliers to the NHS are also asked about accessibility in the Digital Technology Assessment Criteria (DTAC).

The NHS service standard asks teams to make sure everyone can use the service, which in practice means evidence of testing with disabled people, not just a conformance report.

None of these require testing with disabled users in so many words. All of them are far easier to satisfy, and to defend, when you have done it.

Who to include

A useful round covers different ways of using a screen, not just different conditions. We recruit:

• Screen reader users, on JAWS or NVDA on Windows and VoiceOver or TalkBack on phones
• Screen magnifier users, and people with low vision who use zoom and high contrast settings
• Switch and voice control users, often people with limited movement or dexterity
• Keyboard-only users
• People with cognitive or learning disabilities, for whom plain language and predictable steps matter most

For a health platform, also think about who uses it. People with arthritis, Parkinson's, MS or the after-effects of a stroke often use standard devices but struggle with small targets, timeouts and long forms. They are rarely in an accessibility panel because they don't think of themselves as disabled, and they are exactly who your service has to work for.

How a session runs

On their own setup. People test on their own device, with their own assistive technology and settings. A screen reader in a lab with default settings is not the screen reader someone has spent years configuring.

Mostly remote. Testing from home removes the journey, which for many participants is the hardest part, and lets them use their real setup.

Longer, with breaks. Sessions with assistive technology users take longer, and fatigue is real for many people with long-term conditions. We plan for it rather than rushing the tasks.

Realistic tasks. Book an appointment, find a test result, update a medication list. Not "find the menu".

Findings you can act on. Each issue is rated by how badly it blocks people, explained with what we saw, and mapped to the WCAG 2.2 success criteria it relates to, so your developers know where to look.

What it costs

Adding assistive technology users to a usability study, such as two or three screen reader or keyboard-only sessions alongside a standard round: £1,200 to £1,600 on top of the study.

A dedicated round with five or six assistive technology users is priced as usability testing: from £5,500, or £6,250 to £7,250 for five remote sessions on a health product, which carries a 15% uplift for the extra care with consent and governance. Where a recruitment profile is unusually narrow, we say so in the quote before you commit.

Participants are paid properly for their time, and that is included. People who use assistive technology are asked to test things constantly, often unpaid, and paying fairly is part of how we recruit people who aren't jaded professional testers.

For a full breakdown of what sits inside a usability testing price, see how much usability testing costs in the UK.

Questions health teams ask us

Can testing replace a WCAG audit? No, and an audit can't replace testing. The audit shows conformance; testing shows whether people can actually use it. Most teams need both, audit first.

How many participants do we need? Five or six across a mix of assistive technologies will find most of the serious barriers in one round. It will not certify compliance, and it is not meant to.

When should we do it? Before launch, and earlier if you can. Testing a prototype with screen reader users is cheaper than rebuilding a live service.

Do you test native apps as well as websites? Yes, on iOS and Android, with the platform's own assistive technology.