"To ensure accessibility, we added plenty of aria-label attributes to buttons and links." When taking on accessibility remediation in client projects, we frequently encounter sites that have purportedly been "addressed" this way. Yet listening through an actual screen reader reveals repetitive announcements like "navigation, main navigation, navigation," or finds heading text completely overwritten and hidden by aria-label. Labels added with good intentions end up making comprehension worse. People often mistakenly believe accessibility means "adding lots of ARIA," but the reality is the opposite: overusing it causes harm.
A clear illustration dispelling this misconception is CSS-Tricks' article, There’s no need to include ‘navigation’ in your navigation labels (CSS-Tricks). As the article points out, adding the word "navigation" to a label like <nav aria-label="メインナビゲーション"> causes the screen reader to announce both the element role (navigation) and the label's "navigation," resulting in duplicate phrasing. In this article, we examine how these names are constructed and how to resolve both redundant and missing labels from a web development standpoint.
How screen reader accessible names are determined
Buttons, links, and input fields all have an accessible name that screen readers announce. This name is not determined by a single attribute; rather, it is calculated according to a strict precedence order. Broadly speaking, the order is as follows, with higher items taking precedence:
| Priority | Source of name | Examples |
|---|---|---|
| High | aria-labelledby (derives name from another element) | References heading ID |
| ↓ | aria-label (explicitly specified name) | aria-label="検索" |
| ↓ | Element's own text content / <label> | Text inside button |
| Low | Supplementary fallbacks like title or alt | Image alt |
The critical point to understand here is that aria-label completely overrides an element's native text. If you apply aria-label="フォームを送る" to <button>送信</button>, a screen reader will announce "Submit form" instead of "Submit." When the visible text conflicts with what is read aloud, voice navigation (such as saying "click Submit") breaks, making the interface harder to use. aria-label is a last resort when an accessible name cannot be provided via text; it is not something where more is always better. For other mechanisms that convey state and dynamic changes to assistive technologies, see our article on announcing dynamic changes with aria-live. It helps to keep roles distinct: naming (what an element is) versus notifications (what just happened).
Common patterns of redundancy
Redundancy caused by over-labeling typically falls into three common patterns:
First is duplicating role names. This occurs when you include the role that the element already announces automatically (like "navigation" or "button") inside the label itself, as in <nav aria-label="ナビゲーション"> or <button aria-label="ボタン: 送信">. Screen readers will read this redundantly as "main navigation, navigation." Labels should not contain roles; providing distinguishing context like aria-label="メイン" is entirely sufficient.
Second is doubling up on text. This happens when an aria-label with identical content is placed on a link that already contains visible text. Because the label overrides the name, differing text causes a mismatch, while matching text is entirely redundant. If visible text is present, a label is generally unnecessary.
Third is duplication between image alt text and adjacent text. When an image with an alt of "Company Logo" sits beside text displaying the company name, screen readers read the same thing twice. For decorative images or images already reinforced by text, setting alt="" to remove them from screen reader announcements is often the proper approach.
Common patterns of omission
Conversely, missing names that leave controls announced as merely "button" or "link" are also widespread.
The most frequent culprit is the icon-only button. Buttons containing only <button>✕</button> or SVG icons lack text content, meaning screen readers announce them simply as "button," leaving their purpose unknown. This is the proper use case for supplying a name via text, such as with aria-label="閉じる". Similarly, when multiple links labeled "Learn more" appear in sequence, they share identical names and cannot be distinguished. You must provide wording that clarifies the destination or supplements context.
<!-- 悪い例：何のボタンか読まれない / 役割名が重複 -->
<button><svg ...></svg></button>
<nav aria-label="ナビゲーション">...</nav>
<!-- 良い例：アイコンには名前を、navには区別だけを -->
<button aria-label="メニューを開く"><svg aria-hidden="true" ...></svg></button>
<nav aria-label="メイン">...</nav>In short, the fundamental rule is: add accessible names to icons, and avoid adding them to elements that already have text.
Pitfalls When Integrating Agents in Custom Development
On a corporate website where GleamHub took over accessibility remediation (client name withheld), the previous agency had added aria-label to virtually every link, button, and region in the name of compliance. Listening through a screen reader revealed a chaotic state: heading text was overwritten by aria-label into different phrases, navigations were redundant with repeated role names, and the icon buttons that actually required accessible names had none. Despite a high count of added attributes, usability had actually deteriorated.
We began by subtracting unnecessary aria-label attributes. We removed labels from elements with visible text, eliminated role duplications, and restored overwritten headings. Then, we selectively added labels only to icon buttons that genuinely lacked names. Verifying announcements one by one on real-device screen readers, we ensured visible text matched spoken output. As a result, announcements became concise and accurate, and voice navigation began working properly. What made the difference was not addition, but subtraction combined with surgical additions where truly needed.
What proved most impactful in this engagement was verifying announcements through actual screen readers. ARIA makes it easy to assume something works when it doesn't communicate correctly, a disconnect invisible from simply looking at the screen. To comprehensively elevate accessibility, evaluating name, state, and operation as distinct facets—in tandem with the principles covered in our foundational web accessibility guide—minimizes oversights. Just like verifying font sizing and zoom resilience, name accuracy can only be guaranteed by testing under actual usage conditions. For visual resilience, our article on font scaling resilience serves as a helpful reference.
Where to begin
Reframing accessibility from "adding lots of ARIA" to "accurately balancing the accessible names read by screen readers" is how a site becomes genuinely usable. Subtract role duplications and text overrides, and selectively add names only to unlabeled controls like icon buttons—this combination of subtraction and surgical addition forms the foundation.
As a first step, we recommend checking icon-only buttons on your site to ensure they have appropriate names, and verifying with a real screen reader that existing aria-label attributes are not unnecessarily overwriting visible text.
If you are concerned about overly verbose screen reader output from excessive aria-label attributes, icon buttons with unclear purposes, or ensuring your accessibility efforts communicate accurately, please reach out via GleamHub's contact form. We will inspect your live site using physical screen readers, isolate redundancies and omissions, and refine your markup into a balanced, accessible structure.
