An element with an interactive role must be keyboard focusable

Rule interactive-role-focusable · Component patterns (best practice) · impact serious · Static + live

↩ Back to the rules index · WCAG cross-reference

Why it matters#

Adding an interactive ARIA role to a <div>/<span> tells assistive technology the element is operable, but the role does not make it focusable. Without tabindex="0" (or an aria-activedescendant model on an ancestor) keyboard users can never reach the control. Native controls (<button>, <a href>, form fields) and elements with tabindex="-1" managed by a roving/activedescendant widget are not flagged.

How to fix#

Add tabindex="0" to the element, or use the equivalent native control. For composite-widget members (tabs, options, menu items) use a roving tabindex or an ancestor aria-activedescendant model instead.

Example#

<div role="button">Buy now</div>

<div role="button" tabindex="0">Buy now</div>

Example#

<span role="checkbox" aria-checked="false">Remember me</span>

<span role="checkbox" aria-checked="false" tabindex="0">Remember me</span>

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#

• APG — Keyboard interface