openui
[focusgroup] Should the entrance algorithm not consider direction?
Created out of https://github.com/openui/open-ui/issues/1314#issuecomment-3469766888
I don't personally feel strongly here, and thought the "Existing" behavior was reasonable, but opening this up of discussion
Existing behavior
When navigating using sequential focus navigation (tab/shift+tab) the current explainer considers the direction that the user is entering from when determining which focus group item should be focused (when memory is not a consideration). This comes from: https://github.com/openui/open-ui/issues/537#issuecomment-1934930124
<button>Before</button>
<div focusgroup="toolbar no-memory">
<button>Bold</button>
<button>Italic</button>
<button>Underlined</button>
</div>
<button>After</button>
When focus is on "Before" and tab is pressed, "Bold" should be the initially focused item, hitting tab again brings us to "After". If instead focus was on "After" and shift+tab was pressed, "Underlined" should instead be the initially focused item.
Potential Change
Instead, we could not take the direction the user is navigating in into consideration, ensuring that both tab and shift+tab will always pick the same item.
<button>Before</button>
<div focusgroup="toolbar no-memory">
<button>Bold</button>
<button>Italic</button>
<button>Underlined</button>
</div>
<button>After</button>
When focus is on "Before" and tab is pressed, "Bold" should be the initially focused item, hitting tab again brings us to "After". If instead focus was on "After" and shift+tab was pressed, "Bold" is still the first item to be focused.
I think that not considering directionality should be the default behavior, and we should avoid adding an option to support directionality unless there are compelling real-world examples.
The only example I’m aware of that considers directionality is Chrome’s native HTML radio groups:
If none of the radio buttons are selected, moving focus into the radio group using Shift+Tab places focus on the last radio button instead of the first.
(Firefox, by contrast, always places focus on the first radio button.)
Additionally, @mcking65 made some strong arguments in this issue: https://github.com/w3c/aria-practices/issues/2258 https://www.w3.org/WAI/ARIA/apg/patterns/radio/
Based on today's discussion in the APG task force teleconference, the task force is unwilling to commit to introducing an inconsistency between Tab key behavior in the radio group pattern and Tab key behavior in other patterns that support the reversability of Tab navigation. Many members of the task force view Reversability (or "undo") as a valuable principle for Tab key navigation.
That is, if a user is navigating forward with Tab and presses Tab one too many times and then presses shift+Tab to recover, it is most beneficial to users if Shift+Tab returns focus to the element that was previously focused.
The Tab key behavior of the APG radio group is consistent with Tab key behavior for other composites, such as menubars, trees, grids, and toolbars. In all composite implementations, tab and Shift+Tab are reversable so that Shift+Tab can "undo" Tab and vice versa. Browser implementations of radio groups are anomolous with respect to this principle of reversability or "undo".
The APG Task Force position is that consistent implementation of this ability to "undo" with shift+Tab is beneficial to users and that accessibility would be improved if browsers were to respect Tab reversability.
