Google Chrome’s DevTools includes a resource for auditing general website performance and potential accessibility issues.
That resource, Lighthouse, is not perfect — no automated tool can guarantee conformance with the Web Content Accessibility Guidelines (WCAG), the international standards for digital accessibility. If you’re using Lighthouse, it’s important to understand the limitations of Chrome DevTools.
With that said, Lighthouse is easy to use, free, and accurate at diagnosing certain issues. After running an audit, you might run into a message that reads:
“Links do not have a discernible name. Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users.”
Here’s what the message means (and how to fix it).
Why Lighthouse Reports a “Links Do Not Have Discernable Name" Error
The error message indicates a potential failure of WCAG 2.1 Success Criterion (SC) 2.4.4, “Link Purpose (In Context).” This criterion simply requires the text of (or associated with) a hyperlink to describe the purpose of the link.
You’ll have to look at the element in question to determine whether the error is accurate — but if it involves a hyperlink, it probably needs to be addressed.
Here’s why discernible names are important: Not all internet users perceive content visually. Some people use screen readers (software that outputs text as audio or braille) or other types of assistive technology.
If a link doesn’t have a unique, descriptive name, these users won’t understand what happens when they activate the link. That can be frustrating, especially when the linked component is part of a process (such as a checkout process on an eCommerce website).
Fixing the “Links Do Not Have a Discernible Name" Error
Fortunately, it’s fairly easy to give your hyperlinks accessible names.
Lighthouse will identify each element that fails this check. Your first step is to double-check your HTML syntax. From there, you’ll use one of the following techniques to remediate the issue:
Simple Text Hyperlinks
For a simple text hyperlink, the text within the HTML tags should indicate the purpose with simple, descriptive language (learn why “click here" isn’t enough context for hyperlinks).
Since many screen reader users “jump” around to hyperlinks (rather than reading through every word of your content), the best practice is to determine whether people could understand the link’s purpose simply by reading the link text on its own. If possible, the link text should be similar or identical to the title of the linked page.
For more guidance, read: Quick Guide to Accessible Hyperlinks
Hyperlinked Images
If you’re using an image as a hyperlink, there may not be any on-screen text. Instead, you’ll write alternative text (also called alt text) that describes what happens when the link is activated.
Some quick tips:
- Screen readers will identify the image as a link, so you don’t need to use language like “this is a link" or “link goes to" — simply provide the same information that visual users could understand from looking at the image.
- Keep the alt text concise. Describe the image with the first words that come to mind. The description should include any text that appears in the image.
- In many cases, the text alone may be enough to describe the purpose of the link, so you don’t need to describe the rest of the image. For example, if you’ve got an image with a big, red button that reads “visit our store,” the alt text might simply read: “Visit our store.’”
For more guidance, read: 8 Common Image Alt Text Mistakes to Stop Making.
Discernible Links for Complex Content
The issue gets slightly more complicated if you’re using a complex or dynamic element.
If the element cannot be defined with native HTML, you may need to use WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications, also referred to simply as ARIA) to define the name and purpose of the link via the aria-label or aria-labelledby properties.
However, ARIA is powerful stuff: If you misuse ARIA markup, you can actually make your website less accessible for assistive technology users. Wherever possible, you should use native HTML instead — if you decide to use ARIA, test it carefully before publishing your changes.
For more guidance, read: 4 Questions to Ask Before Using ARIA
Remember, automated audits aren’t enough for WCAG conformance
Google Lighthouse can tell you whether links have names, but it can’t always determine whether those names are helpful.
For example, if you have a text hyperlink that reads “get started,” you may pass a Lighthouse audit, but you haven’t fulfilled WCAG SC 2.4.1 — your users won’t know what happens when they click the link.
Like all automated accessibility tools, Lighthouse isn’t great at handling issues that require human judgment. It can’t determine whether your ARIA markup is perfect, it may miss “Skip to Content" links, and it won’t be able to identify misleading subheadings or page titles.
You can certainly use Lighthouse for quick checks, but you’ll need to perform more thorough tests throughout development. At the Bureau of Internet Accessibility, we use a four-point hybrid testing methodology that pairs powerful automation with guidance from human experts. We believe this approach provides the best path to digital compliance.
To build an effective and sustainable digital accessibility strategy, get started with a free WCAG website accessibility analysis or download our eBook: The Ultimate Guide to Web Accessibility.
