Keyboard accessibility: can people use your website without a mouse?

Unplug your mouse, put your laptop’s touchpad out of reach, and try to buy something from your own website. For many owners, the experiment ends at the menu or the cookie banner. Keyboard accessibility means every action on your site can be completed using only a keyboard, and it is one of the most basic requirements in the Web Content Accessibility Guidelines. This article explains who depends on it, what “reachable” really means, and the design patterns that shut keyboard users out.

Who navigates without a mouse

Keyboard users are a broader group than most people expect:

• Blind and low-vision people using screen readers, which are driven from the keyboard rather than by pointing at things they cannot see.
• People with motor disabilities, tremors or limited hand movement, for whom precise mouse control is painful or impossible.
• Users of switch devices, sip-and-puff controls and some voice software, which often behave like a keyboard as far as the browser is concerned.
• People with temporary injuries, such as a broken wrist or repetitive strain.
• Power users, like data-entry staff and developers, who simply work faster with Tab and Enter.

Get the keyboard basics right and you serve all of these groups at once, because so many assistive technologies build on the same keyboard interface.

What the guidelines actually require

WCAG 2.2 includes several success criteria centred on the keyboard. In plain language:

• 2.1.1 Keyboard (Level A): all functionality must be operable through a keyboard, without requiring specific timings for individual keystrokes.
• 2.1.2 No Keyboard Trap (Level A): if focus can move into a component, it must be able to move out again using the keyboard.
• 2.4.3 Focus Order (Level A): the order in which focus moves must preserve meaning and operability.
• 2.4.7 Focus Visible (Level AA): the keyboard focus indicator must be visible.

Level A is the minimum. Failing it means some people cannot use the feature at all, not just that it is inconvenient.

Tab order: the route through your page

Pressing Tab moves focus to the next interactive element, and Shift+Tab moves back. The browser follows the order of elements in the HTML source, not the order they appear on screen.

When visual order and source order disagree

Modern CSS such as flexbox order, grid placement and absolute positioning can move things visually without changing the source. A visitor sees a form with name, then phone, then email, but focus jumps from name to email and back up to phone. For a sighted keyboard user that is disorienting; for a screen reader user it can change meaning.

Why positive tabindex causes trouble

The tabindex attribute with values like 1, 2 or 3 forces elements to the front of the tab sequence. It quickly becomes impossible to maintain and usually creates a more confusing order. The healthy uses are tabindex="0", to make a custom element focusable in normal order, and tabindex="-1", to allow focus from script without adding the element to the tab sequence. Fix the source order instead of numbering elements.

Elements that must be reachable and usable

Anything a mouse user can click or change needs a keyboard equivalent. Check especially:

• Main navigation, including dropdown and mega menus
• Buttons, links and icon-only controls such as search, close and share
• Form fields, checkboxes, radio buttons and custom selects
• Sliders, carousels, tabs and accordions
• Modals, popups and the cookie consent banner
• Add-to-cart, quantity controls, coupon fields and payment options
• Video players and embedded maps
• Chat widgets and floating WhatsApp buttons

The div that pretends to be a button

The most common cause of unreachable controls is a div or span with a click handler. It looks like a button but is not focusable and does not respond to Enter or Space. A native button element gets focus, keyboard activation and correct screen reader announcement for free. Links should be real a elements with an href. Using native elements avoids most problems before they start.

Hover-only features

Menus that open only on mouse hover, or information shown only in a hover tooltip, leave keyboard users stranded. Anything revealed on hover should also be revealed on focus or by activating a control.

Keyboard traps: getting in but not out

A keyboard trap happens when focus enters a part of the page and cannot leave. The user presses Tab repeatedly and cycles within the same few elements, or focus disappears into something invisible. Without a mouse, their only escape may be reloading the page and losing what they typed.

Common sources include:

• Embedded third-party content, such as some older video players, maps or payment iframes
• Rich text editors that capture Tab to insert indents, with no documented way out
• Badly built modals that keep focus locked after they close, or that never received focus properly
• Date pickers and custom widgets that intercept arrow keys and Tab

Note the difference from a well-built modal dialog. A dialog should keep focus inside while it is open, but it must close with Escape or a reachable close button and return focus to the control that opened it. That is intentional containment, not a trap.

Where to begin improving keyboard access

Choose the single most important journey on your site, such as making an enquiry or completing a purchase, and walk it using only Tab, Shift+Tab, Enter, Space and Escape. Note every point where you cannot reach something, cannot see where you are, or get stuck. Those notes become your first fix list. If the problems sit deep in a theme or plugin, our website development team can rebuild the affected components with proper keyboard support.

Frequently asked questions

Is keyboard accessibility a legal requirement in India?

Indian rules under the Rights of Persons with Disabilities Act and government web guidelines reference accessibility standards aligned with WCAG, particularly for public bodies. Confirm how they apply to your business with a qualified professional.

Do mobile users need keyboard accessibility?

Yes. Some mobile users connect external keyboards or switch devices, and screen readers on phones rely on the same underlying focus and semantics.

Does a skip link help keyboard users?

Yes. A “Skip to main content” link as the first focusable element lets people jump past long menus instead of tabbing through every item on each page.

Can an accessibility overlay widget fix keyboard problems?

Overlays generally cannot repair unreachable custom controls or traps in the underlying code. Fixing the HTML and scripts directly is the dependable approach.