Typescript RSPEC-6819 should not always require HTML's output element instead of ARIA status role

The Typescript rule RSPEC-6819: Prefer tag over ARIA role is applied a bit too broadly.

This can be observed both with SonarLint in VSCodium and with SonarQube.

Snippet to reproduce the issue

<form>
  <p><label for="textarea-1">First text area</label><br />
    <textarea id="textarea-1" maxlength="100" aria-describedby="textarea-1-charsleft"></textarea><br />
    <span id="textarea-1-charsleft" aria-live="polite" role="status">
      <span id="charcount-1"></span> characters left
    </span>
  </p>
  <p><button type="submit">Submit</button></p>
</form>

In this snippet, the Sonar issue goes away if I remove the attribute role=status. With the attribute, Sonar says,

Use output instead of the status role to ensure accessibility across all devices.

The error message is based on two things:

  • The first rule of ARIA use, which says,

    If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

  • The documentation about implied WAI-ARAI semantics for HTML elements in ARIA in HTML, which says that the output-element implicitly has role=status.

However, it does not follow from the above that every element with role=status must be replaced with HTML’s output element. The mapping table works in the direction HTML → WAI-ARIA, but the opposite direction cannot be assumed in all cases.

More specifically, not every element with role=status represents an intended output of a user action or the result of a calculation performed by an application. For example, the output element should be used to represent the result of a calculation in a web-based calculator; this result is what the user wanted from the application. But the number of remaining characters in a textarea is something different: the user’s action does not have that number as intended result, that information is just helpful guidance.

For this reason, suggesting that every element with role=status is replaced with an output element is inappropriate.

1 Like

Again, thanks, this is a very interesting and informative post.

Do you think it applies only to this specific role, or to some others to? Typically, do you see some cases where the button role would make sense to be used instead of the button tag?

It may also apply to other combinations of roles and HTML elements. I’ll do some more testing in the coming weeks and then update the issue.

1 Like