A composite widget must respond to arrow-key navigation

Rule widget-keyboard-operable · Component patterns (best practice) · impact serious · Live only (static → incomplete)

↩ Back to the rules index · WCAG cross-reference

Why it matters#

Composite ARIA widgets are operated with the arrow keys: one item stays in the Tab sequence and the arrows move the active item (roving tabindex, or aria-activedescendant). A widget that declares the right roles and a roving tabindex but has no working arrow-key handler cannot be operated by keyboard at all — the structural roving-tabindex rules cannot see this. The engine focuses each visible widget and presses its APG arrow keys to verify the active item actually moves.

How to fix#

Handle the arrow keys on the widget: move focus (or aria-activedescendant) to the next/previous item and wrap as the pattern requires. Follow the exact keys in the matching ARIA APG pattern.

Example#

<div role="tablist"><button role="tab" tabindex="0" aria-selected="true">One</button><button role="tab" tabindex="-1" aria-selected="false">Two</button></div>

<div role="tablist"><button role="tab" tabindex="0" aria-selected="true">One</button><button role="tab" tabindex="-1" aria-selected="false">Two</button></div>

WCAG success criteria#

2.1.1 Keyboard — Level A#

All functionality must be operable through a keyboard alone (composite widgets need roving tabindex or aria-activedescendant so every control is reachable and operable).

Understanding 2.1.1

Standards#

This rule contributes to the following standards:

WCAG A EN 301 549

References#

• ARIA APG — Keyboard patterns