w3c
Roving tabindex may need expansion/clarification to keep in sync with non-keyboard use
"Managing Focus Within Components Using a Roving tabindex" https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_roving_tabindex is currently fully based on the assumption that a user is just navigating via the keyboard. Hover, if just following the steps there, users that interact with a component with the mouse or with non-kbd AT (like touch+AT scenarios) and who then switch to using keyboard will find a mismatch of what they've activated previously, and what still has focus.
Not formulated a full plan on this, but something in that section should also make reference to also listening to things like click events (regardless of what the tabindex on those child elements is), and doing the tabindex switcheroo even as a result of click (so that the roving tabindex matches whatever the user has activated/clicked directly with mouse/touch+AT/etc), so that the interface state remains consistent - otherwise there may be a weird scenario where the user clicked and actually selected one thing with the mouse for instance, but tabindex on that element is still -1
same or similar probably for "Managing Focus in Composites Using aria-activedescendant" too, in the
When the composite widget contains focus and the user presses a navigation key that moves focus within the widget, such as an arrow key:
part.
note for myself, if i ever get around to it: this now refers to https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
@mcking65 I'll add it to my ever-increasing pile of "things I'll do when I get a moment of free time" 👍🏼
@mcking65 done ... filed https://github.com/w3c/aria-practices/pull/3311 with a first naive note