E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 11 (In chronological order)

From: Peter Quale
Date: Fri, Jan 10 2020 11:35AM
Subject: Instructions for Custom Keyboard Shortcuts
No previous message | Next message →

Wondering if anyone can help justify a requirement.

In my mind, if a web application requires a custom keyboard shortcut or has
non-standard keyboard interactions, instructions are required. I'm not
finding any WCAG success or failure examples that match what I'm looking
for.

I did find a Deque University
<https://dequeuniversity.com/checklists/web/device-independent-input> page
that claims this is covered by 3.3.2. Quote: "Custom Keystroke
Instructions: When custom keyboard behavior is required to use a component,
keyboard instructions MUST be provided."

Would anyone know where the Deque team finds this correlation with 3.3.2,
other than logic says so.

We're in one of those delightful situations where the developer won't budge
unless they read it themselves. So, short of hacking the W3C site and
adding my own success technique, I'm looking for official documentation.

Thanks so much for any assistance!

-Peter Q

--
*Peter Quale*
Google Voice: (707) 992-5696

From: Paul Rayius
Date: Fri, Jan 10 2020 12:41PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

Hi Peter,
WCAG 2.1 - 3.3.2 is actually dealing with Forms and not really addressing keyboard shortcut functionality.

This might be a stretch but Guideline 3.2 requires that "Webpages appear and operate in predictable ways." The "stretch" then, is applying this to keyboard shortcuts, requiring that they also operate in predictable ways. In other words, if you're using a keyboard shortcut for something other than what it's "universally known to do" then that could be considered unpredictable and, as such, providing clarification or instructions on what happens when someone uses that keyboard shortcut would be necessary.

Unfortunately, the answer to your question does not appear to be totally cut and dry, though.

I hope that helps at least a little. I'm interested to read what input others can provide!

Paul Rayius
Director of Training
CommonLook

From: John Foliot
Date: Fri, Jan 10 2020 3:14PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

As a senior member of the Deque Team...

Peter, the Understanding Document for SC 3.3.2 at:
https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html
states:

The intent of this Success Criterion is not to clutter the page with
unnecessary information but to provide important cues and instructions that
will benefit people with disabilities. ... The goal is to make certain
that enough
information is provided for the user to accomplish the task without undue
confusion or navigation.


Today the discoverability of custom key-board shortcuts (with or without
the use of @accesskey) is a serious concern - effectively, they cannot be
'discovered' by the user short of code-inspection. Failing to provide
information (instructions) related to using those shortcuts means the
important cues and sufficient information to "...benefit people with
disabilities." required by SC 3.3.2 cannot be discovered, and so those
users cannot subsequently accomplish the task (where, you could argue, the
task is to fire a custom key-stroke event).

Yes, this is interpretive from within Deque, and / but is based upon
internal discussion and the application of 'logic' (as you previously
note). Additionally, because we have multiple evaluators within our team,
it is (was) important that we internally all use the same interpretations
of WCAG across our team (and as you note, this appears to be a gap).

So... Deque's interpretation / recommendation is based on experience,
expertise and logic. HOWEVER it is "non-normative" per the W3C (i.e. not
official), and so it could just as easily be argued in court that our
interpretation is overly strict (if you wanted to). But to date, we've not
gone there, as whenever this comes up, most people understand the logic
argument you initially surfaced and agree with the assertion.

HTH

JF
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com

On Fri, Jan 10, 2020 at 12:35 PM Peter Quale < = EMAIL ADDRESS REMOVED = > wrote:

> Wondering if anyone can help justify a requirement.
>
> In my mind, if a web application requires a custom keyboard shortcut or has
> non-standard keyboard interactions, instructions are required. I'm not
> finding any WCAG success or failure examples that match what I'm looking
> for.
>
> I did find a Deque University
> <https://dequeuniversity.com/checklists/web/device-independent-input> page
> that claims this is covered by 3.3.2. Quote: "Custom Keystroke
> Instructions: When custom keyboard behavior is required to use a component,
> keyboard instructions MUST be provided."
>
> Would anyone know where the Deque team finds this correlation with 3.3.2,
> other than logic says so.
>
> We're in one of those delightful situations where the developer won't budge
> unless they read it themselves. So, short of hacking the W3C site and
> adding my own success technique, I'm looking for official documentation.
>
> Thanks so much for any assistance!
>
> -Peter Q
>
> --
> *Peter Quale*
> Google Voice: (707) 992-5696
> > > > >

<http://deque.com/>;

From: glen walker
Date: Fri, Jan 10 2020 4:33PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

John, thanks for pointing out that Deque's interpretation is
non-normative. That's an important point that is often overlooked.

In this scenario, if the *only* way to perform a certain action is via the
keyboard shortcut, then I'd say it's a failure of 3.3.2. The user has no
way to discover the shortcut.

However, if the same action can be accomplished via other means that are
accessible and discoverable, then not having instructions about the
keyboard shortcut might be more of a usability issue. If there's
documentation separate from the app itself (perhaps via a Help menu or
button) that explains the app's shortcut keys, I think that's sufficient.

From: Jonathan Avila
Date: Fri, Jan 10 2020 4:42PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

The closest related text (but not applicable text) to custom keyboard commands in WCAG is from 2.1.2 keyboard trap:
"and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away"

Jonathan

From: Bossley, Peter A.
Date: Fri, Jan 10 2020 10:33PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

