On a project with an e-commerce site built on React 18 and Next.js 14, users mass-reported that they could not add items to the cart—keyboard focus was lost after selecting a size. Modal dialogs trapped focus and didn't release. Such bugs not only harm UX but also pose legal risks. Keyboard navigation is a strict requirement of WCAG 2.1 (Success Criterion 2.1.1). Our team, TrueTech, helps implement it end-to-end: audit, fixes, testing, and documentation. We estimate your project in one business day, implementation from 5 days. With 5+ years of web accessibility experience and over 20 successful projects, we guarantee WCAG 2.1 compliance. Our approach reduces navigation complaints by 80%—5 times fewer compared to sites without adapted navigation. According to WebAIM, sites with implemented keyboard navigation have 30% higher user satisfaction. Our certified accessibility experts ensure thorough testing. The audit starts from $600.
Why Keyboard Navigation Is Critical for Accessibility?
Without it, your site is inaccessible to screen reader users, people with tremors, or those with temporary limitations (broken mouse). Google and Yandex factor accessibility into rankings. Implementing per WCAG is an investment in both UX and SEO.
What Tools Help Test Keyboard Navigation?
We use Cypress with the cypress-axe plugin for automation, plus manual testing. Below is a table of WCAG criteria we check.
| Criterion | Requirement | Example |
|---|---|---|
| SC 2.1.1 | All functions operable via keyboard | Buttons, links, form elements |
| SC 2.1.2 | No keyboard trap | Modals, custom menus |
| SC 2.4.3 | Logical focus order | Tab index matches visual order |
| SC 2.4.7 | Visible focus indicator | Outline or custom style |
Common Problems and Solutions
Clients often come with issues like: users cannot fill forms because focus disappears after input; modal dialogs trap focus and don't release; custom dropdowns don't open with keyboard. Each problem requires detailed audit and subsequent refactoring. Our navigation refactoring ensures a logical tab order.
How We Implement: A Detailed Case
Recently, our client, an e-commerce site on React 18 with Next.js 14, faced issues in the cart modal. We implemented a focus trap with cyclic switching and return to trigger after close. Also added aria-modal="true" and Escape handling.
function Modal({ isOpen, onClose, children }) {
const modalRef = useRef(null);
useEffect(() => {
if (!isOpen) return;
const focusableSelectors = [
'a[href]', 'button:not([disabled])', 'input:not([disabled])',
'textarea', 'select', '[tabindex]:not([tabindex="-1"])'
].join(', ');
const focusable = modalRef.current?.querySelectorAll(focusableSelectors);
const first = focusable?.[0];
const last = focusable?.[focusable.length - 1];
first?.focus();
const handleTab = (e) => {
if (e.key !== 'Tab') return;
if (e.shiftKey) {
if (document.activeElement === first) {
e.preventDefault();
last?.focus();
}
} else {
if (document.activeElement === last) {
e.preventDefault();
first?.focus();
}
}
};
const handleEsc = (e) => {
if (e.key === 'Escape') onClose();
};
document.addEventListener('keydown', handleTab);
document.addEventListener('keydown', handleEsc);
return () => {
document.removeEventListener('keydown', handleTab);
document.removeEventListener('keydown', handleEsc);
};
}, [isOpen]);
if (!isOpen) return null;
return (
<div role="dialog" aria-modal="true" ref={modalRef}>
{children}
</div>
);
}
This approach ensures the user won't get stuck in the modal.
Custom Components: Dropdown
For each custom component we define a keyboard pattern following WAI-ARIA Authoring Practices. We also use the CSS pseudo-class :focus-visible to distinguish keyboard focus from mouse clicks.
function DropdownMenu({ trigger, items }) {
const [open, setOpen] = useState(false);
const [activeIndex, setActiveIndex] = useState(-1);
const itemRefs = useRef([]);
const handleKeyDown = (e) => {
switch (e.key) {
case 'ArrowDown':
e.preventDefault();
setActiveIndex(i => Math.min(i + 1, items.length - 1));
break;
case 'ArrowUp':
e.preventDefault();
setActiveIndex(i => Math.max(i - 1, 0));
break;
case 'Escape':
setOpen(false);
triggerRef.current?.focus();
break;
case 'Home':
setActiveIndex(0);
break;
case 'End':
setActiveIndex(items.length - 1);
break;
}
};
useEffect(() => {
if (activeIndex >= 0) {
itemRefs.current[activeIndex]?.focus();
}
}, [activeIndex]);
return (
<div>
<button
aria-haspopup="listbox"
aria-expanded={open}
onClick={() => setOpen(!open)}
>
{trigger}
</button>
{open && (
<ul role="listbox" onKeyDown={handleKeyDown}>
{items.map((item, i) => (
<li
key={item.id}
role="option"
tabIndex={-1}
ref={el => itemRefs.current[i] = el}
>
{item.label}
</li>
))}
</ul>
)}
</div>
);
}
We use aria-haspopup on MDN and role="listbox" so the screen reader announces the menu correctly.
Basic Navigation Keys
| Key | Action |
|---|---|
| Tab | Next focusable element |
| Shift+Tab | Previous focusable element |
| Enter / Space | Activate button, link, checkbox |
| Arrow keys | Navigate within radio group, menu, slider |
| Esc | Close modal, dropdown |
| Home / End | First / last element in list |
Checklist of Typical Errors
Full keyboard navigation audit checklist
- Verify all interactive elements are keyboard accessible.
- Ensure focus does not get trapped on any element.
- Check correctness of Tab order.
- Ensure focus indicator is visible.
- Check Escape handling.
- Verify custom components respond to arrows and Enter.
- Ensure outline is not removed without replacement.
- Verify ARIA attributes are correct.
Process of Work
- Analysis — audit current implementation, produce report.
- Design — define patterns for each component.
- Implementation — fix styles, JS, ARIA.
- Testing — unit tests, integration tests, manual verification.
- Deployment — deliver documentation and support.
What's Included
As a result, you get:
- Audit with detailed report per WCAG 2.1 criteria.
- Fixed components with correct tabindex and ARIA.
- Documentation of implemented keyboard patterns.
- Integration tests in Cypress.
- Developer guide for maintaining accessibility.
Timeline
- Keyboard navigation audit: 1 day.
- Fixing native elements and focus styles: 1–2 days.
- Custom components (dropdowns, modals, sliders): 3–5 days.
- Testing and adjustments: 1–2 days.
Cost is individual, but the audit is comparable to one developer day. Order a keyboard navigation audit and get a free consultation. Contact us to discuss your project details.