Invisible focus, keyboard traps: the accessibility bugs nobody sees

Have you ever navigated a website using the keyboard only? Probably not. Yet it is daily life for millions of people: users with low vision, people with motor disabilities, assistive technology users. And what they experience is often a nightmare.

Invisible focus: the element you cannot see

The problem

When you press Tab in a browser, focus moves from one interactive element to the next: links, buttons, form fields. A visual indicator — usually a blue outline — shows which element is currently selected.

Except many designers find that outline "ugly". So they add this CSS line:

*:focus {
  outline: none;
}

The result: the user navigates with the keyboard but no longer knows where they are on the page. It is like navigating a website with your eyes closed.

How Scrutia detects it

Scrutia simulates a real Tab journey across your page and verifies that every interactive element shows a perceivable visual change when it receives focus. If no focus indicator is visible, it is a non-conformance with WCAG 2.1 AA Success Criterion 2.4.7 (Focus Visible).

The best practice

Never remove outline globally. Use :focus-visible if you want to hide the indicator for mouse clicks while keeping it for keyboard users:

/* Hide for mouse click */
button:focus:not(:focus-visible) {
  outline: none;
}

/* Keep for keyboard */
button:focus-visible {
  outline: 2px solid #4361ee;
  outline-offset: 2px;
}

Keyboard trap: the dead end you cannot escape

The problem

A keyboard trap (WCAG 2.1.2, a Level A blocking criterion) occurs when focus enters a component and can no longer leave it using Tab or Shift+Tab. The user is stuck.

Common cases:

• Embedded text editors (TinyMCE, CKEditor) that capture Tab for indentation
• Video players with custom controls that do not handle Tab
• Interactive maps (Google Maps, Leaflet) that capture keyboard events
• Custom widgets with tabindex and onkeydown poorly implemented

A real example

We tested a popular European e-commerce site. When navigating with the keyboard, focus entered the homepage carousel. Tab then scrolled through the slides instead of moving to the next element. It was impossible to escape without closing the page.

Scrutia detects keyboard traps automatically by simulating a full Tab journey and verifying that focus always progresses through the page.

The solution

Every component that captures Tab must offer a way out, usually via Escape. For text editors, a common convention is Ctrl+M to toggle between edit mode and navigation mode.

<!-- Accessible component: Escape lets you leave -->
<div role="application" aria-label="Carousel"
     onkeydown="if(event.key === 'Escape') this.blur()">
  ...
</div>

ARIA components that do not work with the keyboard

The problem

Dropdowns, modals, accordions and tabs use ARIA roles (role="menu", role="dialog", role="tablist"). But adding an ARIA role does not make a component accessible — it is like putting an "Emergency exit" sign on a door that does not open.

The W3C publishes the APG Design Patterns which define the expected keyboard behavior for each component:

Menu:

• Enter or Space: open the menu
• Up/Down arrows: navigate between items
• Escape: close the menu
• Tab: leave the menu

Modal:

• Focus must be trapped inside the modal (looping between the first and last focusable element)
• Escape closes the modal
• Focus returns to the trigger element after close

Tabs:

• Left/Right arrows: switch tabs
• Tab: enter the content panel of the active tab

What we observed

Across a sample of audits we ran:

• Most sites had menus that do not respond to the keyboard (only mouse clicks work)
• Several had modals that do not trap focus (Tab escapes the modal)
• A few had tabs that do not respond to arrow keys

How Scrutia tests

Scrutia automatically detects ARIA components on the page and verifies they respect the keyboard interaction patterns defined by the W3C APG Design Patterns.

The human cost

Invisible focus means navigating blind. A keyboard trap means being locked in. A broken ARIA component is a closed door.

For a sighted user with a mouse, these issues are completely invisible. The site works perfectly. But for the 15% of the world's population living with a disability (source: WHO), these bugs turn a website into an obstacle.

What you can do now

1. Navigate your site using only Tab. Can you reach every link and button? Can you always see where you are? Can you exit every component?

2. Test your interactive components with the keyboard. Do your menus open with Enter? Do your modals close with Escape? Do your tabs navigate with the arrow keys?

3. Run an automated audit. Classic scanners do not detect these issues. Use a tool that tests real interactions.

Keyboard accessibility is not a "nice to have". It is the foundation of web accessibility. And since the European Accessibility Act took effect in June 2025, it is also a legal obligation.