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

I guess I'd say there are a few standard keyboard interactions in the
vernacular usage of standard as being something expected or normally
encountered, as opposed to standardized, such as being able to press the
space or enter key on things that have the role button or link, and being
able to press the escape key to close things like modals etc. or as you say

>"de-facto"/"best practice"/"most browsers seem to do it this way"

discoverable to me where keyboard interactions are concerned are as
follows:

Things that have functionality that can be called via shortcut key press
should have
1. title text telling you shortcut for future reference
2. screenreader info about shortcut for future reference.

If you have shortcuts you should probably also have some sort of area on
page that you can read as to what the shortcuts are.

Elements that have functionality that can be called by keypress while
focused on that element or within a parent element (a local shortcut)
should follow these principles -

a single key should cause the action
that single key should be indicated in the design with an underline of the
letter in some element.
title or alt text should inform what the shortcut does.
Coming into the parent element should announce for screen readers - there
are local shortcuts here, press H now to hear them.

I've only worked on two projects that did this. It was a pain, but I also
felt like things worked really well, and I liked the ease with which I
could navigate through things with all the shortcuts.



On Fri, Aug 2, 2024 at 11:00 AM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> Just picking up on the first two points:
>
> On 02/08/2024 04:49, Steve Green wrote:
> > Completely by accident, I recently found that the WCAG 2.2 SC 2.1.1
> > Understanding page was modified on 04 July 2024. Two notes have been
> > added, stating that the use of non-standard (and even non-discoverable)
> > keyboard interactions is not a non-conformance. The page did not
> > previously mention non-standard interactions at all, and it raises a
> > number of issues and questions:
> >
> >  1. This is one of the original WCAG 2.0 success criteria from 2008. The
> >     new notes reverse the interpretation that we have applied for the
> >     last 16 years. I have never heard of anyone interpreting the SC the
> >     way we now have to.
>
> Interestingly, in my last three jobs doing audits, we have always
> interpreted it exactly the way it is now, exactly because the normative
> language of the SC even back in 2008 never said anything about the
> keyboard interactions needing to be "standard" (especially because there
> IS no "standard" anywhere, nothing normative anyway ... maybe
> "de-facto"/"best practice"/"most browsers seem to do it this way" but
> nothing else), or "discoverable" (however that may be defined). So folks
> have been imagining these extra requirements that aren't actually in the
> normative requirement on their own, with no actual basis in either the
> normative wording of the SC, nor the understanding document or any
> related techniques.
>
> So this addition not so much reverses the interpretation, but clarifies
> that that interpretation was never intended in the first place.
>
>
> >  2. Was this change discussed anywhere? On GitHub, the most recent
> >     discussion I could find petered out in 2021 without a conclusion.
>
> These changes are discussed in AGWG meetings, generally as part of the
> WCAG 2.x backlog task force's work.
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
>
>