Allow clr-button for Web:MouseEventWithoutKeyboardEquivalentCheck

Then tell us:

  • What language is this for?
    • HTML
  • Which rule?
    • Web:MouseEventWithoutKeyboardEquivalentCheck
  • Why do you believe it’s a false-positive/false-negative?
    • Because the clr-button element is rendered as a button in the browser. See dedails below.
  • Are you using
    • SonarQube Server 2025.1.2
  • Code snippet
<clr-button-group>
  <clr-button (click)="doSomething()">The button</clr-button>
</clr-button-group>

Since the upgrade to 2025.1 we get a lot of issues related to click handlers that do not have a keyboard event. In our case we often use Angular, and Clarity as the UI library (https://clarity.design/).

Clarity allows for creating buttons using the clr-button component that is rendered as a button element in the browser. When adding a click handler to a clr-button, sonarqube creates a Web:MouseEventWithoutKeyboardEquivalentCheck finding, because there are no keyboard events defined on the element.

The exceptions chapter for the rule states

For the following elements, pressing a key will trigger the onClick attribute: <input type=“button”>, <input type=“submit”>, <button>, <a>. Thus no issue will be raised when an onClick attribute is found in these elements without a onKeyDown/onKeyUp/onKeyPress.

An issue will still be raised for elements with the role=“button” attribute as they don’t behave the same way.

Since the clr-button is rendered as a normal button in the browser, it should fall under those exceptions, but the rule does not detect it as a button element. I checked the source code of the rule and found that the isException method (sonar-html/sonar-html-plugin/src/main/java/org/sonar/plugins/html/checks/sonar/MouseEventWithoutKeyboardEquivalentCheck.java at 2df9f818c844493ac36a2ac9de05775cad36e9e5 · SonarSource/sonar-html · GitHub) already checks for a lightning-button element.

Since the lightning-button is also a element from a UI library, maybe it is possible to also add the clr-button as an exception.

Or even better maybe the rule could be parameterized, so that user can specify a list of elements that behave like a button in the browser. This might reduce the need to update the rule every time a new component library comes out.

What do you think about such a change?

Regards
Daniel

Hello @furti ,

indeed, I agree the ideal solution for this rule would be to have a parameter in the rule configuration. I added a ticket to implement this.

Cheers,
Victor

1 Like