Accessible Name Computation: The UI Naming Algorithm

WHY IT EXISTS A sighted user sees a magnifying glass icon and knows it means "Search." A screen reader user needs a text equivalent. Accessible Name Computation is the standardized process browsers use to find or create that text label so all assistive technologies, like screen readers, work consistently. Without it, every browser and screen reader might interpret the UI differently, leading to a broken experience.

THE MENTAL MODEL Think of it as a naming cascade, similar in spirit to CSS specificity. The browser has a prioritized list of sources to check for an element's name. It starts with the most explicit source (like an aria-labelledby attribute) and works its way down to less explicit ones (like the text inside a button). The first valid name it finds, it uses. This ensures a predictable outcome for how your UI is announced.

HOW IT WORKS The browser traverses the DOM and builds a parallel "accessibility tree." For each object in this tree, it needs a name. The computation follows a strict, multi-step algorithm. The general order of precedence is: first, aria-labelledby (if present and valid); second, aria-label; third, the element's own text content or native HTML attribute (like an <img>'s alt text or a <label> for an <input>); fourth, a title attribute (as a last resort). The process stops as soon as a name is found. The exact steps are complex and depend on the element's role, but this hierarchy covers most common cases.

WHEN TO USE IT You don't "use" the computation directly; the browser does it automatically. You influence it by providing the right HTML and ARIA attributes. This is critical for any interactive element (buttons, links, form controls) and for elements that convey information without text, such as icon-only buttons or informative images.

WHEN NOT TO USE IT Avoid overriding an element's name when its visible text is already clear and sufficient. If a button has descriptive text like <button>Submit Form</button>, adding aria-label="Click to submit" is redundant and can be harmful. The computation would correctly use "Submit Form" on its own. Only provide an explicit accessible name when an element has no visible text or its visible text is ambiguous.

ONE CANONICAL EXAMPLE Consider a close button that is just an "X" icon. A sighted user understands this, but a screen reader needs more. If the HTML is just <button>×</button>, the computed accessible name is "×" (the multiplication sign), which is unhelpful. To fix this, we provide an explicit name: <button aria-label="Close">×</button>. The computation algorithm now checks for aria-label, finds "Close", and stops. The screen reader will announce "Close, button," providing a clear, actionable label.