Accessible Name Computation

Every interactive element on a web page—buttons, links, form controls, landmarks—needs a human-readable name so that assistive technologies like screen readers can announce it to users. The Accessible Name and Description Computation (often shortened to "AccName") is the W3C specification that defines, step by step, how a browser's accessibility tree derives that name. Because multiple HTML attributes and techniques can supply a name simultaneously, the algorithm establishes a strict priority order to guarantee a single, deterministic result.

Understanding this algorithm is essential for developers who want their pages to pass automated accessibility checks and, more importantly, to actually work for people who rely on assistive technology. When the algorithm resolves to an empty string—or to the wrong string—screen-reader users may encounter unlabeled buttons, ambiguous links, or form fields they cannot identify.

Why Accessible Name Computation matters

The accessible name is the primary piece of information a screen reader announces when a user focuses an element. If a <button> has no computed name, a screen reader may announce only "button," leaving the user guessing what it does. For form inputs, a missing name means users cannot tell what data they should enter, which directly violates WCAG 2.1 Success Criteria 1.1.1 (Non-text Content), 1.3.1 (Info and Relationships), and 4.1.2 (Name, Role, Value).

Automated validators such as axe-core and Lighthouse rely on the same algorithm to flag issues. If you see a warning like "Element has no accessible name," it means the AccName algorithm resolved to an empty string. Knowing the priority order lets you fix the issue quickly and choose the right labeling technique for each situation.

How Accessible Name Computation works

The algorithm processes a set of sources in a defined priority order. When a higher-priority source provides a non-empty string, lower-priority sources are ignored.

Priority order

1. aria-labelledby — References one or more elements by id. Their text content is concatenated to form the name. This always wins when present and pointing to valid targets.
2. aria-label — A string attribute applied directly to the element. Used when there is no visible label to reference.
3. Native HTML labeling — Includes <label> elements associated via for/id, the <label> wrapping the control, <caption> for tables, <legend> for fieldsets, and the alt attribute for images.
4. Element content or title — For elements like <button> or <a>, the algorithm falls back to the element's text content. As a last resort, the title attribute is used, though it is considered the least reliable source.

Recursive text computation

When the algorithm needs the text of a referenced element (e.g., the target of aria-labelledby), it recursively walks the subtree, collecting text from child nodes. Hidden elements referenced by aria-labelledby are still included—this is an intentional exception that lets authors create off-screen labels.

Flat string result

Regardless of how many sources contribute, the final output is a single flat string with extra whitespace collapsed. This is what gets exposed in the browser's accessibility tree and announced by screen readers.

Code examples

Bad example — button with no accessible name

<button>
  <svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
    <path d="M3 6h18M3 12h18M3 18h18" stroke="currentColor" stroke-width="2"/>
  </svg>
</button>

A screen reader announces "button" with no additional context because SVG content alone does not produce a computed name.

Good example — using aria-label

<button aria-label="Open menu">
  <svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
    <path d="M3 6h18M3 12h18M3 18h18" stroke="currentColor" stroke-width="2"/>
  </svg>
</button>

The aria-label attribute gives the button a clear accessible name of "Open menu."

Bad example — input with no associated label

<input type="email" placeholder="Enter your email">

The placeholder attribute is not a reliable accessible name source in the AccName algorithm. Many screen readers will read it, but WCAG considers placeholder text insufficient because it disappears once the user types.

Good example — explicit label association

<label for="user-email">Email address</label>
<input id="user-email" type="email" placeholder="you@example.com">

The <label> element's for attribute matches the input's id, providing a robust accessible name of "Email address."

Good example — aria-labelledby overriding native label

<h2 id="section-title">Billing details</h2>
<label for="card-number">Card number</label>
<input id="card-number" type="text" aria-labelledby="section-title card-number-label">
<span id="card-number-label">Credit or debit card</span>

Because aria-labelledby sits at the top of the priority chain, the accessible name becomes "Billing details Credit or debit card," concatenated from both referenced elements. The native <label> is overridden entirely.

Tip: inspecting the computed name

Modern browsers expose the computed accessible name in DevTools. In Chrome, open the Elements panel, select the node, and expand the Accessibility pane to see the Name field and its source. This is the fastest way to verify which step of the algorithm provided the name.

By understanding and working with the Accessible Name Computation algorithm, you ensure that every interactive element on your page is clearly identifiable to all users, passes automated accessibility audits, and meets WCAG requirements without guesswork.