W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Issue #69: Character key commands

From: David MacDonald <david100@sympatico.ca>
Date: Tue, 16 May 2017 09:41:35 -0400
Message-ID: <CAAdDpDbPpYOT6AG1vOXkEhx1NijXGsamtDsTPp6B3WA_MEJA9Q@mail.gmail.com>
To: John Foliot <john.foliot@deque.com>
Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
@ 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?

David MacDonald

*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902



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

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
Received on Tuesday, 16 May 2017 13:42:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC