A link is a promise about where it goes. People who can see the whole page guess
the destination from the surrounding words, the layout, and the visuals. A screen
reader user often does not have that luxury: they pull up a list of every link on the
page and read it out of context. In that list, ten links that all say “Read more” are
ten identical, useless promises. The same user can also be thrown when a link silently
swaps their tab out from under them, or when an icon-only link is announced as nothing
more than its file name.
This lesson covers the three defects behind most link failures: link text that means
nothing on its own, links that open a new window without warning, and image links with
no accessible name. Each one is fixed in the markup — the right words, a small piece of
honest text, or a real alt — and none of them needs JavaScript.
What you’ll learn
How to write link text that describes its destination so it works
out of context; how — and whether — to open a link in a new window, and how to warn
the user when you do; and how to give an image or icon link a real accessible name
through alt text so it is never announced as a bare URL.
Standards this lesson maps to
Standard
Criterion
Level
What it requires
WCAG 2.2
2.4.4 Link Purpose (In Context)
A
The purpose of each link can be determined from its text, or from the text together with its programmatic context.
WCAG 2.2
1.1.1 Non-text Content
A
An image used as a link has a text alternative that conveys the link’s purpose.
WCAG 2.2
4.1.2 Name, Role, Value
A
Every link exposes an accessible name to assistive technology, never an empty one.
WCAG 2.2
2.4.9 Link Purpose (Link Only)
AAA
The purpose of each link is clear from its link text alone, without relying on context.
WCAG 2.2
3.2.5 Change on Request
AAA
Changes of context such as opening a new window happen only on user request, or the user is warned beforehand.
WCAG 2.2
3.2.2 On Input
A
Activating a control does not cause an unexpected change of context.
EN 301 549
9.2.4.4 / 9.1.1.1 (incorporates WCAG)
—
European harmonised standard; references the WCAG A/AA set including link purpose and non-text content.
Section 508
502.3 / 504 (incorporates WCAG A & AA)
—
US federal ICT must meet WCAG 2.0 Level A and AA, including link purpose in context.
ADA Title II
WCAG 2.1 AA (DOJ rule)
AA
US state/local government web content must conform to WCAG 2.1 AA.
The three problems we’ll fix
Each card below isolates one common link defect. For every issue you get a
plain-language statement of the problem, a Bad example (shown as
escaped, non-running code so it can’t harm this page), a Good
example, the copyable Code, and an ordered fix.
Ambiguous “read more” / “click here” link text
WCAG 2.2 · 2.4.4A2.4.9AAAEN 301 549Section 508ADA Title II
Screen reader users frequently navigate by pulling up a
list of every link on the page, or by tabbing from link to link, hearing only the
link text and nothing around it. In that mode, “Read more”, “Click here”, “Learn
more”, and “Details” are indistinguishable — a list of five “Read more” links is a
list of five identical, meaningless choices. Link Purpose (In Context) is met when
the text alone, or the text plus its programmatic context (the same sentence, list
item, paragraph, table cell, or an aria-label), makes the destination
clear. The most robust fix, and the only one that satisfies 2.4.9 at AAA, is to put
the destination into the link text itself.
Bad
Out of context, every link says the same thing. A user reviewing the page’s
link list hears “Read more, Read more, Read more” and cannot tell the articles
apart.
bad-read-more.html
<h3>Annual accessibility report</h3>
<p>Our 2025 findings are in. <a href="/report-2025">Read more</a></p>
<h3>New keyboard guidance</h3>
<p>Updated focus patterns. <a href="/keyboard">Click here</a></p>
Good
The destination is in the link text itself, so each link is unique and
self-describing whether it’s read in context or in a flat link list (2.4.4 and
2.4.9).
If the design must keep a short visible “Read more”, extend its accessible name
with aria-label so assistive tech hears the full purpose while
sighted users still see the short text. Keep the visible words at the start of
the label so speech-input users can still target it (2.5.3).
aria-label-extend.html
<a href="/report-2025"
aria-label="Read more about the 2025 accessibility report">
Read more
</a>
How to fix
Write link text that names the destination or action — “Read the 2025
report”, not “Read more”.
Make sure no two links with the same text go to different places, and the
same destination uses the same text.
Where a short visible label must stay, extend its accessible name with
aria-label, keeping the visible words at the start.
Don’t link bare URLs or “here”; link the meaningful phrase instead.
Test by listing all links with a screen reader (e.g. the rotor or links
list) and check each one stands on its own.
Link opens a new tab or window with no warning
WCAG 2.2 · 3.2.5AAA3.2.2AEN 301 549
Opening a link in a new tab is a change of context. A
sighted mouse user usually notices a fresh tab, but a screen reader or screen
magnifier user may not: their Back button suddenly does nothing, because they’re now
in a new window with no history. WCAG addresses this under 3.2.5 Change on Request
(AAA), which asks that new windows open only on request or with a prior warning.
Even though the strict requirement is AAA, the established courtesy practice — and
the safer default — is to avoid forcing new windows at all, and to warn the user
whenever you do. The warning must reach assistive tech, so a bare
target="_blank" with only a visual icon is not enough.
Bad
The link forces a new tab and gives no hint at all. The user activates it,
loses their Back button, and has no idea why.
bad-new-window.html
<a href="/terms.pdf" target="_blank">Terms of service</a>
<!-- Visual-only icon: not exposed to assistive tech -->
<a href="https://example.org" target="_blank">
Partner site <span class="icon-external"></span>
</a>
Good
The warning is part of the link’s accessible name — in visible text, so every
user sees it. Adding rel="noopener" on external
target="_blank" links also closes a security gap.
good-new-window.html
<a href="/terms.pdf" target="_blank" rel="noopener">
Terms of service (opens in a new tab)
</a>
Code
If the “opens in a new tab” phrase can’t be shown for every link, expose it to
assistive tech with a visually hidden span (still announced) and keep the icon
decorative with aria-hidden="true". Best of all, reconsider whether
the new window is needed — leaving links in the same tab avoids the issue.
new-window-hidden-text.html
<a href="https://example.org" target="_blank" rel="noopener">
Partner site
<span class="visually-hidden"> (opens in a new tab)</span>
<svg class="icon-external" aria-hidden="true" focusable="false">...</svg>
</a>
How to fix
Default to opening links in the same tab; let users choose a new tab
themselves with their browser.
When a new window is genuinely needed, warn the user as part of the link’s
accessible name — “(opens in a new tab)” in visible or visually hidden text.
Mark any external-link icon decorative with aria-hidden="true";
never rely on it as the only warning.
Add rel="noopener" (or noopener noreferrer) to
external target="_blank" links to close the security gap.
Use the same warning wording consistently so users learn to recognise it.
When the only thing inside an <a> is
an image, that image’s text alternative is the link’s accessible name. If
the image has no alt attribute, the link has no name: many screen
readers fall back to reading the file path, announcing something like “link, slash
assets slash logo dot png”. If the alt is empty
(alt=""), the link is announced as nothing at all — an empty link the
user can land on but can’t understand. This breaks 1.1.1 (no text alternative),
2.4.4 (no determinable link purpose), and 4.1.2 (no accessible name). The
alt must describe where the link goes, not what the picture looks
like.
Bad
The first link has no alt at all, so the file name is read; the
second has an empty alt, so the link is announced with no name and
is effectively invisible in meaning.
bad-image-link.html
<!-- No alt: screen reader reads the file path -->
<a href="/"><img src="/assets/logo.png"></a>
<!-- Empty alt on the only content: an empty link -->
<a href="/cart"><img src="/assets/cart.svg" alt=""></a>
Good
The alt names the destination, so the image link has a clear
accessible name — “Link, EqualWeb Academy home” and “Link, View cart” (1.1.1,
2.4.4, 4.1.2).
If a link holds both an image and text, the text already names the link, so the
image should have alt="" to avoid a doubled announcement. For an
inline SVG icon used as the only content, give the link itself an
aria-label and hide the SVG.
image-plus-text.html
<!-- Text names the link; decorative image is silenced -->
<a href="/cart">
<img src="/assets/cart.svg" alt=""> View cart
</a>
<!-- Icon-only link: name the link, hide the SVG -->
<a href="/search" aria-label="Search">
<svg aria-hidden="true" focusable="false">...</svg>
</a>
How to fix
Give every image that is the sole content of a link an alt that
states the link’s destination, not the picture’s appearance.
Never leave an image link with a missing or empty alt — that
produces a file name or an empty link.
When the link also contains real text, set the image to alt=""
so it isn’t announced twice.
For an icon-only link built from inline SVG, label the
<a> with aria-label and add
aria-hidden="true" to the SVG.
Confirm in the accessibility tree that the link has a non-empty name, e.g.
“View cart, link”.
Recap
Write link text that describes the destination so it makes sense out of context —
never “read more” or “click here” on their own (2.4.4, and 2.4.9 at AAA).
Prefer to leave links in the same tab. If a link must open a new window, say so in
the link text or with a visible, announced note so the change isn’t a surprise (3.2.5
at AAA; good practice everywhere).
Give every image or icon link a real accessible name through alt that
states where it goes — never an empty link or a bare file name (1.1.1, 2.4.4, 4.1.2).
The same fixes satisfy WCAG, EN 301 549, Section 508, and ADA
Title II at once — name every link by its destination and you meet them all.