Technique G13 - allows surveys to advance on input with notice, even radio buttons?

[jhausler1266]

Question about g13, https://www.w3.org/WAI/WCAG21/Techniques/general/G13

I'm working with a team building a survey creation tool. We pointed to SC 3.3.2 and said they can't advance on input, especially since they use radio buttons. They highlighted this text in G13:

A 50 question online survey displays one question at a time. Instructions appear at the beginning of the survey that explain that users will be taken to the next question of the survey upon selecting an answer to each question.

Even with advance notice, surely selecting a radio button from a group cannot advance a survey. Keyboard users would have to go back and forth as many times as it too to get to the final item in the group.

[mraccess77]

Personally I agree -- this seems wrong for radio buttons. Perhaps for checkboxes it might be allowed under the rules when an advisement is provided although problematic. I've seen some surveys where a new question appears but the old question is still above -- it seems like making this a user option is best to help users with different/conflicting needs.

[awkawk]

Current link to technique: https://www.w3.org/WAI/WCAG21/Techniques/general/G13

I would say that this was intended to mean that once you change the radio selection and move the focus away.

[jhausler1266]

PM goal is "Click on Radio, move to next page". They aren't thinking about tabbing off to trigger the change. To them, and others i would assume, it would be the same as having to click a Next button. That's what they want to avoid.

Agree on user pref... but that goes for any failure technically, for better or worse.

[mraccess77]

@awkawk then that situation would be better linked to 3.2.1 instead.

[awkawk]

@mraccess77 I don't think so because if the change happens when the component loses focus it doesn't arrive at the other one so 3.2.1 doesn't apply.

[jhausler1266]

I referenced 3.2.1 with them as well for why their approach is bad.

I'm just pointing out that this example in G13 can cause confusion. Maybe a clarification that 3.2.1 must still be met? or a call out that this wouldn't apply to radio buttons, listboxes where focus=selection, and other similar input components?

[mraccess77]

@awkawk your're right -- however, under 3.2.2 tabbing away is not really a setting change -- but clicking, checking or selecting is. So the note is still problematic.

[JAWS-test]

I find 3.3.2 very unfortunate formulated, as it allows the exception that it would be ok if the user is informed in advance. For harmless examples cited by the Understanding, it could be indeed sufficient for the user to be informed in advance. In reality, many examples can be seen in which a web application is not or very difficult to use if a context change occurs during operation. What use is a hint in advance if there is a context change during operation that leads you unintentionally to a new page or places the focus at the top of the page? My question would be whether such cases would then be regarded as violations of 2.1.1 or 2.4.3.

[alastc]

In the scenario where a series of radio buttons change context on-change (i.e. as soon as you move the selection), I don't think you could fail that under 2.1.1 or 2.4.3:

• It is possible, if not easy. You can shift-tab back and select the next option until you get the right one.
• The order is fine, it is the auto-movement that's the problem.

I agree that scenario is not good from a keyboard accessibility point of view, but I think G13 is correct.

We could add a note to the effect that there are still potential problems with this approach.

Personally, if I could then I'd make the developers use it keyboard-only in sprint demos, that usually sorts out this sort of issue!

[mraccess77]

I consider focus moving on selection of a radio button a WCAG failure although moving focus on blur is not.

[alastc]

@mraccess77 under 3.3.2? That's where the issue started though, if there's an instruction about it, then it is not a failure of that.

[mraccess77]

@alastc - right - I'd fail under 3.3.2 without an instruction. Just wanted to make sure there wasn't some disagree with that!

[JAWS-test]

@alastc

It is possible, if not easy. You can shift-tab back and select the next option until you get the right one.

I'm afraid that's not true. I've had several applications where navigation through the radio buttons caused a new page to load. When I returned to the old page, the focus was on the first radio button again. This means that I could always only trigger the action of the second radio button but not that of all the others. Thus the function would not be usable at all for keyboard users. A advice "of the behavior before using the component" as suggested in 3.2.2 must seem like a mockery to every keyboard user at this point.

SC 3.2.2 should therefore be modified accordingly. Alternatively, the Understanding should explicitly state that the exception with the advice only applies if the application can still be operated with the keyboard.