Avoiding Role Words in Accessible Names
Avoiding Role Words in Accessible Names records a distinct W3C-supported interface-writing task while keeping implementation mechanics outside the writing guidance.
Do not add generic role words such as “button” or “navigation” to an accessible name when assistive technology will already announce the role.
Key details
Important caveats
Scope Boundary
A role word can still be meaningful when it is part of the actual proper name or user-facing phrase; the rule targets redundant role labeling.
Further guidance
Content
Write the identifying purpose only; omit generic role words such as “button,” “image,” or “navigation” when the platform will announce that role.
Practical Application
Name the element by its purpose or destination and let the interface semantics supply generic roles such as button, link, or navigation unless the role word is genuinely part of the visible content.
Purpose
Removing duplicated role words avoids repetitive screen-reader output and keeps the name focused on what distinguishes the element.
Reader Check
If assistive technology already announces the element type, does the accessible name repeat that role without adding meaning?
Worked Example
For a button that saves changes, use the accessible name “Save changes,” not “Save changes button,” because the button role is announced separately.
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.