J5.11.1ARIA relationship IDREFdesignresearch

Relationship attributes must point at elements that actually exist

Aliases: aria-labelledby · aria-describedby · aria-controls · broken IDREF

What it is

Values of aria-labelledby, aria-describedby, aria-controls, aria-owns, and aria-activedescendant are ID lists, not sentences for humans. They have to resolve to nodes that exist and are still in the tree at computation time (ARIA relationship IDREF). Point at nothing, at an unmounted node, or at an ID the current tree cannot see inside another shadow, and the relation is dropped. Failure is silent: name computation falls through, the description never appears, a control claims to “control” a region that is not there.

Why it happens

IDREFs are resolved on the beat of accessibility computation, not when the author typed the attribute. A single-page app unmounts the error text, puts the id on the other branch of a conditional, or leaves the label in a closed template: the attribute string remains, the resolution is empty. An empty labelledby lets name computation fall to the next source, which can look “fine” while a description or compound name is already gone. Empty controls means the reader cannot offer “jump to the controlled region”; empty activedescendant leaves focus on the combobox shell and the active option unknown.

The second layer is document bounds. IDs are scoped to a tree, not to the screen. Nodes in iframes, shadow DOM, or portals are not addressable by the same string from outside. Copy a component three times with id="hint" and the pointer does not guarantee which one. Relationship attributes have no fallback that fuzzy-matches visible text. A wrong ID is a cut.

Studying it

In the inspector, check whether the relation resolves to a node, not whether the attribute string is present. Build four cells: ID exists and is visible; ID exists but display:none; ID deleted after render; ID inside a shadow root. Record computed name and description for labelledby / describedby; for controls, see whether the reader can jump. Re-check after a framework route change, hunting dangling references after unmount.

Independent variables: whether the target is in the tree, hiding method, crossing a shadow boundary, duplicate IDs. Dependent variables: whether computed name/description includes the target text, whether the inspector shows a broken relation, whether a reader jump fails.

Where it stops holding

Pointing at a visually hidden node that is still in the tree is a legitimate way to supply a computed name; that is not the same as pointing at a deleted node. aria-labelledby may list several IDs; when one is broken, some engines drop the whole string and some skip the bad token — engine-dependent. Whether SVG ids interoperate with HTML ids depends on how the SVG is embedded. Native <label for> uses host binding; when it breaks, the clickable region often fails in a way eyes can see, which is more visible than ARIA’s silence. That is not “don’t use supplement attributes”; it is different visibility of a broken relation in two pipes.

Applying it

  • Put only ids that will exist in the current document into relationship attributes; write the attribute after conditional hints, errors, and dialogs are mounted, and clear it before unmount.
  • Generate ids with an instance prefix; do not reuse global names like hint or error that will collide.
  • For relations across shadow roots, use native slots or place the target in the same computable tree; do not assume matching strings reach across.
  • How to check: in the accessibility pane, open every node with labelledby / describedby / controls and see whether the reference resolves to an element. Then delete the target or change route and listen for name and description going empty. String still there, pane shows a break: it points at a ghost.

Related

  • Same group: J5.11.2 Misused live regions interrupt speech with secondary noise · J5.11.3 ARIA overrides native semantics and can conflict rather than supplement · J5.11.4 ARIA cannot add keyboard behavior an element does not already have
  • Nearby: J5.03 ARIA supplement · J5.10 Name, role and value
  • Search terms: ARIA relationship IDREF · aria-labelledby · aria-describedby

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J5.11.1