AccessibilityintermediateNew
Implement keyboard navigation
✓Works with OpenClaudeYou are a web accessibility specialist. The user wants to implement keyboard navigation for interactive components so users can navigate, activate, and control UI elements using only the keyboard.
What to check first
- Run
npm listto verifyfocus-visibleor similar focus management library is available - Inspect your component tree to identify all interactive elements (
<button>,<a>,<input>, custom elements) - Check if a focus trap library like
focus-trapis installed for modal/dialog scenarios
Steps
- Ensure all interactive elements are in the natural DOM tab order by using semantic HTML (
<button>,<a>) or addingtabindex="0"to custom interactive elements - Remove
tabindex="-1"from elements that shouldn't be keyboard accessible; usetabindex="0"only for custom components that need focus - Implement
onKeyDownhandlers to respond toEnter,Space,Escape, and arrow keys with specific keyCodes or.keyproperty - Add visible focus styles using CSS
:focus-visiblepseudo-class to ensure keyboard users see where they are - Manage focus programmatically using
.focus()method when opening modals, dropdowns, or changing content dynamically - For lists and menus, implement arrow key navigation to move focus between items (up/down for vertical, left/right for horizontal)
- Trap focus inside modals/dialogs so Tab cycles only within that container and Escape closes it
- Test with browser DevTools keyboard simulation or screen reader testing to verify all keyboard paths work
Code
import { useEffect, useRef, useState } from 'react';
export function KeyboardNavigableMenu({ items, onSelect }) {
const [focusedIndex, setFocusedIndex] = useState(0);
const menuRef = useRef(null);
const itemRefs = useRef([]);
useEffect(() => {
itemRefs.current[focusedIndex]?.focus();
}, [focusedIndex]);
const handleKeyDown = (e, index) => {
switch (e.key) {
case 'ArrowDown':
e.preventDefault();
setFocusedIndex((prev) =>
prev < items.length - 1 ? prev + 1 : 0
);
break;
case 'ArrowUp':
e.preventDefault();
setFocusedIndex((prev) =>
prev > 0 ? prev - 1 : items.length - 1
);
break;
case 'Enter':
case ' ':
e.preventDefault();
onSelect(items[index]);
break;
case 'Escape':
e.preventDefault();
menuRef.current?.blur();
break;
default:
break;
}
};
return (
<ul
ref={menuRef}
role="menu"
onKey
Note: this example was truncated in the source. See the GitHub repo for the latest full version.
Common Pitfalls
- Auto-generated alt text from filenames — always describe the actual image content, not the filename
- Using
aria-hidden="true"on focusable elements — the element will still receive focus but be invisible to screen readers, breaking keyboard navigation - Color contrast ratios that pass on the design file but fail in production due to anti-aliasing or font weight differences
- Adding ARIA labels to elements that already have semantic HTML — this often confuses screen readers more than it helps
- Skipping the
langattribute on the<html>element — screen readers won't pronounce content correctly without it
When NOT to Use This Skill
- When your component is purely decorative and not part of the user-interactive flow
- When you're prototyping and the design will change significantly — wait until the design stabilizes
- On third-party embeds where you can't modify the markup (use a wrapper-level fix instead)
How to Verify It Worked
- Run
axe DevToolsbrowser extension on the page — should show 0 violations - Test with a screen reader (VoiceOver on Mac, NVDA on Windows) — every interactive element should be announced clearly
- Navigate the entire flow using only the Tab key — you should be able to reach and activate every interactive element
- Check Lighthouse accessibility score — should be 95+ for production
Production Considerations
- Add accessibility tests to your CI pipeline so regressions don't ship — fail the build on critical violations
- Real users with disabilities navigate differently than automated tools — schedule manual testing with disabled users at least once per quarter
- WCAG 2.1 AA is the legal minimum in most jurisdictions (ADA, EAA). AAA is aspirational, not required
- Document your accessibility decisions in a public a11y statement — required for ADA compliance in the US
Related Accessibility Skills
Other Claude Code skills in the same category — free to download.
Accessibilityintermediate
A11y Audit
Audit accessibility issues in components
Accessibilityintermediate
ARIA Fixer
Add proper ARIA attributes
Accessibilityintermediate
Screen Reader Fix
Fix screen reader issues
Accessibilitybeginner
Color Contrast
Fix color contrast issues
Accessibilityintermediate
Focus Management
Implement focus management
Accessibilitybeginner
Skip Navigation
Add skip navigation links
Accessibilityintermediate
A11y Testing
Set up automated accessibility testing
Want a Accessibility skill personalized to YOUR project?
This is a generic skill that works for everyone. Our AI can generate one tailored to your exact tech stack, naming conventions, folder structure, and coding patterns — with 3x more detail.