ACT Rule ffbc54 · proposed
No keyboard shortcut uses only printable characters
Single letter shortcuts fire while a speech recognition user is dictating, which turns a sentence into a run of commands. This rule checks that any shortcut built from printable characters can be switched off, remapped, or only works while a particular control has focus.
A tool can find the places this applies and then hand you the decision. The rule is proposed, so it has not yet been implemented in full by a tool and reviewed by a W3C working group, and the wording can still change.
What passing this rule proves
This is one of only four rules in the whole published set where W3C says a passing result satisfies the criterion outright. If the rule applies to your page and every result passes, 2.1.4 Character Key Shortcuts is satisfied. A failing result means it is not. On 59 of the other live rules a pass only means no failure of that kind was found, and the remaining 24 name no criterion for a pass to clear.
Two things still hold. If the rule finds no shortcuts at all it returns inapplicable, and an inapplicable result sends the criterion back to needing further testing rather than clearing it. And W3C notes that whatever mechanism you use to turn shortcuts off has itself to meet every Level A criterion.
The criteria this rule is a test for
These are the criteria the rule names as its own conformance requirement. Each one is a far bigger question than this rule asks, and our page for it sets out what the whole criterion covers.
- 2.1.4 Character Key Shortcuts Level A
The normative rule text lives at W3C
What the rule applies to, and exactly what it expects, is published by W3C and can change. We link to it rather than restate it, so nothing here can quietly fall out of date against the source. Read rule ffbc54 at W3C.
Focus must be visible, reachable and escapable
Keyboard users move through a page one stop at a time. Three things have to hold at every stop. You can see where you are, you got there in an order that matches the page, and you can leave again.
Break the last one and you create a keyboard trap. The person cannot go forward, cannot go back. Their only way out is to close the tab and lose whatever they had entered.
Custom widgets and modals cause most of these. A dialog that takes focus but never returns it leaves keyboard users stuck inside it with no way out except closing the entire tab.
Fixes that satisfy it
If this rule fails on your site, these are the techniques that put it right.
All 87 ACT rules are grouped by the criteria they test, and 24 of them decide nothing about WCAG on their own. Run a free scan to see which of these your own pages trip.