Glossary / Accessible names

Accessible names

An accessible name is the short label exposed to assistive technologies to identify an element’s purpose. It is computed from sources such as associated <label> text, element contents, aria-labelledby, aria-label, and—in limited cases—attributes such as alt. The name is not necessarily visible in the same form, but should normally match or include the visible label so speech-input users can invoke controls by what they see.

What to know

• A control’s computed name is different from its role, description, value, and state. “Search” may be the name; “textbox” the role; “Enter keywords” the description.
• Prefer visible text or native labeling. Use aria-labelledby to reference existing visible text; use aria-label when no visible text is practical and the intent is unambiguous.
• For <button> and links, descendant text commonly provides the name. Icon-only controls need a concise programmatic name such as aria-label="Close dialog".
• Images use alt according to purpose: informative images need equivalent content; decorative images use alt=""; functional images describe the action/destination, often via the containing link/button name.
• title is not a dependable substitute for a visible label; it may be unavailable to keyboard, touch, and some assistive-technology users.
• WCAG 2.5.3 Label in Name requires the accessible name of controls with visible text labels to contain that visible text, supporting speech input and consistency.
• Duplicate names among repeated controls can be ambiguous; add contextual text via aria-labelledby or visually hidden content when needed.

Debugging

Inspect the computed accessible name in browser developer tools rather than guessing from markup. Check precedence and hidden referenced text, ensure IDs are unique, and verify that CSS-hidden text intended for screen readers is hidden visually without display:none or visibility:hidden. Test icon buttons, repeated “More” links, form fields, and custom components. Keep names action-oriented and concise; do not repeat the role (“Submit button”) unless it adds meaning because assistive technology already announces role.

Interview questions

1. Name versus description? Name identifies the control; description supplies additional context.
2. When use aria-labelledby over aria-label? When suitable visible text already exists and can be referenced; this avoids duplicate strings and aligns visual and spoken labels.
3. How should an icon-only button be labeled? Give the button a concise action name, such as “Close dialog”; do not rely on the icon glyph or tooltip alone.
4. What is Label in Name? Visible label text should be included in the programmatic name so speech users can address the control.
5. How do you find the actual name? Inspect the accessibility tree or browser accessibility pane and test with assistive technology.

References

• Accessible Name and Description Computation 1.2
• WCAG 2.2 Label in Name