Blog October 26, 2026 · 14 min read

Link Text Accessibility: How to Write Links Everyone Can Use

Editor revising link wording at a computer

Accessible link text tells people where a link goes or what it does, without making them read the surrounding paragraph. “Download the 2026 menu (PDF, 2 MB)” works. “Click here” does not. WCAG 2.2 Success Criterion 2.4.4 is the rule behind this, and fixing your links is one of the fastest accessibility wins on any site.

This guide covers what the rule says, how to write links that pass, how headings and plain language support them, and how to check your whole site without reading every page by hand.

AccessWiser

Find and Fix Accessibility Issues

AccessWiser scans websites against WCAG 2.2 AA criteria, identifying code-level issues and providing plain-language guidance for fixing them.

Explore AccessWiser

TL;DR

Write each link so its purpose is clear from its own text. Skip “click here,” “read more,” and bare URLs.
WCAG 2.4.4 (Level A) allows the purpose to come from the link text plus its surrounding context. The stricter 2.4.9 (Level AAA) asks for link text alone.
Use one H1, then H2 and H3 headings in order. Never choose a heading level for its size.
Write in short, plain sentences. Name file types, expand acronyms, and make links with the same destination use the same words.
Scanners find many link problems, but a person still has to judge whether the words make sense.

Why link text matters more than it looks
What WCAG actually requires
How to write descriptive link text
Common link mistakes and quick fixes
Headings: the other half of page navigation
Plain language makes both links and headings better
Is WCAG legally required for U.S. websites?
Our perspective: fix the code, keep the record
A practical workflow for auditing your links
Where AccessWiser fits
FAQ
Sources

Why link text matters more than it looks

Sighted visitors scan a page and spot links by color and underline. People using screen readers often do something different: they pull up a list of every link on the page and move through it. W3C explains that meaningful link text helps people who navigate by a list of links or by tabbing from link to link.

In that list, the surrounding sentence is gone. If your page has six links that all say “Read more,” the user hears “Read more, Read more, Read more” and has no way to tell them apart. Section508.gov makes the same point: link text should be understandable when isolated, because many screen-reader users move through a page by reviewing links.

The benefit reaches beyond screen readers:

Keyboard users tabbing through a page hear or see each link in sequence.
People with cognitive disabilities get a clear promise about what happens next.
Voice-control users can say the visible link name to activate it.
Everyone on a phone, tapping with one thumb, benefits from a link that says what it does.

Clear link text is also good writing for search. Descriptive words give people and crawlers a better idea of the destination.

What WCAG actually requires

Two success criteria cover link purpose, and they are easy to mix up.

Criterion	Level	What it asks
2.4.4 Link Purpose (In Context)	A	The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined context. Exception: where the purpose would be ambiguous to users in general.
2.4.9 Link Purpose (Link Only)	AAA	The purpose can be identified from the link text alone.

Most legal and procurement standards point to Level AA, which includes 2.4.4 but not 2.4.9. So 2.4.4 is your baseline. Writing to 2.4.9 is still the safest habit, because it is simple: make every link self-explanatory and you pass both.

What counts as “context”

Under 2.4.4, a vague link can pass if its context is built into the markup. W3C says that context can come from the same sentence, paragraph, list item, or table cell, or through an ARIA association, and that context is generally most usable when it comes before the link.

That means a table row like “Spring newsletter | PDF | Download” can technically pass, because the row cell supplies the meaning. It is still weaker than a link that explains itself. Context only helps when assistive technology exposes it, and a list of links strips it away.

How to write descriptive link text

The core rule from W3C’s G91 technique is to put the purpose in the link text, and a destination address is generally not descriptive enough. Here are the habits that follow.

1. Name the destination or the action

Section508.gov offers examples such as “Download the annual report” and “Learn more about our accessibility policy” in place of “click here,” “read more,” or bare URLs. W3C’s own H30 technique uses “Current routes at Boulders Climbing Gym” as a model.

Here is how that looks for small businesses:

Weak link	Stronger link
Click here to book	Book a table for Friday night
Read more	Read about our teeth-whitening options
Learn more	See Wi-Fi and parking details for guests
https://example.com/menu.pdf	View the dinner menu (PDF)
Here	Contact our front desk

2. Skip the filler words

Drop “link to,” “click,” and “go to.” Screen readers already announce that something is a link, so “link to our menu” is announced as “link, link to our menu.” Keep the text short, too: three to six words usually does the job.

3. Tell people about files

