Preferring Visible Text for Accessible Names
Preferring Visible Text for Accessible Names records a distinct W3C-supported interface-writing task while keeping implementation mechanics outside the writing guidance.
Prefer an appropriate visible label as the accessible name so the same wording serves visual and assistive-technology users whenever practical.
Key details
Important caveats
Scope Boundary
Hidden naming text is still appropriate when no useful visible label exists; the guidance is a preference, not a ban on aria-label or other techniques.
Further guidance
Content
Reuse the visible label text when it already communicates the right purpose instead of inventing a separate hidden label with different wording.
Practical Application
When an element already has an appropriate visible label, use that visible wording as the accessible name whenever practical instead of creating different hidden text. Introduce a separate hidden name only when the visible text does not provide a usable name.
Purpose
Matching accessible and visible wording reduces maintenance drift and supports users who rely on both visual text and assistive technology.
Reader Check
Will users who see the label and users who hear the accessible name encounter matching language for the same control or link?
Worked Example
If a button visibly says “Save draft,” use “Save draft” as its accessible name instead of assigning a different hidden label such as “Store unfinished document.”
Sources and evidence
Sources are shown with the role they play in this guide. Historical or style-sensitive claims are kept within the evidence boundary described above.
- Providing Accessible Names and Descriptions — W3C WAI ARIA APG (opens in a new tab)W3C Web Accessibility Initiative · W3C WAI-ARIA Authoring Practices guidance for descriptive accessible names, visible labels, and button/control naming.