Who actually navigates by keyboard

Keyboard accessibility is sometimes framed narrowly as a screen reader issue. That framing is both incomplete and misleading. The full population of keyboard-dependent web users is considerably wider.

People with motor disabilities that affect hand or wrist function — repetitive strain injury, tremor, limb difference, paralysis — often cannot use a mouse at all. They may use a keyboard, a head switch, a sip-and-puff device, or eye-tracking software, all of which typically emulate keyboard navigation at the software level. What these users need is exactly what a keyboard user needs: predictable, visible, untrapped focus.

Screen reader users — people who are blind or have low vision — navigate primarily using keyboard commands. The relationship between keyboard accessibility and screen reader accessibility is tight: a screen reader cannot interact with an element that is not keyboard-focusable, so any keyboard failure is also a screen reader failure.

Power users and efficiency-oriented users frequently navigate forms and pages by keyboard, using Tab, Enter, and arrow keys rather than a mouse. This is especially common on complex forms, data entry interfaces, and checkout flows. These users are not disabled — they are fast — but they notice keyboard failures immediately.

According to the WebAIM Screen Reader User Survey and related research, keyboard navigation failures consistently appear among the top barriers reported by users with disabilities. It is not an edge case.

What WCAG requires for keyboard access

WCAG 2.1 has an entire principle dedicated to keyboard accessibility — Principle 2: Operable. The core requirement is stated in Success Criterion 2.1.1: all functionality of the content must be operable through a keyboard interface, without requiring specific timings for individual keystrokes. This is a Level A criterion, which means it is among the minimum required for any level of compliance.

SC 2.1.2 (also Level A) addresses keyboard traps: if keyboard focus can be moved to a component using a keyboard interface, then focus must be movable away from that component using only a keyboard interface. If this requires more than unmodified arrow keys or tab keys, users must be informed of the method.

SC 2.4.3 (Level A) requires that if a web page can be navigated sequentially and the navigation sequences affect meaning or operation, the focus order must preserve meaning and operability. In other words: the Tab order must make logical sense.

SC 2.4.7 (Level AA) requires that any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible. This is the criterion responsible for the visible focus outline requirement — the blue or other visible ring that shows where keyboard focus currently sits.

WCAG 2.2, which is increasingly referenced in newer accessibility standards, strengthened the focus visible requirement in SC 2.4.11 (Level AA): Focus Not Obscured (Minimum) — the focus indicator must not be entirely hidden by other content such as sticky headers or cookie banners.

Focus indicators: the most common failure

The single most common keyboard accessibility failure on Canadian small business websites is the removal of the default focus outline via CSS. The typical culprit is a single line: 

* { outline: none; }

or: 

a:focus, button:focus { outline: 0; }

These lines are written by developers who find the browser's default focus ring visually unpleasant — typically because it does not match the site's design. The intent is cosmetic. The effect is to make the page completely unnavigable for keyboard users, who now have no idea where focus currently sits.

The correct fix is not to remove the outline — it is to replace it with a custom focus indicator that is both visible and on-brand. WCAG 2.1 AA requires only that the focus indicator be visible. WCAG 2.2 added more specific requirements: the focus indicator must have an area of at least the perimeter of the component times 2 CSS pixels, and must have a contrast ratio of at least 3:1 between focused and unfocused states.

A practical custom focus style that satisfies these requirements: 

:focus-visible {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
  border-radius: 2px;
}

Note the use of :focus-visible rather than :focus. The :focus-visible pseudo-class applies the style only when the browser determines that focus should be visible — which means keyboard users see the indicator, but mouse users clicking buttons do not get an outline flash. This balances accessibility with the visual design concerns that led to the outline: none anti-pattern in the first place.

Tab order and logical focus flow

When a user presses Tab, focus moves to the next interactive element in the DOM order — the order in which elements appear in the HTML source code. This is usually fine when the visual layout matches the source order. It becomes a problem when CSS has been used to significantly rearrange the visual presentation.

A common example: a page where CSS flexbox or grid has visually reordered content so that a "secondary" navigation appears first on screen, but the primary navigation appears first in source order. A keyboard user tabs through the primary nav — which they cannot see because it is visually positioned mid-page — before reaching the secondary nav that is visually at the top. The experience is disorienting and confusing.

The fix is to ensure that the visual order and the DOM order match. If you have rearranged content using CSS order or flex-direction: row-reverse, check whether the Tab sequence still makes logical sense.

The tabindex attribute can be used to manage focus order, but it should be used with care. Setting tabindex="0" on a non-interactive element makes it focusable. Setting a positive tabindex (like tabindex="1") creates a separate focus sequence that runs before the natural DOM order — and this almost always creates more problems than it solves. In general: fix your DOM order rather than patching it with positive tabindex values.

Keyboard traps: when users get stuck

A keyboard trap occurs when focus enters a component and cannot leave it using standard keyboard controls. The user is stuck. They cannot reach the rest of the page without closing their browser tab or reloading.

The most common source of keyboard traps in the wild is modal dialogs — popups, lightboxes, cookie consent overlays — that are built without proper focus management. When a modal opens, focus should move into the modal. While the modal is open, Tab should cycle through elements inside the modal and not escape to the page behind it. When the modal closes, focus should return to the element that triggered it.

This pattern — called a "focus trap" when implemented correctly — is actually required behaviour for modals, not a bug. The bug is when a modal opens and focus stays on the page behind it, or when a modal cannot be closed using the keyboard (Escape key, or a clearly labelled close button that is keyboard-reachable).

