ARIA meter elements must 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
A meter represents a value within a known range — such as progress, usage, or a score — but without an accessible name, screen readers can only announce a number with no explanation. Users relying on assistive technologies would have no idea what that value represents, reducing comprehension and usability of dashboards and analytics interfaces.
How to fix this issue
Provide a meaningful accessible name that describes what the meter measures, such as 'Storage usage' or 'Battery level.' This can be done with aria-label or aria-labelledby attributes. Keep the name short and descriptive, and avoid encoding the numeric value in the name — assistive tech already announces it automatically.
Developer guidance
Custom meters often appear in monitoring dashboards or admin panels. Create a design system rule that all meter components require a descriptive label prop. During development, test the element’s announcement with NVDA or VoiceOver. Integrate axe-core automated checks into CI to detect unlabeled role='meter' elements before release.
Code examples
Incorrect Implementation
<div role="meter" aria-valuenow="80"></div>Correct Implementation
<div role="meter" aria-valuenow="80" aria-label="Storage usage"></div>
Trusted by organizations across Europe working toward WCAG and EAA conformance