Search topics
Links like "click here" that need the words around them
A shop's care guides each end in a "click here" link, or in the same "Care guide" link, so a link says which guide it opens only with the words before it.
<a href="/guides/enamel-care.pdf">click here</a> The problem
Screen reader users choosing from a list of links hear "click here" three times, with nothing to say which care guide each one opens.
A homeware shop's help pages have a page of care guides: one line for each kind of mug, with a PDF that says how to wash it, store it and what to avoid. Each line was written in the shop's editor the way people write an email: "Enamel mugs: for the care guide, click here (PDF, 120 KB)." Read from top to bottom, every line is clear.
Someone using a screen reader opens its list of links to go straight to the travel mug guide, and hears "click here, click here, click here". The list shows each link's own words and nothing else, so nothing says which one is which. They close the list, read the page line by line, and find the right link that way.
A writer, told that "click here" is poor practice, moves the link onto the words "Care guide". The line now reads "Enamel mugs: Care guide (PDF, 120 KB)", which looks tidier, but the list of links reads "Care guide, Care guide, Care guide": three links with the same words, opening three different files.
WCAG has two criteria for link text. 2.4.4 Link Purpose (In Context), at Level A, lets a link's purpose come from its text together with its programmatically determined link context: the text in the same sentence, paragraph, list item or table cell, or words tied to the link with ARIA. Every line here is a list item that names its mug, so both versions of these links most likely pass 2.4.4.
2.4.9 Link Purpose (Link Only), at Level AAA, asks for more: a way to tell each link's purpose from the link text alone. Link text alone is what a list of links, or Tab from link to link, gives: "click here". W3C describes this as failure F84, non-specific link text such as "click here" or "more" with no way to make it specific. The second version is a real description, but not of which guide: W3C calls it best practice for links with different purposes and destinations to have different descriptions, and three files called "Care guide" don't. Its exception, for a link whose purpose would be "ambiguous to users in general", doesn't apply either: the page itself says which guide each one opens, just outside the link.
Nothing stops either version from being written. A link's name is whatever words sit inside the a element, and a browser doesn't compare them with each other or with the line around them; a screen reader's list of links shows those names on their own.
The pattern is everywhere text is written in an editor rather than designed: help pages, news posts, press releases, emails published as pages, and lists of downloads where each item ends in "PDF", "Download" or "Details".
4 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision Screen reader users often open a list of every link on the page, or Tab from link to link, and hear "click here" three times, with nothing to say which guide each one opens, so they have to leave the list and read the lines around the links.
- Limited language, cognitive and learning abilities People who skim read a page's links first, because links stand out; "click here" makes them read each line again to find out which guide it opens.
- Limited vision Under high zoom, a magnifier can show the link with the start of its line out of view to the left, so the words that said which guide it was are off screen.
- Limited manipulation Voice control users follow a link by saying its words. "Click here" or "Care guide" matches all three links, so they have to choose from numbers instead.
axe's link-name rule passes every one of these links, because each has text. axe's identical-links-same-purpose, which finds links that share a name but go to different addresses, is tagged Level AAA, so a run on the usual A and AA tags never runs it. The audit switches it on by id and records what it finds as a lead, because only a person can tell whether two such links serve the same purpose: three PDFs called "Care guide" may be one guide in three languages. A lone "click here" doesn't repeat, so that rule never sees it; the audit's own check for generic link names, such as "click here" and 「こちら」, records it as a lead with the line around it, for the same reason. Asked to make "click here" accessible, an AI coding tool can add an aria-label that replaces the words on screen, which fails Label in Name instead.
Try it
Find the travel mug guide in the screen reader’s list of links under the page.
Broken 1: every line ends in “click here”. Which entry in the list opens the travel mug guide?
Broken 2: the links now say “Care guide”. Read the list again.
Apply a fix. Read the list again, and with the hidden words, compare it with the words the page shows.
Broken Can you fix this?
Care guides
- Enamel mugs: for the care guide, click here (PDF, 120 KB)
- Stoneware: for the care guide, click here (PDF, 95 KB)
- Travel mugs: for the care guide, click here (PDF, 140 KB)
Screen reader says:
Its list of links:
- click here
- click here
- click here
The fix
Put the words that say where it goes inside the link.
Click here on every line
<h2>Care guides</h2><ul class="guides"> <li> Enamel mugs: for the care guide, <a href="/guides/enamel-care.pdf">click here</a> (PDF, 120 KB) </li> <li> Stoneware: for the care guide, <a href="/guides/stoneware-care.pdf">click here</a> (PDF, 95 KB) </li> <li> Travel mugs: for the care guide, <a href="/guides/travel-care.pdf">click here</a> (PDF, 140 KB) </li></ul>What is wrong3 points
- Each link's text is "click here", which says nothing about where it goes.
- Which guide it opens is only in the words before the link.
- The list of links reads "click here" three times.
The guide's name as the link
<h2>Care guides</h2><ul class="guides"> <li> <a href="/guides/enamel-care.pdf">Enamel mug care guide</a> (PDF, 120 KB) </li> <li> <a href="/guides/stoneware-care.pdf">Stoneware care guide</a> (PDF, 95 KB) </li> <li> <a href="/guides/travel-care.pdf">Travel mug care guide</a> (PDF, 140 KB) </li></ul>How it is fixed2 steps
- Write each guide's whole name as the link's text: "Enamel mug care guide". The link now says which guide it opens on its own, in the list of links, on Tab and to anyone who skims.
- Take out "click here", and the words before the link that it now holds, so the line doesn't say them twice.
This fixes both Befores. It passes 2.4.9 (technique G91), and 2.4.4 with it. Every link's text is different, so axe's rule has nothing to report.
Why this fix: Write labels and link text that make sense on their own
Both pass 2.4.9. Choose the guide's name as the link: it gives every reader a link that says where it goes, not only people whose screen reader reads the hidden words, and there is no hidden text to keep in step with the line. Hidden words suit a dense list or table that shows many short links after each item's name, such as a guide in several formats, where writing the item's name into every link would repeat it on screen. Saying "click Care guide" then matches every line, and Apple's Voice Control has been reported to need the whole name, so on a Mac or an iPhone the person may have to use numbers.
Not an aria-label on "click here". aria-label="Enamel mug care guide" replaces "click here" as the link's name, so the name no longer contains the words on screen, which fails 2.5.3 Label in Name, a Level A criterion: speech software that matches what is said against the name may find nothing for "click here". An aria-label that starts with the visible words ("Care guide for enamel mugs") passes, but some browser translation tools leave it untranslated, so hidden text is the safer way to add words. Buttons and links named differently from their text covers that failure.
Not a description or a title. aria-describedby pointing at the line, or a title attribute, adds words that a screen reader may read after the name, but its list of links shows names only, and still reads "click here" three times.
A switch for long link text passes, but rarely helps. 2.4.9 asks for "a mechanism", so a control near the top of the page that rewrites every link to its long form passes (techniques G189 and SCR30). People have to find it, and may have to use it again on every page; writing the long form in the first place does the same job for everyone.
Same words, same place is fine. Two links called "Care guides" that both open the care guides page, one in the menu and one in the footer, pass: W3C calls it best practice for links with the same destination to have the same descriptions, and for links with different destinations to have different ones. axe's rule reports only links that share a name and go to different addresses, and even then a person decides, since the same guide in two formats is one purpose.
The file's type and size. Keeping "(PDF, 120 KB)" after the link is how many sites write it, and it doesn't affect 2.4.9. Putting it inside the link, "Enamel mug care guide (PDF, 120 KB)", tells people in a list of links that the link opens a file before they follow it; see links that open a new tab without saying so for the warnings a link gives, and scanned and untagged PDFs that screen readers can't read for the file itself.
Fix it where the text is written. These links come from editors, not templates, so a component can't fix them once. Give the editor's link tool a warning for "click here", "here", "this page" and 「こちら」, and keep link text in the publishing review. Where a list of downloads is built from data, take each link's words from the item's name.
Verify the fix
4 checks, no mouse.
Test with: Screen reader, Speech input, Keyboard
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after editors publish new help pages.
Limits
This is a starting pattern, not a guarantee for every page. Paths and class names in the snippets are placeholders. A heading above a link is weaker context than the line it sits in, and W3C lists it only as an advisory technique for 2.4.4, so a link that leans on a heading may fail Level A as well as AAA. A row of cards that each end in the same "Read more" is covered in "Read more" links that all say the same thing, and a link with no name at all in banner and image links with no name. Test the complete page with the assistive technology your visitors use.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: link-purpose-link-only (opens in a new tab)
- WCAG Technique F84 (opens in a new tab)
- WCAG Technique G91 (opens in a new tab)
- WCAG Technique C7 (opens in a new tab)
- WCAG Technique G189 (opens in a new tab)
- WCAG Understanding: link-purpose-in-context (opens in a new tab)
- webaim.org: link_text (opens in a new tab)
- smashingmagazine.com: voice-control-usability-considerations-partially-visually-hidden-link-names (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.