axe-core avoid-inline-spacing error: inline styles break text spacing

Not specified by the original author.

axe-core avoid-inline-spacing error: inline styles break text spacing - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. Inline styles pin text spacing, so users who need extra letter or line spacing for readability cannot apply it. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core avoid-inline-spacing error: inline styles break text spacing

Fix it step by step

Step 1

Remove inline styles that force letter-spacing, word-spacing, or line-height with hard values on text.

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

Step 2

Move the spacing to the stylesheet without !important so user stylesheets can override it.

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

Step 3

Test with increased text spacing (letter-spacing 0.12em, word-spacing 0.16em, line-height 1.5) and confirm nothing clips or overlaps.

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

Step 4

Re-run axe; the rule passes when no inline style blocks the spacing adjustments.

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

• This is a WCAG 1.4.12 check; the fix is about overridability, not about your default spacing looking nice.
• 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 avoid-inline-spacing, WCAG 1.4.12).

Variant phrasings

axe avoid-inline-spacing: inline styles block text spacing

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

Why it happens

Inline styles pin text spacing, so users who need extra letter or line spacing for readability cannot apply 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/pstAfBVH6qCrZCaQnHJPO6zg

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

Thread query: axe-core avoid-inline-spacing error: inline styles break text spacing

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. Inline styles pin text spacing, so users who need extra letter or line spacing for readability cannot apply 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 link-in-text-block error link not distinguishable without color - how to fix it

TL;DR

When a link sits inside a block of text, color alone is not enough to identify it: color-blind users and users with low vision cannot tell it apart from surrounding text. Add a persistent underline (or another non-color cue like a border or icon) to text links via CSS, for example a { text-decoration: underline; }. Keep the underline on all states, not just hover.

Design systems love the clean look of color-only links, and the pushback on underlines is predictable. The data point that settles it: links must be identifiable without color per WCAG 1.4.1, and this is one of the few color rules that automated tooling can check reliably. Offer the design team underline-offset and thickness tuning; a well-styled underline looks intentional, not dated.

The verbatim error looks like this:

axe-core 4.8+
Rule: link-in-text-block (serious)
"Links must be distinguishable without relying on color"

Element: [a href="/terms"]terms of service[/a] inside a paragraph
  Link uses color alone; no underline or other non-color indicator.

Steps

1. Reproduce with the single rule:

npx @axe-core/cli https://example.com/article --rules link-in-text-block

Expected: inline links that rely on color alone are listed.

2. Confirm the flagged links are inline within text blocks. Standalone links in navs, footers, or buttons are out of scope for this rule.
3. Add a non-color indicator in your stylesheet:

a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

If the design forbids underlines, use a persistent border-bottom or an inline icon that is present in every state.

4. Re-run the focused scan. Expected output: 0 violations for link-in-text-block.
5. Check contrast too: the link text must still meet the 4.5:1 contrast ratio against the background (the color-contrast rule), and the non-color indicator must survive forced-colors mode.
6. Check the design system's link component, not just the page. A 'subtle' or 'plain' link variant that strips the underline will fail everywhere it is used in body text. Fix the variant or restrict it to contexts outside text blocks (navs, buttons, standalone CTAs).
7. Verify in forced-colors mode (Windows High Contrast). Some underline styles vanish there; text-decoration underline generally survives, but border-bottom tricks may not. Test with the OS high-contrast theme on.

When to use

• Axe flags link-in-text-block on inline links.
• A content site styles links with color only and no underline.
• A design system ships a 'subtle link' variant that removes the underline everywhere.

When not to use

• The link has no discernible text at all (that is link-name).
• The link is a standalone nav item or button (this rule targets links inside text blocks).
• You are restyling visited/hover states only (keep the default-state indicator; that is what the rule checks).

Why it happens

About 1 in 12 men has some form of color-vision deficiency, and low-vision users may not perceive subtle color shifts at all. A link that is only 'blue text' is invisible as a link to them. The underline is the web's oldest affordance for a reason: it works without color perception. WCAG 1.4.1 (Use of Color) is the underlying criterion.

The web's default link style (blue and underlined) existed because early browsers could not rely on color alone on monochrome displays. As design matured, the underline was dropped for aesthetics while the blue remained, recreating the exact problem the underline solved. Axe added link-in-text-block as an experimental rule precisely because color-only links became the default in modern design systems.

Edge cases

• The rule is experimental in axe-core; some CI configs do not enable experimental rules. If your gate misses it, enable experimental rules or check it manually.
• Links that are already underlined on hover only still fail. The indicator must be present in the default state.
• Icons next to links count as a non-color indicator only if they are always visible, not hover-revealed.
• Email and print stylesheets sometimes strip underlines; keep the screen stylesheet compliant regardless.
• The rule ignores links that are the only content of a list item or nav, where position already identifies them as links.
• Links styled as buttons (background, border, padding) pass because the button affordance is a non-color indicator.
• Print stylesheets that underline all links are good practice; keep the screen styles compliant too.

Provenance

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

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

Thread query: axe-core link-in-text-block error link not distinguishable without color

TL;DR: When a link sits inside a block of text, color alone is not enough to identify it: color-blind users and users with low vision cannot tell it apart from surrounding text. Add a persistent underline (or another non-color cue like a border or icon) to text links via CSS, for example a { text-decoration: underline; }. Keep the underline on all states, not just hover.

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.