5.2.1 Key equivalents (Re: CSS3 User Interface working draft updated)

At 13:31 16.02.00 -0800, Tantek Çwelik wrote:
>The CSS3 User Interface working draft has been updated.
>
> User Interface for CSS3
> 16 Feb 2000
> http://www.w3.org/TR/css3-userint
>
>Thanks for all the feedback on the previous draft (16 Sep 1999), both private
>and on this list.  We have incorporated it into this draft, and look forward
>to seeing more feedback, preferably on the public www-style list:
>
>
>Tantek

The hardest part is the key equivalents section. Then handling keyboards
universally is hard. Mice, err pointing devices, are simple, they got one
or more buttons that can be in an up or down state, and they have a
position in two-dimensional space. If you add devices like tablets, you
also get pressure and absolute vs relative position, 3D mices add a third
dimension like a tablet does.

Keyboards are far from homogenous. Devices from cell phones to VCR remote
controls to electric pianos have a keyboard. The only thing they have in
common is that they have from a dozen to more than a hundred keys.

QUESTION 1: Should CSS key commands override UA key commands or vice versa?
(*) If UA overrides, the result of CSS key commands are unpredictable,
given the wide variety of User Agents, versions, platforms, and localized
versions (non-English often use different shortcuts than the English ones).
(*) If CSS key commands override, vital functions can be unaccessible. If
for instance command-Q was one of the alternatives, a Mac user would be
unable to shut down the application from the keyboard.

QUESTION 2: What about key mapping?
Many or most of the key combinations will not be available for any
platform. Most UCS letters will not be available on any keyboard. Cross
platform program use a lot of key mapping (ie. the Win control key becomes
the Mac command key, and potentially Unix meta key (though usually control
key). Any cell phone/PDA UA would have to do this overtime due to the small
number of keys.

Should this be explicitly disallowed (with potential accessibility
problems), or if not, what about "key collisions"? Eg. if Control is mapped
into Command for a Mac, and one element has Ctrl-M as one of its shortcuts
and another element has Cmd-M as one of its shortcut, which one is valid?
The first, the second, neither, the non-mapped one, the one with "the
highest priority" (higher up on the list)?


EXPERIENCES WITH ACCESSKEY

It could be interesting to get others' experiences with HTML 4.0 ACCESSKEY.
It is (in theory) an accessability win/win, not only does it reduce the
dependency on a pointing device, it can make power users more efficient. I
have used ACCESSKEYs only for two uses. This is because there is no
feedback, at least with WIMP browsers, so the only way a user can be aware
of ACCESSKEYs (apart from reading source) is by me telling about it. This
is a UA issue, not a CSS issue, but since the "big browsers" are
represented in this group: Consider an option to add a tool tip (or
equivalent) for ACCESSKEY (or equivalent) appended to TITLE tool tip (or
equivalent). So <a href="armageddon.cgi" title="Press this button to bomb
Moscow" accesskey="F4"><img src="redbutton.gif" alt="Red button"/></a>
could trigger 
   [Click this button to bomb Moscow (F4)]

So I'm digressing. I've found ACCESSKEY useful, and frustrating, for two
purposes:

1. Buttons
For this purpose ACCESSKEY works rather well, at least in the limited
setting I have used it so far. Later this year I plan to foist this on a
larger general public with no presumed computer skills. It is possible to
give visual feedback, for instance underlining, Windows-style, the "active"
letter. There is the risk that the accesskey will collide with some UA on
some platform using some language.

2. Alphabetic lists shortcut
This is very handy, but also the use with most issues. Very often you have
a menu of choices sorted alphabetically by
letters (say a directory of employees sorted by last name), and by pressing
the accesskey letter you can go to the page in question. For a moderately
complex example I'll use the Czech sorting alphabet. Czech is a latin
language within Latin-2 (ISO8859-2). The sorting order is:

ABC[C]DEFGH{CH}IJKLMNOPQR[R]S[S]TUVWXYZ[Z]
Where [C][R][S][Z] are the ASCII counterparts with a hook (v) on top of
them. {CH} is the digraph C+H.
The vowels ÁÉ[E]ÍÚ[U-ring]Ý are sorted as their ASCII counterpart, as are
the consonants [B][D][M][N][T].

Some of the issues are:
0. The usual UA reserved characters issue apply
1. To be fully useful, access to a Czech keyboard (hardware or software) is
necessary, since it is the keypress, not the letter, that triggers
ACCESSKEY; you have to have [C][R][S][Z] keys. This is not usually much of
a problem as people looking up a Czech directory can be expected to have
that access.
2. The letter {CH} can't be triggered by ACCESSKEY. It is written by
writing C followed by H, there is no "CH" key. As for 5.2.1, is
<key-press-combination> meant to be simultaneous, a sequence or left up to
the UA? That is, when "<key>-C-H" is specified, is the user expected to
press <key>, C and H simultaneously? <win> and <meta> are usually sticky,
<alt> is sticky on a Windows platform, while <shift>, <control>, <command>
and <option> (Mac) usually are not sticky (unless set otherwise with
accessability add-ons).
3. Some Czech letters are not available without a modifier key. Lowerkey
Á[C]É[E]Í[R][S]Ý[Z] are reached by <shift>+[2-0], others by "´" or "v"
pluss the letter.
4. A directory listing "use up" all the available letters. If you have
"_N_EXT" and "_P_REVIOUS" buttons, you can't go to the N or P page.
Conversely, if you give each letter an ACCESSKEY, all that is left is the
numbers and the special characters, the latter are very non-portable. The
numbers are portable (very much so for cell phones), but that destroys the
option of making mnemonic names, "N_3_XT", "PREV_1_OUS" and "ST_@_RT" is
not a good solution.


A NAIIVE FIRST PROPOSAL
From a web producer's point of view I could like two different mechanisms.

1. An extension of accesskey
One way to extend accesskey is to accept arbitrary letters (not keys) and
more than one of them, so you could have "<access>CH". The problem with
"<access>CH" is that you really need "<access>CH</access>". By not
accepting for instance Return as an accesskey value, Return could function
as </access>. This makes accesskey more powerful, but slower, as you would
have to end the accesskey sequence. For those using accesskey as
convenience, not to increase access, there is an alternative. If say
<access> is ctrl+alt, the access sequence could be the characters typed
when ctrl+alt is held down (presuming that neither ctrl nor alt is needed
to generate those characters).

An intriguing option here is to use the same namespace as the ID namespace.
That way you could go directly to any ID'ed element. There is a conceptual
difference however, as an activated A triggers that link, but an activated
P just makes it visible in the view. *Selecting* that P would be closer in
concept.

This is rather "Emacsy" and an "accesskey command line mode" is not optimal
from a usability standpoint, but it is predictable and extensible.


2. A generalisation of key commands

<prelude>
All UI designers agree on the virtue of consistency, the question remains
consistency to what. An example can be instructive. Ctrl+B is not available
on an Norwegian Internet Explorer/Win, as it is shortcut for "Find (on this
page)". Why? The US version uses Ctrl+F (for _F_ind). The Norwegian word
for "Find" is "Finn", so there is no reason to change this for mnemonic
reasons. The reason it changed is because the Norwegian MS Office packege
wanted to change the B as in Boldface to something mnemonic for Norwegian,
where the word is "(halv)_f_et". So the shortcut for bold in Norwegian
Office is "Ctrl+F", unfortunately "Ctrl+F" is used for "Find" so they had
to change that, and "Ctrl+B" was suddenly vacant... Since IE wants to be
consistent with Office, even if it has no use for "Bold" (not being an
editor), Ctrl+B is used for "Find (on this page)".

