Potentially confusing description of Radio Group focus behavior

[jorycunningham]

The Keyboard Interactions section of Radio Group in the 1.2 docs says:

Tab and Shift + Tab: Move focus into and out of the radio group. When focus moves into a radio group :

• If a radio button is checked, focus is set on the checked button.
• If none of the radio buttons are checked, focus is set on the first radio button in the group.

But the behavior of native radio groups seems to be: Tab and Shift + Tab: Move focus into and out of the radio group. When focus moves into a radio group :

• If a radio button is checked, focus is set on the checked button.
• If none of the radio buttons are checked, focus is set on the first radio button in the group when tabbing into the group or the last item when shift + tabbing back into the group

The difference being what happens when you are shift tabbing versus tabbing into.

Should this language be clarified?

[jnurthen]

@jorycunningham The last time I checked I think this behaviour differed in the some of the major browsers. Have you checked this is the same in all of them?

[jorycunningham]

@jnurthen great question. I should have specified that I tested this on latest version of the following:

• Firefox (Mac + WIndows)
• Chrome (Mac + WIndows)
• Edge (Windows)

All behaved the same way: Shift-tab goes to the last item if none selected or the selected item if one exists.

I'm happy to put in a PR if this seems addressable

[jnurthen]

There is this note but it does seem like it is no longer true in the browsers I tested.

NOTE The initial focus behavior described above differs slightly from the behavior provided by some browsers for native HTML radio groups. In some browsers, if none of the radio buttons are selected, moving focus into the radio group with Shift+Tab will place focus on the last radio button instead of the first radio button.

We would need the code to be changed in the same way if changing this.

[jorycunningham]

Yes, I was thinking since the behavior I'm describing seems pervasive that we might want to establish it as the norm in the keyboard interaction and perhaps have the note portion mention that there may be some variance in other browsers and that variance may be that it focus on the first item regardless.

By code change, do you mean the example implementations, such as this?

I'd be happy to do that as well if it seems warranted

[JAWS-test]

The ARIA examples do not always follow the browser or HTML standard, because this standard may not be easily accessible (see listbox with multiple selection). Therefore, for the radio button group, it should first be considered whether it makes sense for SHIFT+TAB to focus on the last radio button instead of the first. If this is not considered sensible, the ARIA example can also deviate from this and in parallel a ticket can be set for the browsers to change their implementation.

[jorycunningham]

@JAWS-test thanks for your thoughts on that. I don't have any data to say which model is more usable and I personally think both are defensible as a practice. My concern comes from two things specifically:

1. There may be a native radio set and an aria-driven one on a given page, either in the same document or, for example in mixed domain iframed content and I'd like to see things that report the same role behave the same way
2. The nuance of the difference between prevalent user agent patterns and aria can be confusing for engineers, designers, and customers who may be reporting issues.

[JAWS-test]

@jorycunningham

Yes, I understand your arguments. However, I think the problem is minor because

• you rarely navigate backwards (SHIFT+TAB)
• it doesn't make much difference whether the first or last radio button receives the focus

[mcking65]

The primary reason I'd consider suggesting that we raise a bug against browsers instead of changing APG is that I think the reversability of navigation actions is an important principle. If you are tabbing through a page, perhaps going a bit quickly, and then go past a group, it is benefitial to users, especially users who are blind, if tabbing back "undoes" what you experienced going forward. I have found myself confused, sometimes very confused, when tabbing backward moves focus on a path that differs from tabbing forward.

[mcking65]

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.

@jorycunningham, would you be open to opening bugs against browsers to resolve the inconsistency? Another potential forum is the OpenUI project.

[jorycunningham]

@mcking65 pardon my ignorance but is the behavior being inconsistent from browser to browser a bug or is it just inconsistency? Which is to say is there some standard that user agents are violating with this, or is it more of a "it would be better if it was more consistant here" sort of thing, i.e. a feature request?

[mcking65]

@jorycunningham asked:

@mcking65 pardon my ignorance but is the behavior being inconsistent from browser to browser a bug or is it just inconsistency? Which is to say is there some standard that user agents are violating with this, or is it more of a "it would be better if it was more consistant here" sort of thing, i.e. a feature request?

The latter. 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.