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.

[mraccess77]

We do have a gap where context is so severely changed on blur that it is difficult for the user to recover. Generally on blur changes are ok when content appears below or focus can easily be shifted back -- but in the cases @JAWS-test mentions that is much more problematic.

[JAWS-test]

@mraccess77 The problem I am describing does not occur with blur (i.e. leaving the radio button group with Tab key) but with the arrow key navigation within the radio button group.

[JAWS-test]

I have created an radiobutton example, and a select example which I already encountered several times during the accessibility test.

Please try to select the radio buttons or list entries with the keyboard. If this does not work, please tell me which WCAG SC is violated...

[alastc]

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.

That's a different scenario to the one described above, I'd fail that under 2.1.1 if you literally cannot choose from any of the radio buttons at all.

[JAWS-test]

The scenarios are very similar. In Firefox, for example, the last selected list entry was displayed after the page reload, but not in IE 11 and Chrome. I.e. in Firefox it was possible to reach all list entries by reloading the page several times. Hence, in Firefox my select example (without the explicit focusing via JS) would only be a violation of 3.2.2 and in Chrome and IE 11 a violation of 2.1.1?

Be that as it may: I think it would be very good if this distinction were made in Understanding 3.2.2. I would be happy to write a draft. Or isn't that necessary? Or does someone else write that?

[alastc]

For the browser side, that depends on your conformance claim. For public facing sites with a range of usage if it doesn't work in a particular browser then I'd generally fail on whichever applies (possibly both).

It doesn't look like any of the examples fail 3.2.2 because they all had instructions, therefore I'm not sure what distinction you mean for the 3.2.2 understanding doc.

For examples that extreme I'm skeptical they are common because it causes usability issues for everyone: You are unable to change your mind. It is unexpected behavour, I haven't come across that in the wild.

The original scenario in this thread is more common, and doesn't usually have instructions so often fails 3.2.2.

[JAWS-test]

For examples that extreme I'm skeptical they are common because it causes usability issues for everyone: You are unable to change your mind. It is unexpected behavour, I haven't come across that in the wild.

I don't see any usability problem at all, because as a mouse user I decide on an option and send it at the same time (and get informed about it in advance). This is even better than having to press a submit button before, because this would be an additional step. These elements, which are easy to use for mouse users and not for keyboard users, are often found not only in surveys, but also for navigation: I choose a list entry to get to the respective page. I can also change my mind and go to another page. But as a keyboard user, I don't reach all pages, only one.

[alastc]

Even typeform (the poster-child of slick but inaccessible forms) allows you to go backwards and change you're answers. It is a usability issue in most cases as it is easy to click the wrong thing.

Anyway, if with a keyboard you cannot select any option, that's a 2.1.1 issue.

[mraccess77]

I agree with @JAWS-test that this affects keyboard users differently than mouse uses. With keyboard it is a barrier with mouse it is usable but not ideal.

[alastc]

I agree it can be, but there are at least two levels to this:

• The original scenario in this thread where: It is possible for keyboard users (passes 2.1.1) and has instructions, but is much more difficult for keyboard users (gap in 3.2.2 coverage?).
• The scenario JAWS-test presented where it is not possible to select any choice except the first (fails 2.1.1 IMHO).

Both present usability issues, the second scenario is possibly severe enough that it is very rare in practice.

So in my mind the comparison is between:

• Legitimate uses for change-on-input that justified the original SC having the bit about instructions in the first place.
• The gap in coverage for 3.2.2 for change-on-input when there are instructions.

I.e. would removing that gap ban legitimate scenarios?

[JAWS-test]

@alastc
I don't see any difference between G13 and my examples, especially not in the case of

A series of radio buttons at the top of a page include options for German, French and Spanish. Instructions precede the buttons that instruct the user that the language will be changed upon selecting an option.

If the radio buttons are only used to select the language and not to display the selected language at the same time, then the example is identical to mine and the selection of languages is not possible with the keyboard.

[alastc]

It's different because in the G13 instances you can change them. I.e. you change to French, and the page does load/reload in french, but you can tab to and change the option to German.

In your example, as soon as any selection was made, it was irriversable.

[JAWS-test]

It's different because in the G13 instances you can change them. I.e. you change to French, and the page does load/reload in french, but you can tab to and change the option to German.

It could be, but it doesn't say that exactly in G13. It could also be so, as in my example.

The selection of further radio buttons is only possible if the selected language has the status checked after the language change in the radio button group. However, this does not necessarily have to be the case. It is possible that the radio buttons are only used to select the language, but not to display the currently selected language. And then it would be like my example: Not operable with the keyboard. But that's not too bad, because it's a violation of 2.1.1.
It would be much worse if I had to navigate to the radio button group several times to select the desired language. A simple action can become a work step that takes many minutes and contains countless tabulator steps. That's why I also suggested that it could be a violation of SC 2.4.3 because the focus sequence is disturbed by the additional navigation steps

[mraccess77]

A related issue is when the user moves the mouse outside of the page, focuses out of the page to the address bar or scrolls to the top of the page which triggers an exit modal that pops up causing a change of context to the page based on user actions -- although it's not a setting change of a user interface component.

[JAWS-test]

@mraccess77 For these reasons I am very much in favour of a comprehensive revision of SC 3.2.2 with WCAG 3.

• No context change (without the restriction to change a "user interface component")
• Exception "unless the user has been advised of the behavior before" only if it does not make the operation of the application more difficult, but makes sense.

[patrickhlauke]

Revisiting this belatedly, I'd argue that having a construct like

<fieldset onchange="console.log('proceed to next question')">
  <legend>Choose an answer</legend>
  <label><input type="radio" name="foo"> One</label>
  <label><input type="radio" name="foo"> Two</label>
  <label><input type="radio" name="foo"> Three</label>
  <label><input type="radio" name="foo"> Four</label>
</fieldset>

would fail 2.1.1 as for keyboard users, there's no way (to my knowledge) to explicitly move focus to a particular radio button and then activate/choose it ... keyboard users can only move to the radio button group, and then any change they make with the cursor keys immediately triggers a selection. and if they can't then return back to the same question and choose another one, they effectively can't operate the interface with the keyboard at all. unlike, say, <select>, where keyboard users can at least open the <select> first, and then choose an option or bail back out.

perhaps to resolve this issue, G13 should be amended/clarified

[patrickhlauke]

Had a little play here to address the underlying concern #4291