Accessibility
Keyboard Navigability
Every interactive element must be reachable and operable using a keyboard alone, with visible focus indicators showing where the user currently is.
Where it comes from
It's anchored in WCAG 2.1 Success Criterion 2.1.1 (Level A — the minimum requirement): all functionality must be operable through a keyboard interface. It's also the single most commonly violated accessibility criterion.
Why it matters for your website
Keyboard accessibility is the single most commonly violated WCAG criterion — representing 15-20% of all accessibility failures on typical websites (TestParty, 2025), and affecting not only users with motor disabilities but also visually impaired users navigating with screen readers, elderly users who find mouse use difficult, and power users who prefer keyboard efficiency. WCAG 2.1 Success Criterion 2.1.1 (Level A — the minimum requirement) is clear: all functionality must be operable through a keyboard interface. WebAIM's Million 2025 report found 56% of websites have inaccessible navigation menus. The fix is almost always structural: interactive elements should be built with semantic HTML (`<button>`, `<a>`, `<input>`) rather than generic elements, and focus styles should never be suppressed. A visible focus indicator is not a design inconvenience — it is the cursor for keyboard users.
Keyboard access isn't a minority concern. It's required for users with motor disabilities, but also for visually impaired users navigating with screen readers, elderly users who struggle with a mouse, and power users who prefer the keyboard — and it's the most violated WCAG criterion, around 15–20% of all failures.
The fix is almost always structural. Building interactive elements with semantic HTML (`<button>`, `<a>`, `<input>`) rather than generic `<div>`s makes them keyboard-operable by default, and focus styles should never be suppressed. A visible focus indicator isn't a design inconvenience — it's the cursor for keyboard users, the only way they can see where they are.
Wrong vs right
Interactive controls built from generic `<div>`s with click handlers, unreachable and unusable by keyboard.
Controls built with semantic HTML (`<button>`, `<a>`, `<input>`), keyboard-operable by default.
Focus styles removed for aesthetics, so keyboard users can't see where they are.
A clear, visible focus indicator on every interactive element — the cursor for keyboard users.
A navigation menu that can't be opened or traversed without a mouse.
Navigation fully operable by keyboard, in a logical order.
Understanding Keyboard Navigability
Keyboard navigability is the requirement that every interactive element be reachable and operable using a keyboard alone, with a visible focus indicator always showing where the user currently is. It's codified in WCAG 2.1 Success Criterion 2.1.1 at Level A — the minimum conformance level — which states plainly that all functionality must be operable through a keyboard interface.
It's also the most commonly violated accessibility criterion, accounting for an estimated 15–20% of failures, and it affects a wide range of people: users with motor disabilities, visually impaired users on screen readers, elderly users who find a mouse difficult, and power users who simply prefer the keyboard. WebAIM's Million 2025 report found 56% of websites have inaccessible navigation menus.
The remedy is structural and well-understood. Build interactive elements with semantic HTML — `<button>`, `<a>`, `<input>` — rather than generic elements, and never suppress focus styles; a visible focus indicator is the cursor for keyboard users. It connects to focus management, the POUR principles, and accessibility broadly.
How Kweri checks it
Keyboard navigability is partly automatable and partly not. Kweri's automated checks can catch some structural problems — interactive elements built from non-semantic markup, missing focus indicators, and the like — which are reliable, measurable signals. What automated testing can't fully verify is whether the *whole* page is genuinely operable by keyboard in a logical order: that requires actually tabbing through it. So Kweri flags the structural issues it can detect (non-semantic controls, suppressed focus styles) and is explicit that confirming true keyboard operability means testing the page with a keyboard and, ideally, a screen reader.
FAQ
What is keyboard navigability?
Keyboard navigability is the requirement that every interactive element on a page be reachable and operable using only a keyboard, with a visible focus indicator showing where the user is. It's WCAG 2.1 Success Criterion 2.1.1, at the minimum Level A.
Who relies on keyboard access?
Users with motor disabilities, visually impaired users navigating with screen readers, elderly users who find a mouse difficult, and power users who prefer the keyboard. It's a broad audience, not a niche one — and keyboard access is the most violated WCAG criterion.
How do I make a site keyboard accessible?
Build interactive elements with semantic HTML — `<button>`, `<a>`, `<input>` — rather than generic `<div>`s, so they're keyboard-operable by default. Never suppress focus styles, ensure a logical tab order, and test by navigating the whole page with only a keyboard.
Why shouldn't focus styles be removed?
Because a visible focus indicator is the cursor for keyboard users — the only way they can see where they are on the page. Removing focus styles for aesthetics leaves keyboard users navigating blind, unable to tell which element is selected.
Why is semantic HTML important for keyboard access?
Because native elements like `<button>` and `<a>` are keyboard-operable by default, while generic `<div>`s with click handlers are not. Using semantic HTML gives you keyboard accessibility for free; rebuilding it on generic elements is error-prone and often incomplete.
Related principles
Web accessibility is organised around four principles: content must be Perceivable, Operable, Understandable, and Robust — failure on any one principle makes content inaccessible to some users.
Keyboard focus must be visible at all times, move in a logical order, and be actively managed when content changes — especially when modals open, overlays appear, or dynamic content updates.
Tap targets need to be big enough, and spaced enough, to hit reliably with a finger.
Attribution & sources
Identified by W3C Web Accessibility Initiative (WAI). Catalogued from W3C — Web Content Accessibility Guidelines (WCAG).
Based on WCAG 2.1 SC 2.1.1 (Level A); the linked W3C page is the reference used here.
See Keyboard Navigability on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →