Every page has a route most visitors never see: the order in which the Tab key moves from one control to the next. For someone who browses without a mouse, that route is the whole website.
A keyboard trap is a point where the route stops. Focus goes into a component and never comes back out. The page still looks correct in a screenshot, but everything past that point is unreachable.
Two places it happens on almost every site
The first is the cookie banner. It sits above the page and holds focus while open, which is correct. The failure comes next: the visitor presses Tab past "Accept" and "Settings", lands back on "Accept" and stays there, because the banner keeps focus inside itself and only closes on a mouse click. Neither the page nor the way out is reachable.
The second is the mega menu. A category flyout opens on hover and stays in the tab order after it visually closes. Focus walks into a hidden panel of forty links, then reappears somewhere unpredictable. Nothing on screen shows where focus is.
Both are ordinary bugs in ordinary code, and neither shows up in an automated report.
Why a rule checker never notices
axe-core, the engine behind many automated accessibility checks, ours included, reads the page. It walks the document object model, applies about a hundred rules to the elements it finds, and reports failures. It will tell you an image has no alternative text or a form field has no label.
What it does not do is press a key. Every rule is a question about the state of the markup at one moment. A keyboard trap is not a state, it is a behaviour over time: press Tab, see where focus went, press Tab again, notice it went nowhere. No attribute in the markup says "this component will refuse to release focus". The refusal lives in a JavaScript event handler that runs only on a real key press.
There is a second reason: trapping focus is sometimes correct. A modal dialog is supposed to hold focus while it is open, so a rule that flagged every focus trap would be wrong most of the time. The difference is whether the component releases focus when it should, and that shows only when you try it.
What the Inkluso audit records
The paid audit does what the scanner cannot: it presses Tab. A real browser loads the page and walks it key press by key press, up to three pages, four for a Shoptet shop, starting from the homepage.
The report carries a table under the heading Recorded focus order, covering the first forty stops on each page: the element that received focus, its text or label, and whether a visible focus indicator was painted, was not, or could not be determined. That table is often more useful than the findings: it shows the route a keyboard visitor must take through your checkout.
The walk reports four things:
- Focus got stuck on one element, WCAG 2.1.2 No Keyboard Trap, EN 301 549 V3.2.1 clause 9.2.1.2
- Focus loops without reaching most of the page, WCAG 2.1.2 No Keyboard Trap, EN 301 549 clause 9.2.1.2
- Focus disappeared mid-page, WCAG 2.4.3 Focus Order, EN 301 549 clause 9.2.4.3
- No visible focus indicator, WCAG 2.4.7 Focus Visible, EN 301 549 clause 9.2.4.7
Each finding is printed with the related requirement: the EN 301 549 clause and the national act your report cites. That act is zákon č. 424/2023 Sb. in Czechia, the BFSG in Germany, ustawa z 26 kwietnia 2024 r. in Poland, the BaFG in Austria or zákon č. 351/2022 Z. z. in Slovakia. It is chosen per report, not per language.
The three-minute keyboard test
You can check the two worst cases yourself, right now.
- Click the browser address bar and press Tab. Focus should move to the first element on the page.
- Keep pressing Tab and watch whether you can always see where focus is.
- Open the menu and the cookie bar with the keyboard only and close them with Escape. If focus gets stuck, you have a trap.
What we do not claim
The walk is heuristic evidence from one automated pass. It is excluded from your score and your grade, it never appears as a confirmed violation, and every finding asks you to confirm it manually before treating it as a defect. A slow widget can produce the same signature as a real bug. The walk covers up to three pages, four for a Shoptet shop, reached in crawl order, so it cannot find a trap on a page or in a flow it never reached, and a clean walk is not proof that your site has none. It is not a full manual audit and we do not sell it as one. It is a record of what happened when something actually pressed Tab on your site.
See where your site stands
A free scan checks your site against WCAG 2.1 AA and shows the first findings in minutes.
This article is informational and does not constitute legal advice.