Do not trap keyboard users inside embedded content
F10 is a documented failure for the no keyboard trap rule, and it is the most serious kind of finding a page can carry. Focus goes into something and cannot come out. The technique was written for pages combining formats, where a plug-in catches focus and the only way out is closing the browser, and its applicability is phrased around the outcome rather than the technology. So anything a keyboard can enter and cannot leave is inside it, embedded players and editors and third-party widgets included. One trap fails the whole page rather than the component, because content that stops somebody using a page is treated as interference with everything else on it. There is a legitimate way to hold focus and it gets missed. If escaping needs something other than Tab, Shift and Tab, or another standard exit, the user has to be told what the key is.
How we find it in an audit
Reviewers tab into every embedded thing on the page and then try to leave it, first with Tab, then with Shift and Tab, then with Escape. If none of those work we look for instructions telling the user what does, because a documented exit is part of how this rule gets met rather than a consolation prize. Automated tools cannot find a trap, since it is a behavior rather than a property of the markup. So this is always a person with a keyboard and no mouse.
How affected users experience it
A keyboard user reaches your video player, or your rich text editor, or a third-party booking widget, and focus goes in. Tab moves within it. Shift and Tab moves within it. Escape does nothing. There is no route back to the page, no route forward to the footer, and no message explaining what is happening. What is left is closing the tab, which throws away everything they had done, and the page they were trying to use is the one page they can never finish.
Passes vs. fails
Passes
<div role="dialog" aria-label="Store locator" onkeydown="if (event.key === 'Escape') closeLocator()">
<p>Press Escape to return to the page.</p>
<!-- Focus can leave, and the way out is written where the user will meet it. -->Fails
<embed src="locator-widget.html">
<!-- Focus enters the widget. Tab, Shift+Tab and Escape all keep it there. -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Focusable element has no keyboard trapA tool can check this
- Focusable element has no keyboard trap via standard navigationNothing implements this yet
- Focusable element has no keyboard trap via non-standard navigationA tool can check this
The other techniques filed under this rule
2 guides on this site are filed under 2.1.2 No Keyboard Trap. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
This guide is our interpretation of W3C technique F10: Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining multiple content formats in a way that traps users inside one format type. 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.