S1082 / RSPEC-1082 on native buttons versus custom buttons

RSPEC-1082: Mouse events should have corresponding keyboard events is triggered on custom buttons with only onclick but not on native buttons.

Consider the following snippet:

  <p><button type="button" onclick="pleaseDoIt()">Please do it</button></p>
  <p><span type="button" role="button" tabindex="0" onclick="justDoIt()">Just do it</span></p>
  <p><custom-button type="button" onclick="doItAgain()">Do it again</custom-button></p>
  <p><custom-button type="button" onclick="continueDoinIt()" role="button" tabindex="0">Continue doing it</custom-button></p>
  1. The native button element does not trigger an error message, even though it only appears to have a click even listener and no keyboard event listener. This makes sense; see WCAG Technique SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons, which says,

    While “onclick” sounds like it is tied to the mouse, the onclick event is actually mapped to the default action of a link or button. The default action occurs when the user clicks the element with a mouse, but it also occurs when the user focuses the element and hits enter or space, and when the element is triggered via the accessibility API.

  2. The span-based button triggers the error message “Add a ‘onKeyPress|onKeyDown|onKeyUp’ attribute to this tag.”, even though, based on the above, one may think it shouldn’t. (It also triggers the warning “Use <button> or <input> instead of the button role to ensure accessibility across all devices.”, which is justified but outside the scope of this topic.)
  3. The custom-button-based button triggers essentially the same error message as above: “Add a ‘onKeyPress|onKeyDown|onKeyUp’ attribute to this <custom-button> tag.” It does not take into account that custom-button can be a web component that has a native and perfectly accessible HTML button in its shadow DOM.
  4. The last button generates the same error message as the previous one and the same warning as the second button.

Given the above variations, can the rule RSPEC-1082 reliably judge whether the error message about missing keyboard handlers is justified?

Related topic: False positive for S1082 (Angular keyup.enter event not recognized), posted in April 2024.

@ChristopheS , that’s a very legit question, that may also apply to some other HTML rules whenever custom components are involved.

We could definitely benefit from your opinion, here. What do you think we should do to improve the reliability of S1082? I know that, at some point, it was discussed that it should only targets tags that are defined by the HTML specification - i.e. that it should ignore custom components - but it seemed excessive at that time, and maybe prone to a lot of false negatives. Maybe it is time to re-evaluate our position.

What do you think? Do you have any other recommendations?

Thanks a lot for your time,

Eric.

1 Like