How to fix: empty links and image-only links

What it looks like in the wild

Screen reader announces "link" with no destination context.

The screen-reader user, keyboard user, or low-vision user encountering this issue does not get an error message. The page just stops working for them. Which is why this kind of bug rarely shows up in your error tracker; it shows up in support tickets, lawsuits, and abandoned conversions.

Why it fails WCAG

Every link needs text content or an aria-label describing its purpose.

The wrong pattern (avoid)

<a href="/cart"><img src="/cart.svg"></a>

The right pattern (copy this)

<a href="/cart" aria-label="View cart with 3 items">
  <img src="/cart.svg" alt="">
</a>

Notes from real audits

• The aria-label completely overrides visible text — make sure the label is complete and descriptive.

• Dynamic labels (e.g. "View cart with 3 items") must update when the count changes — use JavaScript to keep aria-label in sync.

• If a link wraps both an image and visible text, the visible text alone may be sufficient without aria-label.

• Voice control users say the visible text, so aria-label must start with or contain the visible label per WCAG 2.5.3.

How to verify the fix

Shipping the change is not the same as passing 2.4.4 and 4.1.2. Re-run these checks against the page you edited before you close the ticket.

• List all links with a screen reader; each should make sense in isolation.

• Inspect components with the browser accessibility tree (Chrome DevTools → Accessibility).

What 2.4.4 and 4.1.2 require

2.4.4 Link Purpose (In Context) (Level A, Operable): The purpose of every link must be clear from its link text, or from its text combined with the surrounding context. Screen readers can list every link on a page. "Click here", "Read more", and "Learn more" become identical entries with no distinguishing information.

4.1.2 Name, Role, Value (Level A, Robust): For every UI component, the name, role, and state (and any value where applicable) must be programmatically determinable. A custom toggle that looks like a switch but is built from <div>s is invisible to assistive tech. WCAG 4.1.2 is the bridge between custom UI and the accessibility tree.

• "Click here" / "Read more" without context

  2.4.4

• Icon-only links without aria-label

  2.4.4

• Different links sharing the same text but different destinations

  2.4.4

• <div role="button"> without aria-label

  4.1.2

• Toggle state not reflected in aria-pressed

  4.1.2

• Custom dropdown without combobox role

  4.1.2

Priority: Serious

This is one of the findings that shows up in demand letters, because the barrier it creates is total rather than inconvenient: the affected user cannot complete the task at all. Treat it as a release blocker, not a backlog item.

Because the cause is almost always a shared component rather than a single page, fix it where the component is defined and re-scan the whole site. Record 2.4.4, 4.1.2 on the ticket verbatim: that string is what an auditor, a procurement questionnaire or a regulator will search for.