Keyboard only: put the mouse away

One American adult in eight has a mobility disability⁷.

The guidelines list who depends on the keyboard: people who cannot use a mouse, people with hand tremors, people who are blind and use a screen reader, and anyone using speech input, sip-and-puff, an on-screen keyboard or scanning software¹, all of which reach a page through the same door. A broken arm in a sling makes anyone a keyboard user for six weeks, and many people simply work faster without a mouse.

The most common failure is a control built from a plain box with a click handler. It looks like a button, and the Tab key never stops on it.

Close behind: focus outlines removed because a designer found them ugly, so nobody can see where they are; focus that lands under a sticky header; menus and date pickers that only open on hover; and pop-up dialogs that let the focus wander behind them, or never hand it back when they close. The rule is simple to state: everything you can do with a mouse must be possible with a keyboard¹, and you must always be able to see where the keyboard is.

The cost of getting it wrong is real. In 2025 more than 5,000 digital accessibility lawsuits⁸ were filed in the United States, nearly half of the federal ones against companies that had been sued before, and about 1,400 against sites that had installed an accessibility widget to avoid exactly that.

This tool reads the page’s structure, so it needs real text, headings and buttons. A Figma prototype is drawn as a picture, with nothing underneath to read, and the tool will say so rather than report nonsense.

It does work on prototypes built as real pages: Axure, UXPin and Justinmind exports, Framer and Webflow previews, Storybook stories, and apps generated by tools like Figma Make or v0. If the content sits in a frame from another site, the tool offers to open the frame on its own.