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

> please make the case for [programmatically focusable] separately. 

Complex widgets, such as [tab panels](https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel), [list boxes](https://www.w3.org/TR/wai-aria-practices-1.1/#Listbox) [menus](https://www.w3.org/TR/wai-aria-practices-1.1/#menu), [tree views](https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView), [grids](https://www.w3.org/TR/wai-aria-practices-1.1/#grid) etc. will typically have many interactive parts, but only represent one "stop" in the sequential focus (tab) order.

This is achieved in practice by programmatically moving focus to interactive elements within the widget, often "[roving](https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_roving_tabindex)" which sub-element should take part in the tab order.

For example, an `<x-tree>` pattern might have a number of `<x-node>` elements, but only the one the user last interacted with would be in the sequential focus order. The remainder would be `programmatic` focusable, becoming `auto` or `sequential` focusable depending on user interactions.

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