Keyboard Navigation Broken on Website

Why it matters

Approximately 7 million Americans have a motor disability affecting hand and arm movement, making keyboard navigation their primary — or only — way to use the web. This includes people with ALS, multiple sclerosis, Parkinson's disease, and spinal cord injuries. Many power wheelchair users control their computers via switch access or sip-and-puff devices that emulate keyboard input. When your site breaks keyboard navigation, these users are completely locked out — they cannot browse products, fill forms, complete purchases, or access information. Under WCAG 2.1.1, keyboard accessibility is a Level A requirement, meaning it is considered a baseline that all websites must meet. Courts have consistently held ADA violations for keyboard inaccessibility. In 2022, a federal court found Domino's liable in part because users with disabilities could not operate the site without a mouse.

Symptoms — what you'll see

If your site has this problem, you may observe any of the following:

• Tab key does not move focus to interactive elements
• Focus jumps unpredictably or skips important controls
• Dropdown menus or modals open but can't be operated or closed with keyboard
• Custom components (sliders, date pickers, carousels) are completely inaccessible via keyboard
• JavaScript event handlers respond only to mouse click, not Enter or Space keypress
• Focus disappears entirely after clicking certain elements
• Navigation menus require mouse hover to reveal sub-items

Common causes

• Using <div> or <span> elements as buttons or links instead of native HTML elements
• Setting tabindex="-1" on elements that should be reachable by keyboard
• JavaScript event listeners that only fire on mouse events (click, mousedown, mouseover)
• CSS that hides the :focus outline without providing an alternative visible indicator
• Third-party widgets (chat widgets, date pickers, carousels) that were not built with accessibility in mind
• Single Page Application (SPA) routing that moves content but does not manage focus
• Modal dialogs that do not trap or redirect focus appropriately
• Dropdown navigation menus that only respond to CSS :hover pseudo-class

How to fix it

1. 1Audit your site by unplugging your mouse and tabbing through every page — note every element that should be interactive but is not reachable.
2. 2Replace non-semantic elements (div, span) used as buttons with <button> or <a> elements, which receive keyboard focus natively.
3. 3Ensure all custom interactive components implement the ARIA keyboard interaction patterns from the ARIA Authoring Practices Guide (APG).
4. 4Remove or correct any tabindex="-1" set on elements that should be in the focus order, and remove tabindex values greater than 0.
5. 5Add visible :focus-visible CSS styles so keyboard users can see where focus is at all times.
6. 6Test modal dialogs: focus must move into the dialog on open, cycle within it, and return to the trigger on close.
7. 7Verify that JavaScript event listeners that use mousedown or click also handle keydown for Enter and Space keys.

<!-- BROKEN: div-button with only mouse handler -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- BROKEN: custom dropdown with no keyboard support -->
<div class="dropdown" onmouseover="openMenu()">
  Products
  <div class="dropdown-menu" style="display:none">...</div>
</div>

<!-- FIXED: semantic button, keyboard accessible by default -->
<button type="button" class="btn" onclick="submitForm()">Submit</button>

<!-- FIXED: keyboard-operable dropdown with ARIA -->
<button
  aria-haspopup="true"
  aria-expanded="false"
  aria-controls="products-menu"
  id="products-btn"
>
  Products
</button>
<ul id="products-menu" role="menu" aria-labelledby="products-btn" hidden>
  <li role="none"><a role="menuitem" href="/products/a">Product A</a></li>
</ul>

How to test your fix

After applying the fix, verify it works using these testing steps:

1. Disconnect your mouse entirely and navigate the full page using Tab, Shift+Tab, Enter, Space, and arrow keys.
2. Verify that every interactive element (links, buttons, form fields, dropdowns, tabs, accordions) can be reached and activated.
3. Check that focus never disappears — you should always see a visible focus indicator.
4. Open any modal dialogs: confirm focus moves inside, cycles within, and returns to the trigger on close.
5. Run Lighthouse in Chrome DevTools > Accessibility and check for keyboard-related violations.
6. Install the axe DevTools browser extension and scan each page — filter violations by "keyboard" category.
7. Use NVDA (Windows) or VoiceOver (Mac) screen reader together with keyboard-only navigation to test the real-world experience.

Frequently asked questions