Operable · 2.1 Keyboard Accessible
If keyboard focus can move into a component, users must be able to move focus away again using only the keyboard. If this needs more than unmodified arrow or Tab keys or other standard exit methods, users must be told how to leave.
Live demo
The same task, done two ways: switch between the version that passes and the one that fails, or put them side by side. Everything in the box is live, so try it with a keyboard, a pointer or a screen reader.
Tab to Write a gift message and press Enter, then try to reach Continue to payment. In Fails the box holds on to your focus: press Escape three times to leave the trap.
One scented candle in a gift box, $24.
Press Escape to close this box. What you typed is kept.
One scented candle in a gift box, $24.
Press Escape to close this box. What you typed is kept.
The tools follow the version you last used.
What happened
Why it passes
Tab stays inside the open box, as it should in a modal dialog, but Escape closes it and puts you back on the button that opened it.
Why it fails
Once the box opens, Tab and Shift+Tab only go round inside it and Escape does nothing, so a keyboard user can never reach Continue to payment.
Examples
Four examples, each one running: the usual ways this criterion fails, and code that passes. Listen to them, measure them, or copy the code.
Fails
Live preview
codeEditor.addEventListener("keydown", (event) => { if (event.key === "Tab") { event.preventDefault(); insertAtCursor("\t"); }});Tab and Shift+Tab always insert a tab character, and nothing tells the user another way out. A keyboard user who enters the editor is stuck there.
Passes
Live preview
// Help text beside the editor: "Tab indents. Press Escape, then Tab, to leave the editor."let leaving = false;codeEditor.addEventListener("keydown", (event) => { if (event.key === "Shift") return; if (event.key === "Escape") { leaving = true; return; } if (event.key === "Tab" && !leaving) { event.preventDefault(); insertAtCursor("\t"); } leaving = false;});Tab still indents, but Escape followed by Tab or Shift+Tab moves focus on. Because this is not a standard way out, the help text beside the editor explains it, as the criterion requires.
Fails
Live preview
signupModal.addEventListener("keydown", (event) => { if (event.key !== "Tab") return; const items = signupModal.querySelectorAll("input, button"); const first = items[0]; const last = items[items.length - 1]; if (event.shiftKey && document.activeElement === first) { event.preventDefault(); last.focus(); } else if (!event.shiftKey && document.activeElement === last) { event.preventDefault(); first.focus(); }});// No close button, and Escape is not handledKeeping focus inside is right for a modal dialog, but with no close button and no Escape handling the user can never get back to the page.
Passes
Live preview
<dialog id="signup" aria-labelledby="signup-title"> <h2 id="signup-title">Get 10% off your first order</h2> <form method="dialog"> <label for="signup-email">Email</label> <input id="signup-email" name="email" type="email" autocomplete="email"> <button value="join">Sign up</button> <button value="cancel" formnovalidate>No thanks</button> </form></dialog>Opened with showModal(), the rest of the page is inert while the dialog is open, and both Escape and the No thanks button close it.
Why it matters
Keyboard and screen reader users who get stuck in a widget cannot reach the rest of the page and often have to reload or give up. Because a trap blocks the whole page, WCAG applies this to all content on the page, even content not relied on for conformance.
W3C: Understanding 2.1.2Level A
Level A is the minimum: failing it can shut some people out completely.
Where it is required
Required where the law names WCAG 2.0 or later at this level: the United States, Canada, the European Union, the United Kingdom, France, Germany, Italy, Spain, the Netherlands, Ireland, Norway, Switzerland, India, Japan, Australia, New Zealand and Israel.
How to test
A few concrete steps. Automated tools find some failures; most need a person.
Common failures