RE: [XHTMLAccess] i18n comment 2: Keycode or character

All,

I composed this personal response a few days ago, but decided to wait for our call instead of sending it. However, I think it a useful compendium of my thoughts, so provide it as a starter for our discussion.

Addison
===

(personal response)

Hello Steven,

Thanks for your note back.

> 
> > I'm not sure I buy the reasoning given here. I agree that the
> name 'key'
> > might be too suggestive... except that the whole idea of the
> <access>
> > element is to provide accessibility via a keyboard-key sequence
> mapping.
> 
> That is not the idea at all.  The idea is to identify the access
> points. You'll note that the key attribute is  optional. There may not even
> be a keyboard.

You are correct. The point of the <access> element is as you state. I meant to say something like "the whole idea of the 'key' attribute..."

> 
> > I'm not sure that obscuring this by renaming the attribute is
> that
> > useful and personally I'm more concerned about what we say around
> the
> > element than with just the attribute name. Does XHTML-WG have a
> problem
> > with our suggested text?
> 
> Well, since it was predicated on keyboard keys producing characters,
> yes!


> We don't mind including text that gives hints about mapping
> keyboard-produced keys to access mappings, but we don't want people
> reading it thinking that we are talking principally about keyboards.

Okay, I understand. However, you are principally talking about linking the <access> element to a user action (spoken, typed, gestured, etc.). You've taken some care to try and separate this from keyboards per-se, but the attribute's type is "Character" and there is still talk about keyboards (such as the application of meta keys and such). To wit [1]:

--
The key attribute represents an abstraction. The use of the name "key" for this attribute is historical and does not mean that there is any association with a specific "key" on a keyboard, per se. It is up to the user agent to provide a mechanism for mapping the document character set value(s) of the attribute to the input methods available to the user agent. For instance, on some systems a user may have to press an "alt" or "cmd" key in addition to the access key. On other systems there may be voice commands, or gestures with a mouse, an eye tracking input device, etc. Regardless of the mechanism, the result is that it appears to the access element processor as if the defined key was entered.
--

Even if we s/key/mumble, there is still some linkage to user input. One ramification of this would be to change the attribute by allowing for a string as the data type instead of a character. This would allow for selection via (for example) a complete grapheme cluster (translation: a sequence of characters that forms a single glyph or screen image, such as an Indic syllable might use). The character type really means a single Unicode code point, which is most applicable in situations where only a single code point may be generated.

> The text starts with explicit text that says that, but apparently
> that's not enough.

It would be enough, except that our WG felt as if the remainder of the text implies (or outright states, as in "in addition to the access key") that the access event is linked or translated to a keystroke somehow.

In any event, our WG really should take a look at your WG's proposal before officially responding.

Kind Regards,

Addison

[1] http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081023/#A_key

Received on Wednesday, 11 February 2009 00:45:04 UTC