Keyboard accessibility and focus: designing for people who don't use a mouse

Who relies on the keyboard — and why it’s the law

A larger group than most teams picture. Keyboard accessibility matters for people with motor disabilities, people with visual impairments, those with repetitive strain injuries, and anyone with a temporary injury that prevents mouse use — plus switch-device users, screen-reader users, and power users who simply prefer it (UXPin, 2026). The numbers are not small: an estimated 2.5 million Americans have motor disabilities that prevent mouse use, and missing focus indicators alone make sites unusable for the roughly 8 million who rely on keyboard navigation (DEV, 2026; TestParty, 2026). If your site cannot be operated entirely by keyboard, you are excluding them completely.

It is also a legal requirement, not a nicety. Keyboard operability is mandated under the ADA Title III for private businesses, Section 508 for federal agencies, and similar legislation worldwide, and courts have repeatedly ruled that sites must be fully usable by keyboard (UXPin, 2026; Level Access, 2026). It is, by most accounts, one of the most important and most neglected parts of accessibility — which makes it a place where getting the craft right is a genuine advantage.

What does WCAG actually require?

A handful of criteria, all under the “Operable” principle, cover it. The foundational ones are 2.1.1 Keyboard, which requires all functionality to be operable by keyboard, and 2.1.2 No Keyboard Trap, which requires that focus can always be moved back out of any component — both Level A (DEV, 2026). On top of those sit 2.4.1 Bypass Blocks (a skip link past repeated navigation), 2.4.3 Focus Order (focus follows a logical, predictable sequence), and 2.4.7 Focus Visible (a visible focus indicator), the last of which is Level AA (Line25, 2026).

WCAG 2.2 strengthened this area specifically. It added 2.4.11 Focus Not Obscured (Minimum) at Level AA, which requires that a focused component not be entirely hidden by author content like sticky headers or cookie banners, and a Focus Appearance criterion describing minimum size and contrast for the indicator — an area of at least a 2px perimeter of the component and a 3:1 contrast ratio between focused and unfocused states (Line25, 2026; GetWCAG, 2026). In plain terms: everything must work by keyboard, the order must make sense, focus must be visible, and nothing may hide or trap it.

The cardinal sin: removing the focus indicator

There is one mistake that does more damage than any other, and it is depressingly common. Focus indicators are often the first thing designers remove because they feel they clash with the design — and removing them without a replacement makes the site unusable for keyboard users, who lose all sense of where they are, like removing every street sign in a city (Webability, 2026). The scale is striking: WebAIM’s analysis of one million home pages found 78% had detectable focus-indicator issues (TestParty, 2026).

The offending code is a one-liner — *:focus { outline: none }, or the same applied to buttons, links and inputs — and the rule is simple: never remove the default focus outline without providing an equal or better replacement (TestParty, 2026). The default browser outline is exempt from contrast requirements, but the moment you override it you become responsible for making your version visible and sufficiently contrasting (Vispero, 2026). Removing it is not a design decision; it is a defect.

How to style a focus indicator that looks good

The objection that focus rings spoil the design has a clean answer: :focus-visible. This CSS pseudo-class applies focus styles only when the browser judges the user needs them — during keyboard navigation or assistive-technology use — while suppressing the ring on ordinary mouse clicks, which resolves the old tension between aesthetics and accessibility (Vispero, 2026). The pattern is to reset the default and apply your own indicator:

button:focus { outline: none; }
button:focus-visible {
  outline: 2px solid #1E90FF;
  outline-offset: 2px;
  box-shadow: 0 0 0 2px rgba(30, 144, 255, 0.3);
}

The style itself should follow a few rules: a contrast ratio of at least 3:1 between focused and unfocused states, an outline of at least 2px, consistent indicators across similar elements, and a focus color that works on every background the component might sit on — light, dark or image (UXPin, 2026; TestParty, 2026). The focus color does not have to match your brand exactly; many design systems use a single high-contrast accent for focus everywhere, which is easier to keep visible and consistent.

Get the tab order right

Focus order is about predictability: when someone tabs through the page, the sequence should match the visual reading order so the experience stays logical (Vispero, 2026). Components that appear in a certain visual order should receive focus in that same order — WCAG 2.4.3 exists precisely to prevent the disorienting jumps that happen when they do not (Line25, 2026).

