W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

Re: aria-action2036 aria-keyshortcuts

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Thu, 10 Mar 2016 01:02:18 +0100
To: "James Craig" <jcraig@apple.com>, "Richard Schwerdtfeger" <richschwer@gmail.com>
Cc: "Dominic Mazzoni" <dmazzoni@google.com>, "John Foliot" <john.foliot@deque.com>, "ARIA Working Group" <public-aria@w3.org>
Message-ID: <op.yd2014zrs7agh9@widsith.local>
On Thu, 10 Mar 2016 00:22:18 +0100, Richard Schwerdtfeger  
<richschwer@gmail.com> wrote:

> Thank you to you and the Apple i18n team for the feedback. I made  
> extensive to the the branch to reflect the feedback:
>
> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts
>
> I did not, yet, take into account comments from the list regarding  
> applying it to other roles yet as it is very hard to follow the spec.  
> (as to what supports what) until Shane makes changes to respec.
>
> I am sure there were be additional comments as i introduced more  
> normative text for authors.

Yep. Should I reply in response to this thread, on a separate email thread  
here, in the comments list, or somewhere else?

cheers

> Rich
>
>
>> On Mar 1, 2016, at 4:08 AM, James Craig <jcraig@apple.com> wrote:
>>
>>> On Feb 28, 2016, at 8:42 AM, Richard Schwerdtfeger  
>>> <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
>>>
>>> Here is a draft of the spec. with the changes:
>>> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts  
>>> <https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts>
>>
>> 1. Changelog reference to aria-kbdshortcuts is a broken link.
>>
>> 2. Examples list "Ctrl" (KeyboardEvent spec value is "Control".)
>>
>> 3. [From the Apple i18n team] It's recommended to avoid anything other  
>> than ASCII letters. Even numbers and common punctuation often require  
>> modifiers. For example, in French keyboard layouts, the number keys are  
>> not available until you hold the Control key, so a keyboard shortcut  
>> defined as "Control+2" would be ambiguous (This is just the way you  
>> type "2") or impossible to input (Control modifier may not be passed to  
>> the web application).
>>
>> As such this requirement may need to be reconsidered.
>>
>>> The valid names for non-modifier keys are any printable character such  
>>> as "A", "B", "1", "2", "$", "Plus" for a plus sign, "Space" for the  
>>> spacebar, or the names of any other non-modifier key specified in the  
>>> DOM Level 3 KeyboardEvent key Values  
>>> <http://www.w3.org/TR/DOM-Level-3-Events-key/> spec  
>>> [DOM-Level-3-Events-key  
>>> <https://rawgit.com/w3c/aria/action2036/aria/aria.html#bib-DOM-Level-3-Events-key>]  
>>> - for example, "Enter", "Tab", "ArrowRight", "PageDown", "Escape", or  
>>> "F1".
>>
>>
>> Next example:
>>
>>> When specifying an alphabetic key, both the uppercase and lowercase  
>>> variants are considered equivalent: "a" and "A" are the same, as are  
>>> "ü" and "Ü".
>>
>> In light of all the i18n warnings about this property, avoid the  
>> umlauts and accented characters altogether, as it shines a light on the  
>> problems. Worse, it makes it seem like the WG is unaware that the  
>> problems exists, making the group appear naïve or foolish.
>>
>> It's impossible to enter ü or Ü on most keyboards without a modifier (Ü  
>> is actually a set of two key shortcuts on Mac OS X "Option+u" for the  
>> umlaut, immediately followed by "Shift+u") so this requirement  
>> conflicts with the statement that immediately follows:
>>
>>> When specifying a key on the keyboard that changes when you hold down  
>>> a modifier key other than an alphabetic key, authors must specify the  
>>> unmodified key name.
>>
>> This requirement is flanked on both sides by examples that conflict  
>> with it. (See ü above and &quot; below.)
>>
>> The first clause is also hard to understand. I think "other than an  
>> alphabetic key" may be a misplaced modifier in this sentence, or if  
>> it's not, the sentence should be rewritten to avoid the ambiguity.
>>
>>> For example, on most U.S. English keyboards, the percent sign "%" can  
>>> be printed by pressing Shift+5. The correct way to specify this  
>>> shortcut is "Shift+5". It is incorrect to specify "%" or "Shift+%".  
>>> However, note that on some international keyboards the percent sign  
>>> may be an unmodified key, in which case "%" and "Shift+%" would be  
>>> correct on those keyboards.
>>
>>
>> Replace: s/printed/input/
>> Replace: s/would/could/
>>
>>> If the key that needs to be specified is illegal in the host language  
>>> or would cause a string to be terminated, authors must use the string  
>>> escaping sequence of the host language to specify it. For example, the  
>>> double-quote character can be encoded as "&quot;" in HTML.
>>
>>
>> This example also conflicts the previous requirement, because on a US  
>> English layout, the double quotation mark character should be specified  
>> as a shifted single quotation mark: "Shift+&#39;"
>>
>>> Adding the aria-keyshortcuts attribute to an element does not change  
>>> the behavior of the user agent by mapping the specified keyboard  
>>> shortcuts to the triggering of the element's activation function. It  
>>> is still up to the application to implement support for the keyboard  
>>> shortcuts.
>>
>>
>> These are non-requirements that should be rewritten as two RFC-2119  
>> statements: ~"User Agents MUST NOT change keyboard behavior…" and  
>> ~"Authors MUST handle scripted keyboard events…"
>>
>>> The aria-keyshortcuts attribute exposes the fact that these shortcuts  
>>> exist so that assistive technologies can communicate this information  
>>> to users.
>>
>>
>> It is not a "fact" that the shortcuts exist. They very well may not  
>> exist. Even rephrased, I don't think this sentence adds value. Consider  
>> dropping it.
>>
>>> Keyboard shortcuts are assumed to be global. If a button is present in  
>>> a document and it is visible and enabled, and it exposes a keyboard  
>>> shortcut, it is assumed that as long as the document has focus,  
>>> pressing that keyboard shortcut will activate that button. If the  
>>> button or other element is not currently available to be activated  
>>> normally, for example because it's currently invisible or hidden, or  
>>> explicitly marked as disabled, that implies that the keyboard shortcut  
>>> is unavailable too.
>>
>> • If this paragraph is intended to be non-normative, it should be  
>> wrapped in a Note.
>> • The second and third sentences are run-on sentences.
>> • The term "document" here is ambiguous or perhaps incorrect. Should  
>> this work in a containing frame's document? Perhaps this should be  
>> "window"?
>>
>> That's all I've got for now.
>> James
>>
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Thursday, 10 March 2016 00:03:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 March 2016 00:03:37 UTC