[focusgroup] How to account for browsers that don't automatically tab focus buttons

[lukewarlow]

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.

[janewman]

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.

[lukewarlow]

https://mayank.co/blog/safari-focus/ - this describes the safari behaviour. I think you're probably not actually on default settings.

[janewman]

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.