Digital.gov recommends action- and destination-specific text such as “Download the full report” and naming linked file types such as PDFs. W3C’s writing guidance adds that document type and size are useful target information. Someone on a metered mobile plan wants to know a file is 40 MB before tapping.

4. Make identical links match, and different links differ

Two links with the same words should go to the same place. Two links to different places should not share the same words. If your homepage has three “Learn more” links to three services, a screen-reader user cannot distinguish them. Rename each: “Learn more about teeth cleaning,” “Learn more about Invisalign.”

5. Handle image links deliberately

When an image is the only content of a link, the alternative text becomes the link text. W3C says that alt text should describe the link’s function, not the picture. A logo linking home should say “Home” or the business name, not “Blue circle logo.” If your icons are SVGs, our SVG accessibility patterns cover the naming options.

6. Do not rely on color alone

A link has to be recognizable as a link. Underlines remain the most reliable cue, and we cover when to keep them in our guide to underlined links. If you do style links without underlines, check the contrast between the link and surrounding text and between the link and its background. Our nontext contrast guide walks through the 3:1 test.

Common link mistakes and quick fixes

“Click here” and “read more” repeated down a page. Rewrite each with its subject.
Raw URLs pasted into paragraphs. Replace them with a short phrase that names the destination.
Whole sentences as links. Link only the key phrase so list navigation stays quick.
Links that open new windows with no warning. Add “(opens in a new tab)” where it helps, or avoid new windows.
Buttons that act like links, and links that act like buttons. A link goes somewhere; a button does something on the page. Use the right element so assistive technology announces the right role.
Vague card links. A product card with “Shop now” repeated 12 times needs product names in the link or an accessible name that includes them.
Skip links with unclear labels. A “skip to content” link is a link too. Our 10-minute skip link fix shows how to build one.

Links are one way screen-reader users move through a page. Headings are the other. Good heading structure and good link text work together, so it helps to fix both in one pass.

The H1 to H2 to H3 pattern

Section508.gov’s guidance for content authors is simple: use H1 for the page title, H2 for major sections, and H3 for subsections. It also says not to skip levels, not to use headings only for visual styling, and not to substitute bold text for heading elements.

In practice:

One H1 per page, matching the page’s main topic.
H2s for the main sections, such as “Services,” “Pricing,” and “Visit us.”
H3s only under the H2 they belong to.
Go back up freely. An H2 can follow an H3. A jump from H2 straight to H4 is the thing to avoid.

The related WCAG criteria are 1.3.1 and 2.4.6. Section508.gov maps 1.3.1 Info and Relationships to semantic heading structure, and identifies 2.4.6 Headings and Labels as a Level AA requirement that headings and labels describe their topic or purpose. So a heading must be both correctly marked up and meaningful. “More info” is a poor heading for the same reason it is a poor link.

Common heading mistakes in site builders

Wix, Squarespace, WordPress, Webflow, and Shopify themes make it easy to pick a heading level because it looks right. W3C notes that visual size or styling alone does not expose heading structure to assistive technology, which needs real heading markup. Watch for:

A theme that outputs the site name as an H1 on every page, leaving your page title as an H2.
Footer headings set as H4 because they look small, with no H2 or H3 above them.
Bold paragraphs that act as headings but are invisible in a headings list.
Empty headings left behind by a page builder.

A quick test: open a headings list in your screen reader or a browser extension and read only that list. If it works as an outline of the page, you are in good shape.

Plain language makes both links and headings better

Digital.gov says plain language improves accessibility because people with developmental disabilities, limited technical literacy, or limited English proficiency may struggle with content written above their comprehension level. Link text and headings are the shortest, most-read words on your page, so they matter most.

W3C’s practical checklist: use short, clear sentences and paragraphs, avoid unnecessarily complex words, expand acronyms on first use, use lists where appropriate, and consider a glossary. Digital.gov adds a few more: define unfamiliar terms, avoid idioms, and run drafts through a readability tool such as Hemingway or Readable.

For links, that means:

“Check your coverage” beats “Verify benefit eligibility parameters.”
“Request a quote” beats “Initiate a service inquiry.”
Write “Americans with Disabilities Act (ADA)” once, then “ADA.”

Plain language is not dumbing down. A dental patient on a phone at 10 p.m. wants “Book a cleaning” and nothing else.

Is WCAG legally required for U.S. websites?

The ADA does not contain WCAG technical language. For state and local governments, the picture is clearer: DOJ’s 2024 Title II rule requires web content and mobile apps to be accessible consistent with WCAG 2.1 Level AA. A 2026 interim final rule moved the compliance dates to April 26, 2027 for larger entities and April 26, 2028 for smaller ones, with the requirements themselves unchanged.

Private businesses, such as restaurants, clinics, hotels, salons, law firms, and online stores, fall under a different part of the ADA. That part has no web rule of its own, and WCAG 2.x AA is the standard most often used to measure a site in demand letters and settlements. We are not a law firm, so if you have received a demand letter, talk to an attorney who handles ADA matters. What you can do right away is fix the failures that are easy to see and easy to document, and link text is one of them.

If you sell to customers in the EU, the European Accessibility Act and EN 301 549 point to the same WCAG criteria for web content, including link purpose.

Is WCAG legally required for U.S. websites? — overview diagram

Our perspective: fix the code, keep the record

We built AccessWiser around a simple belief: accessibility improves when each problem is tied to a specific element and a specific criterion, and when the fix lives in your own code. Link text is a good example. A scan can flag a link whose text is “Click here,” or two links with identical text and different destinations. That is valuable, and automated checks detect a substantial subset of accessibility barriers.

Our perspective: fix the code, keep the record — overview diagram

But a tool cannot always know whether “Our process” is a clear name for your page. That judgment stays with a person. So we pair findings with plain-language guidance for the fix, and we do not claim automation settles the question alone. We also do not think a runtime overlay can stand in for better link text. If the HTML says “Read more,” the underlying page still says “Read more.”

The most useful habit we see is a content checklist paired with scheduled re-checks. Pages change every week: a new blog post, a seasonal menu, a promo banner. Each one can introduce a vague link. Re-checks catch that early, and dated records of scans and fixes show your effort over time.

— The AccessWiser Team

A practical workflow for auditing your links

You can do a first pass this afternoon.

List your links. Use a browser extension or screen reader to open the links list on your five most important pages: home, services, pricing or menu, contact, and your top blog post.
Read the list aloud. Would you know where each link goes? Mark every one that fails.
Search for the usual suspects. In your editor or CMS, search for “click here,” “read more,” “learn more,” “here,” and “this page.”
Fix by rewriting. Add the subject, the file type, or the action. Keep it to a few words.
Check headings. Read the headings list. Fix a skipped level or a missing H1.
Tab through the page. Make sure each link shows a visible focus indicator and the order makes sense. If forms are on the page, our form accessibility guide shows what scanners miss there.
Record what you changed. Date the fix and keep a note. If anyone asks, you can show what you did and when.

Where AccessWiser fits

Manual review is a good start, but it does not scale past a handful of pages, and it does not catch regressions. AccessWiser scans your site against WCAG 2.2 AA, with Section 508 and EN 301 549 mappings, and ties each finding to the element and criterion it affects. Every issue comes with plain-language guidance for fixing it in your own code. Scheduled re-checks flag new problems, and dated records plus an accessibility statement document your work.

Plans are published on our pricing page: Starter is $24 per month, Basic is $49 per month, and Pro is $119 per month. Business has no published price. Extra specific page scans are $12 one-off and extra full site scans are $19 one-off. Every subscription starts with a 7-day free trial, so you can scan your own site and see your link and heading findings before you commit. You can start from the AccessWiser homepage. For more developer-focused fixes, browse the AccessWiser blog.

FAQ

What are the WCAG requirements for link text?

Success Criterion 2.4.4 (Level A) requires that each link’s purpose can be worked out from its text, or from its text plus programmatically determined context. Level AAA criterion 2.4.9 goes further and asks for link text alone. Writing links that explain themselves satisfies both.

What is a good link text example?

“Download the annual report (PDF, 1.2 MB)” is a good example because it names the action, the subject, and the file type. “Book a table for Friday night” works for a restaurant. Compare these to “Click here,” which tells a screen-reader user nothing in a links list.

Should every link be underlined?

Not required by one single rule, but links inside body text should be identifiable by more than color. An underline is the most dependable way. If you remove it, you need another visible cue that meets contrast requirements.

How should I structure H1 and H2 headings?

Use one H1 for the page title and H2s for the main sections. Put H3s under the H2 they belong to, and do not skip levels. Choose levels for structure, then use CSS to adjust how they look.

Can a scanner fix my link text automatically?

A scanner can find many problems, such as empty links, generic phrases, and duplicate text with different destinations. Deciding what the better wording is still takes a person who knows the page. The fix should then go into your site’s code so it stays in place.