Links and Buttons

Meaningful Link Text

Link text should follow these principles:

• Unique within a page – Each link should have distinctive text so users can tell them apart
• Meaningful when read out of context – A screen reader user can generate a list of links on the page; the link text alone should clearly describe where it goes
• Descriptive of destination – The link text should indicate what will happen when clicked or what content the user will reach

Screen reader users typically navigate pages using the Tab key, moving from link to link, form field to form field, and button to button. When focus lands on a link, the screen reader announces “link” and then reads the link text. Voice input users can activate links by saying “click” followed by the link text, so keeping link text short, unique, and easy to pronounce is important.

Many screen readers can generate a list of all links on a page. In that context, vague link text like “Click here” or “Read more” is meaningless and unhelpful.

Example

Avoid: “For more information about UGA Athletics, click here.”

Better: “For more information, see UGA Athletics.”

URLs as Link Text

Avoid using URLs as link text. Screen readers read them character by character, and they are difficult for voice input users to select. Long URLs like “https://www.example.com/pages/documents/accessibility/guides/pdf” are especially problematic.

Short URLs such as uga.edu can sometimes be acceptable exceptions, but descriptive text is always preferred.

Techniques

HTML: Links vs. Buttons

Links and buttons have different purposes and should be used accordingly:

• Links (<a>) – Use when the action navigates the user to a new location (a different page, section, or URL)
• Buttons (<button>) – Use when the action triggers an interaction on the current page (showing or hiding content, opening a modal, playing a video, submitting a form, etc.)

This semantic distinction matters because it sets user expectations. Screen readers announce “link” for anchors and “button” for buttons, and users interact with them differently. ARIA roles can override the default behavior:

• <button role=”link”> – A button element that behaves like a link and is announced as a link
• <a role=”button”> – A link element that behaves like a button and is announced as a button

HTML: Opening links in new tabs

In general, avoid opening links in new tabs or windows. New tabs can be disorienting, especially for people who have difficulty perceiving visual content, people using screen readers, and people with cognitive disabilities. Users should retain control over how they navigate – they can always choose to open a link in a new tab themselves.

There are limited situations where opening in a new tab may be appropriate:

• Help pages or context-sensitive information displayed alongside a form or multi-step workflow, where navigating away would cause the user to lose their progress
• Secure sites where navigating away would terminate the user’s login session

If you do open a link in a new tab, you must warn the user. WCAG requires that users of all abilities are alerted before a new window or tab opens. To do this:

• Add a visual indicator (such as an external link icon) so sighted users can see the link opens a new tab
• Add hidden screen reader text (e.g., <span class=”sr-only”>(opens in a new tab)</span>) so screen reader users hear the warning
• Alternatively, include the warning directly in the link text, such as “View the guide (opens in a new tab)”

Never open a link in a new tab without providing both a visual and a non-visual warning.

HTML: “Read More…” Links

When using abbreviated link text like “More…” or “Read More”, provide context using one of these techniques:

Technique 1: aria-label Attribute

The aria-label attribute provides a longer, descriptive label that screen readers announce instead of the visible text. This approach offers maximum flexibility:

• <a href=”post.php?post=632″ aria-label=”More on Using Meaningful Link Text”>More…</a>

Technique 2: aria-labelledby Attribute

The aria-labelledby attribute combines multiple elements to form the accessible label. This is useful when you have an article title and a “Read more” link:

• <h2 id=”article-title”>Using Meaningful Link Text</h2>
• <p>An article about best practices for link text… <a href=”article.html” aria-labelledby=”article-title”>Read more</a></p>

Technique 1 (aria-label) offers more flexibility and is often simpler to implement. Technique 2 (aria-labelledby) is a good option when custom aria-labels are not feasible and existing elements can provide context.

Word and PowerPoint

To create a hyperlink in Word or PowerPoint:

1. Select descriptive text
2. Press Ctrl+K (Windows) or Cmd+K (Mac), or right-click and select Hyperlink
3. Enter the destination URL

Always use descriptive text in the visible link. Avoid displaying raw URLs as link text.

PDF Links

If your PDF was exported from an accessible Word or PowerPoint document, links should function correctly. Always verify links in your PDF using the Accessibility Checker:

1. Open your PDF in Adobe Acrobat
2. Go to Tools > Accessibility > Full Check
3. Review any issues related to links

To manually add or edit links in a PDF:

1. Highlight the text you want to make a link
2. Right-click and select Create Link
3. Choose Go to page view or Open web page depending on your destination
4. Specify the target page or URL

eLC Links

The rich content editor in eLC supports both external URLs and internal links to course content.

Avoid: “For more information, click here.”

Good: “Review the Digital Accessibility Checkpoints.”

Citations Links

When citing sources, use the article or document title as link text rather than the raw URL:

Avoid: “https://www.example.com/articles/accessibility-guide”

Better: “Accessibility Guidelines for Web Content”

You may include an unlinked URL at the end of a citation for reference purposes.

WCAG 2.1 Success Criteria

• 2.4.4 Link Purpose (In Context) (Level 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
• 2.5.3 Label in Name (Level A) – For user interface components with labels that include text or images of text, the name contains the text that is presented visually
• 3.2.5 Change on Request (Level AAA) – Changes of context (such as opening a new window or tab) are initiated only by user request, or a mechanism is available to turn off such changes

Getting help

If you have questions or need assistance, the Digital Accessibility Services Hub (DASH) is available to support colleges, schools, and administrative units as they build sustainable accessibility practices.

• Contact DASH at [email protected] for consultations, training, or technical assistance.

Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.