Links

Overview

What a link is in your document

A link is a piece of text a reader can activate to go somewhere else: a web page, an email address, or another place in the same document. On screen you see it, often underlined or in a different colour, and you click it. In the file, a link is two things working together. There is the visible text, the words the reader sees and acts on, and there is the destination the link points to.

For a link to work for everyone, the words a reader sees have to say where the link goes. "Read the full enrolment report" tells a reader what they will get if they activate it. "Click here" does not. A reader who can see the page can sometimes guess from the surrounding sentence, but a screen reader user often moves through a document by jumping from link to link, hearing each one on its own, out of the sentence around it. When every link in that list says "click here," the reader hears "click here, click here, click here" and has no way to tell them apart.

What a reader loses when a link is wrong

A screen reader user who pulls up the list of links on a page is looking for a fast way to navigate. Good link text turns that list into a table of contents. Bad link text turns it into noise.

A bare web address as the visible link text is a second common problem. A screen reader may read it out character by character, so "https://example.org/reports/2026/annual.pdf" becomes a long string of letters, slashes, and dots spoken one at a time. It is slow to listen to and tells the reader almost nothing about where they are going.

There is also a hidden layer. In the file, a link should be wrapped in a Link tag so the assistive technology knows it is a link at all, and it can carry a short description that gives an alternate name for the link. If that tag or that description is missing, a screen reader may not announce the link as a link, or may have nothing useful to say about it.

In depth

A link with clear text that names its destination

This is the case to aim for. The visible link text describes where the link goes, and it makes sense on its own, lifted out of the sentence around it.

Take a sentence that reads: "For the full figures, read the 2026 enrolment report." The words "read the 2026 enrolment report" are the link. A screen reader user who jumps to this link, or pulls it up in a list of links, hears a phrase that names the destination. They do not need the rest of the sentence to know what they will get.

The test is simple. Read the link text by itself, with nothing around it. If it still tells you where you are going, it is good link text. "Read the 2026 enrolment report" passes. "Read more" does not.

A bare web address used as the visible link text

Here the visible link text is the raw address itself, for example "https://example.org/reports/2026/annual.pdf". This looks informative to a sighted reader who can scan it, but it reads badly aloud.

A screen reader may announce it character by character: "h, t, t, p, s, colon, slash, slash" and onward through the whole address. The reader sits through a long spoken string and learns very little, because the meaning of a web address is not in how it sounds.

The fix is to keep the address as the destination, where it belongs, and put plain words on top as the visible text. Before: the link text is "https://example.org/reports/2026/annual.pdf". After: the link text is "2026 annual report", and the address sits underneath as the place the link points to. The reader hears "2026 annual report" and knows exactly what to expect.

A web address is sometimes shown on purpose, for example in a printed handout where someone may need to type it. If you must show the address as the visible text, that is a judgement call about your audience, not a rule the file can settle for you.

Vague text that means nothing on its own

Words like "click here", "read more", "this", or "link" are the most common link problem. In a full sentence they may seem to work, because the reader fills in the meaning from the words around them. Pulled out on their own, they collapse.

Imagine a page with three links, all reading "click here". A screen reader user opens the list of links and hears "click here, click here, click here". There is no way to tell which one leads to the timetable, which to the reading list, and which to the contact form. The reader has to go back into the body text and read around each link to work out where it goes, which removes the whole point of having a links list.

The fix is to move the meaning into the link text itself. Before: "To see the timetable, click here." After: "See the timetable." The destination words are now inside the link, and the link stands on its own.

A link that is not wrapped in a Link tag, or has no description

This case is about the hidden layer of the file rather than the words on screen. A link in a PDF should be a Link structure element that wraps the link annotation, the part of the file that actually carries the destination. The annotation can also hold a Contents entry, a short description that gives an alternate name for the link.

When the Link tag is missing, the visible text may still look and even behave like a link for a sighted reader, but a screen reader may not announce it as a link, so the reader does not know it can be activated. When the Contents description is missing, the assistive technology has nothing to fall back on if the visible text is unclear.

A correctly built link has three parts in place: clear visible text, a Link tag wrapping the annotation, and a Contents description on the annotation. A concrete failure: a web address is drawn on the page in blue underlined type and points to a real destination, but it sits in the file as plain content with no Link tag around it. On screen it looks like a link. To a screen reader, it is just blue text.

Where machine checking stops for links

Software can check the parts of a link that live in the file structure. It can confirm that a link is wrapped in a Link tag. It can confirm that the annotation carries a Contents description. These are present-or-absent questions, and a machine answers them reliably.

What software cannot do is judge whether the visible link text is meaningful on its own. A machine sees that link text exists and that it is not empty. It cannot tell that "click here" says nothing, or that a bare web address will read out as a string of characters, or that "read the 2026 enrolment report" is exactly right. That judgement needs a person who reads the link text on its own and asks whether it names the destination.

This is the same divide that runs through most accessibility checks. The machine confirms the plumbing is present. A person confirms the meaning is right. For more on this divide, see the topic on what automated checking can and cannot find.

Reference detail

Standards mapping

WCAG Level A is the minimum conformance level. Level AA is the level most laws and policies require, and it includes everything in Level A. For the levels and the four POUR principles, see the topic on WCAG and the four POUR principles.

How a link is built in a PDF

A tagged PDF has a visual layer and a structure tree that a screen reader follows. A link has to be correct in both: clear words in the visual layer, and a Link tag with a Contents description in the structure tree. For how the structure tree works, see the topic on PDF/UA and the Matterhorn Protocol.

Common mistakes

What to do

Use clear link text that says where the link goes, so the words make sense on their own. Wrap each link in a Link tag so assistive technology announces it as a link. Add a Contents description to the link annotation so there is an alternate name for it. A machine can confirm the Link tag and the Contents description are present, but only a person can confirm the visible text is meaningful, so read each link on its own before you sign off.

Authoritative sources