This doesn't just apply to Microsoft of course. Apple Macintosh has
stringent UI rules that are mostly followed, one of which is that shortcuts
should not be localized, so in Norwegian Mac programs you use "Cmd+C" to
copy, even though the command is "Kopier". Not so in neighboring Sweden,
where "Cmd+K" is just as likely.
</prelude>

My point is, there are scores of OSes each having scores of UAs localized
to hundreds of nations using thousands (actually hundreds) of languages. I
*don't* want to secondguess that. (Millions of web producers using their
own key commands will probably not help the web usability, but that is
another story. An experiment and shake-out phase may be beneficial in the
long run.)

Having  fn + fcn + caps + command key + right command key + left command
key + option key + right option key + left option key + control key + right
control key + left control key + shift key + right shift key + left shift
key + alt key + right alt key + left alt key + win key + right win key +
left win key + meta key + right meta key + left meta key +  f1 + f2 + f3 +
f4 + f5 + f6 + f7 + f8 + f9 + f10 + f11 + f12 + f13 + f14 + f15 + tab + esc
+ enter + return + menu + help + namemenu + rcl + snd + up + down + left +
right + home + end + pgup + pgdn + bs + del + ins + undo + cut + copy +
paste + clr + sto + prtsc + sysrq + scrlock + pause + brk + numlock + pwr
(and connect + hangup + memory + recall + play + forward + fast forward +
backward + fast backward + record + pause + stop + start + teletext + mute
+ defrost + ...) doesn't help.

A single abstract command space, separate from the accesskey space above,
should be sufficient. If there is an available key sequence simulating an
abstract <web> key that had 36 position, you could implement it several ways.

An Internet-oriented device (computer or otherwise) could have an actual
<web> key. Other devices could have it user configurable or hardwired. The
important point is that the 36 positions would be reserved.

The 36 positions could be simulated by 
A-Z0-9 (latin-based keyboards)
F1-12, shift+F1-12, ctrl+F1-F12
<mode key 0-2> 0-9*# (cell phone and other numerical devices)

Received on Sunday, 27 February 2000 09:32:04 UTC