About this AccessLint rule
Elements with ARIA command roles (button, link, menuitem) must have an accessible name. Without one, assistive technologies cannot convey what the element does, leaving users unable to determine its purpose or distinguish it from other interactive controls on the page.
Screen reader users are the most directly affected. When a screen reader encounters a button or menuitem that has no accessible name, it may announce only the role (e.g., "button") with no indication of the action it performs. A sighted user might infer purpose from an icon, but a screen reader user hears nothing useful. This makes the interface effectively unusable for that control.
This rule maps to WCAG 2 success criterion 4.1.2 Name, Role, Value (Level A). That criterion requires all user interface components to have a name that can be programmatically determined. Level A means this is a baseline requirement — failing it is a conformance blocker.
Why this happens
The most common cause is an interactive element that contains only an image (or icon font) with no text alternative. For example, a button with role="menuitem" that contains only an <img> with an empty alt attribute produces no accessible name. The same problem occurs when an element has no text content and no aria-label, aria-labelledby, or title attribute.
Off-screen elements are not exempt. Even if a command is positioned off screen with CSS, it may still be present in the accessibility tree. If it lacks a name, it still fails this rule.
How to fix it
There are several ways to give an ARIA command an accessible name:
- Add visible text content inside the element. This is the simplest and most reliable approach.
- Add an
aria-labelattribute with a descriptive string. - Use
aria-labelledbyto reference another element that contains the label text. - As a last resort, use the
titleattribute. Note thattitlehas inconsistent support across assistive technologies and is generally less reliable than the other options.
Choose whichever method fits the design. Visible text content is preferred because it benefits all users, not just those using assistive technology.
Examples
Failing: menuitem with icon but no accessible name
The image has an empty alt attribute, and the button has no aria-label or text content. A screen reader will announce something like "menuitem" with no indication of what it does.
<div role="menu">
<button role="menuitem">
<img src="file-icon.svg" alt="" />
</button>
</div>
Failing: off-screen menuitem with no accessible name
Moving the menu off screen does not remove it from the accessibility tree. The button still lacks a name.
<style>
.offscreen {
position: absolute;
left: -9999px;
}
</style>
<div role="menu" class="offscreen">
<button role="menuitem">
<img src="file-icon.svg" alt="" />
</button>
</div>
Passing: menuitem with visible text content
<div role="menu">
<button role="menuitem">New file</button>
</div>
Passing: menuitem with aria-label
When visible text is not possible (for example, an icon-only button), aria-label provides the name directly.
<div role="menu">
<button role="menuitem" aria-label="New file">
<img src="file-icon.svg" alt="" />
</button>
</div>
Passing: menuitem with aria-labelledby
The aria-labelledby attribute points to an element that contains the label text. The referenced element can be visually hidden.
<div role="menu">
<button role="menuitem" aria-labelledby="newfile-label">
<img src="file-icon.svg" alt="" />
</button>
<span id="newfile-label" hidden>New file</span>
</div>
Passing: link role with visible text
The same rules apply to other ARIA command roles. A link role needs a name just like a menuitem does.
<span role="link" tabindex="0">View documentation</span>
Failing: link role with no accessible name
<span role="link" tabindex="0">
<img src="external-link.svg" alt="" />
</span>
To fix this, add aria-label="View documentation" to the span, or give the img a descriptive alt value.
Detect accessibility issues automatically
Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.
Help us improve our guides
Was this guide helpful?
🌍
Trusted by teams worldwide
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Scheduled Reports
API Access
Open Source Standards
$7
/ 7 days
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial →
Join teams across 40+ countries