The way to get this right is mostly to not fight it. Tab order follows DOM order, so a sensible, content-first source order gives you a sensible tab order for free — which is one quiet benefit of a semantic, hand-built page over a layout assembled out of order and repositioned with CSS. Avoid positive tabindex values like tabindex="2", which override the natural order and almost always create confusion; use tabindex="0" only to add a custom interactive element to the natural flow, and tabindex="-1" to make something focusable by script but not part of the tab sequence (Webability, 2026).

Modals, menus and keyboard traps

Dynamic components are where keyboard access most often breaks. A keyboard trap occurs when a user can Tab into a component but cannot Tab out of it, and modal dialogs are the classic offender (Level Access, 2026). Proper modal focus management has three parts: trap focus inside the dialog so Tab and Shift+Tab cycle within it, let Escape close it, and return focus to the element that opened it once it closes (UXPin, 2026). The other components people forget — dropdowns, sliders, carousels, date pickers — each need their own key handling for Tab, Enter and Space, the arrow keys, and Escape (Level Access, 2026).

This is also where one anti-pattern causes most of the trouble: building an interactive control out of a plain <div> with a click handler. A <div onClick> is invisible to the keyboard — it cannot be tabbed to and Enter does nothing — so the moment you reach for a div as a button, you have created an inaccessible control that needs a role, a tabindex and manual key handlers to repair. The cheaper path is almost always to use the real element instead.

Skip links and focus management

Keyboard users move through a page linearly, so repeating your full navigation on every page means tabbing past it every time. A skip link fixes that: a “Skip to main content” link that is visually hidden until it receives focus, then jumps the user past the navigation (Line25, 2026). It is a few lines of code:

<a href="#main-content" class="skip-link">Skip to main content</a>
<nav><!-- navigation --></nav>
<main id="main-content" tabindex="-1"><!-- content --></main>

.skip-link { position: absolute; top: -40px; left: 0; padding: 8px 16px;
  background: #000; color: #fff; z-index: 9999; }
.skip-link:focus { top: 0; }

Beyond the skip link, managing focus deliberately matters in dynamic apps. When content changes — a dialog opens, or a single-page app swaps the view — moving focus to the new region, sometimes by setting tabindex="-1" on a heading or the <main> element and focusing it, keeps keyboard and screen-reader users oriented (Vispero, 2026). The inverse rule matters too: do not make non-interactive elements focusable, because focus is a cue that something is interactive, and putting it on plain text is misleading.

Semantic HTML does most of the work

The encouraging truth is that native HTML is keyboard-accessible by default. A real <button>, <a href> or <input> can be tabbed to, activated and operated without a single line of extra JavaScript, because the browser already implements all of that behaviour (UXPin, 2026). You only need ARIA roles and manual key handling when you build a custom control the platform does not provide — and even then, the goal is to reproduce what the native element would have done for free.

This is why keyboard accessibility tracks so closely with how a site is built. The failures cluster around custom JavaScript widgets, removed outlines, positive tabindex and content painted in an order that does not match the DOM — exactly the patterns that template-heavy builders and single-page apps tend to produce. It is also why an accessibility overlay cannot truly fix it: a script that bolts focus styles onto a finished page cannot give a <div>-based control the real keyboard behaviour it never had, which is the same point our guide on why overlays are a legal trap makes. Operability has to be built in.

How to test it: put the mouse away

The definitive test needs no special tools — just your keyboard. Set the mouse aside and Tab and Shift+Tab through the entire page, confirming that every interactive element is reachable, that Enter and Space activate controls, that arrow keys work inside composite widgets, and that Escape closes overlays (UXPin, 2026). As you go, check that focus is visible at every stop, that the order follows the visual layout, that nothing traps you, and that focus returns to the trigger after a modal closes — and if you use Safari on macOS, enable the setting that lets Tab reach every control first (Level Access, 2026).

Automated tools have a role, but a limited one here: scanners catch roughly 40% of keyboard issues, mostly missing tabindex, incorrect roles and absent focus styles, while the interaction patterns that matter most can only be found by a person tabbing through (DEV, 2026). This is exactly how we build and check our own work — semantic markup, a logical source order, a visible :focus-visible indicator in the design system, and a keyboard pass on every interactive flow. Paired with the WCAG 2.2 checklist and the contrast guide, it is the operable half of the same discipline our pillar on whether accessibility is the law covers in full: get it right at the source, and the page works for everyone.