In short and in plain language
Many links and buttons on websites have no name. A screen reader then only says “link” or “button”. People who cannot see well do not know what the button does.
Every link and every button needs a name. The name says what happens. For example: “Add to cart”.
Buttons with a picture often have no name. Text that only the screen reader reads can help. A link with the word “more” does not say where it goes. Clear text can help.
What you see should also be in the name. If not, voice control cannot find the button.
We check the links and buttons on your website. We show you how to fix the problems.
For a heart icon without a name, a screen reader just says “button”; for a linked product image without alternative text it often reads out the address; and for a row of links labelled “more” it repeats the same word again and again. These are among the most common findings an automated check reports: in February 2026, empty links appeared on 46.3 percent (WebAIM Million 2026) of the home pages tested and empty buttons on 30.6 percent (WebAIM Million 2026), and both figures rose compared with the previous year. This article explains where a control gets its accessible name from, which WCAG criteria work together here and how to fix icon buttons, image links and “more” links. Finally, we describe how to test with the screen reader’s links list, which lets you walk through a template without any additional tool.
Key takeaways
- Empty links appear on 46.3 percent and empty buttons on 30.6 percent of the home pages of the one million most visited websites (WebAIM Million 2026); both shares rose compared with 2025.
- Every link and every button needs a name that states its purpose. WCAG 2.2 requires this at Level A through SC 4.1.2 (Name, Role, Value) and SC 2.4.4 (Link Purpose In Context) (W3C, WCAG 2.2).
- Icon buttons get their name from visually hidden text or aria-label, and the icon itself is hidden with aria-hidden. Name the function, not the shape: “Close”, not “X” (W3C, APG).
- An image link and a text link to the same target belong in one shared a element, with an empty alt on the image (W3C, Technique H2). A linked image without alternative text yields no usable link name.
- Overriding a visible label with aria-label easily breaks SC 2.5.3: the name must contain the visible text, ideally at its start (W3C, WCAG 2.2, SC 2.5.3).
- Test with the screen reader’s links list, for example NVDA+F7: every entry must make sense without its surroundings. Empty entries, addresses, file names and repeated “more” are template findings.
What an accessible name is and where it comes from
For assistive technology, every control on a website has three properties: a role such as link, button or checkbox, a state where relevant, such as pressed or expanded, and a name. The screen reader reads the name aloud, voice input uses it as a command, and in the links list it is the only text that appears. For links and buttons, the accessible name is the only content screen reader users perceive for that element (W3C, APG). If it is missing, only the role remains: “button” or “link”, with no hint at all about what will happen.
Where the name comes from follows a fixed order of precedence. For a simple link or button it is the contained text, for a linked image its alt attribute. The attributes aria-labelledby and aria-label take precedence over these sources and override the visible text, even when that text is correctly associated with the element (W3C, Understanding SC 2.5.3). At the very end come title and placeholder: browsers only fall back on them as a last resort, and the result is usually a weak name (W3C, APG). The ARIA Authoring Practices sum this up in five cardinal rules (W3C, APG): heed warnings and test thoroughly, prefer visible text, prefer native HTML techniques, avoid browser fallback and compose brief, useful names.
In practice this means a <button> with text is well named without a single ARIA attribute. Problems arise mainly where text is missing, that is with icons, images and elements styled only through a CSS background, and where an aria-label is later placed over existing text. Our article on screen reader optimization gives a general overview of roles, landmarks and headings; this one is solely about the names of links and buttons.
One finding, several criteria: WCAG 2.4.4, 2.5.3 and 4.1.2
In an audit report, a poorly named link rarely shows up under just one number. Several WCAG 2.2 success criteria interlock, all of them at Level A and therefore part of every Level AA evaluation (W3C, WCAG 2.2). The table maps them to typical findings.
| Criterion (W3C, WCAG 2.2) | Level | What it requires | Typical finding |
|---|---|---|---|
| 4.1.2 Name, Role, Value | A | Name and role of every control can be programmatically determined | Icon button without text and without aria-label |
| 2.4.4 Link Purpose (In Context) | A | Purpose of each link can be determined from the link text or from link text plus programmatically determined context | “more” without reference, linked image without alt |
| 2.5.3 Label in Name | A | The name contains the text that is presented visually | visible “Buy now”, announced “Complete order” |
| 1.1.1 Non-text Content | A | A non-text control has a name that describes its purpose | magnifier image as search button with alt “magnifier.svg” |
SC 4.1.2 explicitly includes links and components generated by scripts (W3C, WCAG 2.2, SC 4.1.2). SC 2.4.4 allows context: the purpose may follow from the same sentence, paragraph, list item or table cell (W3C, Understanding SC 2.4.4). The stricter SC 2.4.9 requires a mechanism that lets the purpose of each link be identified from the link text alone, but it belongs to Level AAA (W3C, WCAG 2.2, SC 2.4.9). SC 2.5.3 only applies where a visible text label exists; a pure icon does not fall under it. If an element with visible text has no name at all, it fails both 4.1.2 and 2.5.3 (W3C, Understanding SC 2.5.3).
Legally, this is no detail. The German Accessibility Strengthening Act applies to services provided to consumers after 28 June 2025 (BFSG, § 1), including e-commerce services. Under § 12 no. 3 BFSGV, websites must be made perceivable, operable, understandable and robust in a consistent and adequate way (BFSGV, § 12). For web content, the European standard EN 301 549 refers to WCAG; our article on EN 301 549 explains the chain of rules, and the duties are summarised under BFSG requirements. Depending on the offence, infringements can be punished with a fine of up to one hundred thousand euros (BFSG, § 37).
How common empty links and buttons are
The annual WebAIM Million analysis provides figures. For the 2026 edition, WebAIM tested the home pages of the 1,000,000 (WebAIM Million 2026) most visited websites automatically with the WAVE evaluation tool; the results date from February 2026 (WebAIM Million 2026). Empty links appeared on 46.3 percent (WebAIM Million 2026) of home pages, after 45.4 percent (WebAIM Million 2026) the year before. The share with empty buttons rose from 29.6 percent to 30.6 percent (WebAIM Million 2026). Both belong to the error types that have formed the list of most common findings unchanged for 7 years (WebAIM Million 2026).
On top of that come links that do have text, just not useful text: 15.2 percent (WebAIM Million 2026) of home pages used ambiguous link text such as “click here”, “more” or “continue”, compared with 13.7 percent (WebAIM Million 2026) the year before. These pages had 5.3 (WebAIM Million 2026) such links on average. Part of the problem stems from images: 45 percent (WebAIM Million 2026) of the images missing alternative text were linked images, and one in four linked images was missing alternative text (WebAIM Million 2026).
The HTTP Archive’s Web Almanac reaches a similar picture with a different method. It analyses a monthly crawl of 17 million websites (Web Almanac 2025) covering home and secondary pages. According to it, about 9 percent of desktop buttons and 11 percent of mobile buttons have no accessible name (Web Almanac 2025). For 57 percent of desktop buttons the name comes from their content, for 28 percent from an aria-label (Web Almanac 2025). The authors observe a continued increase of 4 to 5 percent in buttons named with aria-label alone, without a corresponding visible label (Web Almanac 2025), in other words a growing gap between what people see and what is announced.
How much this hurts in everyday use is shown by WebAIM’s survey of screen reader users. It ran in December 2023 and January 2024 (WebAIM Screen Reader Survey 2024) and collected 1,539 valid responses (WebAIM Screen Reader Survey 2024). In the ranking of the most problematic items, “links or buttons that do not make sense” come in at rank 3 (WebAIM Screen Reader Survey 2024), behind CAPTCHA and behind menus, tabs and dialogs that do not behave as expected.
Empty is only the lower bound
Pattern 1: giving icon buttons a name
A heart for the wish list, a cart, a magnifier, a close cross, arrows in a carousel: icon buttons are a typical source of empty buttons. The code usually looks like the first example below, a <button> with an SVG graphic inside but no text. The screen reader then just says “button”. There are two equally valid ways to fix it. Either the button contains text that is only hidden visually, for example through a visually-hidden class that removes the text from the screen but keeps it in the accessibility tree. Or the button gets an aria-label. In both cases the icon itself is hidden with aria-hidden="true" so that no graphic name gets in the way.
<!-- Finding: button without a name -->
<button class="tile__fav">
<svg viewBox="0 0 24 24"><path d="..."/></svg>
</button>
<!-- Fix A: visually hidden text inside the button -->
<button class="tile__fav" aria-pressed="false">
<svg aria-hidden="true" viewBox="0 0 24 24"><path d="..."/></svg>
<span class="visually-hidden">Save: hiking boot A</span>
</button>
<!-- Fix B: aria-label when no text should go into the markup -->
<button class="dialog__close" aria-label="Close">
<svg aria-hidden="true" viewBox="0 0 24 24"><path d="..."/></svg>
</button>For the name itself, the APG recommendations apply. Name the function, not the shape, so “Close” rather than “X” (W3C, APG). Put the distinguishing word first, for actions usually the verb, and for many elements one to three words are sufficient (W3C, APG). The role does not belong in the name: a button named “Close button” is announced twice over, because the screen reader states the role anyway (W3C, APG). If an overview shows many heart buttons, each needs its own name such as “Save: hiking boot A”, because elements with the same role should carry distinct names unless they really do the same thing (W3C, APG).
Toggle buttons such as the save heart are a special case. Here the name stays the same and the state changes via aria-pressed. The APG stress that the label on a toggle must not change when its state changes (W3C, APG); the screen reader then says something like “Save: hiking boot A, toggle button, pressed”. Alternatively, the name switches between “Save” and “Remove from wish list”, in which case aria-pressed is dropped. Mixing both produces contradictory announcements. If you are checking the template of an entire product page, you will find the remaining building blocks in our article on accessible product pages.
Pattern 2: image links and linked logos
For a linked image, the alt attribute is the link name. If it is missing, screen readers often fall back on the file name or the target address, and the links list fills up with entries like “product-4711-thumb.jpg”. This fails SC 1.1.1, because an image that serves as a control needs a name that describes its purpose (W3C, WCAG 2.2, SC 1.1.1), and it fails SC 2.4.4 at the same time. The alternative text of a linked image therefore describes the target, not the motif: “Hiking boot A, details” rather than “brown boot on wooden floor”.
The same applies to the logo in the header. If it leads to the home page, the alternative text names the provider and the target, such as “Company name, home page”. A logo embedded only as a CSS background has no text at all; in that case the link needs an aria-label or visually hidden text. Our article on alt text covers how to tell informative, decorative and functional images apart.
Product tiles often place a linked image directly next to a text link to the same target. For keyboard and screen reader users these are two consecutive, identical links. W3C Technique H2 puts image and text into one shared <a> element and gives the image an empty alt=""; then there is only one link, and the links list contains no duplicate (W3C, Technique H2). In an overview with many tiles, this saves as many tab stops as there are tiles.
<!-- Finding: two links to the same target, the image without alt -->
<a href="/hiking-boot-a/"><img src="boot-a.jpg"></a>
<a href="/hiking-boot-a/">Hiking boot A</a>
<!-- Fix: one link, the image is decoration -->
<a href="/hiking-boot-a/">
<img src="boot-a.jpg" alt="">
Hiking boot A
</a>Pattern 3: “more” links with the target in the name
“More”, “read more”, “details” or “click here” are not automatically a failure of SC 2.4.4. The criterion allows the purpose to follow from programmatically determined context, for example the same sentence, paragraph or list item (W3C, Understanding SC 2.4.4). The W3C nevertheless recommends stating the purpose in the link text itself wherever possible, because assistive technology can offer a list of all links on the page, and that list has no context (W3C, Understanding SC 2.4.4). Several “more” entries cannot be told apart in it. Where context-dependent link text cannot be avoided, it belongs at the end of the sentence that describes the target, not at its beginning (W3C, Understanding SC 2.4.4).
There are three ways to fix this, listed here in the order we recommend them:
- Change the visible text: “Details on hiking boot A” instead of “more”. This is the most robust solution, because visible text and name match and the page becomes clearer for everyone.
- Extend the visible text: “More” stays visible, and a visually hidden addition supplies “about hiking boot A”. The name starts with the visible word, as SC 2.5.3 recommends as best practice.
- Associate context:
aria-labelledbypoints to the link itself and to the tile’s heading. The APG show this with a “Read more” link that takes the article heading into its name (W3C, APG). The link’s own text comes first in the reference list.
A title attribute does not help. Browsers only use it as a fallback when no other name is present (W3C, APG); for a link with the visible text “more”, the name stays “more”. Nor does an aria-label that replaces “more” with “Open product details”: the name then no longer contains the visible word, and SC 2.5.3 is failed. For the links list, a further rule applies: links to the same target should have the same text, links to different targets different text (W3C, Understanding SC 2.4.4).
Pattern 4: the visible label in the name
SC 2.5.3 requires the accessible name to contain the text that is presented visually (W3C, WCAG 2.2, SC 2.5.3). As a best practice, the guidelines recommend placing the visible text at the start of the name (W3C, WCAG 2.2, SC 2.5.3). The reason is voice input: someone who says “click Add to cart” only hits the button if its name contains those words. And for screen reader users who can also see, it is confusing when what they hear and what they see diverge (W3C, Understanding SC 2.5.3). Our article on voice control covers the check for speech input, including a test grid; this section is about how to build names for links and buttons without losing the visible text.
The typical error starts with good intentions. A team wants to describe a button more precisely and puts an aria-label on it. Because aria-label takes precedence over the content, the visible text disappears from the name (W3C, Understanding SC 2.5.3). “Buy now” is announced as “Complete order”, and voice input can no longer find “Buy now”. Capitalisation and most punctuation, on the other hand, do not matter for the criterion, and symbols such as an arrow character do not count as a label (W3C, Understanding SC 2.5.3).
| Visible text | Accessible name | Assessment under SC 2.5.3 (W3C, Understanding SC 2.5.3) |
|---|---|---|
| Add to cart | Add to cart | passes |
| Add to cart | Add to cart: hiking boot A | passes, visible text comes first |
| more | More about hiking boot A | passes, capitalisation does not matter |
| Buy now | Complete order | fails, visible text missing from the name |
| Next … | Next | passes, the ellipsis does not count |
| heart icon only | Save: hiking boot A | not applicable, no visible text label |
Rule of thumb for names with an addition
Testing with the screen reader’s links list
A quick check for these findings needs no code editor, just the list that screen reader users rely on themselves. It shows every link on a page without its surroundings, exactly the way links are perceived in the least favourable case under SC 2.4.4. In NVDA, NVDA+F7 opens the elements list with links, headings, form fields and buttons; in VoiceOver on the Mac the rotor (VO+U) serves the same purpose, and in JAWS Insert+F7 lists the links. Our screen reader testing starts with the markup: it checks whether names, roles, states and status messages are marked up so that screen readers can announce them.
- Open the links list and read it from top to bottom. Every entry must say where it leads without the page context.
- Note empty entries, addresses, file names and placeholders such as “icon-arrow”: these are missing or wrong names under SC 4.1.2, 1.1.1 and 2.4.4.
- Mark identical names with different targets, such as repeated “more”, and conversely identical targets with different names.
- Go through the buttons via the elements list or quick navigation, especially icon buttons in the header, tiles, carousels and dialogs.
- For every element with a visible label, compare whether the announced name contains the visible text and starts with it (SC 2.5.3).
- Check states as well: wish list toggles report pressed or not pressed, menu buttons expanded or collapsed.
This check does not replace measurement, it complements it. An automated run finds empty links and buttons across many pages; the links list shows whether existing names are any good. Our article on testing methods compares which tools find what. The browser’s developer tools additionally show in the accessibility tree which source a name was computed from, such as the content, the alt attribute or an aria-label.
| Finding | Automated testing | Manual testing via links list and announcement |
|---|---|---|
| Link or button without any text | reliably detected | confirms the finding in the template |
| Linked image without alt | reliably detected | clarifies which alternative text describes the target |
| Link text “more” or “here” | usually only as a warning | clarifies whether the context is sufficient |
| Name “image”, “icon-cart” or a file name | often not detected | clarifies whether the name states the purpose |
| aria-label differs from visible text | only partly detected | compares what is seen and what is heard |
| Same name, different targets | rarely detected | cross-check in the links list |
Anchoring the fix in templates and editorial work
Empty links and buttons rarely occur on their own. Usually the error sits in a component that recurs on many pages: the product tile, the carousel, the share menu. That is why the fix belongs in the component, not on the individual page. A proven approach is to allow icon buttons only through a component that requires a name as a mandatory property, and to prevent the content management system from saving linked images with an empty alt field. Our article on the accessible design system shows what this looks like in a component library.
Two points are easily overlooked in multilingual shops. First, aria-label values tend to fall by the wayside during translation because they are not visible; the APG explicitly point out that they must be translated too (W3C, APG). Second, visible text is the more stable source: names that exist only in markup are more likely to be forgotten when design or content changes (W3C, APG). For editorial teams, a short rule in the style guide helps: link text names the target, not the gesture, so “Price list as PDF” rather than “here”. We teach rules like these in training for editorial and development teams.
In a WCAG audit, these findings are among the first to show up, because they repeat in every template. We test automatically, evaluate every criterion and go through keyboard operation and screen reader output by hand; every finding comes with severity, WCAG reference and a solution. For implementation in components and templates there is accessible web development, and so that new content does not bring back empty links, accessibility monitoring watches the website continuously. Our article on the audit report describes how a list of findings becomes a remediation plan.
Related Articles
Commissioning Easy Language: DIN SPEC 33429 in Practice
How to commission Easy Language: choosing texts, the briefing, review by at least 2 people with learning difficulties and publishing under DIN SPEC 33429.
Accessible customer support: what § 12 BFSGV requires
Hotline, email, contact form or chat: what § 12 No. 4 BFSGV requires of support services and how to make accessibility answers and contact channels work.
Countdowns, Timers, Pop-ups: Accessible Holiday Promotions
Countdown bar, basket timer and voucher pop-up: which element falls under WCAG 2.2.1 or 2.2.2, and what shops should test before the holiday campaign starts.