SONARHTML-395 Handle template-generated labels in S6853

[erwan-leforestier-sonarsource]

Summary

Handle S6853 false positives on template-generated labels by recognizing Razor and Thymeleaf patterns that only resolve at render time.

Changes

• track whether a Razor asp-for label is truly empty before trusting its generated text
• recognize Thymeleaf th:for and th:attr associations, plus template text attributes such as th:text, th:utext, v-text, and v-html
• add regression coverage for empty Razor labels and template-generated label content

Functional Validation

Artifact: SONARHTML-395-fv.zip

Once the file is attached to the PR description, unzip and run:
./run.sh

Expected output:

******************* MASTER *******************
Analyzing "razor-empty-label.cshtml"...
Results:
    - Rule "S6853" -> L.1
Analyzing "template-generated-label.html"...
Results:
    - Rule "S6853" -> L.1
    - Rule "S6853" -> L.2

****** Branch "fix/sonarhtml-395-handle-template-generated-labels" ******
Analyzing "razor-empty-label.cshtml"...
Results:
    (none)
Analyzing "template-generated-label.html"...
Results:
    (none)

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[asya-vorobeva]

It looks like corresponding RSpec description is very confusing: https://musical-adventure-r9qk65j.pages.github.io/rspec/#/rspec/S6853/html
It says that label elements should have a text label (which is obviously wrong for template-generated labels) and doesn't provide list of exceptions. Should we update it?

[erwan-leforestier-sonarsource]

Hi @asya-vorobeva thanks for the review, it's true that the rspec rule description is bad, but it was improved in this PR: https://github.com/SonarSource/rspec/pull/7179

Though there is no exception listed in the rule description because I think that either you fall into one of the exception, in which case you won't see this isuse or you have this issue raised in your code, then I don't think having a list of exceptions will help the developer to fix it. If he thinks that it's a FP because we don't handle the framework it's using, then he can reach out to us and we will investigate the FP. If for example it's just plain HTML, having a list of exceptions for specific frameworks is just noise.

Be aware that the rule description has been synced in sonar-html as part of a separate PR and it has been merged into master. See commit a8ae2d3

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Updates S6853 to correctly ignore template-generated labels in Razor and Thymeleaf, resolving false positives from incorrect fragment detection and unhandled attribute associations. No issues remain.

✅ 2 resolved

✅ Edge Case: th:attr recognized for control association but not accessible text

📄 sonar-html-plugin/src/main/java/org/sonar/plugins/html/checks/accessibility/LabelHasAssociatedControlCheck.java:98-109 📄 sonar-html-plugin/src/main/java/org/sonar/plugins/html/checks/accessibility/LabelHasAssociatedControlCheck.java:138-141
The new code recognizes Thymeleaf th:attr assignments for the for association (hasThymeleafAssignment(label, "for")), and recognizes accessible text via the dedicated attributes th:text/th:utext/v-text/v-html. However, hasAccessibleTextHint does not inspect th:attr assignments for accessible-text attributes such as aria-label/aria-labelledby/alt.

As a result a label whose accessible text is generated entirely through th:attr, e.g. <label th:attr="aria-label=#{label}, for=${id}"></label>, will still be flagged as missing accessible text (false positive): control association is detected via th:attr for, but the aria-label provided in the same th:attr bundle is not. This is the same false-positive class this PR aims to eliminate, just via the th:attr form for accessible-text attributes.

Consider extending hasAccessibleTextHint to also check hasThymeleafAssignment(node, "aria-label") / aria-labelledby / alt, mirroring the association handling. If th:attr-generated accessible text is intentionally out of scope, a code comment would help clarify the limitation.

✅ Edge Case: Razor fragment detection runs on non-Razor files in characters()

📄 sonar-html-plugin/src/main/java/org/sonar/plugins/html/checks/accessibility/LabelHasAssociatedControlCheck.java:144-148
In characters(TextNode), the new Helpers.containsRazorFragmentRendering(textNode.getCode()) call runs for every label text node regardless of file type (it is not gated by Helpers.isRazorFile(...)). On a plain .html file, label body text that happens to contain a substring like @RenderBody, @RenderSection, or @Html.Partial (e.g. an email address or escaped text) would match RAZOR_FRAGMENT_EXPRESSION and set both foundControl and foundAccessibleLabel to true, suppressing a legitimate S6853 violation.

This mirrors the pre-existing RAZOR_CONTROL_PATTERN usage on the line above, so the risk is low and contrived, but since this is a newly added call it is worth considering gating it on isRazorFile(...) (or otherwise restricting it to Razor-capable files) to avoid false negatives on non-Razor templates.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube

[asya-vorobeva]

Hi @asya-vorobeva thanks for the review, it's true that the rspec rule description is bad, but it was improved in this PR: SonarSource/rspec#7179

Though there is no exception listed in the rule description because I think that either you fall into one of the exception, in which case you won't see this isuse or you have this issue raised in your code, then I don't think having a list of exceptions will help the developer to fix it. If he thinks that it's a FP because we don't handle the framework it's using, then he can reach out to us and we will investigate the FP. If for example it's just plain HTML, having a list of exceptions for specific frameworks is just noise.

Be aware that the rule description has been synced in sonar-html as part of a separate PR and it has been merged into master. See commit a8ae2d3

If you check descriptions of other rules, you'll see that we usually provide exceptions in case they exist. I think that documentation about the rule should be full. It's not for users, it's for us developers (ordinary users even don't have an access to full RSpec descriptions).