Re: side conversation on 386, 659, and 660, 669, and 688 on Character Key Shortcuts

Shift creates confusion. One can make a pretty good argument that an 
author who is failing this with "b" can now do Shift+b and pass. But 
Shift+b is equivalent to B, which we also don't want to allow as a 
single-character shortcut. It just becomes a bit wierder with the new 
language about "upper- and lower-case letters". I consider that a side 
issue though, so let me focus on the larger consideration.

Previously, this was the basic logic flow of this SC:
using one or more character keys alone as a shortcut?
if yes, does it only work when component for which it is intended has 
focus?
If yes, fine.
If no, also use a modifier, or turn it off.
If no, fine.

Now we have:
Using letter, punctuation, number or symbol characters alone as a 
shortcut?
if yes, does it only work when component for which it is intended has 
focus?
If yes, fine.
If no, use a modifier, or turn it off, or make the shortcut be Enter or 
Spacebar.
If no, fine.


The other change is that "printable character" was previously defined:
> single printable Unicode code point, any keyboard character that is 
printable, i.e. letters of the alphabet including capitals, punctuation, 
numbers, and symbols
> Note that the Space and Enter keys, which return empty spaces rather 
than characters, are not character keys.

So  Space and Enter keys were previously explicitly excluded  from 
consideration in the definition. That was the only mention of them. If you 
used Spacebar or Enter as a shortcut, the SC didn't apply.
The same exclusion happens now, since they are do not meet any of the 
criteria in the list, but it isn't explicit. But now they are also being 
called out as a new sanctioned way to overcome the problem. So now the 
direction is: "in any cirucumstance, make the shortcut into Enter or 
Spacebar and you pass!"

I think that is problematic. If you want to have an explicit mention of 
Spacebar and Enter, they should be at the end in a note as an exclusion, 
not dumped into the second bullet. For instance, it could read "Note that 
Space and Enter keys are not considered letter, punctuation, number or 
symbol characters."

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Andrew Kirkpatrick <akirkpat@adobe.com>
To:     Michael Gower <michael.gower@ca.ibm.com>
Cc:     James Nurthen <james.nurthen@oracle.com>, WCAG <w3c-wai-gl@w3.org>
Date:   2018-01-17 11:13 AM
Subject:        Re: side conversation on 386, 659, and 660, 669, and 688 
on Character    Key Shortcuts



Why is adding “shift” bad? With the current language shift would certainly 
count as a non-character key, so it would be ok for a mechanism to allow a 
shortcut “b” to become “shift+b” – this would solve the core issue that 
the single key shortcut created.  That said, I don’t mind removing shift 
from being explicitly mentioned.
 
James has indicated a concern about space that would necessitate leaving 
it (and I should say that we have a product that currently uses space in a 
combination shortcut) and enter is a concern as a developer who needs to 
implement default form submission in a custom form would likely need to 
use it.
 
Can you explain what is different in the SC now as opposed to when we 
referenced “character key” in the glossary and defined it as any printable 
key, not counting space or enter?
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk

 
From: Michael Gower <michael.gower@ca.ibm.com>
Date: Wednesday, January 17, 2018 at 13:59
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: James Nurthen <james.nurthen@oracle.com>, WCAG <w3c-wai-gl@w3.org>
Subject: Re: side conversation on 386, 659, and 660, 669, and 688 on 
Character Key Shortcuts
 
I believe Kathy was the primary initiator of this SC, so I would encourage 
her to be consulted. BTW, I also find the inclusion of "Shift" in the 
wording now problematic, since arguably, a user could meet it with 
SHIFT+letter. So I have removed it and the etc, and would recommend 
including clarification about modifiers in the understanding document.

To restate, I am requesting a change for the second Remap bullet, to 
become:
"A mechanism is available to remap the shortcut to include one or more 
non-printable keyboard characters (e.g., Ctrl, Alt)"
The current proposal reads like this:

If a keyboard shortcut is implemented in content using only letter 
(including upper- and lower-case letters), punctuation, number, or symbol 
characters, then at least one of the following is true unless the keyboard 
shortcut for a user interface component is only active when that component 
has focus: 
Turn off
A mechanismis available to turn the shortcut off;
Remap
A mechanism is available to remap the shortcut to use one or more 
non-printable keyboard characters (e.g. Ctrl, Alt, Shift, etc.) or the 
Space or Enter keys.


Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Andrew Kirkpatrick <akirkpat@adobe.com>
To:        Michael Gower <michael.gower@ca.ibm.com>
Cc:        James Nurthen <james.nurthen@oracle.com>, WCAG 
<w3c-wai-gl@w3.org>
Date:        2018-01-17 10:20 AM
Subject:        side conversation on 386, 659, and 660, 669, and 688 on 
Character   Key Shortcuts

 
Mike,
Who needs to discuss it? We have about 4 hours.
 
