Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762)

The disconnect is that when I referred to tabs I meant window-level tabs, like this:

<img width="882" alt="Screen Shot 2020-03-09 at 11 26 20 PM" src="https://user-images.githubusercontent.com/978436/77145186-0d7ffa00-6a45-11ea-8832-3abd3c5f4dfc.png">

What Alice screenshotted is a "segmented control" but may also reasonable be called tabs.

I can confirm that it has the behavior she describes; it's a single stop in the tab order, it draws a focus ring around exactly one item, and it moves through the items with arrow keys. A similar thing is true of radio button groups in native UI; only the currently active radio button is in the tab order. Or, looked at another way, a radio button isn't a control, a radio button group is. Indeed, the segmented control is sort of an alternate presentation of a radio button group. WebKit even replicates this behavior of radio button groups in HTML when "Use keyboard navigation to move focus between controls" is enabled.

I'm not sure this pattern is best represented. Under full keyboard access, radio buttons are individual elements that are always click-focusable, but, at least on macOS (not sure how this works on Windows), only the active one is in the tab cycle. It's reasonable for other elements intended to be part of a group to have this behavior. Less clear (to me) whether there is a need to not be click focusable in such a scenario.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/762#issuecomment-601576894