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

The reason I am alarmed is there appears to be a surprising gap here.
Unusual and non-discoverable keys could be chosen, passing 2.1.1, but
practically there would be no way for an accessible user to benefit from
said hidden keyboard functionality.

I can't see anything that would require a developer to notify the user of
unusual keyboard input, except possibly for data input under 2.4.6, but
that is questionable.

Yet under 4.1.2, we have a normative requirement for name, role, value to
be additional described if non-standard controls are created.

"If ... interface elements are programmed ... to have a different role
and/or function than usual, then additional measures need to be taken to
ensure that the controls provide important information to assistive
technologies and allow themselves to be controlled by assistive
technologies."

Perhaps non-discoverable and non-pattern keyboard interfaces should also
require additional measures?


On Friday, August 2, 2024, Juliette McShane Alexandria <
mcshanejuliette@gmail.com> wrote:
>> It is a little alarming if the standard controls not being implemented
would pass - e.g. not using arrow keys to navigate listboxes.
> The APG is not normative, nor are the ARIA documents themselves. The
keyboard patterns provided are therefor not normative requirements, only
suggestions for 'good' ways to implement the functionality.
> The requirements within ARIA documentation should not be taken as
requirements to pass WCAG. They can be used to meet WCAG, just like
sufficient techniques can be, but in many cases they are not required.
>
> On 8/2/2024 11:43:38 AM, Michael Livesey <mike.j.livesey@gmail.com> wrote:
>
> On the WAI patterns page, there are a whole host of optional keyboard
inputs for various controls.
>
> https://www.w3.org/WAI/ARIA/apg/patterns/
>
> We sometimes implement the optional controls, sometimes not.
>
> It is a little alarming if the standard controls not being implemented
would pass - e.g. not using arrow keys to navigate listboxes.
>
> Having said that, a widely used integration, AG Grid, breaks the grid
pattern by moving focus to every cell on tab by default, which is a
nightmare for disabled users navigate past.
>
>
> On Friday, August 2, 2024, Steve Green <steve.green@testpartners.co.uk>
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 <mcshanejuliette@gmail.com>
>> Sent: Friday, August 2, 2024 6:07 PM
>> To: bryan rasmussen <rasmussen.bryan@gmail.com>; Steve Green <
steve.green@testpartners.co.uk>
>> Cc: Patrick H. Lauke <redux@splintered.co.uk>; 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 <
mcshanejuliette@gmail.com> 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 <rasmussen.bryan@gmail.com>
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 <
steve.green@testpartners.co.uk> wrote:
>>
>> Thanks to everyone for all the responses. They raise a couple of
questions, though:
>>
>>
>>
>> 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.
>>
>>
>>
>> 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 <redux@splintered.co.uk>
>> 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
>>
>>
>>
>>
>>
>> <
https://ci3.googleusercontent.com/meips/ADKq_NYAQaKtNaxY1A8WFT9wxvwQpnI4--EuRohelVFIBlLPzaVHk30imSxNVf1VD3O7FlglWXo3katpQwziwN11hQam1X_WiEHqiAzdGDP6m1BApzyx-54y-iUatsQS84x_0RB-ouAs_5aXI88PTp08bJvTu74rDT4QTEefnT1TInW6iKKwL61REUmeSl96A6-ke3gqWWva2Zf_paZ4lAkk2KuA2MCjrrBVuF2jAo1fcFuVfaVeOp9sZ3erZHWtHLO5W9igonvTSH95ALpWQ5RbI0LWtcu68mvri7ib1QT4PuzMYMRplD2eQPl3W8FxdFef-wGh3cwkkSxbt3AU3VAjLDlSmfD2W1D1FdiM7RoNZIE4Sykz6WxO9TzscSlHoNXImgVQhxx7EkNGOFiNBoKf2zG6bh0o0qF5624-ukg8o9wHVWnXZ8cS6_HDUXO8pjIhiDfXr_8_O9E=s0-d-e1-ft#https://tracking.getmailbird.com/OpenTrackingPixel/?messageId=Mailbird-2002a8f2-7127-4bee-a7fe-bea6f3747966@gmail.com&senderHash=2DB0E4908157CA5D6C96F6C2D4B878796FB4B77AD6F800A29FA96C2443A5CE7E&recipientHash=D2CE67354614607B4773BCB5DF4F26F5DCAB5F24E04B2D728B1EDA0E81FB186F&internalId=c6974763-6a2a-4966-8af3-f48bbf2de77b
>
>
> <
https://ci3.googleusercontent.com/meips/ADKq_NaafsIMGvA5AKg8UhGL0fIokiR6Q0S67vkUnkQTU80CdWhoEVR1dZ9n84Yjj6xn7iu6ln53J-uhGN3WiRh4xNf_Gq7eVERbyHd566PeZyIx6fO90PLdK-6mautgEJ9HsjWGvj01S5IEMM4TSetfUo1WaM_8SpDLfpa8YmyOtGHuOlgY1GhQ4xr3Hx00vjSsgAy_7pO04jZQLt1bYlVnYUg9kmWwF4soZpOzMdJ52CWwfTyXXFJLr7_2zXB-wmCWGVaa4GJ0oK-KP3POa-8PLqfFP3scNt9ph9U4khF2MpWYHtnZX4XCY7UhKI-VYXZ7u2hpONWhcyiK6sKrM5wL2NBbtFVUe1sUu3_ggchZYqj8U29hHUQnrEyKwLZFQF-CCF-aWlV_bBY53yO9UdRXwG67bKyKP2ltXT1njrHeFvk5X8LvMxvPCzduyeQ0y1Z0dPG-ibgpNhQ=s0-d-e1-ft#https://tracking.getmailbird.com/OpenTrackingPixel/?messageId=Mailbird-51bc639f-e0c9-400c-8dfe-1df8a7430fa0@gmail.com&senderHash=2DB0E4908157CA5D6C96F6C2D4B878796FB4B77AD6F800A29FA96C2443A5CE7E&recipientHash=CF9AD1BA7348984ACA2D531C08FEC369434BF667995F38FC6FE096E2AC5355A3&internalId=233a0f23-8cc6-4e96-a67a-ea1ce19233f7>