Tweak G13, on-input understanding, F37

[patrickhlauke]

• in G13, as radio buttons/inputs would cause 2.1.1 Keyboard failures (as keyboard users are not able to explicitly select a radio button with the keyboard without triggering a change event, which would then lead to a form submission or page reload in these examples), changing the examples to a select and a set of toggle buttons
• reformatting/cleanup of the markup for G13
• in on-input understanding, replacing the mention of radio buttons with a select dropdown as well, for clarity/consistency (in this case, even the radio button example would be fine, but it may confuse matters)
• in F37, add an extra note explicitly mentioning that radio buttons will still fail 2.1.1 even if they included a warning that satisfies 3.2.2

Closes #898

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	933c754
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/68028c00daafca00085862e8
😎 Deploy Preview	https://deploy-preview-4291--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[patrickhlauke]

Do we think we need some extra call-out/note in the actual 3.2.2 understanding, warning that a set of radio buttons that have an onchange handler can still end up causing a 2.1.1 Keyboard failure? or is that a bit too specific?

Alternatively, might be worth also revisiting https://www.w3.org/WAI/WCAG21/Techniques/failures/F37 which does seem to suggest that if a set of radio buttons has a warning, it would then not fail ... maybe squeezing in a note at the end there saying that while that will then pass On Input, it will then fail Keyboard even with that preceding warning

EDIT: done

[dbjorge]

@patrickhlauke In the future, if you're going to accept editor reformattings as part of a PR, could you try to do the reformat first and commit it as a separate commit? Even if it's within the same PR, if you make it a separate commit from the actual content changes, it makes it much easier to review just the content on its own by filtering the first commit out of the diff in the GitHub files changed view.

[fstrr]

Diff viewers for relevant pages:

• G13
• On Input
• F37

[patrickhlauke]

@patrickhlauke In the future, if you're going to accept editor reformattings as part of a PR, could you try to do the reformat first and commit it as a separate commit? Even if it's within the same PR, if you make it a separate commit from the actual content changes, it makes it much easier to review just the content on its own by filtering the first commit out of the diff in the GitHub files changed view.

sure thing sorry. this came out extra messy as well once i merged and force-pushed stuff

[kfranqueiro]

This was out of sync with main and had some large conflicts due to the reformatting. I have resolved this and tried to minimize the whitespace diff, so the diff view in the PR should be easier to read now. (Syncing with main also means the HTML diffs linked by Francis no longer flag things that this branch was out-of-date with.)

@patrickhlauke I am pretty sure I managed to preserve the actual changes in the PR, but I'd invite you to take a look to make sure. And I wanted to confirm, is it intentional that the note you added to F37 is nested only under the Tests section (i.e. not under Expected Results)?

[patrickhlauke]

thanks @kfranqueiro - just checked, and it seems that all my fundamental changes are in there. and yes, i intended the note to be outside of the expected results ... but i could see a rationale for also moving it into that section...whatever makes most sense

[detlevhfischer]

@patrickhlauke I was a bit confused about the assumption that the first example in G13 necessarily fails 2.1.1. If the row of radio inputs is meant to swap languages and loads content in another language when focussing=selecting the radio input, another page loads with focus the same input, and the next TAB or arrow key will then go to the next language and loads content in that language, again setting the focus to the radio input corresponding to that language, where is the 2.1.1 error? It seems a 2.1.1 error would only occur if you can never move beyond the selected language to other languages? I would be surprised if authors of G13 originally cooked up an example that was patently unusable for keyboard users...

Having said that, I agree that changing that to select based example is better.

[patrickhlauke]

I was a bit confused about the assumption that the first example in G13 necessarily fails 2.1.1.

Oh for sure there's probably ways to NOT make it fail, with lots of extra "but since this then happens, users can - in a very convoluted way - still choose the right language" but it's so disruptive and broken as a concept (particularly if the user's focus gets thrown right back to the start of the page by default, and NOT also then moved directly to the radio button they just chose, etc) and requires so much extra context, that I thought it was probably much more digestible to pick a simpler, more common example that is less ambiguous/requiring of lots of other external factors.

same reason why i changed the multiple choice example ... IF the user is still able to navigate back to the previous step/slide and change the radio buttons, then yeah in a horrible way, it IS keyboard accessible. but if it's a type of quiz where they're not allowed to go back for some reason, then that fails. again, too much additional context needed, which I chose to just sidestep for clarity.