Make a scripted div or span keyboard-operable
SCR29 is an advisory technique, and the distinction is doing real work on this page. Its three neighbors for keyboard access, SCR2, SCR20 and SCR35, are all sufficient. This one W3C declines to call sufficient, and says why on its own page. Adding tabindex and key handlers to a div makes it focusable and operable. It still has no role, so assistive technology has nothing to announce it as, and the name, role and value rule remains unmet. Doing everything SCR29 describes leaves you with a control a keyboard can reach and a screen reader cannot identify. That is progress and it is not conformance. The method itself is small. Give the element a tabindex so focus can land on it, add a key handler alongside the click handler, and add a role so the thing has a name for what it is. The version of this that actually finishes the job is SCR35, and the answer there is a button element.
How we find it in an audit
Reviewers tab through the page and stop at anything that behaves like a control. Then come four questions. Can focus reach it, does Enter fire it, does Space fire it, and what does a screen reader call it when it lands. That last question is where advisory techniques come apart, because a div with a keydown handler passes the first three and answers the fourth with silence or with its text content read as plain prose. Automated tools flag click handlers on non-interactive elements reliably, which makes this one of the easier problems to find and one of the harder ones to finish fixing.
How affected users experience it
A screen reader user tabs onto something and hears the words inside it with no indication that it does anything. There is no "button", no "link", no state, nothing that says pressing Enter here would have an effect. Most people move on. A page is full of text, and none of the rest of it is pressable. Someone using speech input has a related problem from the other direction. They cannot say "click Save draft" if nothing on the page is a control called Save draft.
Passes vs. fails
Passes
<button type="button" onclick="saveDraft()">Save draft</button>
<!-- Or, if the div has to stay: -->
<div class="btn" role="button" tabindex="0" onclick="saveDraft()" onkeydown="onEnterOrSpace(event, saveDraft)">Save draft</div>Fails
<div class="btn" onclick="saveDraft()">Save draft</div>
<!-- Tab passes it by, Enter does nothing, and a screen reader reads it as text. -->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 lists this one as advisory for that rule rather than sufficient, which means it helps real readers without being accepted as evidence you conformed.
- 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 SCR29: Adding keyboard-accessible actions to static HTML elements. 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.