Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow gridcell and treeitem roles on button elements #298

Closed
smhigley opened this issue Mar 22, 2021 · 3 comments · Fixed by #446
Closed

Allow gridcell and treeitem roles on button elements #298

smhigley opened this issue Mar 22, 2021 · 3 comments · Fixed by #446
Labels
Allowed roles Pertaining to the allowed roles of HTML elements

Comments

@smhigley
Copy link

In the Rules of ARIA attribute usage by HTML element , <button> already allows every child role of composite widgets that manage focus except for tree and grid.

There are benefits in using <button> as a base of interaction in these widgets, such as:

  • Enter/space triggers the click event
  • Certain colors and interaction styles are applied automatically in forced color modes like Windows High Contrast Mode.

Those benefits also apply to gridcells and treeitems, so it seems like it would be valuable to add those as well.

Happy to do a PR for this :)

@scottaohara
Copy link
Member

Closing. Reasoning provided in the closed PR #299

@smhigley
Copy link
Author

smhigley commented Feb 1, 2023

@scottaohara would you mind reopening, since we discussed taking a look at this again?

@scottaohara scottaohara reopened this Feb 3, 2023
@scottaohara scottaohara added this to the ARIA in HTML 1.1 milestone Feb 3, 2023
scottaohara added a commit that referenced this issue Feb 6, 2023
closes #444
closes #395
closes #298

This PR makes the allowances for button-elements (button, input type=button|image|submit|reset) more consistent with each other.  Additionally, slider and gridcell are now listed under the allowed roles for these elements.

the LOE to properly create the necessary UX for some of these roles when specified, especially on the `input` type buttons, is rather large _but_ possible.  Any failures to not implement these properly would be caught by WCAG rules.  Allowing the roles won't change that.
@scottaohara
Copy link
Member

re: discussion mentioned above - the reason this was re-opened is because while HTML's content model will still disallow nested interactive elements within a button element (regardless if its role was overwritten or not), in further testing there does not appear to be any negative impact from a UX pov. Additionally, even in situations where using a base button element for these roles, or if one were to include nested interactive elements - any problems found would either be issues for all users (e.g., pressing a gridcell submits a form unexpectedly) or would likely be found via other wcag related testing (automated or manual).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Allowed roles Pertaining to the allowed roles of HTML elements
Projects
None yet
2 participants