-
Notifications
You must be signed in to change notification settings - Fork 125
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
For consideration: role=resizer #1348
Comments
Interesting idea. FYI, I believe people usually call that type of resizer-thing a "splitter". |
Agree this would be sensible. Would probably need to deprecate one of the behaviors in 1.3 and then remove in 1.4. Happy to consider this. |
I seem to remember writing a PR to create a splitter role for ARIA 1.1. I don't remember why we went down the path we did. If it was a PR, and not just a branch, maybe we can turn it up. If it was a branch that we deleted, is there still a way to find it in the repo? I am confident it was called splitter. a search of closed PRs doesn't turn it up. :( Hmm, a search of closed PRs doesn't show any of the PRs I believe I wrote for ARIA 1.1, merged or not. Do they somehow get archived? However, if you look at all PRs, there are some that date back to 2014 and 2015. Not understanding. |
Never heard that term, but splitter sounds excellent. |
@jnurthen did this end up getting discussed? I see it tagged with Agenda in Nov 2020 but no updates after that. Tableau recently received an a11y audit which calls out our use of |
The
separator
role is the only role in WAI-ARIA that changes what it is and what it supports based on the element it is used on. When the element is focusable, it behaves like a regular<hr />
separator type thing, and when focused it becomes a resizer that users can drag to adjust the size of panels / components.This makes it difficult to express the separator in a static data structure such as aria-query. Because this is the only role that behaves like this, and not a particularly common one the issue is generally just ignored. Both widget and structure are set as the superclass, and focusable properties are always returned as supported states/props.
There's a straight-forward solution to this, which is to deprecate focusable variant of the separator and introduce a new role for that particular purpose. The added benefit to that is it can be given a more descriptive name. It is not all that obvious that a focusable separator is intended to be a resize widget, so something like
role="resizer"
makes that very clear. Another benefit is that it'll allow for disabled resizers, which is not something that can be expressed with the current pattern.The text was updated successfully, but these errors were encountered: