# Links like "click here" that need the words around them Source: https://easeweb.dev/learn/link-text-alone Topics: Buttons and links > Links say where they go even when read on their own (WCAG 2.4.9) The fix: Put the words that say where a link goes inside the link. Either write the item's name into the visible link text, "Enamel mug care guide" in place of "click here", or keep short visible words and add the item's name after them inside the link as visually hidden text. Test with: screen reader, speech input, keyboard References: https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-link-only.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F84 https://www.w3.org/WAI/WCAG22/Techniques/general/G91 https://www.w3.org/WAI/WCAG22/Techniques/css/C7 https://www.w3.org/WAI/WCAG22/Techniques/general/G189 https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html https://webaim.org/techniques/hypertext/link_text https://www.smashingmagazine.com/2022/06/voice-control-usability-considerations-partially-visually-hidden-link-names/ 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. ## What happens 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. ## Why it fails 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. ## Who is affected 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". ## What automation and AI miss 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](/learn/label-in-name) instead. ## Before: click here on every line ```html

Care guides

``` ```css .guides li { padding-block: 0.75rem; border-top: 1px solid #e3ded5; } ``` - 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. ## Before: the same Care guide on every line ```html

Care guides

``` ```css .guides li { padding-block: 0.75rem; border-top: 1px solid #e3ded5; } ``` The link now says what it opens, a care guide, but not which one: - The mug is still only in the words before the link. - Three links with the same text open three different files. ## After: the guide's name as the link ```html

Care guides

``` ```css .guides li { padding-block: 0.75rem; border-top: 1px solid #e3ded5; } ``` 1. 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. 2. 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. ## After: hidden words after Care guide ```html

Care guides

``` ```css .guides li { padding-block: 0.75rem; border-top: 1px solid #e3ded5; } .visually-hidden { position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; } ``` 1. Replace "click here" with "Care guide", the short words the design wants on every line. 2. Add the mug's name after them, inside the link, in a `span`: " for enamel mugs". The link's name is now "Care guide for enamel mugs", and it starts with the words on screen. 3. Hide the `span` from view with the `visually-hidden` class, so each line looks exactly as before. This fixes both Befores for screen readers. It passes 2.4.9 (technique C7, which is W3C's own example: format links after each book's title, with the title hidden inside each link), and, because the name starts with the words on screen, 2.5.3 too. It is not enough on its own: the words people see still read "Care guide" three times, so anyone who skims the links, or sees only the link under a magnifier, gets nothing more than before. ## Which option to use 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. ## Implementation decisions **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](/learn/label-in-name) 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](/learn/new-tab-links) for the warnings a link gives, and [scanned and untagged PDFs that screen readers can't read](/learn/accessible-pdfs) 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 1. Open the screen reader's list of links (the rotor in VoiceOver, Insert + F7 in NVDA and JAWS). Each link must say which guide it opens, without the line around it. 2. Run axe with `identical-links-same-purpose` switched on, or the audit, and check that no two links share a name while going to different addresses. 3. Inspect each link in the browser's accessibility tree, and check that its name contains the words it shows and starts with them. 4. With voice control, say "click" and the words shown on a link, and check it follows that link, or that numbers appear to choose between the links that share the words and choosing one follows it. 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](/learn/read-more), and a link with no name at all in [banner and image links with no name](/learn/empty-links). Test the complete page with the assistive technology your visitors use. --- Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)