Keyboard accessibility is fully supported
Why it matters
Keyboard accessibility is the baseline for all assistive technology: screen readers, switch access devices, voice control, and eye-tracking all depend on the keyboard interaction model. WCAG 2.2 SC 2.1.1 (Keyboard) is Level A — every function reachable by mouse must have a keyboard equivalent. Mouse-only interactions like hover menus, drag-and-drop without alternative, or right-click context menus completely lock out users who cannot use a pointing device.
Severity rationale
Medium because mouse-only interactions create functional exclusions for keyboard users — a WCAG 2.2 SC 2.1.1 Level A violation — though severity is bounded by how many features are affected.
Remediation
Audit every interactive element for keyboard operability. Hover-only menus must open on focus; drag-and-drop must have a keyboard alternative; custom widgets must handle Enter and Space.
// Hover menu — also opens on keyboard focus
<div
onMouseEnter={() => setOpen(true)}
onFocus={() => setOpen(true)}
onMouseLeave={() => setOpen(false)}
onBlur={(e) => {
// Close only when focus leaves the entire menu subtree
if (!e.currentTarget.contains(e.relatedTarget)) setOpen(false)
}}
>
<button aria-expanded={isOpen} aria-haspopup="true">Products</button>
{isOpen && <ul role="menu">{/* items */}</ul>}
</div>
For drag-and-drop, provide buttons that move items up/down as a keyboard-accessible alternative. Tab through the entire app to confirm every interactive element is reachable.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Accessibility WCAG Compliance Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- wcag:2.2 · 2.1.1 — Keyboard
- section-508:2018-refresh · 407.6 — Operation of Mechanical Controls
Taxons
History
- 2026-04-18·v1.0.0·Initial import from accessibility-wcag·automated