Pair every event handler with keyboard support
Anything a mouse can do, a keyboard has to be able to do as well. G90 is the technique of making sure every handler bound to a pointer event has a keyboard route to the same function, and W3C counts it as sufficient for the keyboard rule at Level A, using a more specific technique. Two ways of satisfying it exist. Bind the keyboard event alongside the pointer one, or provide a separate keyboard mechanism reaching the same outcome. The second is often the better answer, because drag-and-drop reordering does not become keyboard-operable by adding a keypress. It becomes keyboard-operable by adding cut and paste, or a field where you type the new position. Native buttons and links do all of this already, which is the strongest argument for using them.
How we find it in an audit
Every flow gets driven with the keyboard alone, mouse unplugged, and anything that cannot be completed that way is a finding. That is the whole test and nothing substitutes for it. A source scan for pointer-only handlers narrows the search first, looking for mousedown, mouseover, mousemove and their touch equivalents with no keyboard partner. Then the reviewer checks the keyboard route reaches the same outcome rather than a reduced version of it, because a keyboard path that does half the job is a finding of its own.
How affected users experience it
Screen-reader users are keyboard users, and so are switch users, voice-control users, and anyone whose tremor or repetitive strain injury rules out a mouse. When a function exists only on hover or only on drag, none of them can reach it, and usually nothing on the page tells them the function is there at all. That last part is what stings. They are not being blocked from something they can see. They never find out it existed.
Passes vs. fails
Passes
The trigger is focusable, so focus and mouseover both show the tooltip, and Escape dismisses it either way.
Fails
A tooltip with the account's payment status appears on mouseover only, so keyboard users never learn the status.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Iframe with interactive elements is not excluded from tab-orderA tool can check this
- Scrollable content can be reached with sequential focus navigationA tool can check this
Other ways to satisfy this rule
13 guides on this site are filed under 2.1.1 Keyboard. W3C lists this one as sufficient for that rule when it is implemented through a more specific technique, so the condition is part of the test rather than a footnote to it.
- G202sufficientMake every control work with a keyboard
- H91sufficientUse native HTML controls instead of rebuilt ones
- PDF3sufficientFix the reading and tab order in PDFs
- PDF11sufficientTag PDF links so they are announced
- PDF23sufficientUse fillable form fields instead of flat text
- SCR2sufficientPair every mouse handler with a keyboard one
This guide is our interpretation of W3C technique G90: Providing keyboard-triggered event handlers. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.