Keyboard Inaccessible Controls: Why 'Works With a Mouse' Isn't Enough

Try unplugging your mouse and navigating your site using only Tab, Shift+Tab, Enter, and the arrow keys. If you can't reach every interactive element, or can't tell where you are on the page, you've found a keyboard accessibility failure — and you've just experienced the site the way every keyboard-only user, every switch-device user, and every screen reader user does by default, since screen readers navigate through the same keyboard interface rather than a pointer.

Industry data puts keyboard inaccessibility at roughly 61% of ADA web accessibility complaints — the fourth most-cited issue, and one automated tools can only partially catch (WCAG Success Criterion 2.1.1, Keyboard, is a Category B "partially automatable" check: a scanner can flag suspicious patterns like a non-zero tabindex, but confirming full keyboard operability requires actually tabbing through the page).

The most common failure patterns

A <div> or <span> styled to look like a button, with only an onclick handler. Mouse clicks fire it; Tab skips right past it, because a plain <div> isn't in the keyboard focus order and has no built-in Enter/Space activation.

<!-- Before: invisible to keyboard users -->
<div class="button" onclick="submitForm()">Submit</div>

<!-- After: a real button, focusable and Enter/Space-activatable for free -->
<button type="submit">Submit</button>

Custom dropdowns, modals, and menus built from scratch that only respond to mouseover/mouseout and never wire up keyboard events (Escape to close, arrow keys to move between options, Enter to select).

A visible focus indicator that's been removed. Even a fully keyboard-operable page fails in practice if outline: none (or similar) is applied globally with no replacement — a keyboard user can technically tab through the page but has no way to see where they are. This overlaps with WCAG 2.4.7 (Focus Visible).

Positive tabindex values (tabindex="1", tabindex="2", etc.) that try to manually control tab order — these almost always create a worse order than the natural DOM order they're overriding, and axe-core flags any positive tabindex for exactly this reason.

How to fix it

Prefer real, native interactive elements (<button>, <a href>, <input>, <select>) over recreating their behavior on generic elements — they come with keyboard support, focus management, and screen reader semantics built in, for free. This is the same "semantic HTML over ARIA" principle that applies across most accessibility fixes: don't rebuild what the platform already gives you correctly.

If a custom widget is unavoidable, it needs the full set of expected keyboard interactions for its role (the WAI-ARIA Authoring Practices Guide documents the exact keyboard contract for every common widget pattern — menus, tabs, dialogs, comboboxes) plus a visible focus style and tabindex="0" (never a positive number) to bring it into the natural tab order.

Official references

• Deque University: tabindex