ARIA property
aria-activedescendant
Points at the item inside a composite widget that is currently active, when focus stays on the container.
Change the id it holds and the active item changes with it, while DOM focus stays exactly where it was. That is the whole point of it. The container keeps focus and this attribute says which child inside the container is live right now.
Which roles may carry aria-activedescendant
- Value
- ID reference
- Filed as
- A property, which is how ARIA files it and not a rule about how often it changes.
- Roles that may carry it
application,combobox,composite,group,textbox
Those lists are not advice. Browsers are required to ignore a non-global attribute sitting on a role that does not support it, so aria-activedescendant on the wrong element is not weak, it is absent. You can read it in the DOM and nobody using a screen reader can.
Every role above comes from the specification's own list for this attribute, checked name for name. The normative definition stays with the W3C, in the aria-activedescendant section of the ARIA specification.
Keeping aria-activedescendant true
This one has to move on every arrow press, and the spec is stricter about it than about the other attributes that point at an id. The id has to match an existing element exactly, and a value matching nothing is called an author error in its own right rather than quietly forgiven. Two wirings are legal. Either the element you point at is owned by the element holding focus, or the focused element is a combobox, textbox or searchbox whose aria-controls points at a container that supports this. Get that right once, then keep the value moving, because a listbox whose active descendant never updates reads as parked on its first option no matter how far somebody has arrowed down.
How aria-activedescendant gets checked
There are test rules that check an ARIA attribute is one that exists, is allowed on the role underneath it, and carries a value of the right type. What they map to is ARIA's own author requirements rather than any WCAG criterion, so a misplaced attribute breaks ARIA without being a WCAG failure by itself. It becomes one under 4.1.2 Name, Role, Value the moment the missing or wrong value means the control's state cannot be worked out programmatically, which is what usually happens next.
The value testing skips id references on purpose. Pointing at an element that does not exist and having no pointer at all come to the same end, so a broken reference fails no rule directly. It fails later, wherever the missing name or description was needed.
Nothing automated catches the failure this page is about. A stale value is a valid value, on a permitted role, with the right type. It is only wrong about the world.
Attributes you will meet alongside aria-activedescendant
- aria-autocomplete How a text field predicts what you are typing.
- aria-disabled Says a control is present but not available. Unlike the disabled attribute, it stays focusable, so people can still find out it is there.
- aria-errormessage Points at the message explaining why this field is invalid. Only meaningful while aria-invalid is set.
- aria-expanded Whether the thing this control opens is currently open.
- aria-haspopup Says this control opens something, and what kind of thing it opens. A menu, a dialog, a listbox.
- aria-invalid Says a field's value has failed validation.
- aria-multiline Whether a text field takes more than one line, which changes what Enter does.
- aria-placeholder A hint shown in an empty field. It is not a label and does not replace one.
Every ARIA state and property · Every ARIA role · ARIA explained