Skip to main content

Accessibility discovery

Book it without a mouse

The scenario

You have your arm in a sling for six weeks. You can type, slowly, with one hand. You cannot hold a mouse. You need to book a meeting room for tomorrow morning before somebody else takes it.

Your task

  1. Move your mouse and trackpad out of reach. No touching, no cheating.
  2. Using Tab, Shift and Tab, Enter and the space bar only, book the Ceredigion room at 10:00 and ask for the video kit.
  3. When you get stuck, press the button that counts what a keyboard can actually reach.
Time
10 minutes
Barrier
Controls that are not controls, and focus you cannot see
Success criterion
WCAG 2.2 — 2.1.1 Keyboard and 2.4.7 Focus Visible

Room booking

Version

Book a room

Room

Ceredigion Seats 8 · Second floor
Gower Seats 4 · Ground floor

Time

Choose a time

Extras

Video conference kit

Nothing selected yet.

Focus is on: nothing in the booking form yet

A note on safety: nothing on this page traps your keyboard. Real interfaces do, and when they do there is no way out except closing the tab. If you build a custom dialog, that is the failure to test for first.

What this exercise is showing

Nothing in the first version is broken in a way a mouse would notice. Every control responds to a click. The problem is what the controls are: a div with a click handler is a rectangle that happens to react. It is not in the tab order, it does not respond to Enter or the space bar, and a screen reader announces it as nothing at all.

There is a second failure layered underneath. The one control you can reach, the booking button, has its focus outline removed, so even a keyboard user who gets there cannot see where they are.

This is not a small audience. Keyboard-only use covers people with motor conditions such as Parkinson's, tremor or RSI, people using switch access, eye tracking or voice control, screen reader users, and anybody whose trackpad has died. It also covers the developer in your team who navigates by keyboard because it is faster.

Questions for the group

  • How far did you get before you reached for the mouse? Be honest.
  • Where in our product do we use a div or a styled span as a button, a tab, a card or a menu?
  • Has anyone here removed a focus outline because it looked untidy? What did we replace it with?

What good looks like

  • Use the native element. A button is focusable, operable by Enter and space, and announced as a button, for free.
  • If you must build a custom control, it needs a role, a tab stop, keyboard handlers and a focus state — all four, every time.
  • Never remove a focus indicator without designing a better one. WCAG 2.2 also adds 2.4.11 Focus Not Obscured, so sticky headers and cookie banners must not cover the focused control either.
  • Tab through every new screen before it ships. It takes a minute and it catches most of this.