Section 1
Why keyboard access is non-negotiable
Keyboard operability is foundational to web accessibility because it's how a wide range of users, people with motor impairments, many blind users with screen readers, people with certain conditions, actually operate a website. If something can only be done with a mouse (a menu that only opens on hover, a button that only responds to a click, a form control that traps focus), those users simply cannot do it. There's no workaround on their end; the function is closed to them. This makes keyboard inaccessibility not a minor inconvenience but a hard barrier that excludes users entirely from whatever the inaccessible element does, and if that element is your navigation or your booking button, you've excluded those users from converting. WCAG 2.1 AA requires that all functionality be operable through a keyboard. The principle: if it needs a mouse, it's closed to everyone who can't use one. (This follows established WCAG keyboard-operability requirements.) The keyboard test is the closest thing to experiencing your site as a visitor who can't use a mouse. If you get stuck navigating your own site one-handed on the keyboard, you've found a wall that some of your visitors hit every time, and can't get around.
Section 2
How to run the test and what to fix
Run the test. On your homepage and key pages, set the mouse aside and press Tab repeatedly. Watch for: Can you reach everything? Every link, button, menu item, and form field should be reachable by tabbing. If something is skipped, it's inaccessible. Can you see where you are? There should be a visible "focus indicator" (an outline or highlight) showing which element is currently selected. If you can't tell where the keyboard focus is, that's a failure, and a common one, since some designs remove the focus outline for aesthetics. Can you operate everything? Menus should open, buttons should activate, forms should submit, all via keyboard. Does focus ever get trapped? You should never get "stuck" in an element you can't tab out of (a common problem with poorly built modals/popups). Common fixes. The frequent failures and their remedies: restore visible focus indicators (don't remove them for looks); ensure dropdown menus and custom controls are keyboard-operable, not hover-only; make sure modals/popups can be closed and exited by keyboard; and confirm the tab order is logical (follows the visual flow). Many of these are handled correctly by modern builders using standard components, the failures usually come from custom or "creative" interactive elements.
Section 3
The keyboard test, in one view
The takeaway: the keyboard test is the highest-value two minutes you can spend on accessibility, because it reveals one of the most common and serious failures with no tools and no expertise. Run it on your own site, note where you get stuck or lost, and fix the focus indicators, hover-only menus, focus traps, and tab order that cause the failures. If you can navigate your entire site comfortably by keyboard, you've cleared a barrier that a meaningful share of users, and a meaningful share of your potential conversions, would otherwise hit every time. (The test and fixes follow WCAG 2.1 AA keyboard-operability guidance.)
Section 4
Execute This With AI
Step 1, Inputs. Run the keyboard test yourself first and note exactly where you got stuck, lost focus, or couldn't operate something. Note your platform and any custom interactive elements. Step 2, Run the prompt: You are an accessibility specialist. I ran the keyboard test on my site (using only Tab/Enter/arrows). WCAG 2.1 AA requires all functionality to be keyboard-operable. Help me fix what I found. Where I got stuck / lost focus / couldn't operate: [DESCRIBE]. My platform: [X]. Custom interactive elements (menus, modals, sliders): [LIST]. Do four things: 1. Diagnose each problem I found (hover-only menu, missing focus indicator, focus trap, bad tab order, mouse-only control). 2. Give the fix for each, in terms I can act on or hand to a developer. 3. Tell me which are likely my builder's defaults vs. custom-element problems. 4. Prioritize by severity (hard barriers first). Focus on making everything keyboard-operable with visible focus. Step 3, Re-test. "After fixes, what should I re-check by keyboard to confirm everything is now reachable, visible, and operable?" Tools and expected output. Any frontier chat model, but the test itself is yours to run on the keyboard. Expect a diagnosis of each problem, fixes, a defaults-vs-custom assessment, and a severity order. The QA discipline: the keyboard test cannot be delegated, only you, tabbing through your own site, can find where focus gets stuck or lost, and that experience is the truest accessibility check available. The model helps fix what you find; running (and re-running) the test is on you. The most revealing accessibility test on your website takes two minutes and no tools: set your mouse aside and try to use your whole site with the keyboard. Most service sites fail it, because of hover-only menus, removed focus indicators, focus traps, and jumbled tab order, and each failure is a hard wall for the users who navigate by keyboard, including some of the people you'd most want as clients. Run the test, fix what stops you, and re-run it until you can reach, see, and operate everything one-handed on the keyboard. Clear that barrier, and you've fixed one of the most common and serious accessibility failures, the one almost no founder ever tests for.
Section 5
Keep reading
Keep reading in the Accessibility & the EAA cluster and across the library: [The Business Case for Accessibility (Beyond Compliance)](/blog/the-business-case-for-accessibility-beyond-compliance), [Color Contrast and Your CTA: One Fix, Two Wins](/blog/color-contrast-and-your-cta-one-fix-two-wins), [Designing for the 1 in 4: The Market Your Website Is Probably Excluding](/blog/designing-for-the-1-in-4-the-market-your-website-is-probably-excluding). Also relevant: [The Motion Accessibility Mistake That Excludes Real Customers](/blog/the-motion-accessibility-mistake-that-excludes-real-customers), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [Design Consistency Across Touchpoints: The Quiet Growth Lever Most Service Businesses Ignore](/blog/design-consistency-across-touchpoints).