Aug 28, 2026 
Author: Level Access
The most accessible links use descriptive link text that tells users where the link goes, without relying on the context of surrounding content. To avoid introducing barriers, teams should also mark links with more than color and indicate keyboard focus. If the accessible name of a link needs to be different from the on-screen link text, it’s important that this accessible name contains the words in the visible link text.
Links guide users from one destination to the next, but only when the link text tells them where they’re going. As the Web Content Accessibility Guidelines (WCAG) put it, the intent is to help users understand the purpose of each link so they can decide whether to follow it. In a seamless user journey, hyperlink text functions as a digital signpost, clearly indicating what lies ahead and helping users navigate with confidence.
In contrast, poorly written link text derails a digital experience, leaving users puzzled and unsure where to turn next. It’s also inaccessible to people who use assistive technologies, making it difficult, if not impossible, for many individuals to find the information they’re seeking.
In this post, we’ll explore the benefits of creating accessible hyperlink text for both website owners and users, and provide practical tips for writing it effectively.
Key insights
- Descriptive link text conveys a link’s destination on its own, without depending on the words around it. Vague phrases like “click here” and “read more” give users no information about where a link leads.
- Accessible links benefit a wide range of users, including people with cognitive disabilities, keyboard users, and people who use assistive technologies like speech recognition and screen readers.
- Several WCAG 2.2 success criteria apply to links, covering link purpose, color and contrast, focus, accessible naming, and target size.
- Color alone cannot distinguish a link from surrounding text. Underlining satisfies WCAG Success Criterion 1.4.1 Use of Color; removing it could introduce a conditional contrast requirement.
What is descriptive link text?
Link text, also known as a hyperlink or anchor link, is a clickable element on a web page that redirects users to another page, resource, or section of the same page. Ideally, the text references relevant information about the topic being discussed on the page it leads to. Descriptive link text conveys where a link goes without relying on the words around it.
Why is accessible hyperlink text important?
Using clear and relevant link text is crucial to maintaining the accessibility of your website and meeting web accessibility standards.
Specifically, meaningful link text aligns with the Web Content Accessibility Guidelines (WCAG) Success Criterion 2.4.4: Link Purpose. This criterion is aimed at helping users understand the objectives of links, so they can make informed decisions about what to follow.
Additionally, adopting accessible link text can contribute to improved search engine optimization (SEO) for your site, because it communicates the context of a link to search engines. Search engines can use relevant anchor text to index and rank your web page, increasing potential site traffic.
Who benefits from accessible links?
Links that convey their purpose or function are easier for users to understand and navigate. They can be especially important for people with cognitive disabilities who may need additional context to help them understand what action to take.
Additionally, some people with disabilities interact with digital content using a keyboard and screen reader. These users need to be able to quickly understand a link’s purpose when they jump from one link to the next using the keyboard. The screen reader will announce the text of the link, and users may not understand the context if the link text is not clear.
Accessible link text is also vital for users of speech recognition software, who activate a link by speaking the words the page shows. If multiple links have the same generic text (for example, “click read more”), or link text does not match a link’s accessible name, navigation may be more difficult.
Of course, accessible links aren’t just helpful for people with disabilities; well-written link text ultimately enhances the user experience for everyone.
Best practices for writing accessible hyperlink text
To be accessible, hyperlink text should explain the information that a user will receive by clicking on a given link. Imagine that there’s no surrounding text and ask yourself if the meaning of the link text is still clear. That test is stricter than Level AA requires, but it’s the more reliable habit: Screen reader users often navigate by pulling up a list of every link on a page, which strips away the surrounding context that Level A permits you to rely on.
- Clearly communicate the purpose of a link as well as its destination. Do not use vague link phrases such as “click here,” “here,” “more,” “read more,” or “info.” This overly general language has no stand-alone value and provides no concrete information about where users who click through a link will end up.
- Don’t use words like “link to.” Screen readers indicate the role “link” when reading links or displaying in braille, and users of this technology don’t need to hear “link to more information.” This redundancy may cause unnecessary confusion or frustration.
- Don’t include verbs in link text. For example, write “Learn more about the Level Access Platform,” instead of hyperlinking the entire phrase, “Learn more about the Level Access Platform.” After all, the focus here isn’t on the action of reading; it’s on information about the Level Access Platform.
- Avoid using a URL as link text. A URL, consisting of its protocol, domain, and path, conveys little meaning to users. For example, instead of using “visit our website at https://www.levelaccess.com/,” as link text, use “visit our website” as the link text.
- Differentiate links with more than color. Underline in-text links, and reserve underlines for links only, because underlining a word that is not a link can be misleading.
Accessible link text examples
Link text works when it still makes sense out of context. Each row in the following table pairs a common example of inaccessible link text with a stronger version and the reason for the change.
| Instead of this | Write this | The reason |
| Click here | 2026 State of Digital Accessibility Report | Names the destination, so the text stands alone. |
| Read more | Accessible navigation menus guide | Distinct text separates one entry in a link list. |
| https://www.levelaccess.com/contact/ | Contact our team | A URL read character by character conveys little information. |
| Link to our pricing page | Pricing | Assistive technology already announces the element as a link. |
| Download | Annual report 2026 (PDF, 2 MB) | Format and size set expectations before the download. |
| More info (repeated twice, driving to two destinations) | Shipping policy and Returns policy | Identical text with different destinations forces a guess. |
| Here | WCAG 2.2 Level AA requirements | Generic links don’t give enough information about what loads next. |
| Icon link with no accessible name | Icon accompanies by the accessible name “Level Access on LinkedIn” | Icon links need an accessible name that states the destination. |
What WCAG requires for links
Link accessibility requirements span several WCAG 2.2 success criteria rather than one. Here are the most relevant criteria, with the conformance level for each.
| Success criterion | Level | What it means for links |
| 2.4.4 Link Purpose (In Context) | A | Purpose is clear from the text or its context (sentence, list item, paragraph, or table cell. |
| 2.4.9 Link Purpose (Link Only) | AAA | The link text alone conveys the purpose (out of context) |
| 1.4.1 Use of Color | A | Color alone cannot distinguish text as a link from other text |
| 1.4.3 Contrast (Minimum) | AA | 4.5:1 color contrast ratio for link text against its background |
| 1.4.11 Non-text Contrast | AA | 3:1 color contrast ratio for focus indicators and non-text cues |
| 2.4.7 Focus Visible | AA | Keyboard focus is indicated on every control including links |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers cannot fully hide a focused link |
| 2.4.13 Focus Appearance | AAA | A size and contrast floor for focus indicators |
| 2.5.3 Label in Name | A | The accessible name contains the displayed text |
| 2.5.8 Target Size (Minimum) | AA | 24 by 24 CSS pixels, with an in-text exception |
| 2.5.5 Target Size | AAA | 44 by 44 CSS pixels, unless an equivalent link, inline text, user agent control, or essential presentation applies |
| 3.2.5 Change on Request | AAA | Covers links that open a new window |
Two of these, in particular, can catch teams off guard. Criterion 2.5.8 exempts links inside a sentence, but it still applies to standalone, navigation, and icon links. Criterion 2.5.3 is important to keep in mind when using ARIA (Accessible Rich Internet Applications) to provide an accessible name beyond what is in the link text.
Visual design of accessible links
Link text has to be distinguishable from the words around it before anyone interacts with it. An underline is the most dependable way to do that, and it satisfies the WCAG Success Criterion 1.4.1 Use of Color on its own.
Drop the underline and color becomes the only marker, which brings W3C technique G183—a best practice recommended by the World Wide Web Consortium (W3)—into play: The link needs at least 3:1 contrast with the surrounding text, plus a non-color cue on hover and focus. This guidance is conditional; it does not apply to underlined links. A cue supplied only on hover or focus fails WCAG Success Criterion 1.4.1 by itself.
Link text still needs 4.5:1 contrast against its background, focus indicators need 3:1 contrast, and a sticky header must not cover a focused link. Our color contrast checker tests these ratios.
What role does ARIA play in accessible links?
When it comes to link functionality, the code behind the link text is just as important as the text used to describe the link. This is where ARIA comes in.
ARIA gives you two attributes for naming a link. The aria-label attribute supplies a name as a string written into the code. The aria-labelledby attribute builds the name from text already on the page, referencing it by element ID. Reach for aria-labelledby first, and note that if a link carries both, aria-labelledby wins and the aria-label is ignored entirely.
However, simply providing an accessible name isn’t enough to make a link accessible. Here are some ways to get it right:
- Use aria-labelledby when the text already exists on the page. It takes a list of element IDs and combines their text in the order you list them, so the name is assembled from content users already have in front of them. List the link’s own ID first to keep its text at the front of the name:<h3 id=”sodar”>2026 State of Digital Accessibility Report</h3>
<a id=”sodar-link” href=”/report/” aria-labelledby=”sodar-link sodar”>Read the report</a>The accessible name becomes “Read the report 2026 State of Digital Accessibility Report.” Because it’s built from on-page text, the name stays in sync when the copy changes and gets translated along with the page. - Use aria-label when no suitable text exists on the page. This is most often the case with icon-only links. Apply aria-label as an attribute within the HTML tag, don’t overuse it, and prioritize semantic HTML elements whenever possible. For example, <a aria-label=”…”>.
- Keep accessible names clear and concise. Avoid long label text that could distract from the purpose of a link.
- Keep the words on the page inside the accessible name. WCAG Success Criterion 2.5.3 Label in Name, Level A, requires the accessible name to contain the text the link displays. An aria-label of “Level Access pricing” on a link reading “Pricing” passes. Changing it to “Costs” fails, and may create barriers for users, including those who rely on speech recognition. The same applies to aria-labelledby: If you omit the link’s own ID, the name replaces the link text rather than extending it.
When an image is the link, the alt text becomes the link text, so describe the destination rather than the artwork: alt=”Level Access on LinkedIn”, not alt=”LinkedIn logo”. If the image sits inside a link that already has text, leave the alt empty but keep the alt attribute there to convey it is empty on purpose.
Get expert support with accessible links
Creating accessible links have a wide-reaching impact. Chances are, every page of your site has links, and every user relies on them. The practices above make your content clearer for everyone who navigates it.
Level Access Academy offers role-specific training that goes deeper, including Buttons and Links for User Experience Designers and Formatting and Other Considerations for Content Designers.
Of course, link text accessibility is just one aspect of a digital accessibility practice. The Level Access solution combines platform automation, AI, and expert services to streamline digital content accessibility across your organization.
Engage with our team today and let us support you on your digital accessibility journey.
Frequently asked questions
Why is meaningful link text important?
Meaningful link text helps all users understand the purpose of a link, but it’s essential for those using assistive technologies and those with cognitive disabilities. Screen readers can generate a list of links on a page, and if those links are vague like “Read more,” it becomes challenging to determine their destination.
What is anchor tag accessibility?
An anchor tag () defines a hyperlink, and it is accompanied by the link itself and text explaining the hyperlink (link text). Anchor tag accessibility refers to making sure tags (hyperlinks) are usable by all people, including those with disabilities. This means the link text must be clear, keyboard-navigable, accessible to screen reader users, and visually distinguishable.
What does WCAG say about link text?
The Web Content Accessibility Guidelines (WCAG) address link text at two conformance levels. Success Criterion 2.4.4 Link Purpose (In Context), Level A, requires that a link’s purpose be clear from the link text or from its programmatically determinable context, such as the sentence or list item containing it. Success Criterion 2.4.9 Link Purpose (Link Only), Level AAA, is stricter: the link text alone has to convey the purpose. So a “read more” link at the end of a descriptive paragraph can satisfy Level A while failing Level AAA.
Should links open in a new window or tab?
Keep users in the same tab by default. Success criterion 3.2.5 Change on Request, Level AAA, treats a new window as a change of context people should request rather than receive.
Should link text include the file type and size?
Yes, whenever a link goes to something other than a web page. GOV.UK content guidance recommends naming the format and size in the link text, as in “Annual report 2026 (PDF, 2 MB).” It sets expectations before a download starts.
Can two links have the same text if they go to different places?
They can pass 2.4.4 Link Purpose (In Context) when the surrounding content makes each destination clear. Users who pull up a list of links lose that context, so unique link text is the safer default.
Does the title attribute make a link accessible?
No. Browsers reveal title content on mouse hover only, so keyboard and touch users never reach it, and screen reader support is inconsistent. Fix the link text, or supply an accessible name with aria-label.
When should I use a button instead of a link?
Use a link to move to another page or another place on the page. Use a button to trigger an action, such as submitting a form or opening a dialog. The element carries that meaning, so styling one as the other misleads users.
How large does a link need to be to activate with a pointer?
WCAG Success Criterion 2.5.8 Target Size (Minimum), Level AA, states that targets for pointer input should be at least 24 by 24 CSS pixels, or carry equivalent spacing. Links inside a sentence are exempt; standalone, navigation, and icon links are not.
WCAG Success Criterion 2.5.5 Target Size, Level AAA, states that targets should be at least 44 by 44 CSS pixels unless an equivalent link, inline text, user agent control, or essential presentation applies.
