Accessibility discovery

Telling a team that low contrast is a problem changes very little. Handing them a booking reference they cannot read, and asking them to say it out loud, changes quite a lot.

These are the exercises I use in accessibility discovery sessions: an hour or so with a product team, where everyone does the task rather than watches a slide about it. Each one has a scenario, a task, a deliberately broken interface, and a switch to the version that works. They run in a browser, they need no software and no setup, and they work just as well on a call as in a room.

Take what is useful. Run them in any order, or pick the two that match the thing your team is arguing about this week.

The exercises

• Exercise 1 · 5 minutes

  Read the reference number

  Text that a designer signed off on a big bright monitor, read the way most people actually read it.

  Low contrast text

• Exercise 2 · 10 minutes

  Tell us you have moved

  A form with no labels, no hints and an error message that tells you nothing. Then the same form, done properly.

  Unlabelled controls and unusable error messages

• Exercise 3 · 10 minutes

  Book it without a mouse

  Push the mouse away. Find out how much of an interface simply is not there when you can only use a keyboard.

  Controls that are not controls, and focus you cannot see

• Exercise 4 · 8 minutes

  Find the orders that need action

  A status dashboard that says everything with colour and nothing with words.

  Colour used as the only way of telling things apart

• Exercise 5 · 10 minutes

  Find the returns number by ear

  The same web page twice: once as a picture, once as the words a screen reader actually has to work with.

  Missing alt text, meaningless link text and no headings

• Exercise 6 · 8 minutes

  Buy three, on a moving bus

  Small targets, crowded together, with a destructive button next door. Then measured against the standard.

  Targets too small and too close together

Before you run one

There is a real criticism of this kind of exercise, and it is worth taking seriously. Disability simulations can leave people feeling sorry for disabled users rather than annoyed at bad design. They can turn somebody's ordinary daily life into a party game, and they tend to produce “that was awful, how do they cope?” rather than “we should fix that select element”.

So these exercises are not built as simulations of disability. None of them ask you to pretend to be a disabled person. Every one of them puts a barrier in front of you and then takes it away again, so the thing you come away talking about is the interface, not the person. Keep the debrief pointed at the design, and you will get the useful version of this conversation.

Read the facilitator guide for how to structure the session, what to say at the start, and the questions that get a team from “that was interesting” to something on the backlog.