How to Make a Website Keyboard Accessible

Making a website keyboard accessible means ensuring that every interactive element and every task can be reached and operated using only the keyboard — no mouse needed. It is a cornerstone of accessibility (a WCAG Level A requirement) because so many people depend on it: people with motor disabilities, screen-reader users who navigate entirely by keyboard, people using switch or voice control, and plenty of power users. The essentials are straightforward to state: everything must be operable by keyboard, the focus order must be logical, the focus indicator must always be visible, there must be no keyboard traps, and a skip-to-content link should let users bypass repeated navigation. This guide explains each, with the key behaviour expected of common components, and how to test it all by simply unplugging your mouse.

It is the operability deep-dive behind what WCAG is and the difference between A, AA and AAA, and one of the most important things to check in how to check if a website is accessible.

Why keyboard access matters

Keyboard operability is foundational because it serves several groups at once and underpins other assistive technology:

• Motor disabilities. Many people cannot use a mouse precisely or at all — due to tremor, paralysis, repetitive strain or limited dexterity — and navigate with the keyboard instead.
• Switch and voice control. Devices that let people operate a computer with a single switch, sip-and-puff input, or spoken commands typically emulate the keyboard, so if your site works with a keyboard, it works with them.
• Screen-reader users. Blind and low-vision users drive their screen reader (NVDA, VoiceOver, JAWS) almost entirely from the keyboard. If keyboard operability is broken, the screen-reader experience is broken too.
• Temporary and situational needs. A broken wrist, a trackpad that died, an awkward posture — keyboard access helps here as well.
• Power users. Many sighted, able-bodied users navigate forms and apps faster by keyboard and expect it to work.

Because keyboard support sits underneath so much else, getting it right lifts the accessibility of the whole site — and getting it wrong undermines everything layered on top.

The core requirements

Five requirements cover the essentials. Meet these and you have the foundation of keyboard accessibility.

1. Everything must be operable by keyboard

Every control — links, buttons, form fields, menus, tabs, sliders, custom widgets — must be both focusable (reachable with Tab) and operable (activatable with the keyboard). This is WCAG 2.1.1 (Keyboard), a Level A criterion. The most reliable way to achieve it is to use native HTML elements for their intended purpose, because they come keyboard-accessible for free (more on that below). A control you can click but cannot reach or trigger by keyboard is, for many users, simply broken.

2. Focus order must be logical

As the user presses Tab, focus should move through the page in an order that matches the visual and reading order — generally left to right, top to bottom, following the logical structure of the content. Erratic focus order (jumping from the header to the footer to the middle) is disorienting, especially for screen-reader users who cannot see the layout. In practice, a sensible source order in the HTML produces a sensible focus order; problems usually arise when CSS reorders content visually without the DOM matching, or when tabindex values above zero are used to force an order (which is fragile and best avoided).

3. The focus indicator must always be visible

Keyboard users need to see where they are at all times. The browser provides a default focus outline; the most damaging single mistake in keyboard accessibility is removing it with CSS (outline: none) and not replacing it. A visible focus indicator is required at WCAG AA (2.4.7), and WCAG 2.2 adds further criteria about how appropriate that indicator must be. The fix is simple: never remove focus styling without providing a clear, high-contrast replacement. If a sighted keyboard user cannot tell which element is focused, they cannot navigate.

4. No keyboard traps

Focus must be able to move into and back out of every component using the keyboard. A keyboard trap — where focus enters a modal, widget or embed and cannot escape — is an explicit Level A failure (WCAG 2.1.2) and can render the whole page unusable. Modals are the classic risk: focus should move into the dialog when it opens, stay within it while open (a deliberate focus loop, which is different from a trap because Escape and the close button still work), and return to the triggering element when it closes. The distinction is that a managed focus loop is escapable and intentional; a trap is inescapable and broken.

5. A skip-to-content link

Repeated navigation is tedious to tab through on every page. A skip-to-content link — typically the first focusable element, often visually hidden until focused — lets users jump straight to the main content, satisfying WCAG 2.4.1 (Bypass Blocks). It is a small addition with a big quality-of-life payoff for keyboard and screen-reader users, who otherwise face the entire menu before reaching what they came for.

Use native elements first

The single most effective principle in keyboard accessibility is: use the right native HTML element, and most of this comes for free. A real <button> is focusable, activates on Enter and Space, and is announced as a button to screen readers — all without any extra code. A real <a href> is focusable and activates on Enter. Native <input>, <select>, <textarea> and <details> bring their own keyboard behaviour and semantics.

