Motor impairments, screen reader users, and power users all rely on the keyboard alone. This lesson covers natural tab order, manual key handling for custom widgets, closing overlays on Escape, and skip links for bypassing repetitive navigation.
1Not Everyone Uses a Mouse
Motor impairments, screen reader users navigating linearly, and power users all rely on keyboard-only navigation. A custom dropdown, modal, or menu that only responds to onClick presents a complete wall to these users — not a minor inconvenience, but total inability to use the feature.
2The Tab Order Should Match Visual Order
Pressing Tab should move focus in the same order a sighted user would naturally scan the page. A positive tabIndex forces an element earlier in the tab order regardless of its visual position, creating a jarring, confusing jump — natural DOM order should be relied on instead.
3Custom Widgets Need Manual Key Handling
A native <select> handles arrow key navigation automatically, but a custom dropdown built from divs does not — arrow keys, Enter, and Escape must be manually handled in an onKeyDown handler to recreate the expected behavior a native equivalent would provide for free.
4Escape Should Always Close Overlays
Any modal, dropdown, or popover should close when Escape is pressed — a strongly expected convention whose absence feels genuinely broken. This requires a keydown listener attached while the overlay is open and properly removed when it closes.
5Skip Links for Repetitive Navigation
A keyboard user must Tab through every navigation link before reaching main content, on every page load, unless a 'Skip to main content' link — visually hidden until focused, positioned first in the DOM — lets them bypass that repetition entirely.
6Step-by-Step Breakdown
Not Everyone Uses a Mouse. Motor impairments, screen reader users navigating linearly, and plenty of power users all rely on the keyboard alone. If your custom dropdown, modal, or menu only responds to onClick, all of these users are simply unable to use it — no error, no workaround, just a wall.
The Tab Order Should Match Visual Order. Pressing Tab should move focus in the same order a sighted user would naturally scan the page — left to right, top to bottom. A positive tabIndex (like tabIndex={5}) forces an element earlier in the tab order regardless of where it visually sits, creating a jarring, confusing jump. Avoid it; let natural DOM order do the work.
Why is a positive tabIndex value (like tabIndex={5}) generally something to avoid?
- →It forces the element out of its natural, visually-matching tab order
- →tabIndex is not a real, supported HTML attribute
Custom Widgets Need Manual Key Handling. A native <select> handles arrow keys for you automatically. A CUSTOM dropdown built from <div>s does not — you must manually listen for ArrowDown, ArrowUp, Enter, and Escape in an onKeyDown handler to recreate that expected behavior.
Escape Should Always Close Overlays. Any modal, dropdown, or popover should close when the user presses Escape — this is such a strongly expected convention that its absence feels genuinely broken. Attach a keydown listener while the overlay is open, and remove it in the cleanup function when it closes.
Why should you attach the Escape key listener inside a useEffect with a cleanup function, not just once globally?
- →So the listener is only active while the overlay is actually open, and removed when it closes
- →It's purely a minor performance optimization with no functional effect
Skip Links for Repetitive Navigation. A keyboard user on a page with a long navigation menu has to Tab through every single link before reaching the main content, every single page load. A 'Skip to main content' link — visually hidden until focused, positioned first in the DOM — lets them bypass that repetition entirely.
Mastery Achieved. You now understand keyboard navigation: never blocking interactions to mouse-only, keeping tab order natural, manually recreating expected key behavior for custom widgets, closing overlays on Escape, and skip links for bypassing repetitive navigation. Next, you'll learn how to use ARIA in React correctly, and when not to use it at all.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Visible Focus Indicators Must Never Be Removed
Never apply outline: none to a focusable element without providing an equally visible custom focus style — removing focus indicators entirely leaves keyboard users with no way to see where they currently are on the page.
SEO Implications
- 1
Logical DOM Order Also Benefits Content Structure Parsing
Keeping DOM order aligned with visual and logical reading order — the same principle behind good tab order — also helps search engines and other content-parsing tools understand a page's structure correctly.
Best Practices
Test Every Interactive Feature with Only the Keyboard
Unplug the mouse (or simply don't use it) and try completing a core user flow using only Tab, Shift+Tab, Enter, Space, and arrow keys — this surfaces keyboard gaps far more reliably than reading code.
Base Custom Widget Key Bindings on Established ARIA Authoring Patterns
The WAI-ARIA Authoring Practices Guide documents expected keyboard behavior for common widget types (menus, tabs, dialogs) — following these conventions keeps custom components predictable for experienced assistive-technology users.
Frequent Bugs
A custom dropdown menu can be opened with a click but never with the keyboard.
Add an onKeyDown handler responding to Enter and Space to open it (matching native button behavior), plus arrow key handling to navigate options once open.
Pressing Escape while a modal is open does nothing.
Add a keydown event listener (typically via useEffect, active only while the modal is open) that calls the modal's close handler when e.key === 'Escape', with a cleanup function removing the listener when the modal closes.
Real-World Examples
A Fully Keyboard-Accessible Custom Dropdown
A custom-styled dropdown menu needed to match the keyboard behavior of a native <select>: Enter/Space to open, ArrowDown/ArrowUp to move between options, Enter to select the highlighted option, and Escape to close without selecting. Implementing all of these in a single onKeyDown handler made the component fully usable without a mouse.
function handleKeyDown(e) {
switch (e.key) {
case 'ArrowDown': setActiveIndex(i => Math.min(i + 1, options.length - 1)); break;
case 'ArrowUp': setActiveIndex(i => Math.max(i - 1, 0)); break;
case 'Enter': case ' ': selectOption(options[activeIndex]); break;
case 'Escape': closeDropdown(); break;
}
}