feat!: use role attribute instead of native button

[vursen]

Introduction

There are 2 approaches suggested by Tetralogical (#132) on how to organize the HTML structure of the button so that it would become more accessible for screen readers.

1st approach (prototyped and currently used in @vaadin/button):

The approach is based on the native <button> element.

<vaadin-button part="vaadin-login-submit" theme="primary contained">
  # shadow-root
  <button class="vaadin-button-container">
    <span part="prefix">
      <slot name="prefix"></slot>
    </span>
    <span part="label">
      <slot></slot>
    </span>
    <span part="suffix">
      <slot name="suffix"></slot>
    </span>
  </button>
  # end shadow-root

  Log in
</vaadin-button>

2nd approach:

The approach is based on the [tabindex=0] and [role=button] attributes which should be set on the button host.

<vaadin-button part="vaadin-login-submit" theme="primary contained" tabindex="0" role="button">
  # shadow-root
  <div class="vaadin-button-container">
    <div part="prefix">
      <slot name="prefix"></slot>
    </div>
    <div part="label">
      <slot></slot>
    </div>
    <div part="suffix">
      <slot name="suffix"></slot>
    </div>
  </div>
  # end shadow-root

  Log in
</vaadin-button>

While the current implementation of the button is based on the 1st approach (with the native button), this approach supposes us to make some changes in the Lumo and Material themes (moving padding from the host on the native button in particular) in order to adjust them for the new HTML structure.

The 2nd approach, on the other hand, doesn't suppose any changes in the themes and also allows us to get rid of ControlStateMixin in favor of the modern TabIndexMixin, FocusMixin.

The 2nd approach also provides a more convenient HTML structure that makes easier the future removal of the <span> wrappers, see #955 (comment).

---

This PR aims at giving an implementation for the 2nd approach as it has been considered to be more advantageous.

Part of #2224

Related a11y issues

• General: Elements without a robust accessible name or role #153
• [button] NVDA reads the text of the button followed by "blank" #600
• Lighthouse warning: Buttons do not have an accessible name #866

Type of change

• Feature

Checklist

• I have read the contribution guide: https://vaadin.com/docs-beta/latest/guide/contributing/overview/
• I have added a description following the guideline.
• The issue is created in the corresponding repository and I have referenced it.
• I have added tests to ensure my change is effective and works as intended.
• New and existing tests are passing locally with my change.
• I have performed self-review and corrected misspellings.

Additional for Feature type of change

• Enhancement / new feature was discussed in a corresponding GitHub issue and Acceptance Criteria were created.

[knoobie]

Just a note: if you change the underlying implementation from a native button to role="button" - keep in mind that the SPACE and ENTER key work as well to trigger the action. See https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role#keyboard_interactions

[vursen]

@knoobie Thank you for the feedback!

Just a note: if you change the underlying implementation from a native button to role="button" - keep in mind that the SPACE and ENTER key work as well to trigger the action. See https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role#keyboard_interactions

Currently, the button inherits ActiveMixin that aims to support activating the element with both Space and Enter.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

No Coverage information
0.0% Duplication

[web-padawan]

LGTM 💯

[vaadin-bot]

This ticket/PR has been released with platform 22.0.0.alpha2 and is also targeting the upcoming stable 22.0.0 version.