- 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>
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 " 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 """ 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+'" >> >>> 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