Contrast that with a <div> styled to look like a button. Out of the box it is not focusable, not operable by keyboard, and not announced as a button — to make it equivalent you must add tabindex="0", a role="button", key handlers for Enter and Space, and the right ARIA state management. That is a lot of code to reproduce what a <button> does natively, and it is easy to get wrong. So the rule is: reach for the native element first, and only build a custom widget when no native element fits.

Interactive components and ARIA

When you genuinely must build a custom component — a complex dropdown, a tab set, a combobox, an autocomplete — you take on responsibility for its keyboard behaviour and semantics. That means:

• Make it focusable and operable (appropriate tabindex, key handlers for the expected keys).
• Give it the right role and state with ARIA, so assistive technology announces what it is and its current state (expanded/collapsed, selected, checked).
• Manage focus deliberately — for example, moving focus into a menu when it opens and back to the trigger when it closes.

The WAI-ARIA Authoring Practices (from the W3C) document the expected keyboard interaction patterns for common widgets, and following them is the safest path. The guiding caution is the first rule of ARIA: do not use ARIA if a native element will do — ARIA changes how something is announced but adds no behaviour, so it must be paired with real keyboard handling. Custom widgets are where keyboard accessibility most often breaks, so test them especially carefully.

Expected keyboard behaviour by component

Users have learned conventions for how things should respond to keys. Meeting these expectations is a large part of keyboard accessibility:

Component	Expected keyboard behaviour
Link	Tab to focus; Enter activates
Button	Tab to focus; Enter and Space activate
Checkbox	Tab to focus; Space toggles
Radio group	Tab moves into the group; arrow keys move between options (and select)
Text input	Tab to focus; type to enter text
Select / dropdown	Tab to focus; arrow keys change selection; Enter/Space may open the list
Menu / menu bar	Tab to focus; arrow keys move between items; Enter activates; Escape closes
Tabs	Tab moves to the active tab; arrow keys move between tabs; Enter/Space activates
Modal dialog	Focus moves in on open; focus stays looped inside; Escape closes; focus returns to the trigger
Accordion	Tab to each header; Enter/Space expands/collapses
Slider	Tab to focus; arrow keys adjust the value

When a custom component follows the same pattern as its native equivalent, keyboard and screen-reader users can operate it without learning anything new — which is exactly the goal.

How to test keyboard accessibility

The definitive test is also the simplest and costs nothing: put the mouse away and use only the keyboard. Then try to complete every key task on the site. The keys you will use:

• Tab / Shift+Tab — move forward and backward between interactive elements.
• Enter — activate links and buttons.
• Space — activate buttons, toggle checkboxes, often operate custom controls.
• Arrow keys — move within menus, radio groups, tabs, sliders and similar.
• Escape — close modals, menus and popups.

As you go, verify the five core requirements: can you reach and operate everything, is the focus order logical, is the focus indicator always visible, are there no traps (you can always Tab away or press Escape), and do skip links work? This single exercise — done on each key flow — surfaces the great majority of keyboard issues, and it is the test we recommend first in how to check if a website is accessible and a required step in how to run an accessibility audit.

Common keyboard accessibility mistakes

The recurring failures are worth naming. Removing the focus outline with outline: none and not replacing it — the most common and most harmful. Using <div> or <span> as buttons without adding focusability, key handlers and roles. Keyboard traps in modals and embeds that focus cannot escape. Illogical focus order caused by visual reordering that the DOM does not match. Mouse-only interactions like hover-only menus or drag-and-drop with no keyboard alternative. Forgetting Escape on dialogs and popups. No skip link, forcing users through the whole menu every time. Each is straightforward to fix once spotted, and most are avoided entirely by leaning on native elements.

The bottom line

Keyboard accessibility means everything works with the keyboard alone — reachable, operable, in a logical order, with focus always visible, no traps, and a skip link to bypass navigation. It is a WCAG Level A foundation that serves people with motor disabilities, screen-reader users, switch and voice-control users, and power users alike. The biggest lever is using native HTML elements, which are keyboard-accessible by default; when you must build custom widgets, manage focus and ARIA to match the expected key behaviour. And the best test is free: unplug the mouse and try. For the wider picture, see what web accessibility is and why it matters, and to ground it in the standard, what WCAG is and the difference between A, AA and AAA.

Want to know whether your site holds up to a WCAG accessibility check, alongside SEO and performance? Analyse any URL with StackOptic — one report, free, no sign-up.