RE: Recent changes to the WCAG 2.2 SC 2.1.1 Understanding page

> I too Steve have come across radio buttons that, instead of performing like radio buttons actually submit a form..often leading to a page indicating an error.

If the user presses enter when focused on a field, it's expected that a form will submit.

If moving through radio button selections submits the form and causes a 'change in context', whether they've been custom-made and each of them are a tab stop, or whether they're standard radio buttons where the group is a tabstop and arrow keys navigate between them, it's a violation of On input.
On 8/2/2024 12:29:45 PM, Karen Lewellen <klewellen@shellworld.net> wrote:
This is an interesting thread.
I too Steve have come across radio buttons that, instead of performing
like radio buttons actually submit a form..often leading to a page
indicating an error.
Speaking personally? I cannot understand why an undiscoverable keyboard
option is not a violation, let alone why an option like the one we are
referencing is not violating either. after all, if someone is using their
voice instead of a keyboard, or an augmented tool, but the keyboard
behavior cannot be discovered, how does that provide access?
Further the challenge of getting clear answers, when, speaking personally,
rather a few people who may be tasked with compliance are not developers,
but folks confused by accessibility generally?
Well, that seems a recipe for frustration, lets just tell people we are
w3c compliant or WcaG compliant..no one will know the difference anyway!
Karen



On Fri, 2 Aug 2024, Steve Green wrote:

> I don’t know why people do these things, and I suspect in some cases the behaviours come from a framework or plug-in and the developer doesn’t even know about it.
>
> I have encountered plenty of radio buttons and checkboxes that have different behaviours depending on whether you use the Enter key or Spacebar when they have focus. Often, the Enter key submits the form, which is not desirable but apparently doesn’t violate any success criteria.
>
> This means there are two different issues: the original issue regarding the discoverability of intended interactions, and a second issue regarding unnecessary, undesirable interactions.
>
> Steve
>
> From: Juliette McShane Alexandria
> Sent: Friday, August 2, 2024 6:07 PM
> To: bryan rasmussen ; Steve Green
> Cc: Patrick H. Lauke ; w3c-wai-ig@w3.org
> Subject: Re: Recent changes to the WCAG 2.2 SC 2.1.1 Understanding page
>
> Also, weighing in on the 'standard' or 'expected' keyboard interaction being required to pass 2.1.1.
>
> When I was first learning about accessibility I had the understanding that Steve did - if it wasn't the 'standard' or 'expected' method of keyboard interaction it was a failure. Once I started to really understand the difference between normative and non-normative documentation, in combination with being involved with various mailing lists and accessibility SME communities, I adjusted my concept of a 2.1.1 failure to not include non-standard keyboard interactions.
>
> If it's really a strange, unexpected keyboard pattern we will write it up, but we mark is as usability. We also provide a 4 level severity rating, and this is usually "Serious" (the step below "Critical").
>
> On 8/2/2024 10:00:20 AM, Juliette McShane Alexandria > wrote:
> I've come across 'undiscoverable' keyboard commands occasionally. Usually it's when they have a help center or similar that outlines the requirements, but there's no indication on the page that there are instructions for operation elsewhere.
>
> In one case it was an e-learning platform for 3rd - 12th grade and they intentionally keep the UI as pared down and as clean as possible to reduce all possible distractions and keep the learners focused on a lesson. They have a really nice help article about how to use all the custom keyboard commands though. I'm assuming because this platform is used by teachers in educational settings the teachers help the learners find the resources or teach them the commands.
>
> The other examples I've seen are, from my perspective, just overlooking or not realizing how important it is to have the information available to keyboard users in a location where it's discoverable and relevant. I assume it's often the designers who don't want 'extra' stuff on the page, because during the remediation phase that's who usually pushes back against adding a tooltip/toggletip/disclosure to house the information and downright say no if asked to add it as text always visible on the main page.
>
> On 8/2/2024 9:26:52 AM, bryan rasmussen > wrote:
> I actually find it very weird, the concept of undiscoverable keyboard interactions - why would this ever exist? Is iit sort of like Easter Eggs, the devs put n for them and nobody else?
> I would expect that if someone puts in a keyboard interaction they want it to be discoverable and usable, and if it isn't that is actually a bug in their program that they would like you to point out whether or not it is an accessibility issue.
>
>
> On Fri, Aug 2, 2024 at 2:23 PM Steve Green > wrote:
>
> Thanks to everyone for all the responses. They raise a couple of questions, though:
>
>
>
> 1. If data entry requires the use of an undiscoverable keyboard interaction (and we do encounter them), can we report a non-conformance of SC 3.3.2 (Labels or Instructions)? The normative text and Understanding page don't mention this at all - they focus entirely on the labelling of controls and data validation rules.
>
>
>
> 1. If undiscoverable keyboard interactions relate to functionality other than data entry, it appears that they don't violate any success criterion. Surely that can't be right.
>
>
>
> After spending an hour trawling through GitHub, I have some understanding of it. It's pretty daunting for someone who doesn't use GitHub in their work. It's safe to say I would never have found that Commit page if I didn't know it existed. And the distinction between Issues and Discussions is far from clear.
>
>
>
> I have subscribed to notifications and will participate as best I can. Sadly, membership is unaffordable for me.
>
>
>
> I had a look at keyboard.html commits, but it’s full of all kinds of stuff. What I really want is a changelog for each Understanding page (and perhaps other pages such as techniques). I have no idea how easy that would be, but I will raise an issue anyway.
>
>
>
> Steve
>
>
>
> -----Original Message-----
> From: Patrick H. Lauke >
> Sent: Friday, August 2, 2024 10:37 AM
> To: w3c-wai-ig@w3.org
> Subject: Re: Recent changes to the WCAG 2.2 SC 2.1.1 Understanding page
>
>
>
> Thanks Bryan, these are all useful and good observations.
>
>
>
> To the original point, these are all things that are not normatively required by the SC, and never have been. Many auditors have added these in the own interpretation or what 2.1.1 should say, and that these factors are all involved in deciding whether or not content passes or fails 2.1.1, even though this was not in the spec per se. Hence the recent additions to the understanding in 2.2 tried to clarify this, as it historically led to inconsistent audit results.
>
>
>
> P
>
> --
>
> Patrick H. Lauke
>
>
>
> * https://www.splintered.co.uk/
>
> * https://github.com/patrickhlauke
>
> * https://flickr.com/photos/redux/
>
> * https://mastodon.social/@patrick_h_lauke
>
>
>
>
>
>
[78c34616-443c-459d-9ca7-76909e62a141]