# axe-core link-name error links must have discernible text - how to fix it

## TL;DR

Give every link an accessible name: visible text, an aria-label, or an aria-labelledby reference. Icon-only links and empty linked images are the usual failures. One line of why: a link with no name is announced as just link, and a page of those is unusable with a screen reader.

## The error, verbatim

```text
{
  "id": "link-name",
  "impact": "serious",
  "help": "Links must have discernible text",
  "nodes": [
    { "target": [".social-icon-link"], "failureSummary": "Fix any of the following: Element does not have text that is visible to screen readers" }
  ]
}
```

## Fix it step by step

### Step 1: Reproduce on one page

```bash
npx @axe-core/cli https://example.com --rules link-name --save axe-link.json
```

Expected: Violations array contains link-name with the nameless link selectors.

### Step 2: List the offending links

```bash
node -e "const r=require('./axe-link.json'); r.violations[0].nodes.forEach(function(n){console.log(n.target.join(' '))})"
```

Expected: Selectors like .social-icon-link pointing at each nameless link.

### Step 3: Find them in source

```bash
rg -n --glob '*.{jsx,tsx,vue,html}' 'aria-label' src/components | head -30
```

Expected: Shows labeled links for reference; the flagged ones are the icon-only links missing labels.

### Step 4: Name the links and re-scan

```bash
npx @axe-core/cli https://example.com --rules link-name
```

Expected: Exit code 0, 0 violations. Screen reader now announces the destination, for example Twitter profile, instead of just link.

### Step 5: Gate the rule in CI

```bash
npx @axe-core/cli https://example.com --exit | tail -3
```

Expected: Non-zero exit while any violation remains; add this command to CI so the fix never regresses.

## When to use this skill

- Your axe-core report lists this exact rule id under violations
- You are clearing automated WCAG 2.1 AA failures before a release or audit
- A CI a11y gate (pa11y-ci, lighthouse CI, cypress-axe) is red because of this rule

## When NOT to use this skill

- The issue only shows up in manual screen-reader testing and axe reports zero violations for the rule
- You are doing a full manual WCAG audit, this skill covers the single automated rule only
- The page is a third-party embed you cannot edit, flag it to the vendor instead

## Compatibility

axe-core 4.8+ (rule link-name, WCAG 2.4.4 / 4.1.2). Same rule in pa11y, lighthouse, and axe DevTools. Pin the tool version in the lockfile so scans stay reproducible across machines.

## Variant phrasings

### links must have discernible text axe

The help text wording, same fix.

### icon link no accessible name

The classic instance: social icon links in footers.

### axe DevTools flags the same rule

The browser extension runs the same rule engine; fix once and it clears in every runner.

## Why it happens

Icon-only links (social icons, linked logos) have no text content, and if the inner img has empty alt or the svg has no name, the computed accessible name is empty. Link text like click here passes the rule but fails WCAG 2.4.4 in spirit, axe only checks that a name exists, not that it is meaningful. Footer social icon rows are the single most common source. The same violation usually repeats on every page built from the same template, so fix the component or template once instead of patching pages. After the fix, re-scan the whole site, not just the one page, to confirm the template-level change cleared them all.

## Edge cases

- An aria-label on the link overrides everything inside, keep it accurate to the destination.
- Linked images: the img alt becomes the link name, so empty alt on a linked image fails link-name too.
- Title attributes are a weak fallback and not reliably announced, prefer aria-label or visible text.
- Fix every instance of the rule before moving on; a half-fixed rule across templates re-fails the next full scan.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_D2KlQyoY0KPVxc30J2xFIw