This came up when we were having a similar discussion at my institution about top-level menu items with both sub menus and pages themselves. Where I landed with this is that if a widget requires non-expected keyboard interaction patterns (for whatever reason) the information about that shortcut had to be available programmatically associated with the first control of that type and also visually present for keyboard reliant users.

Perhaps a strict interpretation of WCAG 2.0 might be argued, but on the other hand we specifically adopt expected interaction patterns from Aria Authoring Practices in our technical standard for this very reason.

Just my .02.

From: glen walker
Date: Sat, Jan 11 2020 10:03AM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

WCAG is the "low bar", so to speak, of what we're trying to achieve.
Anything you can do to make the user experience better for everyone is
always a bonus.

On Fri, Jan 10, 2020 at 11:08 PM Bossley, Peter A. < = EMAIL ADDRESS REMOVED = >
wrote:

> This came up when we were having a similar discussion at my institution
> about top-level menu items with both sub menus and pages themselves. Where
> I landed with this is that if a widget requires non-expected keyboard
> interaction patterns (for whatever reason) the information about that
> shortcut had to be available programmatically associated with the first
> control of that type and also visually present for keyboard reliant users.
>
> Perhaps a strict interpretation of WCAG 2.0 might be argued, but on the
> other hand we specifically adopt expected interaction patterns from Aria
> Authoring Practices in our technical standard for this very reason.
>
> Just my .02.
>
>
>

From: Murphy, Sean
Date: Sun, Jan 12 2020 3:14PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

Peter,

There is another issue which I believe is outside the scope of WCAG. Shortcut keys that conflict with browsers shortcut keys and the OS keys. This is a consideration that all developers should take into consideration. Also consideration of screen readers that the shortcut key does not impact them as well or any other assistive technology.

Sean

From: Birkir R. Gunnarsson
Date: Sun, Jan 12 2020 3:33PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

There are two factors at play here
The key requirement is WCAG 2.1.1

"All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual
keystrokes..."
https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html

You can either comply with this by using standard controls and expect
keyboard users to know how to operate them (this is usually true,
though nobody knows how to select multiple non-contiguous options from
a combobox) or implement your own custom keyboard commands.
If you do the latter, you must notify the user about those commands,
how else is the user able to operate the content using the keyboard,

this is where 3.3.2 comes in.
In other words, in my opinion, 2.1.1 is a fail if your custom keyboard
shortcuts are not discoverable by the user (because in that case the
user can't operate the page using the keyboard).

For WCAG requirements regarding keyboard shortcuts and avoiding
conflict with operating system/assistive technologies, the WCAG 2.1
success criterion 2.1.4 comes fairly cloes:
https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html

The non-normative ARIA Authoring Practices Guide has a good section on this:
https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard

I have to admit that I find it downright astonishing that one of the
so-called accessibility vendors use a keyboard shortcut for their
custom overlay that conflicts directly with a Jaws keyboard shortcut.
To me that's a pretty instant "no deal".




On 1/12/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
> Peter,
>
> There is another issue which I believe is outside the scope of WCAG.
> Shortcut keys that conflict with browsers shortcut keys and the OS keys.
> This is a consideration that all developers should take into consideration.
> Also consideration of screen readers that the shortcut key does not impact
> them as well or any other assistive technology.
>
> Sean
>
>

From: Guy Hickling
Date: Mon, Jan 13 2020 4:47PM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | Next message →

> in my opinion, 2.1.1 is a fail if your custom keyboard
shortcuts are not discoverable by the user (because in that case the
user can't operate the page using the keyboard)

Birkir, I suppose I have never thought my way through this reasoning quite
as rigourously as you have. But I agree with your logic, and I have also
actually followed it in testing many times. When I'm testing some custom
component that someone's invented, I try the obvious keys (usually Enter
and spacebar). I then try the arrow keys, just in case. After that I don't
try anymore on the basis that, although the designers maybe have provided
some weird key combination to operate it, I don't want to find it. So far
as I'm concerned, if they haven't provided one of the obvious, commonly
used keypresses to do it, then it's a 2.1.1 fail and I don't want to be
stopped from reporting it as such just because I happen to stumble a
solution that no ordinary user is likely to think of.
If one day a client does push back saying "If you press CTRL Shift XYZ then
turn three somersaults it will work" I will simply reply saying I couldn't
find it and refer them to 3.3.2!

From: Tim Harshbarger
Date: Tue, Jan 14 2020 5:15AM
Subject: Re: Instructions for Custom Keyboard Shortcuts
← Previous message | No next message

Maybe there is a non-WCAG way to look at this issue.

There is a user interface rule that is rarely stated, but frequently
enforce. Unusable functionality is the same as absent functionality.

Can anyone think of a situation where a project team has implemented
required functionality in a manner that is unusable where the site owners or
business partners, who paid for the work, considered the requirement
successfully met? It is one of the reasons teams will run function tests so
they can avoid implementing an unusable feature.

I am trying to think of a good non-accessibility related example, but I
can't. That is because doing something like this would be unthinkable.

Perhaps the way to convince the developer is to explain there is one key
difference between unusable functionality and absent fucntionality.
Unusable fuctionality costs a lot more to do. If you have spent the effort
to take it this far, why not do just a little more work to ensure the
functionality is usable.

Thanks,
Tim
Tim Harshbarger
Senior Accessibility Consultant
Deque Systems