ARIA Activedescendant Needs A Focusable Element
ID |
html.aria_activedescendant_tabindex |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Reliability |
Language |
Html |
Tags |
accessibility, reliability |
Description
Flags aria-activedescendant on an element that cannot hold focus, because it is neither natively
focusable nor given a tabindex.
Rationale
aria-activedescendant is how a composite widget says "the focus is really on this child" while the
DOM focus stays on the container. That indirection only works if the container is the focused
element: a screen reader reads the active descendant of whatever holds focus, so on an element that
never receives focus the attribute is never consulted and the widget’s keyboard navigation is
silent.
<ul aria-activedescendant="opt-1"><li id="opt-1">One</li></ul> <!-- FLAW — a ul takes no focus -->
<p aria-activedescendant="opt-1">Text</p> <!-- FLAW — same -->
<ul aria-activedescendant="opt-1" tabindex="0">...</ul> <!-- OK -->
<input aria-activedescendant="opt-1" type="text"> <!-- OK — natively focusable -->
<div aria-activedescendant="opt-1" th:tabindex="${order}">x</div> <!-- OK — a tab index does render -->A natively focusable element needs nothing further — input, select, textarea and button are
in the tab order already, and that is the usual shape of a combobox. Everything else has to opt in
with a tabindex, and its mere presence is enough: whether it is 0, -1 or a template
expression, the author has thought about focus.
The attribute’s value is not read at all — the defect is where the attribute sits, not what it points at.