• Success Criterion 2.1.1
  • Conformance level A

Hover-Only Menu With No Way to Open It by Keyboard

2.1.1 — Keyboard

Scenario

Setting

A hospital's patient portal appointment scheduler

What’s wrong

Hover-only menus with no keyboard-open equivalent (submenu items unreachable).

Example 

.dept-menu .submenu { display: none; }
.dept-menu:hover .submenu { display: block; }
<!-- the submenu has no click, focus, or keydown trigger, only the CSS :hover rule -->

Why it matters

A patient tabbing through the scheduler reaches "Departments" but the submenu never appears, so they cannot select a specialty.

How to test

Tab to a menu trigger (don't hover): if opening the menu requires mouse hover with no keyboard-triggered equivalent, submenu items are unreachable.

How to fix

Pair a :focus-within CSS rule with keyboard handling on the trigger so focus, not just hover, reveals the submenu.

.dept-menu:hover .submenu,
.dept-menu:focus-within .submenu { display: block; }

menuButton.addEventListener('keydown', (e) => {
  if (e.key === 'Enter' || e.key === 'ArrowDown') openSubmenu();
});

Outcome

A patient tabs to "Departments," presses Enter, and picks Cardiology from the submenu that appears.

Who is affected

Keyboard-only users and screen magnifier users who never trigger CSS hover cannot see or reach the submenu items.

Learn more

Related scenarios