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

> Complex widgets, such as tab panels, list boxes menus, tree views, grids etc. will typically have many interactive parts, but only represent one "stop" in the sequential focus (tab) order.

On macOS, with full keyboard access enabled, in many cases, each such interactive part should be in the tab order. Without full keyboard access, it shouldn't be. At the very least, that's true for tabs and tree views. List boxes don't give individual focus to their elements, the list box as a whole is the only thing to get focus. Likewise for menus. For grids, I'm assuming you mean editable grids, like a spreadsheet, and those tab to each item.

Maybe on other platforms this category makes more sense, but on macOS any use of it for the named items would violate platform conventions. Whereas using either control or text-input-control categories (depending on whether the piece takes text input) or none if non-control the container is supposed to get focus would do the right thing.

> This is achieved in practice by programmatically moving focus to interactive elements within the widget, often "roving" which sub-element should take part in the tab order.

Are parts like that not meant to be click-focusable? What exactly sends programmatic focus to a specific piece?


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