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

Many CRM platforms use proprietary and unconventional keystrokes for performing operations that would otherwise be ‘standard’ like pressing F4 to expand a dropdown in SAP … 

 

the highly questionable assumption being that either people will trawl through their help pages or undergo intensive training and thereby come to know these keystrokes by osmosis.

 

But then, all CRM user interfaces are notoriously badly designed and poorly coded garbage so being unusable is par for the course, I guess.

 

 

From: bryan rasmussen <rasmussen.bryan@gmail.com> 
Sent: Saturday, August 3, 2024 2:22 AM
To: 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

 

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.

 

2. 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://www.splintered.co.uk/

*  <https://github.com/patrickhlauke> https://github.com/patrickhlauke

*  <https://flickr.com/photos/redux/> https://flickr.com/photos/redux/

*  <https://mastodon.social/@patrick_h_lauke> https://mastodon.social/@patrick_h_lauke