axe-core aria-text error: text node not in accessible name computation

Not specified by the original author.

axe-core aria-text error: text node not in accessible name computation - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A text-wrapper element carries role text but contributes nothing to the accessible name computation, swallowing semantics around it. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-text error: text node not in accessible name computation

Fix it step by step

Step 1

Locate the element with the text role that wraps the failing text node.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

If the wrapper exists only to style text, remove the text role and let the text stay plain content.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

If the wrapper is needed, make sure its contents produce a non-empty accessible name or move the semantics to a parent.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe; the rule clears when the text node participates in name computation again.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Do not slap an aria-label on a text wrapper just to silence the rule; the label would override the visible text.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-text, WCAG 1.3.1 / 4.1.2).

Variant phrasings

axe aria-text: text node excluded from accessible name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A text-wrapper element carries role text but contributes nothing to the accessible name computation, swallowing semantics around it. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

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

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

Thread query: axe-core aria-text error: text node not in accessible name computation

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A text-wrapper element carries role text but contributes nothing to the accessible name computation, swallowing semantics around it. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core aria-treeitem-name error: treeitem missing accessible name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A treeitem in a tree widget has no accessible name, so keyboard and screen-reader users cannot tell nodes apart. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-treeitem-name error: treeitem missing accessible name

Fix it step by step

Step 1

Give each treeitem its name from its visible text content first; that is the cleanest fix.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For icon-only tree nodes, add an aria-label that matches the node's purpose.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Check child nodes too; the rule flags every nameless treeitem, not just parents.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe and arrow through the tree with a screen reader to confirm each node announces its name.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Grouping elements like tree or group do not need names under this rule; only the treeitem leaves and parents do.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-treeitem-name, WCAG 4.1.2).

Variant phrasings

axe aria-treeitem-name: tree node has no name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A treeitem in a tree widget has no accessible name, so keyboard and screen-reader users cannot tell nodes apart. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

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

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

Thread query: axe-core aria-treeitem-name error: treeitem missing accessible name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A treeitem in a tree widget has no accessible name, so keyboard and screen-reader users cannot tell nodes apart. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

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

{
  "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

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

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

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

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

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

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

Thread query: axe-core link-name error links must have discernible text

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.