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