Pair every mouse handler with a keyboard one
SCR2 is a sufficient technique for keyboard access when you use it with G90, the general technique for keyboard-triggered handlers. The method is small enough to hold in your head. Anything wired to onmouseover gets the same thing wired to onfocus, and anything wired to onmouseout gets it on onblur. Both live on the same element, so the effect fires whichever way the user arrives. W3C's own worked example is modest, a decorative image that swaps on hover and swaps back on blur, and that is the case the technique was written for. Your case is probably bigger. If the hover reveals content rather than swapping a picture, pairing the handlers is the floor rather than the finish. Content that appears on hover also has to be hoverable, dismissible and persistent under SCR39.
How we find it in an audit
A scanner can list elements carrying mouse handlers with no keyboard twin, and that list is a starting point rather than a finding. What it cannot do is confirm the twin does the same job, because a handler named onfocus can be wired to nothing at all. So a reviewer unplugs the mouse, tabs to each element on the list, and holds the keyboard result next to the pointer result. Same content, same timing, same way out. Anything less is a partial fix that will pass an automated re-scan.
How affected users experience it
Keyboard-only users cover more people than the phrase suggests. Blind screen reader users are in it, and so is anyone with tremor, limited hand movement, or an input device that emulates a keyboard rather than a pointer. They reach the element. They press Enter. Nothing happens. There is no error and no missing-feature notice, because as far as the page is concerned nothing went wrong. The feature simply does not exist on their side of the screen.
Passes vs. fails
Passes
<a href="#detail" onmouseover="preview(this)" onfocus="preview(this)" onmouseout="hidePreview()" onblur="hidePreview()">Chart</a>
<!-- Focus now does exactly what hover does. -->Fails
<a href="#detail" onmouseover="preview(this)" onmouseout="hidePreview()">Chart</a>
<!-- Tab to it and nothing appears. The preview belongs to the pointer. -->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 SCR2: Using redundant keyboard and mouse 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.