Ensure ARIA buttons, links, and menu items have accessible names
Accessibility isn’t only about avoiding violations — it’s about ensuring your product can be used confidently by everyone. This guide explains the principle of this rule, shows what goes wrong in real-world code, and provides a verified fix that meets WCAG and the European Accessibility Act (EAA).
Why this matters and how to fix it
Why this matters
ARIA buttons, links, and menu items that lack accessible names are completely silent to screen readers. While visual users can see the label or icon, non-visual users will have no idea what action is available. This violates the WCAG Name, Role, Value criterion, which requires all interactive elements to expose a clear, perceivable name.
How to fix this issue
Add accessible names using visible text, aria-label, or aria-labelledby. If the element contains an icon-only button, provide a descriptive label that communicates the purpose (e.g., 'Search', 'Close', or 'Download PDF'). Avoid generic names like 'button' or 'click here' that provide no context about the action. Test using screen readers such as NVDA or VoiceOver to confirm that names are announced correctly.
Developer guidance
This error often occurs in icon-only components or dynamically generated menus. Ensure that your design system enforces accessibility at the component level — for example, requiring an aria-label prop in icon-only buttons. Automated linting and unit tests can prevent regressions by verifying that every command element exposes an accessible name before merge.
Code examples
Incorrect Implementation
<div role="button"></div>Correct Implementation
<div role="button" aria-label="Submit"></div>
Trusted by organizations across Europe working toward WCAG and EAA conformance