Manual Keyboard Navigation Audits

Technical Deep Dive & Specifications

The WCAG Focus Specification Matrix

WCAG 2.1 and 2.2 define precise, non-negotiable success criteria governing keyboard interaction:

The 5-Step Keyboard Testing Protocol

To perform a rigorous manual keyboard audit, follow this systematic 5-step test sequence:

[ STEP 1: TAB TRAVERSAL ]
Press Tab sequentially from top to bottom.
Verify: Every link, button, input, select, textarea, and custom control receives focus.
Verify: Hidden offscreen elements DO NOT receive invisible ghost focus.

       |
       v
[ STEP 2: SHIFT + TAB REVERSE ]
Press Shift+Tab backwards across the entire page.
Verify: Focus retreats symmetrically along the exact reverse path.

       |
       v
[ STEP 3: ARROW KEY / COMPOSITE CHECKS ]
Navigate into Radio Groups, Tablists, Menubars, and Sliders.
Verify: Tab moves focus into the widget; Arrow keys navigate child options; Tab moves out.

       |
       v
[ STEP 4: INTERACTION & ACTIVATION ]
Press Space on checkboxes/buttons; Press Enter on links/buttons; Press Alt+Down on selects.
Verify: State transitions occur immediately without requiring pointer events.

       |
       v
[ STEP 5: OVERLAY & MODAL TRAPPING ]
Trigger a modal or dropdown menu.
Verify: Focus moves immediately inside the modal.
Verify: Tab is strictly trapped inside the modal boundary.
Verify: Pressing Escape immediately closes the overlay and returns focus to the triggering button.

Focus Indicators: :focus vs :focus-visible

Stripping focus rings via * { outline: none; } is one of the most widespread accessibility anti-patterns on the web.

Modern CSS provides the :focus-visible pseudo-class, which selectively renders focus indicators only when the browser heuristic determines keyboard navigation is active:

/* ❌ ANTI-PATTERN: Completely destroys accessibility for keyboard users */
button:focus {
  outline: none;
}

/* ✅ MODERN BEST PRACTICE: Universal, high-contrast, double-ring focus indicator */
:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
  border-radius: 4px;
}

/* Optional high-contrast fallback for dark backgrounds */
@media (prefers-contrast: more) {
  :focus-visible {
    outline: 3px solid #ffffff;
    box-shadow: 0 0 0 5px #000000;
  }
}

Managing Focus Traps & Background Inertness

When a modal dialog opens, background elements must not receive keyboard focus. Historically, developers manually intercepted keydown events to cycle focus. Modern web standards provide the inert HTML attribute and the native <dialog> element:

+------------------------------------------------------------------------------+
| [PAGE HEADER] (inert)                                                        |
| [MAIN CONTENT] (inert)                                                       |
|                                                                              |
|       +--------------------------------------------------------------+       |
|       | [MODAL DIALOG: Active Focus Boundary]                        |       |
|       |                                                              |       |
|       |  [X Close] (Initial Focus) <-------+                         |       |
|       |      |                             | (Tab cycles inside)     |       |
|       |      v                             |                         |       |
|       |  [Input: Name]                     |                         |       |
|       |      |                             |                         |       |
|       |      v                             |                         |       |
|       |  [Button: Save Changes] -----------+                         |       |
|       +--------------------------------------------------------------+       |
|                                                                              |
| [PAGE FOOTER] (inert)                                                        |
+------------------------------------------------------------------------------+

When an element has the inert attribute (<main inert>):

1. It is removed from the sequential focus navigation order.
2. It is ignored by assistive technologies (removed from the accessibility tree).
3. Pointer and user interaction events are blocked.

💻 Interactive Code Playground

Real-Time Live Focus Logger & Accessible Dialog

The following playground provides a complete HTML/JS harness with a live visual Focus Tracker HUD and a fully accessible, keyboard-trapped modal dialog.

Line-by-Line Code Breakdown

• Lines 8–11: Defines a global :focus-visible selector. By using :focus-visible, mouse users clicking buttons won't see an aggressive border, but pressing Tab instantly produces a 3px high-contrast blue focus ring.
• Lines 26–29: Employs the native <dialog> element with dialog::backdrop for built-in top-layer elevation.
• Lines 73–80: Sets up a global focusin event listener that queries document.activeElement and updates the floating HUD on every keystroke.
• Lines 89–93: Calling dialog.showModal() automatically activates the browser's built-in focus trap, places initial focus on the first interactive form element, and binds the Escape key to close the dialog.
• Line 92: Adds inert to #main-content, guaranteeing that assistive technologies and offscreen crawlers cannot interact with background layers while the modal is active.
• Lines 99–103: Restores focus to openBtn when the dialog closes, preventing focus from being dropped onto <body>.

Expected Browser Render Output

• Pressing Tab moves focus from #open-dialog-btn to the privacy link, displaying the current tag and ID in the bottom-right HUD.
• Pressing Enter on #open-dialog-btn opens the modal dialog. Focus immediately jumps inside to #full-name.
• Repeatedly pressing Tab cycles strictly between #full-name, #email-addr, #cancel-btn, and the submit button. Focus never escapes to the background page.
• Pressing Escape immediately dismisses the modal and returns focus to #open-dialog-btn.