Skip to main content

Facilitator guide

How to run an accessibility discovery session

The exercises are the easy part. What decides whether a session changes anything is how you open it, and what you do in the ten minutes after it.

What this is for

An accessibility discovery session is not training. Nobody leaves knowing how to write an accessible autocomplete. What they leave with is a felt sense that the barriers are real, specific and fixable — and, if it goes well, two or three things written down that they want to change in their own product.

It works best with a whole product team together: designers, engineers, a product manager, a content designer, a tester. Six to twelve people. Mixed disciplines matter, because half the value is a designer and an engineer disagreeing out loud about whose problem the error summary is.

A 60 minute shape

  1. Frame it, 5 minutes. Say what the session is and, just as importantly, what it is not. See the script below.
  2. Three exercises, 30 minutes. Ten minutes each: five doing, five talking. Do not try to fit all six in; three done properly beats six rushed.
  3. Debrief, 15 minutes. Move from the exercises to your own product. This is the part people cut when time runs short, and it is the part that does the work.
  4. Commitments, 10 minutes. Everyone names one thing they will look at in your product this month. Write them down where the team will see them again.

Picking three

  • Design-heavy team: low contrast, colour alone, target size.
  • Engineering-heavy team: keyboard only, form controls, screen reader.
  • A team that has never thought about this: form controls, keyboard only, screen reader. These three land hardest.
  • A design system team: form controls and target size, then ask which of these could only be fixed once, centrally.

What to say at the start

Everything you are about to use is deliberately broken. None of it is a trick and none of it is a test — if you get stuck, that is the exercise working.

We are not simulating disability today. I am not asking anyone to imagine what it is like to be blind, and none of these exercises would tell you that anyway. What they do is put a barrier between you and something you are trying to finish. The thing worth noticing is the barrier, not the feeling.

If anyone in the room has a disability, please say as much or as little as you want. You are not the exhibit, and you do not have to answer questions about how you use a computer.

That last point matters more than it looks. There is very likely a disabled person in the room, and they may not have told you. Do not put anyone in the position of being the live demonstration.

Running it well

  • Everyone does it on their own device. Watching the facilitator do it is not the same experience.
  • Do the target size exercise on phones. It barely registers on a laptop with a trackpad.
  • Make people say their numbers out loud — the contrast ratio they stopped at, the number of attempts, the mis-tap count. The spread across the room is the interesting bit.
  • Do not rescue people. The silence while somebody hunts for a keyboard-reachable control is doing the teaching. Let it run.
  • Always switch to the accessible version. Ending on the broken one leaves people with a feeling. Ending on the fixed one leaves them with a solution.
  • Watch the language. Redirect “how do they cope?” to “what would we have to change?” every single time. It takes a couple of goes and then the room does it for you.

Debrief questions that work

  1. Which exercise made you think of something in our own product? Be specific — name the screen.
  2. Which of these would we only have to fix once, in the design system, and which would we have to fix on every screen?
  3. Which of these would our current process have caught? At what point — design review, pull request, QA, never?
  4. What is the thing we already knew was wrong and have not fixed? Why not?
  5. If one of these barriers was in our checkout tomorrow, who would find out, and how?

Question four is usually the one that changes the conversation. Most teams already know about at least one barrier. The interesting question is not awareness, it is what is stopping the fix.

Afterwards

Within a day, send round three things:

  • The list of commitments people made, with names against them.
  • A link back to these exercises, so people can show somebody else.
  • One concrete next step that is yours, not theirs — a ticket you raised, a component you are fixing, a check you are adding to the definition of done.

A discovery session on its own is a nice hour. A discovery session followed by a visible change is how a team starts to believe the subject is real.

Running it remotely

It works on a call, with two adjustments. Put people in breakout rooms of three so nobody does the exercise in silence with their camera off, and ask one person per room to narrate what they are doing. Come back together for the debrief and keep the exercise pages open so you can share your screen and point at things.

If you want more

  • Ask a colleague who uses assistive technology every day whether they would be willing to demonstrate their setup, paid and on their terms. Fifteen minutes of that is worth more than everything here. It is their expertise, so treat it that way.
  • Book real usability sessions with disabled participants. Empathy exercises tell you that barriers exist. Only research tells you which ones are hurting your users.
  • Read the WCAG 2.2 Understanding documents. They are far more readable than the standard itself, and every exercise here links to the relevant one.