How to fix links with no discernible text

WCAG 2.4.4 Link Purpose and 4.1.2 Name, Role, Value require every link to have text that conveys where it goes. The common failures:

• Icon-only links: a social or menu link that is just an <svg> with no text.
• Image links with no alt: a logo or thumbnail wrapped in a link, where the image has empty or missing alt.
• Empty links: an <a> with no content at all.

It means the link has no accessible name: nothing a screen reader can read out to say where it goes. The link is still in the browser's accessibility tree, but its name is empty, so it gets announced as bare "link" with no destination.

You will see the same finding worded several ways. "Links must have discernible text" is axe-core's message. "Links do not have a discernible name" is the same check described in terms of the accessible name. Some tools say the link has no text alternative. All three describe one condition, and one fix.

PageSpeed Insights and Chrome DevTools report it too, because Lighthouse's accessibility category runs axe-core, so the wording is identical to what you get here. This one is a real WCAG failure, not a best-practice suggestion: axe maps it to 2.4.4 Link Purpose and 4.1.2 Name, Role, Value at Level A.

Work out the accessible name in this order, taking the first that exists: aria-labelledby, then aria-label, then the link's own text content (including the alt of an image inside it), then title. If every one is empty, the link fails.

Put the destination in the image's alt. When an image is the only thing inside a link, its alt text becomes the link's accessible name, so an empty alt="" leaves the link nameless even though the markup looks complete.

<!-- fails: nothing to announce -->
<a href="/"><img src="logo.svg" alt=""></a>

<!-- passes: alt names the destination -->
<a href="/"><img src="logo.svg" alt="Home"></a>

Describe where the link goes, not what the picture shows. A logo linking home is "Home", not "Company logo". If the same image also appears outside a link elsewhere, the two alts can legitimately differ.

Alt on a linked image is not optional the way it is for decorative images. alt="" is correct for decoration precisely because it removes the image from the accessibility tree, which is the opposite of what a link needs.

Give the link an accessible name. For an icon-only link, add aria-label:

<a href="/cart" aria-label="View cart">
  <svg aria-hidden="true">...</svg>
</a>

Mark the decorative icon aria-hidden="true" so it is not announced separately. For an image link, describe the destination in the image's alt:

<a href="/"><img src="logo.svg" alt="Home"></a>

If a link has visible text, prefer that over an aria-label. Avoid vague text like "click here" or "read more" on its own, since those fail 2.4.4 in context.

An Elementor Icon widget with a link, or a linked icon inside another widget, outputs an <a> around an icon and nothing else, so it fails this check unless you name it. Elementor's custom link attributes add attributes to the link's own <a> element, in key|value form: aria-label|View cart.

Use that field, not the Custom Attributes box on a widget's Advanced tab. Those land on the widget's wrapper, and an aria-label there does not reach the link, so the scan still reports it. Re-scan after the change to confirm the name shows up on the link itself.

Nameless links cluster in the header and footer: the logo, social icons, a cart icon. Those sit on every page, so fixing the template clears the finding site-wide. The scan above lists each link with no accessible name and the element it found. Fix the markup and scan again. To stop new ones shipping, the CLI and GitHub Action can fail a build on this rule.