LEARNING OBJECTIVES โต
- Understand the fundamental concept of an Accessible Name and how it determines what screen readers announce upon focus.
- Trace the step-by-step resolution order of the W3C Accessible Name and Description Computation (AccName 1.2) specification.
- Differentiate between
aria-labelledby,aria-label, andaria-describedbyin semantic meaning, announcement order, and tree resolution. - Identify when an accessible name overrides child subtree text content and when it is ignored on generic elements.
๐ The Mental Model & Story (Intuitive Foundation)
Imagine entering an international airport baggage claim terminal. Every carousel is outfitted with multiple identification badges:
- The Overhead Neon Display (
aria-labelledby): A bright sign that references official flight numbers from the departures board: "Flight BA-178 from London Heathrow". - The Stenciled Badge on the Machine (
aria-label): A direct label painted onto the steel frame: "Baggage Carousel 4". - The Mechanical Label inside the Mechanism (Native Subtree / Tag Content): The physical metal gears stamped with "Conveyor Belt Unit #42".
- The Advisory Placard underneath (
aria-describedby): A small informational note: "Oversized sporting luggage will arrive at Door C".
When a passenger approaches the carousel and asks "What is this carousel?", the airport announcer does not read every single badge at once. There is a strict, unambiguous protocol:
- If the Overhead Neon Display (
aria-labelledby) is present, read that first and stop looking for other titles. - If not, check the Direct Stenciled Badge (
aria-label). - If neither exists, read the Mechanical Label stamped directly inside the belt (the inner HTML text).
- Finally, read the secondary Advisory Placard (
aria-describedby) only as auxiliary secondary context after announcing the main name.
In the browser, this protocol is known as the Accessible Name and Description Computation (AccName) algorithm. Every interactive element exposed to the Accessibility Tree must have an accessible name, and the browser follows a strict cascading priority hierarchy to compute it.
Technical Deep Dive & Specifications
The Accessible Name vs. Accessible Description
Every accessible object in the Accessibility Tree has two primary text properties computed by the browser:
Name: The core label of the object. This is what the screen reader speaks first when focusing the element (e.g., "Submit, Button" or "First Name, Edit text").Description: Additional auxiliary information spoken after a brief pause or upon requesting additional details (e.g., "Password must contain at least 8 characters").
+-------------------------------------------------------------------------------+
| ACCESSIBILITY NODE ARCHITECTURE |
+-------------------------------------------------------------------------------+
| Role: button |
| Name: "Close Dialog" <-- Computed via AccName 1.2 Algorithm |
| Description: "Unsaved changes will be lost" <-- Computed via aria-describedby|
| State: focusable, focused |
+-------------------------------------------------------------------------------+
The W3C AccName 1.2 Computation Priority Algorithm
The W3C AccName 1.2 specification defines how browsers calculate the name of a DOM node. The priority hierarchy operates in the following descending order:
+-------------------------------------------------------------------------------+
| ACCNAME 1.2 DETERMINISTIC RESOLUTION |
+-------------------------------------------------------------------------------+
| |
| 1. Is aria-labelledby present and valid? |
| |---> YES: Concatenate text of all target IDs separated by spaces. |
| |---> NO : Proceed to Step 2 |
| |
| 2. Is aria-label present and non-empty? |
| |---> YES: Use the string value directly. |
| |---> NO : Proceed to Step 3 |
| |
| 3. Does the element have native host language labeling semantics? |
| (e.g., <label for="...">, <img alt="...">, <fieldset><legend>, <svg><title>)|
| |---> YES: Compute name from native labeling mechanism. |
| |---> NO : Proceed to Step 4 |
| |
| 4. Does the element's ARIA Role allow "Name from Contents"? |
| (e.g., button, link, heading, tab, menuitem, checkbox) |
| |---> YES: Recursively traverse child text nodes & pseudoelements. |
| |---> NO : Proceed to Step 5 |
| |
| 5. Fallback Attributes: title or placeholder |
| |---> Use title or placeholder attribute value if present. |
| |
+-------------------------------------------------------------------------------+
Attribute Comparison Matrix
| Attribute | Target Type | Primary Purpose | Overrides Subtree Text? | Screen Reader Timing |
|---|---|---|---|---|
aria-labelledby |
Space-separated list of element IDs | Point to existing visible DOM text nodes to construct the name. | Yes (Highest priority) | Spoken immediately as the element's identifier. |
aria-label |
Direct String literal | Provide a hidden string label when no visible text exists on screen. | Yes (Overrides child nodes) | Spoken immediately as the element's identifier. |
aria-describedby |
Space-separated list of element IDs | Provide secondary supplementary instructions or help text. | No (Does not affect Name) | Spoken after a brief pause after role and name. |
aria-description (ARIA 1.3) |
Direct String literal | Provide secondary text without referencing external DOM IDs. | No (Does not affect Name) | Spoken after the name and role. |
The "Name from Subtree" Rule
Certain interactive elements (like <button>, <a>, <th>, <summary>) calculate their accessible name from their child text nodes by default. However, when aria-label or aria-labelledby is declared, the entire child DOM subtree is completely discarded for accessible name calculation:
<!-- The visible word "Cancel" is completely obliterated from the A11y Tree! -->
<button aria-label="Permanently Delete Account">
Cancel
</button>
<!-- Screen Reader announces: "Permanently Delete Account, Button" -->
Multi-ID Resolution with aria-labelledby
aria-labelledby accepts multiple ID references separated by spaces. The browser concatenates the text content of those nodes in the exact order specified:
<span id="qty-lbl">Quantity</span>
<span id="item-lbl">Organic Colombian Coffee</span>
<input type="number" value="2" aria-labelledby="qty-lbl item-lbl">
<!-- Accessible Name: "Quantity Organic Colombian Coffee" -->
๐ป Interactive Code Playground
Starter Code
Line-by-Line Code Breakdown
- Line 26 (
<h2 id="billing-hdr">): Serves as the primary context node for the composite label. - Line 27 (
<p id="sub-hdr">): Serves as the sub-context node. - Line 29 (
<label id="street-lbl" for="street-input">): Standard HTML label element, also assigned anidso it can participate in composite naming. - Line 33 (
aria-labelledby="billing-hdr sub-hdr street-lbl"): Instructs the browser to concatenate the text from all 3 IDs:"Billing Address Primary Residence Street Address". This completely overrides the standard<label for>association. - Line 34 (
aria-describedby="street-hint"): Connects the helper paragraph as the accessible description. Screen readers announce this after the input type. - Line 41 (
<button class="icon-btn" aria-label="Close notification banner" ...>): Provides an explicit text name for an otherwise empty icon button. - Line 42 (
<svg ... aria-hidden="true">): Hides the raw SVG graphic nodes from the accessibility tree so they don't produce garbage character readings.
Expected Browser & Screen Reader Render Output
[Visual Display]
-----------------------------------------
Billing Address
Primary Residence
Street Address
[ Input Box ]
Include apartment, suite, or unit number if applicable.
[ X ] (Icon button) Will dismiss for 24 hours.
-----------------------------------------
[Screen Reader Focused Announcement]
Input:
"Billing Address Primary Residence Street Address, Edit text. Include apartment, suite, or unit number if applicable."
Icon Button:
"Close notification banner, Button. Will dismiss for 24 hours."๐๏ธ Hands-On Exercise
๐ฏ The Challenge: Build a Multi-Factor Security Token Input
Instructions:
- Create a security verification card with a heading (
id="auth-title"): "Two-Factor Authentication". - Create an input field for a 6-digit numeric OTP code.
- Compute the accessible name of the input by combining the card title (
#auth-title) and a field label (#token-labelreading "Security PIN"). - Associate an error message container (
id="token-err") reading "Code has expired. Request a new SMS code." usingaria-describedby. - Add an icon-only reload button (
<button>) that visually showsโปbut has the accessible name "Generate new security code" and a description referencing#token-err.
๐ Starter Code Sandbox
โ ๏ธ Common Pitfalls
- Using
aria-labelon Non-Interactive Generic Elements (<div>,<span>): Browsers and screen readers intentionally ignorearia-labelandaria-labelledbyon<div>and<span>elements unless they have an explicit ARIArole(likerole="region"orrole="group"). - WCAG 2.5.3 (Label in Name) Violations: If a button visually says "Save", setting
aria-label="Submit Form Data"fails WCAG 2.5.3 because speech recognition users saying "Click Save" will fail to activate the button. The accessible name must contain the exact visible text string. - Redundant Repetitions with
aria-describedby: Do not duplicate the element's name insidearia-describedby. This forces screen reader users to listen to the same phrase twice on every single tab stop.
๐ก Pro Tips
- Audit via Chrome DevTools A11y Pane: Open Chrome DevTools -> Elements -> Accessibility Tab -> Computed Properties. Look at the Name section; DevTools displays the entire calculation trace, showing exactly which attributes took precedence and which were overridden.
- Self-Referencing
aria-labelledby: An element can reference itself inaria-labelledbyalong with another element:aria-labelledby="prefix-id my-button-id suffix-id". This is invaluable for dynamic shopping carts and complex table headers.
๐ Key Takeaways
- The Accessible Name is the primary textual identifier exposed by the browser to platform Accessibility APIs (UIA, AXAPI, ATK).
aria-labelledbytakes top priority over all other naming mechanisms and can concatenate multiple space-separated DOM element IDs.aria-labeloverrides child text content and native host tags, but should be used sparingly to avoid diverging visual and auditory UI.aria-describedbyprovides secondary, non-essential description text spoken after the name, role, and value.- Always adhere to WCAG 2.5.3 (Label in Name): any visible text label must be included verbatim inside the computed accessible name.
- --