Accessible Name

The accessible name is derived algorithmically, not by visual heuristics. The browser computes it by walking a strict precedence order: aria-labelledby → aria-label → native HTML labeling (e.g., <label> wrapping) → title attribute → placeholder text. This ensures AI parsers and screen readers receive a consistent, machine-readable identifier regardless of CSS styling or visual layout.

The Accessible Name and Description Computation algorithm defines a strict hierarchy. If multiple sources exist, the highest-priority source wins, and lower-priority sources are ignored entirely.

• 1st: aria-labelledby (references other element IDs)
• 2nd: aria-label (direct string attribute)
• 3rd: Native host language labeling (e.g., <label for='id'>)
• 4th: title attribute (fallback only)
• 5th: Placeholder text (weakest, not recommended as sole name)

An accessible name should convey the purpose of the control, not its current state or descriptive metadata. For interactive elements, it typically answers 'What will happen if I activate this?'

• Good: 'Submit application'
• Bad: 'Blue rounded button with shadow'
• Good: 'Close dialog'
• Bad: 'X icon' (unless purely decorative and hidden from accessibility tree)

The computation algorithm flattens all referenced content into a single, plain text string. Nested semantics are stripped: if aria-labelledby points to a <div> containing a <strong> element, the bold formatting is lost. The algorithm concatenates text nodes in depth-first DOM order, ignoring CSS display: none and visibility: hidden content, but including off-screen text positioned via CSS tricks.

The accessible name inherits the language of the element or its nearest ancestor with a lang attribute. This is critical for screen reader pronunciation. An English button labeled 'Paris' inside a French lang='fr' container will be pronounced with French phonetics. AI agents use this language signal to correctly disambiguate named entities in multilingual documents.

Certain ARIA roles require an accessible name for the element to be valid in the accessibility tree. Without one, the element is effectively hidden from assistive technology.

• Require name: button, link, checkbox, textbox, combobox, dialog
• Do not require name: group, presentation, none
• Conditional: region (requires name only if not a landmark)

A complementary, programmatically determined text string that provides extended context beyond the accessible name. Computed via aria-describedby, it is announced after the name and role by screen readers. Unlike the name, the description is not used as the primary identifier. For AI parsers, the description offers rich semantic context—for example, associating a password input with its complexity requirements or linking a button to a tooltip explaining its action.

A constraint in the ARIA specification stating that certain roles must not have an accessible name provided by the author. Roles like generic, none, and presentation are intentionally nameless to prevent them from being exposed as distinct objects in the accessibility tree. Violating this rule—for example, adding aria-label to a <div> with role='presentation'—creates a malformed accessibility tree that confuses both assistive technologies and AI content parsers.