# eslint-plugin-jsx-a11y anchor-is-valid error - how to fix it

## TL;DR

Use the right element for the job: anchors need a valid href for navigation, buttons for actions, and next/link style components need the rule configured to recognize them. Replace href="#" and javascript: links with buttons or real hrefs. One line of why: an anchor without a valid href is not keyboard-focusable in all browsers and confuses assistive tech about what the control does.

## The error, verbatim

```text
/app/src/components/Nav.jsx
  12:5  error  The href attribute is required for an anchor to be keyboard accessible  jsx-a11y/anchor-is-valid

```

## Fix it step by step

### Step 1: Reproduce on one file

```bash
npx eslint src/components/Nav.jsx --rule '{"jsx-a11y/anchor-is-valid": "error"}'
```

Expected: ESLint prints the anchor-is-valid error with line and column.

### Step 2: Find every bad anchor

```bash
npx eslint src --rule '{"jsx-a11y/anchor-is-valid": "error"}' | rg 'anchor-is-valid' | head -20
```

Expected: Full list of offending anchors across the codebase.

### Step 3: Decide link vs button per case

```bash
rg -n 'href=.#|href=.javascript' src --glob '*.{jsx,tsx}' | head -20
```

Expected: Shows placeholder-href anchors; those that trigger actions become buttons, those that navigate get real hrefs.

### Step 4: Fix and re-lint

```bash
npx eslint src | rg -c 'anchor-is-valid' || echo 0
```

Expected: Prints 0. Keyboard test: every former anchor is now a focusable link or button with the right role.

### Step 5: Enforce it in CI

```bash
npx eslint src --max-warnings 0 | tail -3
```

Expected: Clean output; add the lint command to CI with max-warnings 0 so the violation cannot come back.

## When to use this skill

- Your linter output names this exact jsx-a11y / a11y rule
- You want the violation fixed at author time so it never reaches axe or CI
- You are adding the rule to a shared eslint config and need the fix pattern

## When NOT to use this skill

- The failure comes from axe-core or lighthouse at runtime, not from lint
- You plan to disable the rule project-wide, this skill shows the fix, not the escape hatch

## Compatibility

eslint-plugin-jsx-a11y 6.7+ with eslint 8 or 9. Configure the components/aspects options if you use next/link or a custom Link component. Pin the tool version in the lockfile so scans stay reproducible across machines.

## Variant phrasings

### the href attribute is required for an anchor to be keyboard accessible

The default error message, same fix.

### jsx-a11y anchor-is-valid next/link

The framework variant: configure the rule with components: ['Link'] so it checks your router links.

### the rule fires in the editor too

With the eslint extension installed, the same error appears inline while typing; the fix is identical.

## Why it happens

The rule enforces that anchors are used for navigation (valid href), because an anchor without href is not in the tab order in some browsers and screen readers may not announce it as a link. Codebases full of href="#" placeholders and click-handler anchors trip it constantly. Router link components (next/link) need explicit rule config or they are ignored entirely, which hides real violations. Linter rules catch the violation at author time, which is cheaper than any runtime fix. When this rule fires across many files, fix the shared component and mention it in team onboarding so new code does not reintroduce it.

## Edge cases

- Configure aspects: ['noHref', 'invalidHref', 'preferButton'] to tune which checks run; preferButton pushes action-anchors toward button elements.
- An anchor wrapping block content is fine as long as the href is valid, the rule does not complain about that.
- If you must keep a placeholder href during development, that is what the rule is trying to stop, use a button.
- After fixing, run the whole lint suite once; a11y rules interact and one fix can surface the next violation.

## Provenance

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