- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 1 Feb 2006 17:54:21 -0500
- To: w3c-wai-ua@w3.org
<note class="coordination DRAFT coverMemo"> on the WAI CG call today, I offered a fresh summary of requirements as a draft of what I could take to the Hypertext CG for Friday. Jim has offered that you might discuss this on your call tomorrow. Here's a version for tomorrows review. Al PS: for reference, the last time we went around on this was at: http://lists.w3.org/Archives/Public/w3c-wai-ua/2005JulSep/0005 </note> <draft> Topic: accessibility requirement for shortcuts a.k.a. ACCESSKEYs * Background: the Hypertext CG asked the WAI for some use cases. the HTML WG asked if WAI would authenticate that there is a requirement for ACCESSKEYs (or for access keys, along the lines of the XHTML 2.0 draft, give or take). * Summary and Requirements: The answer is roughly "in part." Yes, the WAI believes that formats should support shortcuts and that these have to be activatable from the keyboard. On the other hand, it is debatable (there are substantive arguments for and against) as to whether the authors should be afforded a means to set what key should be used to activate these shortcuts). + Firm requirements: - content [allowing for implicit in role] MUST have [machine identifiable functional equivalent of] labels for shortcut action/outcome compare with WCAG2: http://www.w3.org/WAI/GL/WCAG20/guidelines.html#understandable compare with UAAG1: http://www.w3.org/TR/UAAG10/guidelines.html#tech-ui-text-eq compare with UAAG1: http://www.w3.org/TR/UAAG10/guidelines.html#tech-info-current-author-config - User Agents MUST afford shortcut activation somehow (work around key collisions) compare with UAAG1: http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handlers - User Agent SHOULD let user pick key bindings as much as possible. compare with UAAG1: http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-input + Debatable issue: ? content+UserAgent MAY let author suggest mnemonic keys for shortcut activation * Use cases + case 0 user: Temporarily Able Bodied method of use: -- mix of recall and recognition; user may recognize hotkey styling in page or may recall hotkey for repetitively-used function. recalled function may be a web idiom like 'home' or an application-specific notion such as 'previous in thread' or "I'm feeling lucky." -- mix of focus and activate-immediate responses (emulates mouse click). Checkbox toggles; text box focuses only. http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JanMar/0012.html + case 1 user: has Repetitive Stress Injury, must avoid mouse use, full vision method of use: -- visual review of page; -- detects short-cut items by styling, -- decides to activate by reviewing [action label-equivlent] in scene; -- activates keycode; -- desires activate-immediate system response -- Note: this user derives added value from author-defined, application-unique shortcuts, over and above web-generic concepts that can be bound by role. + case 1A user: single-switch or bio-feedback as per case 1, but it gets more important to afford the activate-immediate behavior + case 2 user: blind; using screen reader method of use: -- AT pushes page summary on load -- page summary contains alert that the page offers shortcuts -- review of shortcuts at this point is a pull option; requires overt user request -- memorizes mapping of hotkeys to concepts -- activates hotkeys by recall, primarily -- can live with always-focus behavior; full keyboard agility, can use <MODIFIER-key><ENTER> as key sequence when wants activate-immediate response -- response may yet better be profiled so that accelerators bound to standard role values that are known to have unique outcomes (home, logout) may behave as activate-immediate while others focus only and require the user to make another action to activate anything. -- note: this user is critically dependent on having something that functions as a usable label for the shortcut action available in a machine-recognizable way. Need the functional equivalent of API resources to synthesize a context-menu entry. -- in terms of author uptake, there is a risk that if the author can define "what does it" and can get by without adequate labeling of "what it does" that most shortcuts will be so under-described. -- Note: for this user, the author's nomination is of little benefit, aside for use in existing browsers that haven't implemented a new design. Keys are much more plentiful in the screen reader case, but so heavily used as to still be quite scarce and the usable binding is one worked out in the client context. * Pro and con on debatable issue: Q: Should author be able to irrevocably bind keys to accelerators? A: No (i18n, OMA, WAI). Doesn't work across keyboards, OS, browser, etc. Q: Should author be able to nominate keys so long as user agent will repair non-available? A: Maybe. Consider: Pro: makes shortcuts available for application-specific actions. Makes shortcut-creation more appealing to look-and-feel-obsessed author/designers. Con: Confusing when keys have to be reprogrammed and page elsewhere assumes original key, e.g. Con: hard to feed back actual key into styling of label. Con: Lacking ironclad enforcement of label-euqivalent for "what it does," can't allow field option to only specify "what does it." </draft>
Received on Wednesday, 1 February 2006 22:54:28 UTC