Accessible digital CBT: testing a therapy product

Cognitive behavioural therapy (CBT) delivered as an app or a website is still software, and it breaks in the ways software breaks.

Why a therapy product is an accessibility product

A digital mental health service is a product with accounts, forms, scales, audio, video, charts and timed exercises. Every one of those is an accessibility surface, and each one has its own way of excluding people.

The audience for it is also wider than the audience for most products. Disability and poor mental health overlap in both directions, and a service that is hard to operate reaches fewer of the people it was built for.

We test software. We do not deliver therapy, we take no view on clinical content, and we make no claim about outcomes. That boundary is worth stating plainly, because it is what makes the rest of this post useful rather than promotional.

Where these products break

  • The scales. A mood or symptom scale built as a slider that only drags, or as a row of small circles, is hard to operate with a keyboard, a motor impairment or a screen reader. Dragging needs a single pointer alternative (WCAG 2.2, 2.5.7), targets need to be big enough (2.5.8), and every input needs a label (3.3.2) with its meaning not carried by colour alone (1.4.1).
  • The audio. A guided exercise that exists only as audio needs a transcript, and a timed one needs captions as well (1.2.1, 1.2.2).
  • The timing. A breathing animation that cannot be paused sits badly with WCAG 2.2.2 if it runs for more than five seconds, and any interaction driven by motion has to respect the reader's request for less of it (2.3.3). Our own site handles this with the pause control in the running head.
  • The sign in. A puzzle or a memory test to log in is a cognitive function test, which WCAG 2.2 restricts at 3.3.8. Pasting a password has to work.
  • The questions asked twice. A service that asks for a date of birth, a medication and a sleep pattern at intake should not ask for them again at week two (3.3.7).
  • The language. Clinical vocabulary is often unavoidable, and where it is, it needs a plain explanation beside it. Reading level sits at 3.1.5, and its absence is the single most common finding in this sector.
  • The charts. A line of mood over weeks needs a text alternative and enough contrast to be read at all (1.1.1, 1.4.11). A chart is information, not decoration.

How we test a service like this

With the tools the audience actually uses: VoiceOver on iOS and TalkBack on Android on real devices, NVDA (NonVisual Desktop Access) and JAWS on desktop, keyboard only, and screen magnification at 200 and 400 per cent text.

Then with attention to the states that only turn up under strain. What does the screen do when a reader is in distress and gets a validation error? Can they stop a breathing exercise halfway and come back? Does the session survive a long gap, or does it throw away an hour of typing?

Our mobile app accessibility testing guide covers the device side, and the method is set out in full on how we test.

What to ask any testing supplier

Four questions sort the useful answers from the rest. Do you test with real assistive technology on real devices, or only with a scanner? Do you test motion, timing and pause behaviour? Do you test the states a reader reaches when the service is failing? And will the report name the criterion for every finding, so your clinical and product teams can argue with it?

We answer yes to all four, and the accessibility audit and testing page sets out exactly what is delivered. If it is easier, start with the free one-page audit and read our own findings before you buy anything.

Test the page that matters

One free page, tested by hand, with the findings written out.