James, any thoughts?
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk

 
From: Michael Gower <michael.gower@ca.ibm.com>
Date: Wednesday, January 17, 2018 at 13:17
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: James Nurthen <james.nurthen@oracle.com>, WCAG <w3c-wai-gl@w3.org>
Subject: Re: CFC - Response to issues 386, 659, and 660, 669, and 688 on 
Character Key Shortcuts
 
-1 
Andrew, I would really like to get some more folks looking at this, 
because I do not read it that way. It seems far from clear, and could lead 
to some unfortunate implementations.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Andrew Kirkpatrick <akirkpat@adobe.com>
To:        Michael Gower <michael.gower@ca.ibm.com>, James Nurthen 
<james.nurthen@oracle.com>
Cc:        WCAG <w3c-wai-gl@w3.org>
Date:        2018-01-15 01:11 PM
Subject:        Re: CFC - Response to issues 386, 659, and 660, 669, and 
688 on Character  Key Shortcuts

 
Mike,
I don’t think that this is any different now.
 
Originally, the SC said:
If keyboard uses only character keys (doesn’t include space and enter) 
then a mechanism  to turn off the shortcut must exist or they need to be 
able to remap the shortcut to use at least one “non-character key” (keys 
that don’t count as character keys, including space and enter). 
 
Now it says the same thing, I believe.
 
Authors might include space and enter – e.g. a mail application might use 
alt+enter to send a message, or space in a similar way. They are unlikely 
to use space or enter entirely independently.
 
Enter could be used to trigger a default button in a custom form, so that 
one should probably stay. Space was mentioned by James Nurthen, but I’m 
not sure what the use case is – it seems to be more applicable when a 
control is focused.
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk

 
From: Michael Gower <michael.gower@ca.ibm.com>
Date: Monday, January 15, 2018 at 14:56
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: CFC - Response to issues 386, 659, and 660, 669, and 688 on 
Character Key Shortcuts
 
I'm concerned with the rewording of Remap, both the addition of "or the 
Space or Enter keys" and the wording "to use". 
https://github.com/w3c/wcag21/pull/732/files

It is now proposed to read:

<dd>A mechanism is available to remap the shortcut to use one or more 
non-printable keyboard characters (e.g. Ctrl, Alt, Shift, etc.) or the 
Space or Enter keys.</dd> 

In the original wording, Space and Enter were excepted from counting as 
character keys. That has now been altered to state that authors can use 
Space and Enter to replace author-created shortcuts. However, Space and 
Enter tend to be assigned by the user agent for specific activations. We 
should not be encouraging their use for remapping purposes, especially 
without the use of a modifier key. This will potentially lead to exactly 
the same issues with Speech operation that the SC was attempting to 
overcome.

The concerns that were raised by the definition of character key seem to 
have been addressed by replacing 'character keys' with the phrase "using 
only letter (including upper- and lower-case letters), punctuation, 
number, or symbol characters ", which does not include Space or Enter. So 
it does not seem neccesary to later specify them in the remap definition. 
I would advocate that "or the Space or Enter keys" be removed.

As well, the rewording infers that justa modifier key can now be used. I 
think this can be overcome by changing "use" to "include". The resulting 
Remap's definition would read:

A mechanism is available to remap the shortcut to include use one or more 
non-printable keyboard characters (e.g. Ctrl, Alt, Shift, etc.).


Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Andrew Kirkpatrick <akirkpat@adobe.com>
To:        WCAG <w3c-wai-gl@w3.org>
Date:        2018-01-14 11:30 PM
Subject:        CFC - Response to issues 386, 659, and 660, 669, and 688 
on Character  Key Shortcuts

 
Call For Consensus — ends Wednesday January 17th at 2:30am Boston time.
 
The Working Group has discussed responses to the following issues:
386: What do 'character key' and 'printable' mean? (
https://github.com/w3c/wcag21/issues/386)
659: Ambiguous definition (https://github.com/w3c/wcag21/issues/659)
660: Characters (https://github.com/w3c/wcag21/issues/660)
669: SC 2.4.11 Character Key Shortcuts - Proposal for change of wording (
https://github.com/w3c/wcag21/issues/669)
688: Comment on 2.4.11 (https://github.com/w3c/wcag21/issues/688)
 
Response to Issue 386: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#386

Response to Issue 659: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#659

Response to Issue 660: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#660

Response to Issue 669: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#669

Response to Issue 688: 
https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues#688

 
The changes to the SC are implemented in this pull request: 
https://github.com/w3c/wcag21/pull/732

The changed SC can be viewed here: 
http://rawgit.com/w3c/wcag21/character_changes/guidelines/index.html#character-key-shortcuts

 
If you have concerns about this proposed consensus position that have not 
been discussed already and feel that those concerns result in you “not 
being able to live with” this decision, please let the group know before 
the CfC deadline.
 
Thanks,
AWK
 
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 
 
akirkpat@adobe.com
http://twitter.com/awkawk

 
 
 
 

Received on Wednesday, 17 January 2018 20:07:42 UTC