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

@othermaciej wrote:
> List boxes don't give individual focus to their elements, the list box as a whole is the only thing to get focus. 

@alice replied
> I just tested it on the macOS settings app, and tabs are one tab stop in that context. Arrow keys choose between the different tabs (and move the focus indicator).

If I understand the distinctions you're each making, you two are agreement on the relevant parts. 

Maciej mentioned that managed focus AppKit controls don't focus the sub-views, per se. But AppKit does style the sub-views and vends enough information for AT to understand the relationship... Somewhat similar to the concept of `aria-activedescendant`

Alice mentioned that more web controls use the other managed focus technique: roving/roaming tabindex. (There's a demo video of [r–ing tabindex in Example 2 of this 2014 WebKit post](https://webkit.org/blog/3302/aria-and-accessibility-inspector/)). Each technique is useful.

In both cases, on Web or native platforms, the user experiences the same end result: one tab stop, with other non-Tab keypresses modifying the widget's sub-level focus or visible focus indicator. The distinction of whether the container or the sub-view gets actual focus feels like a implementation detail of the platform. 


-- 
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-601847776