Link text: “Click here” is not information

There is a test that shows the quality of your link texts in ten seconds. A screen reader can output all the links on a page as a list — detached from the surrounding text. In NVDA that is the key combination NVDA key + F7.

What often comes out is a list like this:

Learn more
Learn more
Click here
Read more
Learn more
Details
Read more

That is no navigation aid, that is noise. And it is the state the link texts of most websites are in.

What this is about

A link should be understandable on its own. Whoever reads it should know where it leads — without the surrounding paragraph, without the heading above, without the image next to it.

That is the requirement of success criterion 2.4.4 “Link Purpose (In Context)”, level A: the purpose of every link has to be determinable from the link text alone or from the link text plus context.

The stricter version at level AAA (criterion 2.4.9) requires the purpose to be recognisable from the link text alone. That is a good yardstick for the wording, even if you are not aiming for AAA.

Who benefits:

• Screen reader users who move through a page by link list — a common way of working, because it is faster than linear reading.
• People with cognitive impairments who decide from the link text whether to click.
• Users of voice input who call up a link by its name.
• And everyone else. A person skimming a page reads the links first — they are highlighted in colour and draw the eye. A link with content is a signpost for sighted people too.

(Rheinwerk, Barrierefreie Webseiten, ch. 8.1)

What makes a good link text

Concrete instead of general. Not “click here”, not “learn more”, not “read more”. But: what lies behind it.

<!-- not like this -->
<p>We have revised our prices. <a href="/preise">Click here</a>.</p>

<!-- like this -->
<p>We have revised our prices. <a href="/preise">To the current price list</a>.</p>

For files: name the format and size. Whoever clicks a link and suddenly starts a download has been surprised. A note in the link text or directly after it prevents that: “Maintenance contract as PDF, 240 kB”.

Same text, same target. If two links carry the same text but lead somewhere else, the link list user cannot resolve it. The reverse applies too: two links leading to the same target should also have the same name.

No “link” in the link text. The screen reader announces that it is a link anyway. “Link to the price list” then becomes “link, link to the price list”.

And the most common fix in real life: on overview pages with tiles, every tile has a “Learn more” underneath. Instead of setting the same text five times, make the tile's heading the link. Then the link is called “Accessibility audit” and not “Learn more”, and you have solved the problem at the root instead of cosmetically.

What a link has to look like

Success criterion 1.4.1 “Use of Color”, level A, applies here too: colour must not be the only means of recognising a link as a link.

So a link in running text needs a second signal besides colour. In practice that means: underline. There would be alternatives — bold, a different font size, a small icon after it — but the underline is the only one every user understands without explanation.

In recent years the underline has often been removed for design reasons. That is the second big mistake in this area, right after “click here”. If the default underline bothers you, design it:

.beitrag a {
  text-decoration: underline;
  text-decoration-thickness: 1px;
  text-underline-offset: 0.2em;
}

That way the line sits lower, is thinner and no longer cuts through the descenders of g, j and p.

Exception: the main navigation, footer lists and buttons need no underline. There, position and design make clear that they are controls. The rule applies to links in running text, where they have to stand out from normal text.

One more point on design: the formatting has to be the same across the whole website. If links are blue and underlined on one page and green without underline on another, every visitor has the same learning task twice.

New windows

A link with target="_blank" opens a new window or tab. That should be used sparingly.

What speaks against it:

• The back button no longer works. For many users it is the most important control in the browser.
• An extra window is left behind that someone has to close later.
• Screen reader users often only notice the switch when they want to go back and cannot.
• On a smartphone, managing tabs is a real hurdle for many users.

If you do it anyway — for external sources, for documents, for forms opened during an ongoing process — then announce it. A note in the link text or an icon with alternative text is enough: “To the DIN standard (opens in a new window)”.

Technically, external links should also have rel="noopener". Modern browsers now apply this behaviour by themselves, but stating it explicitly does no harm and covers the cases where the default does not apply.

When what is visible and what is read out diverge

Success criterion 2.5.3 “Label in Name”, level A, is one of the criteria you only understand once you think of voice input.

A user says “Click Send”. Their system looks for an element whose programmatic name contains “Send”. If the button visibly says “Send” and the code does too, that works.

The error arises from a well-meant aria-label:

<!-- wrong: visibly it says "Send", read out is "Submit form" -->
<button type="submit" aria-label="Submit form">Send</button>

<!-- right -->
<button type="submit">Send</button>

In the first case voice input fails, because “Send” does not occur in the programmatic name.

The rule is: the visible text has to be contained in the programmatic name. An aria-label may be longer and explain more — but the visible text has to occur in it. “Send” may become “Send — submit enquiry”, not “Submit form”.

