Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Focus trap

Also called: Keyboard trap

A focus trap is somewhere on a page that keyboard focus can get into and not out of. A mouse user clicks past it and never knows it was there. Somebody on a keyboard presses Tab and watches it cycle round the same three controls, and their options narrow to leaving the page. It is a Level A failure, and it is one of the few that can end a session outright rather than just make it harder. Two things are worth knowing before you go looking for one. Keeping focus inside a modal dialog on purpose is not a trap, and it is the correct way to build one, as long as there is a way out. A dialog that is not modal is a different case, because nothing outside it has been switched off, so containing the tab sequence there needs a deliberate way back into the page. And a component that needs something other than Tab or the arrow keys to release focus still conforms if it tells the user which key does it. A media player that says press Escape to leave is passing, not failing.

In practice

Open every modal, dropdown, date picker, media player and cookie banner, then try to leave using the keyboard alone. Escape first, then Tab. If one of them needs a different key, the question is not whether that is allowed. It is whether the page says so on screen, because that is the difference between a conforming component and a Level A failure.

The exit test is deliberately vague in the standard, which surprises people. WCAG never defines what counts as a standard exit method, on the grounds that it depends on the hardware, the browser and the operating system. Escape is the convention because the authoring practices for dialogs say so, not because the rule does. Our Escape-and-Tab check is a sensible way of operationalising it rather than the letter of anything.

Third-party embeds are structurally harder and the reason is worth knowing. An iframe is another document, so focus inside it has left your page, and where the frame sits on another origin your scripts cannot reach in to help. That is why a chat widget or an embedded player is the first place to look.

The it-is-not-our-script defence does not work either. This is one of four criteria that apply to everything on the page whether you rely on it or not. A failure in any of them can take the rest of the page down with it. A trap in somebody else's widget is a trap on your page.

Why it matters

Most accessibility failures cost somebody time or dignity. This one costs them the session. They cannot continue, cannot go back, and depending on the browser and the platform may not be able to reach the browser's own controls either. That is why it sits at Level A alongside things like flashing content, and it is why you test the components you did not write before the ones you did. Start with the cookie banner.

The check

Open the cookie banner on your own site and try to dismiss it without touching the mouse. Then do the same for the newsletter popup, the chat bubble and the date picker in your booking form. Anything you can get into and cannot get out of is a defect, and anything that needs an unusual key is only a defect if the screen never told you which key.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations