Keyboard Accessibility: Test Your Site in 5 Minutes

A keyboard user lands on your site, opens a modal, and cannot get out. Tab goes nowhere. Escape does nothing. The only exit is closing the browser tab entirely. That single interaction pattern – a keyboard trap – is one of the most common reasons keyboard-only users abandon sites, and courts applying WCAG 2.1 AA as the de facto ADA standard treat it as a clear failure. According to ADA.gov’s guidance on web accessibility, ADA Title III enforcement against private businesses is entirely lawsuit-driven, with no government-mandated compliance deadline. WCAG 2.1 AA is what courts reach for.

Video: Keyboard Accessibility: Test Your Site in 5 Minutes

The good news: you can find the most damaging keyboard accessibility failures yourself, in five minutes, with no tools beyond a keyboard.

What a Keyboard Trap Looks Like and Why It Matters

Keyboard-only users include people with motor disabilities, power users who navigate by keyboard for speed, and anyone temporarily without a functioning mouse. For all of them, interactive elements that swallow focus and never release it are not an annoyance. They are a dead end.

The classic trap: a modal dialog opens, focus moves inside it, and nothing moves it back out. Tab cycles through the modal’s buttons forever. Escape does nothing because no one wired up the event listener. The user is stuck.

A less obvious version: a custom dropdown widget receives focus, and arrow keys do nothing. Tab jumps straight out of the widget without selecting anything. The control appears interactive but functionally is not.

Both patterns expose you to legal risk. ADA Title III has no filing deadline, but lawsuits are filed routinely against sites with documented keyboard failures. WCAG 2.1 AA, which addresses both traps and focus management, is the standard courts apply.

The 5-Minute Keyboard Test: A Step-by-Step Protocol

You need a keyboard, a browser, and your home page or the most interaction-heavy page on your site. No extensions required.

Step 1. Disconnect your mouse. Or simply stop using it. This forces you to notice every moment focus breaks down.

Step 2. Press Tab from the top of the page. Watch for a visible focus indicator (a ring, outline, or highlight) as it moves through links, buttons, inputs, and controls. If focus disappears at any point – if you cannot see where you are on the page – that is a failure. Note where it happened.

Step 3. Press Shift+Tab. Focus should move backwards through the same elements in reverse order. If it jumps unpredictably or gets stuck, you have a tab order problem.

Step 4. Open every interactive widget: dropdowns, accordions, date pickers, carousels. Once focus is inside, try each of these:

• Arrow keys should navigate within the widget (for example, through dropdown options).
• Escape should close the widget and return focus to the trigger.
• Enter and Space should activate buttons and select options.

If arrow keys do nothing, Escape does not close the element, or focus does not return to where it came from, record it.

Step 5. Open any modal dialog. Once it is open, press Tab repeatedly. Focus must stay inside the modal. It must not escape to the content behind it. Then press Escape. The modal should close and focus must return to the element that triggered it. If either of those things does not happen, you have found a keyboard trap (or its opposite: a modal with no focus containment at all).

Step 6. Press Tab on the very first keypress from the browser’s address bar. The first focusable element should be a skip navigation link, usually labelled “Skip to main content.” Press Enter on it. Focus should jump past the header and navigation directly into the page’s main content. If no skip link appears, or Enter does not move focus, it is missing or broken.

The whole protocol takes about five minutes on a typical page. Write down every step where focus disappeared, nothing happened, or you could not exit.

The manual test surfaces visible interaction failures. To find structural issues – missing ARIA roles, unlabelled interactive elements, broken focus management buried in JavaScript components – scan your site for accessibility issues.

Four Failures to Fix When Your Tab Test Reveals a Problem

Keyboard Traps

First, distinguish between intentional and accidental trapping. A modal dialog should trap focus. Keyboard users must not be able to Tab into the content behind an open modal. That is correct behaviour. What is required is that the user can exit the trap: Escape closes the modal, and focus returns to the trigger element.

Accidental trapping is different. Focus enters a custom widget – a rich text editor, a date picker, an embedded video player – and cannot leave at all. Tab does nothing. Escape does nothing. There is no designed exit.

The fix for accidental traps: add keyboard event listeners that respond to Escape (to close or exit the component) and ensure Tab moves focus to the next element outside the widget when the user is done. For intentional modal focus trapping, use the inert attribute on background content (supported in all modern browsers) or manage a manual focus trap with JavaScript that intercepts Tab and Shift+Tab to cycle only through focusable elements inside the dialog.

Missing or Invisible Focus Indicators

The most common cause is outline: none or outline: 0 in your CSS, usually applied globally to remove the browser’s default focus ring because a designer found it ugly. Removing it without replacing it means keyboard users have no visible location on the page.

The fix is not simply deleting that rule. You must replace the browser default with a custom focus indicator that meets the contrast requirement for non-text elements: a 3:1 ratio against the adjacent colour (Non-text Contrast, Success Criterion 1.4.11). A solid blue outline on a white background will typically pass. A light grey ring on white will not. Use a WCAG contrast checker to verify your focus ring colour against the background before shipping.

A practical starting point:

:focus-visible {
  outline: 3px solid #0057b8;
  outline-offset: 2px;
}

Use :focus-visible rather than :focus so the ring only appears for keyboard navigation, not on mouse clicks. Check the Color Contrast Checker: How to Find and Fix Low Contrast if you need help picking a colour that passes.

Broken Tab Order

Tab order follows DOM order by default. It breaks when developers use tabindex values greater than 0 (for example, tabindex="3") to force a specific sequence, or when CSS positions elements visually in a different order than they appear in the HTML.

Fix: remove positive tabindex values. Use only tabindex="0" (to make a non-interactive element focusable) or tabindex="-1" (to make an element programmatically focusable but excluded from the Tab sequence). Reorder your DOM to match your visual layout. If you are using CSS Grid or Flexbox to reorder elements visually, check that the HTML source order still produces a logical reading and focus sequence.

Missing Skip Navigation Link

Without a skip link, keyboard users must Tab through every item in your site navigation on every page before reaching the main content. On a site with a 40-item nav, that is 40 keystrokes before they reach anything useful.

The fix is a visually hidden link as the very first element in your HTML <body>, targeted at your main content container:

<a href="#main-content" class="skip-link">Skip to main content</a>

Show it on focus only:

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
}
.skip-link:focus {
  top: 0;
}

Make sure the target element (<main id="main-content">) actually receives focus when the link is activated. Some browsers require tabindex="-1" on the target for this to work reliably.

Keyboard Accessibility QA Checklist

Run this after fixes are applied. Each item is a discrete pass/fail check.

• [ ] Skip link present – first Tab keypress reveals a visible “Skip to main content” link
• [ ] Skip link functional – pressing Enter on it moves focus past navigation into main content
• [ ] Focus visible on all interactive elements – no step in the Tab sequence produces invisible focus
• [ ] Focus indicator contrast – focus ring meets 3:1 contrast ratio against adjacent colour (use the WCAG contrast checker to verify)
• [ ] Tab order logical – focus moves left-to-right, top-to-bottom in a reading-order sequence; no unexpected jumps
• [ ] No positive tabindex values – source contains only tabindex="0" or tabindex="-1", never tabindex="2" or higher
• [ ] Modal focus containment – Tab cannot reach background content while a modal is open
• [ ] Modal Escape exit – pressing Escape closes the modal
• [ ] Modal focus return – after modal closes, focus returns to the element that opened it
• [ ] Dropdowns and widgets keyboard-operable – arrow keys navigate options; Enter/Space selects; Escape exits
• [ ] No keyboard traps – no interactive element holds focus with no means of escape
• [ ] All interactive elements reachable – every link, button, input, and control can be reached by Tab alone

What the Tab Test Cannot Catch and How to Find the Rest

Manual keyboard testing tells you what breaks at the interaction level. It does not tell you whether interactive elements are correctly labelled for assistive technology, whether ARIA attributes are applied accurately, or whether dynamic content updates are announced to screen reader users.

For those gaps, scan your site for accessibility issues to surface structural failures the keyboard test cannot reveal. Then move to screen reader testing for the next layer. Keyboard testing is what your hands can check. Screen reader testing is what you need assistive technology to verify. Screen Reader Testing: Beginner Checklist for NVDA, JAWS, and VoiceOver covers exactly that: where the keyboard test ends, screen reader testing begins.

This article is for general informational purposes and is not legal advice.