Other common trap sources: custom dropdown menus where Tab does not exit the open dropdown, embedded third-party widgets (maps, chat widgets, video players) that capture all keyboard input, and date pickers that open calendar grids with no keyboard exit.

Interactive components that break keyboard nav

Several common website components are built in ways that work fine for mouse users but break entirely for keyboard users.

Custom dropdowns built from <div> elements. A native <select> element is keyboard accessible by default. A custom dropdown built from divs is not — it has no keyboard behaviour unless the developer has explicitly added it using ARIA roles (role="listbox", role="option") and JavaScript keyboard event handlers. Many custom dropdowns are missing this entirely.

Navigation menus with hover-only submenus. Mega menus and dropdown navigation that only open on :hover are inaccessible to keyboard users. The submenu must also be openable via keyboard (typically Enter or Space on the parent item, with arrow keys to navigate within) and must be closable (Escape).

Carousels and sliders without keyboard controls. A carousel with previous/next buttons that are not keyboard-focusable, or that autoplay without a pause control, fails multiple WCAG criteria — not just keyboard accessibility, but also 2.2.2 (Pause, Stop, Hide) for moving content.

Clickable <div> elements without keyboard support. If a developer has added an onclick handler to a <div>, that element is clickable by mouse but not activatable by keyboard — because <div> elements are not natively focusable or activatable. The fix is to use <button> for interactive elements that trigger actions, and <a href> for navigation. When semantic HTML is used correctly, keyboard behaviour is provided by the browser for free.

A skip link is a link, usually the first interactive element on the page, that allows keyboard users to jump directly to the main content — bypassing the navigation menu. Without it, a keyboard user must Tab through every single navigation link on every single page before they can reach the content they came for.

WCAG SC 2.4.1 (Level A) requires a mechanism to bypass blocks of content that are repeated on multiple pages. A skip link is the standard implementation of this requirement.

Skip links are often implemented as visually hidden elements that become visible on focus — so sighted keyboard users see them when they start tabbing, but they do not clutter the visual design for mouse users. A basic implementation: 

<!-- HTML: first element in <body> -->
<a href="#main-content" class="skip-link">Skip to main content</a>

/* CSS */
.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
}
.skip-link:focus {
  top: 0;
}

The target element — typically the <main> tag — must have id="main-content" for the link to work. This is simple to implement and is one of the highest-impact, lowest-effort accessibility improvements available.

How to test keyboard accessibility yourself

The most valuable keyboard accessibility test costs nothing and takes about fifteen minutes: put your mouse aside and navigate your entire website using only the keyboard.

The keys you need: Tab moves focus forward through interactive elements. Shift+Tab moves backwards. Enter activates links and buttons. Space activates buttons and checkboxes. Arrow keys navigate within certain components (select dropdowns, radio button groups). Escape should close modals and dropdown menus.

As you navigate, ask yourself: Can you see where focus currently is at every point? Does the Tab order move through the page in a logical sequence — top to bottom, left to right in most cases? Can you open and close every dropdown, modal, and menu? Can you submit forms? Can you reach every interactive element? Does focus return to a sensible place after a modal closes?

Document any point where you lose track of focus, get stuck, or cannot complete an action. These are your failures. Then retest after fixing — keyboard testing is fast enough to do continuously rather than as a one-time audit.

For a more systematic check, the WAVE browser extension (wave.webaim.org) flags some keyboard accessibility issues, including missing skip links and elements with tabindex values. It will not catch all focus indicator problems or keyboard traps — those require manual testing — but it is a useful first pass.

Keyboard accessibility and Canadian law

In Canada, keyboard accessibility is not just best practice — it is increasingly a legal requirement depending on your sector and jurisdiction.

The Accessibility for Ontarians with Disabilities Act (AODA) requires organizations in Ontario with 50 or more employees to meet WCAG 2.0 Level AA for websites and web content. WCAG 2.0 AA includes all keyboard accessibility criteria at Level A and the focus visibility requirement at Level AA. AODA compliance audits regularly flag keyboard failures as among the most common issues.

The BC Accessibility Act (2021) is building toward similar requirements for British Columbia, with technical standards expected to reference WCAG. Federal organizations subject to the Accessible Canada Act (ACA) are required to meet accessibility standards that include WCAG compliance for digital content.

Beyond statutory requirements, keyboard accessibility failures create legal exposure under human rights legislation. The Canadian Human Rights Act and provincial human rights codes prohibit discrimination on the basis of disability, and inaccessible websites have been the subject of human rights complaints in Canada. A website that is navigable only by mouse is a website that discriminates against users who cannot use one.

Where to start fixing

If your keyboard accessibility audit surfaces problems, prioritize in this order: fix keyboard traps first, because they completely block users; restore or add visible focus indicators, because users cannot navigate without them; add a skip link if one is missing; fix non-semantic interactive elements (divs with click handlers, hover-only menus); and then address tab order and more subtle issues.

Most keyboard accessibility fixes are CSS and HTML changes — they do not require rearchitecting your site. Removing outline: none and replacing it with a custom :focus-visible style is a five-minute fix. Adding a skip link is ten minutes. Converting a <div onclick> to a <button> is a one-line change. The cumulative impact of these small fixes is significant.

The broader principle behind keyboard accessibility is the same one that underlies semantic HTML: use the right element for the right job, and the browser provides the behaviour for free. A <button> is focusable, activatable with Enter and Space, and announced correctly by screen readers — without any extra JavaScript. A <div> is none of those things. The more your site relies on semantic HTML, the less keyboard accessibility work you need to do by hand.