Link Names vs Button Names: Why Click Here Fails

A link and a button do different jobs, and their names should show it. A link takes you somewhere. A button does something on the page you are already on. When both are named "click here", a screen reader user pulling up a list of links hears the same phrase again and again, with no clue where each one goes or what each one does.

WCAG success criterion 2.4.4, Link Purpose (In Context), at Level A, states the rule for links: the purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context. WCAG success criterion 4.1.2, Name, Role, Value, at Level A, states the rule for controls in general: the name and role of each user interface component can be programmatically determined. A button with no name fails that second rule outright, even if the button looks clear to a sighted visitor.

Key takeaways

• A link name should say where the link goes or what document it opens.
• A button name should say what the button does, in verb form.
• Test every name out of context: read the list of links and buttons alone and see if each one still makes sense.
• An icon only button needs a text name in code, even though no text shows on screen.
• Never use "click here", "read more" alone, "learn more" alone, or a bare URL as a name.

The list test

Screen reader software can list all the links on a page, and all the buttons, apart from the surrounding text. That list is the test that matters. Open your own page, pull up the links list, and read it top to bottom. If you hear "click here, click here, learn more, click here", the page has a naming problem, no matter how clear each link looked inside its paragraph.

The same test works for buttons. A list that reads "button, button, button" tells a keyboard user nothing. A list that reads "Add to cart, Save draft, Send message" tells them everything they need to choose.

Fixing link names

The fix for a link is usually a rewrite, not new code. Put the destination in the link text itself. The sentence around the link can stay, but the link text must carry the meaning on its own.

Failing version:

<p>Our pricing page has the details. <a href="/pricing">Click here</a> to see them.</p>

Passing version:

<p>See <a href="/pricing">Axeazy pricing plans</a> for the details.</p>

A second pattern causes the same trouble: "read more" repeated under every news item or blog summary. Each "read more" points somewhere different, but the text is identical. Fix it by adding the article title to the link text. If the design only shows "read more" on screen, put the extra words in code so assistive technology hears them, using a visually hidden span or an aria-label that repeats the full name. Keep the visible text and the coded name in agreement, so a voice control user who says the visible words still hits the right link.

For links where the surrounding sentence already names the destination, WCAG 2.4.4 allows the purpose to come from link context, such as the same sentence, paragraph, list item, or table cell. That is a fallback, not a goal. Aim for link text that works alone. It also helps sighted readers who scan a page and sighted search users who read link text in search results.

Fixing button names

A button name should be a verb phrase: what happens when you press it. "Save", "Send message", "Add to cart", "Close menu". A button named with a noun alone, such as "Settings" with no verb, is weaker but often understood from context. A button with no name at all is a plain failure of 4.1.2.

Icon only buttons are the most common failure here. A magnifying glass icon, a hamburger icon, or an X icon means nothing in code until someone writes a name for it. Use visible text when you can. When the design truly leaves no room for text, give the button an aria-label that says what it does.

Failing version:

<button><span class="icon-search"></span></button>

Passing version:

<button aria-label="Search the site"><span class="icon-search" aria-hidden="true"></span></button>

Note the two parts working together. The aria-label gives the button its name. The aria-hidden="true" on the icon keeps the icon character out of the name, so a screen reader does not announce a stray glyph. MDN warns that aria-hidden="true" should not be used on elements that can receive focus, so put it on the inner icon span, never on the button itself.

A native button element already carries the button role and keyboard behavior. If you build a button from a div or span instead, you must add the role and the keyboard handling yourself, and you still owe it a name. The cheaper path is almost always a real button element with real text or a real aria-label.

Image links and linked icons

When an image is the only content inside a link, the image alt text becomes the link name. W3C lists this as failure F89 when no accessible name is provided. So an image link to a product page needs alt text that names the product or the destination, not a description of the picture for its own sake.

Failing version:

<a href="/product/blue-mug"><img src="mug.jpg" alt="A blue mug on a white background"></a>

Passing version:

<a href="/product/blue-mug"><img src="mug.jpg" alt="Blue ceramic mug product page"></a>

When a link holds both an icon and text, hide the icon with aria-hidden="true" and let the text carry the name. Announcing both the icon and the text repeats the same idea twice and can garble the name.

Common mistakes

• Repeating "read more" or "learn more" under every item on a list page.
• Naming a button after its icon ("X", "hamburger") instead of its action ("Close menu", "Open navigation").
• Putting the only useful words outside the link, so the link itself reads as "here".
• Using the same link text for two different destinations on one page.
• Writing a long aria-label that disagrees with the visible label, which breaks voice control.
• Hiding the whole button with aria-hidden instead of hiding only its decorative icon.

How Axeazy helps with this exact issue

Axeazy lists link names and button names among the 14 fix categories it works on. A scan can flag a link or button whose name is missing or empty in the code on your own page. Read the honest scope on the capabilities page, and read how the scan works to see how findings are recorded with a date and time.

For a site with its own GitHub repository, fixes arrive as a real pull request with a visible code diff for review and merge. For other sites, the scan gives the computed fix values and a guided checklist to apply by hand. Link and button names are code level fixes: the name lives in the markup, so changing the markup changes what assistive technology announces.

For related fixes, see the accessible checkout form guide, where labels and button names carry a form, and the WordPress skip link guide, which covers another named control readers meet first on a page.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 30, 2026.

FAQ

Is "read more" ever acceptable as link text?

Only when the link context makes the purpose clear, such as the same paragraph naming the article, and even then a fuller name is better. Repeated "read more" links on one page fail the list test, so add the article title to each one.

What is the difference between a link name and a button name?

A link name says where the link goes. A button name says what the button does on the current page. Both must make sense out of context, and both must be present in code, not only visible on screen.

Do I need visible text on an icon only button?

No, but you do need a name in code. An aria-label on the button gives it that name, while aria-hidden="true" on the decorative icon keeps stray characters out of the announcement. Visible text is still the simpler choice when space allows.

Can Axeazy name my links and buttons for me?

Axeazy can flag missing or empty names in your code and, for sites with a GitHub repository, propose the fix as a reviewable pull request. The wording of each name is still a judgment call about your content, so review the proposed names before merging.

Sources

• W3C Understanding Success Criterion 2.4.4: Link Purpose (In Context), checked October 30, 2026
• W3C Understanding Success Criterion 4.1.2: Name, Role, Value, checked October 30, 2026
• MDN: aria-hidden attribute, checked October 30, 2026
• Axeazy capabilities, checked October 30, 2026