Keyboard Navigation
The ability to operate all functionality using a keyboard alone. Requires logical tab order, focus styles, and skip links.
📋 Complete Guide Contents
Keyboard Navigation: The Accessibility Test Everyone Fails
Can you use your entire website without a mouse? Try it right now – unplug your mouse and navigate your site using only Tab, Enter, Space, and arrow keys. If you can't complete basic tasks, your site isn't accessible.
Keyboard navigation isn't just for blind users. It's essential for motor disabilities (can't use a mouse), power users (keyboard is faster), voice control users (keyboard commands work better), mobile users (touch targets too small), and anyone with a broken trackpad.
Yet keyboard accessibility is one of the most neglected aspects of web development. Developers test with a mouse. Designers design for mouse interaction. And millions of users are left unable to use the resulting websites.
The Basics: What Keyboard Users Actually Do
Keyboard navigation has established patterns that users expect:
Tab: Move forward through interactive elements (links, buttons, form fields) Shift+Tab: Move backward through interactive elements Enter: Activate links and buttons Space: Activate buttons, toggle checkboxes, scroll page Arrow keys: Navigate within components (dropdown menus, radio groups, sliders) Escape: Close modals, cancel actions, exit modes Home/End: Jump to start/end of content or lists
Master these patterns and you've covered most keyboard interactions. The problems arise when sites break these expectations – buttons that don't respond to Enter, Tab traps you can't escape, content you can't reach at all.
Focus Management: Where Am I and Where Can I Go?
The focus indicator shows which element currently has keyboard focus. Without it, keyboard navigation is like wandering in the dark.
Visible Focus Indicators: WCAG 2.4.7 requires that focus be visible. That means: - Clear visual indicator (outline, background change, border) - Sufficient contrast (3:1 minimum against both element and background) - Not removed with outline: none unless you provide an alternative
Browsers provide default focus styles, but they're often subtle. Better to design intentional focus states that match your brand while remaining highly visible.
Focus Order: Elements receive focus in DOM order, not visual order. Your CSS might arrange elements beautifully, but if the HTML order is illogical, Tab navigation will jump around confusingly. Test your tab order – it should match the logical reading flow.
Skip Links: Keyboard users shouldn't have to tab through your entire navigation on every page. Provide a "Skip to main content" link at the very top. It can be visually hidden until focused, but it must be the first focusable element.
Focus Traps: Sometimes you need to trap focus – modal dialogs should keep focus inside until closed. But traps must be intentional and escapable. Users should always be able to reach everything they need and leave when done.
Making Custom Components Keyboard Accessible
Native HTML elements are keyboard accessible by default.
Fake Buttons:
tabindex: The Attribute Everyone Misuses
tabindex controls whether and how elements receive keyboard focus. There are three valid values:
tabindex="0": Makes element focusable in natural DOM order. Use this for custom interactive elements that aren't natively focusable (like clickable divs – though you should use buttons instead).
tabindex="-1": Makes element focusable programmatically (via JavaScript) but not via Tab key. Useful for managing focus in components (moving focus to error messages, into modal dialogs, etc.).
tabindex="1" or higher: ALMOST ALWAYS WRONG. Positive tabindex creates a custom tab order that usually breaks navigation. Elements with tabindex="1" are focused first, regardless of DOM position, then tabindex="2", etc., then normal tab order resumes. This is confusing and should be avoided.
Fix tab order in HTML, not with tabindex. Restructure your DOM if needed. Positive tabindex seems like a quick fix but creates more problems than it solves.
And don't put tabindex on non-interactive elements just to make them focusable. If it's not interactive, it shouldn't receive focus.
Keyboard Testing Checklist
Test keyboard navigation systematically:
Can you reach everything? - Tab through entire page - Can you reach every link, button, form field? - Can you open every menu, expand every accordion? - Is anything only available on hover?
Can you see focus? - Is focus indicator always visible? - Does it have sufficient contrast? - Can you tell which element currently has focus?
Does everything work? - Do buttons activate on Enter and Space? - Do links activate on Enter? - Do checkboxes toggle on Space? - Do custom components respond to appropriate keys?
Is the order logical? - Does tab order match reading order? - Do related elements group together? - Does focus skip irrelevant elements?
Can you escape? - Can you close modals without a mouse? - Can you exit menus and dropdowns? - Are there any focus traps?
Edge cases: - What happens when you reload a page mid-form? - Can you navigate within infinite scroll? - Do lazy-loaded elements become focusable when loaded? - Does focus persist across route changes in SPAs?
Test with actual keyboard, not developer tools. The experience matters, not just technical compliance.
Common Keyboard Navigation Failures
These mistakes break keyboard accessibility constantly:
Hover-Only Menus: Dropdown menus that only appear on :hover. Keyboard users can focus the trigger but never reach the menu items. Fix: Show menus on focus, or use proper dropdown patterns with keyboard support.
Missing Focus Indicators: outline: none without replacement. Keyboard users can't tell where they are. Fix: Always provide visible focus styles.
Invisible Skip Links: Skip links hidden with display: none are broken – they're unfocusable. Fix: Hide with absolute positioning off-screen, then show on :focus.
Focus on Disabled Elements: tabindex on disabled buttons. Why would you let users focus something they can't use? Fix: Remove tabindex from disabled elements.
Wrong Element Types: Clickable divs, tappable spans, fake links. These don't work with keyboard by default. Fix: Use semantic HTML – buttons for actions, links for navigation.
Focus Lost After Actions: Closing a modal, deleting an item, submitting a form – focus often disappears into the void. Users have to Tab from the top again. Fix: Manage focus explicitly. Return focus to logical next element.
Keyboard Traps: Can Tab into element but not out. Often happens with embedded iframes, broken modal dialogs, or poorly coded custom widgets. Fix: Test thoroughly, ensure Escape and Tab always work.
Dynamic Content: New content loads, but focus doesn't move there. Users don't even know it loaded. Fix: Move focus to new content or announce it with ARIA live regions.
WebAbility detects many keyboard issues automatically and tests common interaction patterns, but manual testing is essential. Use your keyboard to navigate your site – it's the only way to truly understand the experience.
Make Your Website Accessible with WebAbility
Join over 1 million websites using WebAbility to ensure digital accessibility compliance and provide equal access to all users.
Related Resources
Industry Applications
Free Accessibility Tools
Related Terms
More Related Accessibility Terms
Active Cursor Indicator
A visible caret or pointer state that helps users track input focus or text insertion position, essential for low-vision and cognitive accessibility.
Character Key Shortcuts
Single‑letter keyboard shortcuts that must be remappable, turned off, or only active on focus to prevent accidental activation.
Focus Management
Strategies to set and maintain focus order during dynamic changes such as modals, route transitions, and component mounts.
Keyboard Trap
A defect where focus cannot be moved away using the keyboard. Users must be able to navigate away with standard keys.
This glossary is continuously improved and maintained by WebAbility to advance accessible design and development.Contact us to suggest improvements or report issues.