Re: Issue #69: Character key commands

Fair enough... have updated to "content".

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 9:59 AM, Gregg C Vanderheiden <greggvan@umd.edu>
wrote:

> To make it a bit clearer
>
> We use both *content* and *web page* in the SC.      We use Web page when
> talking about the unit.   We use content to refer to what is in a web page.
>
> Conformance is all based on the Web Page.       All content on a page does
> not need to conform — but all the information and function in a page must
> conform.  (there can be accessible and inaccessible versions of content on
> the same page - for example a picture of a complex diagram in one place
> (with simple alt text)  and a text description of the same information in
> another)
>
>
> *g*
>
> Gregg C Vanderheiden
> greggvan@umd.edu
>
>
>
>
> On May 16, 2017, at 9:41 AM, David MacDonald <david100@sympatico.ca>
> wrote:
>
> @ 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 <(613)%20235-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
>>
>
>
>