Re: 'access' attribute in XHTML 2.0

At 12:13 PM +0200 8/28/04, Anne van Kesteren wrote:
>>We might want to go so far as to define content markup (XHTML 2)
>>along the lines of [workalike syntax, not literal syntax proposal...]
>>
>><event>
>><label>Nex<key>t</key> message in Thread</label> ...
>></event>
>>
>>This would give a clear indication of which instance of the letter
>>'t' in the label content should (unless the stylesheet is overruled
>>in the client processing) be the one styled in a distinguished way to
>>convey the hotkey code to the visual user.
>
>Such a thing was suggested on the WHATWG mailing list as well. I 
>can't find the mail right now but it had i18n issues. Japanese or 
>Chinese characters are created by typing in multiple characters on 
>the keyboard iirc.

Thank you, Anne.

The overriding defense, here, is that the actual UI would not be
hard-wired to the nomination in the content. That provision is
required in order to enable downstream re-bindings necessary or
convenient for multimodal and disability delivery contexts. This
actually helps with the i18n issues.

But the i18n issues are not, given this outer author-proposes,
user-disposes protocol, a major problem in the end.

All interaction nominations by the author are guessing some delivery
context or another.

There is no global keyboard, and Kanji are just the extreme case.

The point is that if the author's initial version of the menu prompt
was in Kanji, then they would have a keyboard in mind and either use
Ruby to add a single-keystroke alternate that was the hotkey or
accept the typing burden but mnemonic advantages of using the Kanji
as the shortcut.

Also a writer in a Kanji-using langauge, but understanding that they
were dealing with a diversity of keyboards, might select the Kanji
character as the level of 'key' nomination (in the database sense)
and leave it to the User Agent to either allow multi-keystroke
shortcuts (likely in this context) or to provide a mapping of
yet-shorter-cuts to the Kanji 'keys' offered by the author.

The author would provide what they thought was a labor-saving way of
triggering this action, given some assumptions about the keyboard
implementation of that language, and the User Agent (including the
assistive technology, if loaded, if done right) would have the option
of providing the user with an alternate. A precedent for this is
available in the XForms Recommendation.

Reference:

find by string searching 'accesskey' in:
http://www.w3.org/TR/xforms/index-all.html

Not that making this nomination of "an index symbol mnemonically
linked to the label" is absolutely required to happen in the format
contributing the label text. The author could bind an input symbol in
a stylesheet and designate the first, second, or whatever intstance
of that text pattern in the label as what to highlight in the
rendered content using XPath-based selectors.

This could be viewed as more logically consistent, as the display
differences in that view actually coaching the user on the
views-layer shortcut binding, not the label itself. But one can't
entirely separate these two because the user's ability to recall the
hotkey will be improved by presenting the information about the
hotkey inline in the label.

On the other hand, one might be tempted to think that letting the
author do this inline would be more readily understood by the authors
and result in less broken style codes and less motivation to ignore
the "right way" and do something else.

We are left making judgement calls about how much separation
between content and presentation is supportable in actual practice.
For the moment I am inclined to say that having one label in one
language and one key in one keyboard (that is used for that language)
inline in the 'content' is not unreasonable, so long as the format
specification make it clear that use of a translated label or a
substitute UI-event (as required) is all part of the plan.

Al

>--
>  Anne van Kesteren
>  <http://annevankesteren.nl/>

Received on Sunday, 29 August 2004 16:21:20 UTC