Access Key replacement option: custom keys by XML Events.

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