Focusable elements have no suitable role
Automated check focus-order-semantics, run with axe-core
- WCAG
- Best practice: a recommendation, not a WCAG success criterion
- Severity
- Moderate: a degraded experience
- Typical effort
- Moderate, 1 to 4 hours
- Category
- Keyboard
Who this affects
Keyboard and screen reader users.
Why it matters
A <div> or <span> made focusable with tabindex but given no role receives focus without being announced as something the user can operate.
How to fix it
Use a native <button> or <a>, or add a suitable role such as role="button" together with keyboard handling.
Check your own website
The free scan tests 3 pages against WCAG 2.2 A and AA in about 30 seconds. No sign-up.
Related checks: Keyboard
- Duplicate access keys
- Hidden elements can still receive keyboard focus
- Elements with role="text" contain focusable content
- No way to skip repeated navigation
- Frames with interactive content cannot be reached by keyboard
- Scrollable areas cannot be reached by keyboard
- Skip links point to nothing
- Positive tabindex values disrupt focus order