Re: Issue #69: Character key commands

@ John
I added "single printable Unicode code point" to definition of Character key

@Gregg Lowney

>(1) We're supposed to use the term "content" rather than "web page".

Actually, WCAG 2 doesn't use "content" in SCs. It uses Web Pages. It's a
long story but for good reason.

- I've added "one or more" character keys,
- switched non-printing key with non-character key for consistency.


>  *I see no reason to limit this SC to keyboard shortcuts* implemented by
content rather than have it apply more broadly to all keyboard commands
implemented by content.

I'm not seeing the advantage of the wording here. I think of any keyboard
command implemented by the content as a keyboard shortcut. Can you point me
to a definition somewhere that necessitates this distinction between
keyboard command and keyboard shortcut?




Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, May 16, 2017 at 8:20 AM, John Foliot <john.foliot@deque.com> wrote:

> Greg wrote:
>
> > We should standardize on either "character key" or "printing key"
> rather than mixing the two terms in the same to mean the same thing. While
> "printing key" is the one I'm more used to seeing in the past, I think
> "character key" is more intuitive to readers unfamiliar with the concept.
>
> However, as I pointed out recently, even the terms "printing key" and/or
> "character key" have some issues elsewhere at the W3C, specifically around
> internationalization.
>
> "For example, on the Hindi INSCRIPT keyboard layout on Windows the TRA
> key (on number 6) when pressed generates the following Unicode code point
> sequence: U+0924 (TA) + U+094D (Virama) + U+0930 (RA).
>
> We suggest the following wording:
>
> If specified, the value must consist of a string representing an available
> keystroke. For most languages, this will be a single printable Unicode code
> point."
>      (source: https://github.com/w3c/html/issues/485)
>
> ​At a minimum, our Technical standard should align with other W3C
> publications, and while I can live with continued colloquial use​ of either "printing
> key" and/or "character key", I will request that we also include a
> definition in our glossary that reflects the fact that what we mean is "single
> printable Unicode code point.".
>
> Thanks.
>
> JF
>
>
> On Tue, May 16, 2017 at 2:48 AM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 16/05/2017 06:45, Gregg C Vanderheiden wrote:
>> [...]
>>
>>> But I can’t think of the disadvantage.
>>>
>>> can someone help me here?
>>>
>>> [...]
>>
>>>   * it prevents the user from using the ‘e’ key for anything else — but
>>>     (since this only happens if they have focus on the page — and there
>>>     is nothing that the ‘e’ key can do on the page when not in edit mode
>>>     — I’m missing the problem.
>>>
>>
>> I have made this particular point many times before as well...these
>> single-key commands would only trigger accidentally in situations where the
>> user is not on a control/element that is editable. However, it seems that
>> the main concern is accidental unintended triggering (e.g. by overeager
>> speech recognition, or by unintentionally hitting a key on the keyboard).
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>