Give device-specific scripts a keyboard path
SCR20 is a sufficient technique for keyboard access when it is used with G90, and it covers the case SCR2 cannot. Sometimes one handler genuinely cannot serve both input types, because the mouse version tracks a pointer along a path and the keyboard has no path to track. So you write both. A drag becomes an arrow-key nudge, a pinch becomes a plus and minus key, a double-click becomes Enter. W3C's phrase for what the two branches owe each other is the same action, and the applicability line is the widest in this family, reaching all content that uses script to implement functionality. Our own standard is a little harder. The keyboard branch has to reach the same states as the pointer branch, not a reduced set of them. A zoom that stops at 200% when the mouse reaches 800% is still a feature the keyboard user cannot finish using.
How we find it in an audit
Reviewers run every scripted interaction twice, once with each input method, and put the two results side by side. Automation can tell you which handlers exist. It cannot tell you the keyboard branch is a stub, because a stub and a full implementation look identical from the outside until somebody presses the key. So we work the whole feature from the keyboard and note every state the pointer can reach that the keyboard cannot. This is one of the cases where the W3C test procedure is broader than the technique, since it asks you to check that all interactive functionality works from the keyboard alone. That is an audit of the whole rule, not a check of one script, and it is the check we run anyway.
How affected users experience it
People who cannot use a pointer get the cut-down version of your feature, or none of it. The map pans by drag and only by drag. The image viewer zooms on double-click and ignores every key. From the keyboard side there is no sign that a richer interaction was ever built, because absence looks exactly like a feature that was never designed. Nobody files a support ticket about a control they have no way to discover.
Passes vs. fails
Passes
viewer.addEventListener("mousedown", startDrag);
viewer.addEventListener("keydown", function (e) {
if (e.key === "ArrowLeft") pan(-40, 0);
if (e.key === "+") zoomIn();
});
// Both routes reach every zoom level and every corner of the map.Fails
viewer.addEventListener("mousedown", startDrag);
viewer.addEventListener("dblclick", zoomIn);
// No key handler anywhere. The initial view is the only view.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 only alongside G90, so the pair is what passes and neither half does on its own.
- 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 SCR20: Using both keyboard and other device-specific functions. 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.