WCAG 7.3 — Is every script controllable by keyboard and by any pointing device?

Keyboard navigation impossible

The issue

Keyboard navigation is a fundamental pillar of web accessibility. WCAG success criterion 2.1.1 requires that all functionality be operable through a keyboard interface, without depending exclusively on the mouse or touch. Yet a considerable number of modern websites build interactions that only work with a mouse: dropdown menus that only open on hover, buttons built with div or span instead of button, carousels without keyboard controls, modals that do not close with Escape, tabs without arrow key support. When an interactive element is not keyboard-accessible, the user who depends on the keyboard is blocked. They cannot click that button, open that menu, close that modal, or navigate that carousel. Their journey on the site stops immediately. This problem is particularly insidious because it is invisible to developers who test exclusively with a mouse. A div-based button may seem to work perfectly — it has the right visual, the right cursor, the right click behavior. But it is completely transparent to the keyboard: it does not receive focus with Tab, does not trigger with Enter, and is not announced as a button by screen readers. Modern JavaScript frameworks (React, Vue, Angular) often worsen this problem by encouraging the use of div with onClick instead of semantic HTML tags. A native HTML button is natively focusable, keyboard-activatable, and correctly announced by screen readers. A div with onClick does none of that without significant extra work (adding tabindex, role, keydown handling). The solution is almost always the same: use native HTML elements (button, a, input, select) rather than reinventing the wheel with divs.

Does your site have this issue?

106 RGAA criteria analyzed in 5 minutes by our AI.

Test your site for free

Impact on users

People with motor disabilities who cannot use a mouse depend entirely on the keyboard (or an input device emulating the keyboard, such as a switch, voice control, or eye tracker). For these users, a non-keyboard-navigable site is an unusable site — as inaccessible as a building without a ramp for a wheelchair user. Blind people using a screen reader also navigate exclusively by keyboard. If an interactive element cannot receive focus, it simply does not exist for them. Power users also use the keyboard by preference for its speed. Developers, data entry professionals, and anyone with a temporary wrist tendinitis are also affected. Worldwide, hundreds of millions of people have motor disabilities of the upper limbs that can make mouse use difficult or impossible.

Code example

Before (non-compliant)

<div class="menu-toggle" onclick="toggleMenu()">
  Menu
</div>
<div class="dropdown" onmouseover="showDropdown()">
  <span>Services</span>
  <div class="dropdown-content" style="display:none">
    <div onclick="navigate('/consulting')">Consulting</div>
    <div onclick="navigate('/audit')">Audit</div>
  </div>
</div>

After (compliant)

<button type="button" class="menu-toggle" onclick="toggleMenu()">
  Menu
</button>
<div class="dropdown">
  <button type="button" aria-expanded="false" aria-haspopup="true"
    onclick="toggleDropdown(this)" onkeydown="handleDropdownKey(event)">
    Services
  </button>
  <ul role="menu" class="dropdown-content" hidden>
    <li role="menuitem"><a href="/consulting">Consulting</a></li>
    <li role="menuitem"><a href="/audit">Audit</a></li>
  </ul>
</div>

Frequently Asked Questions

How do I test keyboard navigation on my site?

Unplug your mouse (or stop using it) and try to use your site with the keyboard only. Use Tab to move forward, Shift+Tab to go back, Enter or Space to activate an element, Escape to close a modal or menu, and arrow keys within menus and tabs. If you get stuck anywhere or cannot see the focus, it is an accessibility problem.

Why not just use tabindex to make a div focusable?

Adding tabindex="0" to a div makes it focusable but does not give it the semantic role of a button, nor the ability to trigger with Enter or Space. You also need to add role="button", a keydown handler, and manage aria-pressed state. That is a lot of code to reinvent what the native <button> tag does in a single line.

Are hover-only menus accessible?

Menus that only open on mouse hover (CSS :hover or JavaScript onmouseover) are not keyboard accessible. They should either also open on focus (:focus-within in CSS) and on click, or be replaced with a menu pattern conforming to the WAI-ARIA Authoring Practices with full keyboard management (Enter to open, Escape to close, arrows to navigate).

Must carousels be keyboard navigable?

Yes. Carousels must provide focusable and keyboard-activatable Previous/Next buttons, as well as a pause mechanism if auto-scrolling is enabled. Keyboard users must be able to interact with the content of each slide. The carousel must not trap the focus.

Does your site have this issue?

Scrutia audits your site against WCAG 2.1 AA criteria in 5 minutes. Keyboard navigation, ARIA components, visible focus, contrasts, and much more.

Run a free audit