Re: aria-action2036 aria-keyshortcuts

On Thu, 10 Mar 2016 00:22:18 +0100, Richard Schwerdtfeger  
<> wrote:

> Thank you to you and the Apple i18n team for the feedback. I made  
> extensive to the the branch to reflect the feedback:
> 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?


> Rich
>> On Mar 1, 2016, at 4:08 AM, James Craig <> wrote:
>>> On Feb 28, 2016, at 8:42 AM, Richard Schwerdtfeger  
>>> < <>> wrote:
>>> Here is a draft of the spec. with the changes:
>>> <>
>> 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  
>>> <> spec  
>>> [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 - - - Find more at

Received on Thursday, 10 March 2016 00:03:36 UTC