-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
focus.tabbables fails when the tabbables collection is made of only radio buttons #6988
Comments
A challenge here is directionality. For example, in the Demo / Playground: https://codepen.io/aduth/pen/pKQKvm |
One possibility: We add a |
To clarify, the practical consequence of this in the Visibility panel is that tabbing with the keyboard is not constrained within the panel. For example:
So this is a case where constraining tabbing fails and screen reader users get lost. Second example:
|
Considering the aforementioned complexities of directionality, would it be considered an improvement if tabbables considered all radio elements of the same name as a single element, where the chosen element is either the checked input (if available) or otherwise the first in the set? It's non-perfect in that in a browser, Shift+Tab to focus into a radio group where there is no checked input would normally select the last radio in the DOM preceding the current focused element. But it would be relatively more trivial to implement this way. Form with checked radio group: https://codepen.io/aduth/pen/xBbWrm I've sifted through a few relevant specifications ([1] [2]) but am yet to find where this particular behavior is prescribed. If it's not specified, it wouldn't surprise me then if this behavior differed across browsers. |
Thanks for the codepens, really useful. Yep in the "without checked radio group" the behavior is different in Chrome and Firefox. On the other hand, a group of radio buttons should always have one of them selected. As you pointed out, in that case the expected behavior is unspecified and left to browsers implementations so... it differs 🙂 It's also a not ideal UI so that should be avoided. Ideally, the unselected state of a radio buttons group shouldn't be allowed in Gutenberg, at least in the documentation. That said, I'd tend to think your proposal is the best option available +1 ! |
From an already-interesting React Focus Management RFC, I was led to the following recommendation:
https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_general_within The proposal in #14128 abides by the second. |
Interesting. From the comments on the same React RFC proposal:
Yes. 🙂 Also, a very interesting consideration about portals, focus, and tab order (this was discussed at lenght for the popovers): reactjs/rfcs#104 (comment) Besides that, worth noting the ARIA Authoring Practices relates to ARIA widgets. The Section "Keyboard Navigation Inside Components" relates to custom components built with ARIA and doesn't directly applies to native elements and how browsers implement them. The closest thing I've found about native radio buttons is from the old HTML 4.0.1 recommendation: https://www.w3.org/TR/html401/interact/forms.html#h-17.2.1
The above basically just acknowledged browsers have different implementations. That said, #14128 is the best option! |
Splitting this out from #6987
There's a problem with the
focus.tabbables
implementation when the tabbables are exclusively radio buttons. This is clearly visible in the "Visibility setting" when switching to the #6987 branch (see also screenshot below).Radio buttons are technically "tabbables" but in a set of grouped radio buttons it's actually possible to tab into just one of them. In this case, the current implementation fails as
focus.tabbables
returns a collection of 3 elements but only one of them can be "tabbed" into:While technically all the radio buttons are tabbable, the current behavior doesn't help so much and in some cases it defeats the purpose of having such a tool. Gutenberg uses
focus.tabbables
mainly to get the next or previous tabbable elements and manage focus accordingly.In the above scenario, the three radio buttons should be considered 1 tabbable element, to match the native browsers behavior.
The text was updated successfully, but these errors were encountered: