JS-1465 Fix S6819 false positive: SVG role="img" with accessible name

[sonar-nigel]

Relates to JS-1465

S6819 was incorrectly flagging <svg role="img"> elements that carry a proper accessible name — a <title> child, aria-label, or aria-labelledby attribute. These are valid WCAG-compliant patterns for inline SVG icons that need CSS control or animation that a native <img> cannot provide. The fix adds a tightly scoped isSemanticSvgImg() guard in the decorator that suppresses the report only when both role="img" and a non-empty accessible name are present; SVGs with role="img" but no accessible name remain true positives.

• Empty-string values for aria-label/aria-labelledby are correctly treated as missing (no suppression), matching how isDecorativeSvg already handles attribute values.
• <title> suppression requires at least one non-whitespace text child or a dynamic expression child — an empty <title> does not suppress.
• The ruling files were synced after the refinement; the net change is a reduction in reported issues on the Peach corpus.

[sonar-nigel]

Rule Profile

Field	Value
Rule	S6819 — Prefer tag over ARIA role
Severity / type	Minor / CODE_SMELL
Sonar Way	Yes
Scope	Main

A genuine violation — an SVG with role="img" but no accessible name:

<svg role="img" viewBox="0 0 24 24">
  <path d="M5 12h14"/>
</svg>
// ^ S6819: Use <img alt=...> instead of the "img" role

---

False Positive Pattern

<svg role="img"> combined with a proper accessible name is the WCAG-recommended pattern for inline SVG icons that must remain in markup to support CSS class manipulation, animation, or programmatic styling — capabilities that a native <img> element cannot provide. The upstream prefer-tag-over-role rule has no awareness of this distinction and flags all such SVGs unconditionally.

// FP 1: accessible name via <title> child
<svg role="img" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
  <title>Nx</title>
  <path d="M11.987 14.138l-3.132 4.923..." />
</svg>

// FP 2: accessible name via aria-label
<svg role="img" aria-label="GitHub" viewBox="0 0 24 24">
  <path d="..." />
</svg>

// FP 3: accessible name via aria-labelledby
<svg role="img" aria-labelledby="icon-title" viewBox="0 0 24 24">
  <title id="icon-title">Download</title>
  <path d="..." />
</svg>

---

False Negative Risk

The guard is conservative: suppression only fires when role="img" and a substantive accessible name are both present. The two main edge cases where a real issue could be masked are:

• Empty aria-label="": getLiteralPropValue is checked against '', so an explicit empty string does not suppress — the issue is still reported.
• Empty <title></title>: hasTitleChild requires at least one non-whitespace text child or a dynamic expression child (JSXExpressionContainer), so a bare <title/> or <title></title> does not suppress.

The one truly conservative choice is dynamic expressions — aria-label={someVar} or <title>{someVar}</title> suppresses because the value cannot be statically evaluated. If someVar is an empty string at runtime the issue would be silently missed, but this is an inherent limitation of static analysis and is consistent with how every other attribute guard in this decorator behaves.

---

Fix Summary

The implementation adds two pure functions to decorator.ts and wires the new guard into the existing isValidAriaPattern chain:

• isSemanticSvgImg() — early-returns false for any element that is not <svg role="img">, then checks for a non-empty aria-label, a non-empty aria-labelledby, or a <title> child with content.
• hasTitleChild() — walks node.parent.children looking for a JSXElement whose opening tag is named title and that has at least one JSXText child with non-whitespace content or any JSXExpressionContainer child.
• Test suite extended with an explicit aria-label="" invalid case to document and guard the empty-string boundary.

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[sonar-review-alpha]

Summary

This PR fixes a false positive in S6819 (prefer-tag-over-role) by recognizing inline SVG with role="img" as a valid WCAG pattern when coupled with an accessible name. The fix adds a scoped isSemanticSvgImg() guard to the decorator that suppresses the rule only when both conditions are met: the element is an SVG with role="img" AND has an accessible name from <title>, aria-label, or aria-labelledby. SVGs with role="img" but no accessible name remain correctly flagged.

What reviewers should know

Where to start: Look at isSemanticSvgImg() and hasTitleChild() functions in decorator.ts — these contain the core suppression logic. The guard is inserted at line 117 in isValidAriaPattern().

Key implementation details:

• Empty strings for aria-label/aria-labelledby are correctly treated as missing (no suppression)
• <title> suppression requires at least one non-whitespace text child or a dynamic expression — empty <title> tags don't suppress
• The check integrates cleanly with the existing isDecorativeSvg() pattern without duplicating logic

Test coverage: The unit test comprehensively covers both the decorator's suppression (valid SVGs that should not be flagged) and the upstream rule's behavior (which still raises errors on these cases, proving the decorator suppression is working). Test cases include edge cases like empty <title> and empty aria-label to ensure they don't suppress.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
92.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[sonar-review-alpha]

The fix is well-structured and the core logic is sound. One subtle behavior around getLiteralPropValue returning null for non-literal props is worth confirming before merge — see the inline comment on isSemanticSvgImg.

🗣️ Give feedback

[sonar-review-alpha]

getLiteralPropValue returns null for any non-literal prop value — dynamic expressions like aria-label={someVar}, aria-label={null}, or aria-label={undefined}. Because null !== '' is true, those cases all fall through and suppress the report.

This is intentionally more permissive than isDecorativeSvg, which uses === true || === 'true' (so a dynamic aria-hidden does not suppress). For aria-label, accepting unknowable dynamic values is a reasonable static-analysis trade-off — but aria-label={null} is a real pattern in conditional rendering (e.g. aria-label={active ? 'Close' : null}) and React silently drops the attribute at runtime, leaving the SVG with no accessible name.

Two things worth confirming:

1. Is suppressing on any dynamic aria-label/aria-labelledby intentional, or should it require a string literal (mirroring how isDecorativeSvg handles aria-hidden)?
2. If dynamic suppression is intentional, a test case documenting it (aria-label={someVar} in the valid block) would pin the behaviour and serve as an explicit notice that it differs from the decorative-SVG guard.

Suggested change

	const ariaLabelProp = getProp(attributes, 'aria-label');
	if (ariaLabelProp && getLiteralPropValue(ariaLabelProp) !== '') {
	return true;
	}
	const ariaLabelledbyProp = getProp(attributes, 'aria-labelledby');
	if (ariaLabelledbyProp && getLiteralPropValue(ariaLabelledbyProp) !== '') {
	const ariaLabelProp = getProp(attributes, 'aria-label');
	const ariaLabelValue = ariaLabelProp ? getLiteralPropValue(ariaLabelProp) : null;
	if (typeof ariaLabelValue === 'string' && ariaLabelValue !== '') {
	return true;
	}
	const ariaLabelledbyProp = getProp(attributes, 'aria-labelledby');
	const ariaLabelledbyValue = ariaLabelledbyProp ? getLiteralPropValue(ariaLabelledbyProp) : null;
	if (typeof ariaLabelledbyValue === 'string' && ariaLabelledbyValue !== '') {
	return true;
	}

• Mark as noise