openui
[focusgroup] How to account for browsers that don't automatically tab focus buttons
Currently not all browsers allow tab navigation of all conventionally focusable elements. Safari for example won't tab focus buttons without a setting change (or I think nowadays if you set tabindex="0" explicitly).
How does focusgroup play into this? Should it follow the same behaviour or should it be specified to force focusing of these elements when using arrow keys?
Ultimately this might be up to WebKit how they choose to handle this. But I think developers would prefer it to just work.
Currently not all browsers allow tab navigation of all conventionally focusable elements. Safari for example won't tab focus buttons without a setting change (or I think nowadays if you set tabindex="0" explicitly).
How does focusgroup play into this? Should it follow the same behaviour or should it be specified to force focusing of these elements when using arrow keys?
Ultimately this might be up to WebKit how they choose to handle this. But I think developers would prefer it to just work.
Can you expand on this Safari behavior? I tried
<button> Button 1 </button>
<button> Button 2 </button>
<button> Button 3 </button>
<button> Button 4 </button>
and found that I could tab between these with tab, and I don't have any special settings on, just the default.
In the end, I think that focusgroup is looking at focusability in general when considering what elements could be considered focusgroup items. Even the behavior you described (focusable but doesn't participate in tab-order) should still be considered a focusgroup item, just like elements with tabindex=-1. That said, this should impact tab-ordering with regard to the concept of opted-out-barriers, e.g.
<div focusgroup='toolbar'>
<button> Button 1 </button>
<button> Button 2 </button>
<button tabindex='-1 focusgroup='none'> Help </button-not-in-tab-order>
<button> Button 3 </button>
<button> Button 4 </button>
</div>
<button> Button After</button>
In this case, hitting tab from any button in the focusgroup would move focus to "Button After". If the "Help" button was some other native element that a particular user-agent did not make participate in tab ordering, a similar behavior would occur.
https://mayank.co/blog/safari-focus/ - this describes the safari behaviour. I think you're probably not actually on default settings.
https://mayank.co/blog/safari-focus/ - this describes the safari behaviour. I think you're probably not actually on default settings.
Thanks, I hadn't considered the setting could be in system settings, not safari settings. Frankly, I'm shocked that this isn't the default behavior.
Ultimately this might be up to WebKit how they choose to handle this. But I think developers would prefer it to just work.
I agree with this sentiment, but from the text used to describe the feature, I wonder how they will feel about the sentiment. "Use keyboard navigation to move focus between controls. Press the tab key to move focus forward and Shift Tab to move focus backward." The first sentence makes me think that focusgroup would be covered in "using the keyboard to move focus between controls", though the second sentence does make me reconsider if this should be thought of as specific to sequential focus navigation.
Right now, I don't think that focusgroup should impact the focusability of native elements.
My 2 cents is that the element type of the entry element will determine whether keyboard users will reach the focusgroup (at least if they don't have full keyboard access on).
To be honest, I don't know if this is worth worrying about. If a user has not turned on full keyboard access, they are likely A) not relying on keyboard navigation, and B) accustomed to not reaching things with the tab key. This would be equally true for custom-made toolbars, trees, grids, menulists, etc. etc.
@rniwa, during TPAC you mentioned this as a potential issue you wanted to clear up, please take a look at what has been said already here, and please let me know what you think the best past forwards is!
I don't think focusgroup should affect which element is focusable. If a button is not focusable in a given browser, then it should stay not focusable within a focusgroup.
