Do not wire functionality to pointer events only
F54 is a documented failure under the keyboard rule, and its title names something people forget it covers. Pointing-device-specific handlers, gestures included. So a mousedown-only control is inside it and so is a swipe with no alternative. There is an exception written into the rule and it decides the real cases. Functions needing input that depends on the path of the user's movement, rather than just its endpoints, are exempt, and that is what makes freehand drawing, signature capture and some map interactions conforming. The exception attaches to the underlying function rather than to the input method, so handwriting recognition is path-dependent and typing the same words is not. Everything else needs a keyboard route, and on a real button the click event already is one.
How we find it in an audit
The published procedure is two steps and the second is the one that prevents false findings. Check whether pointer-specific handlers are the only way to invoke the function, then check whether the function genuinely needs path information. We run both, in that order, because flagging a drawing canvas as a keyboard failure wastes everybody's time. Automated tools find pointer handlers on non-interactive elements well. Whether a path is essential is a question about what the feature does.
How affected users experience it
Two groups are named on the published page and the second is the larger one. People with no vision, who cannot use a device needing hand and eye together. And people using alternate keyboards or devices that emulate a keyboard, which covers switch access, sip-and-puff, head pointers and most speech input. For all of them a mousedown handler is not a harder route to the feature. It is the absence of one. The control is on screen, described correctly, and pressing it is not something their equipment can do.
Passes vs. fails
Passes
<button onclick="openFilters()">Filters</button>
<!-- click fires for mouse, keyboard and touch alike. -->Fails
<div onmousedown="openFilters()">Filters</div>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
The other techniques filed under this rule
13 guides on this site are filed under 2.1.1 Keyboard. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- G90sufficientPair every event handler with keyboard support
- 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
This guide is our interpretation of W3C technique F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function. 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.