- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 9 Aug 2004 15:51:41 -0400
- To: wai-xtech@w3.org
- Cc: em@w3.org, Tim Boland <frederick.boland@nist.gov>, "'Becky Gibson'" <gibsonb@us.ibm.com>
The current description of an 'access' attribute that is in the XHTML 2.0 Public Working Draft is too much like 'accesskey' in HTML4 to be left as it is. http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_access Here is another way that the capability to define custom keys, guaranteed to be re-bindable to alternative input events, and protected from hazardous outcomes, could be realized using some of the new features in XHTML 2.0. The functionality of the old 'accesskey' in HTML4 can be recognized as being: a) define an event b) bind it to an outcome (method with respect to the document object) c) bind it to a trigger event (in the UI) There are at least two problems with the way that this is defined at present: 1) the system response has not been consistent across browsers. Some focus only, some focus and activate. 2) either of these system responses is bad for some group of users with disabilities. Immediately activating an element is risky for those, screen reader users included, who cannot be expected to have reviewed the display of this element before the hotkey activates it. On the other hand, failing to activate on user input of the hotkey is bad for those with Repetitive Stress Injury or other conditions leading to a high cost per input symbol (UI event). Forcing a confirm for these users is worth seeking to avoid. One of the applications of custom keys that is of interest is jumping to key part of a web page. This could be the top of the page, the "start of main content" the search tool or other points of interest that are either the leading sub-destinations within this page or the instance in this page of a systematic service that will be memorable by the user because it is used throughout the site. The approach described here favors custom keys defined by the developer of a web application spanning multiple pages. The XHTML 2.0 draft has provisions for authors to declare events http://www.w3.org/TR/xhtml2/mod-xml-events.html#s_xml-eventsmodule One approach to re-engineering ACCESSKEY would be to tell them is that we need to move the ACCESSKEY behavior into the standard event-processing framework that they have established by adopting the XForms and XML Events modules. Custom keys could be author-declared events. Metadata associated with the event declaration could give concept backup and outcome hazard warnings. Or the browser could just provide safety-first modes for known hazardous outcomes and not rely on the metadata describing the handler. There are several kinds of hazards that we want to guard against. - user doesn't understand what the hotkey will do for them, fails to take advantage of it [two cases: site author too cute in naming, user with text-reading-related difficulty needs symbol or icon representing idea to recognize the sense of the opportunity.] - user activates hotkey and system response does something that they didn't anticipate and have trouble recovering from. The hazards already clearly identified in the UAAG 1.0 include: http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui - system launches a new browser window [may break back key, certainly complicates mental burden of eyes-free user.] - system loads an new page in current browser window [refresh configuration requirement, for example] - system submits a form containing information collected from the user and potentially committing the user to something To this we probably need to add - system changes the value of a form control before user has chance to review prior value. [consider checkbox example, edit box with hint in initial value...] The dynamic condition for when to suppress the 'activate' when a hotkey handler attempts to focus and immediately activate could be stated as "configure so that an activate must be confirmed unless the element already had focus when the *user event* causing the activation occurred. In this way a full-view user could have the hotkey for a checkbox toggle the checkbox, but an eyes-free user could have the same hotkey focus the checkbox and announce its state and label rather than changing the state first. But all of these hazard avoidances can be specified, and perhaps should be specified, by embedding [some mild superset of] the UAAG requirements in the format specification. That is particularly true because while there may be script langauge to open a new window, or to change the state of a checkbox, the actual opening of the new process is controlled by the browser's interface with the operating system, and the state of the form field is something else that the browser manages and can guard. So much for the failure mode in which the hotkey does something that the user couldn't anticipate, and can regret. On to the non-recognition hazard. If the hotkey is linked to too generic a concept, such as a predefined standard value of the 'access' attribute, then users may not recognize that this concept is referring to the particular content and functionality afforded by the destination part of the actual page at the actual site. A more specific mnemonic clue would make the outcome of activating this hotkey more apparent more readily to those who encounter it for the first time. Then again, if the site author gets too cute with their proprietary 'friendly names' it may not be possible for a cognitive-assitive agent to grasp the intended sense of the verb, and may not be able to generate a plain-language or symbol-language equivalent. Hotkey labels should be available in natural language text for use in context menus and other forms of orientation and help. On the other hand, these terms are not just natural language words that fly by in the rush of prose. The author can reasonably be expected that these terms are special terms that deserve special attention. Roughly on a par with terms that get put in a glossary. So the techniques to look at here are the terms where the author is expected to give a high quality of semantic backup, not just the commodity level of backup asked for with regard to all words in a text. A candidate technique here is to ask the author to compare and contrast the sense they mean by their hotkey with some reference vocabulary that will be easy for a cognitive-assistive tool to base translations on. The verbs identified in 5.2 "Common Commands" in the ETSI standard ES 202 076 "Human Factors (HF); User Interfaces; Generic spoken command vocabulary for ICT devices and services" are a good example to seed the thesaurus with. If a hotkey has an articulable relationship to one of these this should be recognizable from the way the novel concepts are linked into the thesaurus web or concept net. This specification provides a public-standard point of reference for the standard Web concepts of 'help,' 'home [~main menu]' etc. There is at least one more we would want to add which would be the last-page' notion as used in the cognitive-adaptive web style described at http://www.learningdisabilities.org.uk/html/content/webdesign.cfm . I am sure that there are others. But it wouldn't take may such references to give us a good machinable grounding in common general-purpose notions by which to get a general idea of what a custom key is like. Standard verbs for jumping to standard web page parts could then be implemented by someone outside XHTML declaring a family of such events. An XHTML 2.0 instance could then import those events by namespacing. Some default handler for custom events should probably be defined as part of the same publication that creates their namespaced names. This could be done in ECMASCRIPT as a reference implementation. That is because we haven't got XML Handlers in our toolkit yet and we can use ECMASCRIPT handlers as defining a workalike class just as we use a reference CSS stylesheet to define a lookalike class. I call the defined behavior the default behavior because the UAAG requires us to have some adaptation to the delivery context in this behavior. That was discussed above as averting un-expected system responses. The above addresses XHTML 2.0 where we can introduce new events with declarations in XML. We still need a solution for HTML4 and earlier flavors of XHTML. So one of our questions to address to our Semantic Web experts is: "Can we, in the Semantic Web, express assertions on the order of 'the sense of shortcut X [html4:any.accesskey='X'] as used in document-scope Y is (thesaurus assertions)'?" Al
Received on Monday, 9 August 2004 19:52:14 UTC