An aria-label is only needed at all where there is no visible text: for icon buttons without a label, for example. Where visible text is present, it is superfluous in most cases and does more harm than good.

Navigation that is the same everywhere

Two level AA criteria belong together:

3.2.3 “Consistent Navigation”. Repeated navigation elements have to appear on all pages in the same relative order. The menu stays in its place, the items stay in their order, the footer is built the same everywhere.

3.2.4 “Consistent Identification”. Elements with the same function have to have the same name everywhere. If the area is called “My account” once, it is not called “My area” on the next page and “Customer account” in the footer.

That sounds self-evident and is not. It regularly breaks when a website grows over years and different people create content.

Who benefits: everyone, but especially people with cognitive impairments who rely on recurring patterns, and screen reader users who remember an order instead of searching anew each time.

Menu items nobody understands

A point from usability that hits the same nail: menu labels have to be self-explanatory.

The book's example is good: a shop for baby equipment has a category “On the go”. It contains prams and car seats. For the operator the grouping is logical. For the customer looking for a child seat it is invisible — they do not look under “On the go”.

The consequence is not a barrier in the legal sense, but simply a lost customer.

If you are unsure how users would group your own content, you can find out with card sorting: write all pages on cards and have people from the target group sort them into groups and name them. That takes an hour and often produces a menu structure you would never have come up with yourself.

Practical for small businesses: ask three customers under which menu item they would look for a particular piece of information. Not: “Do you like this?” But: “Where would you click if you wanted to know what an audit costs?”

Jump links on long pages

On long pages jump links help — a small table of contents at the top that leads to the sections.

<h2 id="ablauf">How the process works</h2>
...
<p><a href="#ablauf">To the process</a></p>

Every jump target needs a unique id. Duplicate IDs on one page make the jump go nowhere or land in the wrong place — an error that occurs more often on WordPress sites with repeatedly used blocks than you would think.

How to check it yourself

The link list. The quickest and most telling test. With NVDA: NVDA key + F7. If you do not want to use a screen reader, there is another way — skim your page and read only the highlighted words. Does that make a sensible list?

The printout test. Imagine someone reads you only the link texts of your home page, without anything else. Would you know what this website offers?

The underline check. Go through your running texts and see whether links would be recognisable without colour perception. The greyscale mode in the browser's developer tools shows that at once.

The search for target="_blank". Count how many links on your website open a new window, and ask for each one: why, actually?

The menu question to real people. No tool, but the most effective check of all.

What to do

Start with the repetitions. Collect all “Learn more”, “Read more”, “Click here” on one list and replace them. Where there are many, it is usually down to one block used everywhere — then one change in one place is enough.

Make headings into links, instead of putting links under headings. That solves the problem structurally.

Restore the underline in running text. If it bothers you, design it instead of removing it.

Reduce new windows to the cases where there is a reason, and announce those.

Clear out superfluous aria-labels. They are well meant and break voice input.

And if you are working on the structure anyway: menu naming is the point with the biggest lever on enquiries. A menu that speaks your customers' language instead of your own works more strongly than any search engine optimisation on the same page.

Sources

• Rheinwerk, Barrierefreie Webseiten, ch. 8.1 (navigation) — WCAG 2.4.4 on link purpose in context and 2.4.9 at level AAA, the four aspects of good links (link text, formatting, alternative text for image links, keyboard operability), the note on file name and format for downloads, the requirement of a second visual signal besides colour, the restrained use of target="_blank" with the reasoning about the back button and extra windows, WCAG 3.2.3 on consistent navigation and 3.2.4 on consistent identification with the “My account” example, WCAG 2.5.3 “Label in Name” with the aria-label error example and its effect on voice input, the unique id for jump links, the menu example “On the go” from the baby equipment shop, card sorting as a method, and the NVDA link list via NVDA key + F7.
• Rheinwerk, Barrierefreie Webseiten, ch. 6.1 (use of colour) — WCAG 1.4.1, colour never as the only visual means.
• Atlas, security/subresource-integrity.md — rel="noopener" and rel="noreferrer", browsers' default behaviour today with target="_blank" and the reason to state the relationship anyway.
• Atlas, accessibility/criteria/2-4-4-link-purpose-in-context.md — classification of the criterion by principle, guideline and conformance level.
• Own audit practice — the recommendation to link tiles through their heading rather than through an additional text link, designing the underline through text-underline-offset rather than removing it, the distinction between running-text links and navigation elements, duplicate id values with repeatedly used blocks in WordPress, and the three check questions to real customers on menu naming.