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

hi I was going to stay out of this conversation but i find that i can't!
if the standard keyboard     commands are  used in a way that is not
standard it can reely  cause  havoc. For example in a  video player I have
found that the   aro keys have been hijacked to seek the  video. if you
are not a screen reader user you say so what. but the screen reader user
can  now not use the arrow keys to explore the player and find the play
pause or  other critical    controls on the  player. This is a real
example. I have seen that interaction in the wild and it was not at all
usable by me as the screen reader  user. In the end i had to  recamend that
anyone needing to view the  video be given a link to the video on youtube.
That was the only way to play the files without problems.

Now for the non   discoverable keyboard  commands here is another sinaryo
that i   encountered.
In most video  editing applications the standard keys are jkl for back
pause and forward. and of course ? is  how you should find the keys  but in
an app i am trying to    learn today  play pause is space and there is  no
keyboard for back or forword and the standered keyboard commands for
editing is i for the start of a segment and o for the end of the  segment
well the new app i  am learning does not have a start and end point marker
or at  least not one i can find.  so now when i try to do in the new app
that i can do in many other video editors i.e. remove a block from the
midal of the  video. i have to  select a clip that has the same name as
every other clip and then hope i am removing the write clip but i can't
select it with space becuase space starts playing the   video wair ever the
play head is and its not  nessasarily wair the clicp i need is. and space
can't be used to  activate buttons because its always  play    even when
there is nothing to play. this was a long rant to say it takes so much
more   efert to work around the non standered keys some  people will never
use your app. the only   reason i do is i am pay to test not use the tools
that take away my    known keys that    muscle  memory knows and keeps me
failing in the new apps. i know some dev says but its what i have been told
to  design well sory i hait apps that can't just work out of the box and i
will fail them every time for not working with standered interactions and
or changing my    muscle   memory. as the standereds we  depen on start
indacating that things can be changed like this the less i want to test for
compliing to a standered and the more i will just test for the   butifl
interaction that does not need hours of training and or screenreader
scripting to work. lucy


Berkeley IT <https://technology.berkeley.edu/home>

Lucy Greco, Web Accessibility Evangelist

Campus IT Experience
Phone: (510) 289-6008 | Email: lgreco@berkeley.edu |

We champion diversity. We act with integrity. We deliver. We innovate.



On Fri, Aug 2, 2024 at 11:03 PM Adam Cooper <cooperad@bigpond.com> wrote:

> Karen wrote:  lets just tell people we are w3c  compliant or Wcag
> compliant..<no one will know the difference anyway!>
>
> Unfortunately, it follows that many of its practitioners don't know
> either.
>
> -----Original Message-----
> From: Karen Lewellen <klewellen@shellworld.net>
> Sent: Saturday, August 3, 2024 5:30 AM
> To: Steve Green <steve.green@testpartners.co.uk>
> Cc: Juliette McShane Alexandria <mcshanejuliette@gmail.com>; bryan
> rasmussen <rasmussen.bryan@gmail.com>; 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
>
> 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 <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<mailto: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
> <mailto: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<mailto:steve.green@testpartners.co.uk>>
> 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<
> https://github.com/w3c/wcag/commits/main/understanding/20/keyboard.html>,
> 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<mailto:redux@splintered.co.uk>>
> > Sent: Friday, August 2, 2024 10:37 AM
> > To: w3c-wai-ig@w3.org<mailto: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
> >
> >
> >
> >
> >
> >
>
>
>