Keyboard (No Exception)
The Level A keyboard rule lets you off for functions where the path of the movement is the point, like freehand drawing. This one removes that single exception and nothing else. Both criteria say the same thing about keystroke timing, word for word, so there is no timing allowance here for AAA to take away.
Why it matters
Removing the exception does not put you under a duty to make drawing work by keyboard. W3C says so in as many words. It means content genuinely needing path-dependent input cannot meet this criterion at all, so the useful question is a different one. How much of what you excluded ever needed the path? The test for that sits in the Level A rule's own notes. The exception is about the underlying function, not the input technique you picked. Handwriting needs a path. Entering text does not.
Who this rule protects
Keyboard users, switch users and voice control users all reach a page through a keyboard interface, which is why this goes further than people typing on a physical keyboard.
How to check it yourself
- List anything you excluded from keyboard support under the path-dependent exception.
- For each one, ask whether the underlying function needs the path or only the input you chose for it. A signature needs a path. A name does not.
- Try to complete each one by keyboard alone, counting a separate keyboard route as a pass, because W3C does.
- Check any iframe you have pulled out of the tab order, which is the one automated rule that maps here.
Failures we see most often
- The exception gets claimed for drag-and-drop reordering, where the underlying function is moving an item and the path is only the interaction somebody chose.
- A signature pad accepts nothing but a drawn line, when a typed name would carry out the same function.
- An iframe holding focusable content is excluded from the tab order, so the keyboard cannot reach what is inside it.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
How this one is tested
We list 2 ACT rules against 2.1.3. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- 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
How to fix it
- Give drag interactions a move-up and move-down keyboard route.
- Add arrow-key panning and zoom controls to map interfaces.
- Accept a typed name wherever a signature is a formality rather than an actual drawing.
- Where the whole interaction resists it, build a separate keyboard mode instead of contorting the pointer one. W3C accepts that as conformance.
Fix guides for the related rule
Our fix guides are mapped to the 55 rules an audit tests, so none of them is filed against this enhanced criterion. W3C does document techniques for it, and the nearest work we have written up is 2.1.1 Keyboard, which asks for the same thing at a lower bar. Clearing that bar does not clear this one, so treat its 13 fix guides as the place to start rather than the answer.
Passes vs. fails
Passes
The same plan adds a keyboard-navigable list of available seats beside the chart, which is a separate mode of operation and passes.
Fails
A seating plan can only be chosen by clicking, with no other route to a seat.
In audits and lawsuits
This is Level AAA and unreachable for a drawing tool where the stroke itself is the content. It has no techniques of its own either. W3C tells you to follow the Level A ones, and says that where path-dependent input is genuinely required, the criterion cannot be met. Two things it does allow are worth knowing, because auditors write both up as findings and neither is one. A separate keyboard mode of operation passes. So does a custom control responding to Enter but not Space, since platform conventions are best practice here rather than a requirement.