Links and Descriptive Link Text

Table of Contents

Overview

Screen reader users frequently navigate web pages, using the TAB key on the keyboard, through actionable items such as links, buttons and form controls. 

Assistive technology can provide users with a list of links on a webpage and they can navigate from this list.

In these cases the links are taken out of context from the surrounding text but should still provide the user with enough information.

The button/link text alone should convey the function and purpose of the link.

Make sure that all links are provided at the point in the content at which they’re useful without visibibly displaying the URL or “here”.

Combining adjacent image and text links for the same resource.

General Guidelines

Best practice is to provide descriptive, actionable link text or button labels by default.

Avoid the use of single word links (“Here”, “More”, “Go”).   Links should be clear, descriptive and able to stand on their own.  

Good and Bad Link Text Examples:

• Good example: View all upcoming meetings

• Bad example: View more

• Good example: Start the process to apply for a marriage license.

• Bad example: Click here to apply for a marriage license.

However, in situations when this is not possible the following techniques must be used in order to provide descriptive link text for screen reader users.

You can use the “aria-label” or “aria-labelledby” attribute to provide screen reader users with descriptive link text.

When using aria attributes for descriptive link text make sure that they are also accessible to speech to input users.

Use of aria-label

The aria-label will completely override the default link text/button label.

The aria-label is not visible to a sighted user.

The aria-label will be announced by the screen reader instead of the default link text/button label.

Example:

Open

<h1 class="sfgov-campaign-title">State of the City Address</h1>

<p>Mayor London N. Breed delivered the State of the City Address to set forth her top priorities for 2024.</p>
<p><a href="" class="btn" aria-label="Learn more about the mayor's state of the city address">Learn more</a></p>

In the above example the screen reader will announce the Learn more link as “Learn more about the mayor’s state of the city address”.

Use of aria-labelledby

You can also use the aria-labelledby attribute to associate the non-descriptive link text/button label ("Learn more..." "More..." "See more", etc) with the preceding heading.

The aria-labelledby attribute is not visible to a sighted user.

The aria-labelledby attribute will be announced by the screen reader instead of the default link text/button label.

The aria-labelledby attribute will automatically append the preceding heading to the default link text/button label.

Example:

Open

<h1 id="title" class="sfgov-campaign-title">State of the City Address</h1>

<p>Mayor London N. Breed delivered the State of the City Address to set forth her top priorities for 2024.</p>
<p><a href="" id="linktext" class="btn" aria-labelledby="linktext title">Learn more</a></p>

In this example the screen reader will announce the Learn more link as “Learn more state of the city address”.

Speech to Input Users and ARIA Label Attributes

About Speech to Input Users

Speech to input users may be unable to type and use speech recognition software to interact with online content.

Speech input software allows users to interact with devices using voice commands. They can covert speech into text or execute a wide range of tasks via vocal instructions.

How the Use of ARIA Label Attributes Impact Speech to Input Users

A speech to input user can activate links on a web page by instructing the software to click on links and buttons that the user sees on screen.

From a speech to input user perspective best practice would be to include the default link text at the beginning of the aria-label.

If a speech to input user want's to activate a button that says "Learn more" and an aria-label has been provided, the speech recognition software is going to respond to the aria-label (not the default link text).

However, if the aria-label does not include the default link text (Learn more), for example aria-label="State of the City Address", the speech recognition software will not recognize the users command.

The speech to input user will not know what the aria-label is as it is not visible to them.

The speech to input user is going to instruct the speech to input software to click on the “Learn more” link or button, as this is what is visible on screen.

However if the aria-label includes the default link text, aria-label="Learn more about the mayor's state of the city address", the speech input software will recognize the users command and activate that link.

Please see more detailed information on how to comply with this guideline.

What Elements Can Be Used With aria-label?

• interactive elements: such as a (when href attribute is present),audio and video (when controls attribute is present), input, select, button, textarea.

• implicit landmark elements: such as header, footer, nav, main, aside,section, and form.

• explicit landmark elements: such as an element with role="navigation".

• widget role elements: such as an element with role="dialog" or role="tooltip"(there are 27 widget roles in ARIA 1.1).

• iframe and img elements.

If you use aria-label, aria-labelledby, or aria-describedby with any other elements (like div, span, p, blockquote, or strong etc.), they generally won’t work across all browser/assistive technology combinations.

For more information on this, and on using ARIA with HTML in general, refer to the W3C Note on Using ARIA

The Link Text Label Should Not Visibly Display the URL

Provide links at the point in the content at which they're useful without visibly displaying the URL.

Best practice is to provide human-readable and screen-reader friendly link text.

It's faster and easier for screen readers to announce the human-readable link text rather than the URL (one character at a time). 

It's also easier for sighted users to read the social media label. 

Good Example:

Please visit the Help Desk on the second floor of the Permit Center. Drop in or schedule an appointment.

Bad Example:

Please visit the Help Desk on the second floor of the Permit Center. Drop in or click here https://kiosk.na5.qless.com/kiosk/app/home/513 to schedule an appointment.

Email Links

Emails embedded in hyperlinks can be inaccessible because they often launch a user’s preloaded email client, which may not be what they use, instead of allowing them to copy and paste. It also may not be obvious what someone’s email is when a user is looking for it. 

It is better to use the full email address as the link text itself. This allows users to see exactly what the email address is and copy and paste it into the email service of their choice. Instead of concealing the email address behind readable text such as “email us.”

Use the full email address as link text rather than embedding it in other link text. Examples:

Accessible: christina.lutz-hatfield@sfgov.org or christina.lutz-hatfield@sfgov.org

Not accessible: Email Christina

Combining Adjacent Image and Text Links for the Same Resource

Provide both text and iconic representations of links without making the web page more confusing or difficult for keyboard users or assistive technology users. Since different users finding text and icons more usable, providing both can improve the accessibility of the link.

Many links have both a text and iconic representation adjacent to each other, but rendered in separate a elements. Visually they appear to be a single link, but many users encounter them as adjacent identical links. For a keyboard user, it is tedious to navigate through redundant links. For users of assistive technologies, it can be confusing to encounter successive identical links. When the text alternative for the icon is a duplicate of the link text, it is repetitive as screen readers read the description twice.

This technique provides such links by putting the text and image together in one a element and providing null alternative text on the image to eliminate duplication of text. In this way, both representations of the link are provided, but keyboard users only encounter one link and assistive technology that provides users with link lists for a web page do not include duplicate links.

Sometimes the text and the icon link are rendered in separate, adjacent table cells to facilitate page layout. Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If CSS is used, this technique can be applied to combine the links.

Example 1
The icon and text are contained in the same a element.

<a href="products.html">
<img src="icon.gif" alt="">
Products page
</a>

Example 2
A link contains an icon and text, and the site help refers to the icon. The img has a text alternative which is the name used for the icon in the site help, which describes clicking the home page icon.

<a href="home.html">
<img src="house.gif" alt="home page icon">
Go to the home page
</a>

WCAG Related Guidelines

2.4.4 Link Purpose - In Context (Level A)

1.3.1 Info and Relationships (Level A)