- From: Michael Gower <michael.gower@ca.ibm.com>
- Date: Wed, 17 Jan 2018 21:19:17 +0000
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: James Nurthen <james.nurthen@oracle.com>, WCAG <w3c-wai-gl@w3.org>
- Message-Id: <OFD1A54D4A.7D8F42F7-ON88258218.0074ED9B-88258218.00751EC8@notes.na.collabserv.c>
I prefer my suggestions to resolve, but I can live with your response rather than risk harpooning the SC. +1 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 12:46 PM Subject: Re: side conversation on 386, 659, and 660, 669, and 688 on Character Key Shortcuts The issue from multiple commenters was the definition (which was for “character key”). The definition was: “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”. Commenters said that we are trying to redefine a commonly used term in order to exclude printable keys like space. So, I tried to play with the definition and the SC just kept getting longer and longer, until I removed the definition and just used what the SC was requiring before: In the second half, we were using “non-character key” and interpreting that as the opposite of character key, and that was expanded out also. Since space and enter were excluded from being character keys, they are “non-character keys”. It is true that a keyboard shortcut “b” could be replaced by “enter” in the final exception, but I don’t think that is too likely to happen. The only people who are going to use enter (and probably space) are going to be very aware of what they are doing, and like James indicates are going to need to be in the clear to do so. The current last exception reads: 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. I’m happy to remove “shift” and maybe can clarify the final exception. A mechanism is available to remap the shortcut to use one or more of either non-printable keyboard characters (e.g. Ctrl, Alt, etc.) or the Space or Enter keys. Does any of this help? 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 15:07 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 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: 1. using one or more character keys alone as a shortcut? 1. if yes, does it only work when component for which it is intended has focus? 1. If yes, fine. 2. If no, also use a modifier, or turn it off. 2. If no, fine. Now we have: 1. Using letter, punctuation, number or symbol characters alone as a shortcut? 1. if yes, does it only work when component for which it is intended has focus? 1. If yes, fine. 2. If no, use a modifier, or turn it off, or make the shortcut be Enter or Spacebar. 2. 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 considerationin 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 shortcutis 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 componentis 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 21:19:50 UTC