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

Re: Issue #69: Character key commands

From: Gregg C Vanderheiden <greggvan@umd.edu>
Date: Tue, 16 May 2017 09:59:54 -0400
Message-Id: <2BAEE613-CD77-440E-B09B-1821E6B267C1@umd.edu>
Cc: John Foliot <john.foliot@deque.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
To: David MacDonald <david100@sympatico.ca>
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
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://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 <mailto: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 <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 <mailto: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 <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion
> 


Received on Tuesday, 16 May 2017 14:00:29 UTC

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