RE: [WebAIM] More data on accesskeys

Charles McCathieNevile wrote:
> An important requirement (as with any version of accesskeys - not
> just the proposal to bring the HTML one to value) is good browser
> implementation. 

In this we have total agreement - in fact it's critical.  But remember as
well that very often it also transcends *just* the browser/user-agent.  For
daily users of adaptive technology, there is an extra layer of goo in there
that also needs to be accounted for, and this in particular is one of the
major reasons why I continue to advise against using the current accesskey
(there are others... And I think anyone following this thread has heard me
articulate them many, many times).

> Which, in particular, means that the browser should
> treat the key as a hint and have no compulsion at all about changing
> it. The way that scripts already do for some implementations. The
> only reasonable way to handle them on a mobile phone, or a
> joystick-controlled device. 

Question:  If, in certain instances, an author wanted to hint a null value,
what then?  Would the browser advise that there is function sans hinted key?
Is the addition of the hint critical (or even important) in the
functionality we are talking about here?  Or would a null value suffice?

> Which has the result that authors SHOULD NOT say "use Alt-F to find
> things in my page". 

Right, and they should also avoid saying things like "Click Here", or having
multiple links to "More..." on the same page.  Sadly, I have less faith in
the overall developer population than your statement would
encourage/suggest.  Chaals, human nature being what it is, if they can mess
it up, they probably will (and usually with alarming frequency).  This is
why I argue to remove the ability to do so, especially since, in the
scenario you envision, the hint can be abandoned with relative ease.  I am
having a hard time understanding the difference between hint="é" and
hint="[null value]" except that in the second option to make the function
work I would first have to map a key.  I will also qualify this by saying
that I pre-suppose that the "Common collection" of Access Roles currently
envisioned within the XHTML 2 draft would either come "pre-wired" to the
user-agent, or could/would be set once and stored as a user-agent variable
(perhaps as a cookie?) or in a local config file of some sort.

One of the important considerations and current failures of accesskey is the
lack of "standardization" of accelerator keys for the end user.  Will your
envisioned hint key automatically be over-ridden if the user's config file
or cookie is pre-mapped for a common @role (Search for example?), or more
importantly a non-"Common Collection" but frequently used function.  Here
again, why should the author be hinting a key (and possibly trying to aid
the end user by "advertising it") when it would be instantly over-ridden?  

> The user agent must show what keys are currently
> assigned. (This was anticipated in UAAG at a time closer to the
> development of HTML 4 than to now, but the implementation still needs
> work. On the other hand, the whole role attribute approach needs
> implementation, so it isn't ahead in any way).

Well, presumably in a user-configured setting, the user already knows what
keys they are using and for what; I suspect what would be more important is
that the user-agent had an appropriate recovery mechanism ("Alert: that key
is already mapped to foo, are you sure?" or "Alert: that key cannot be set
at this time, please choose another")

> Actually, getting to deal with all that, on a page where I frankly
> don't care about the accesskeys anyway, seems like a good argument
> not to have to use real-time discovery unless I clearly ask to do so.
> 
> What if, instead, my "acceskeys" button - the one next to the
> fast-forward button, lit up so I knew I could activate accesskeys on
> the page if I wanted them? 

A few thoughts:  
 * My blind friends would be out of luck if all it did was light up <grin>
 * Isn't that in effect real-time auto-discovery?
 * Given the small size of hand-held devices today, do you think they will
be prepared to add an accesskey button to their keypads?
 * What of the joy-stick controlled device you referenced above?

...but I get your point.  The auto-discovery need not be intrusive, but it
none-the-less must be there.

But again, in an un-obtrusive scheme such as you described, if I as an end
user wanted to take advantage of "extended" mappings beyond the "common
collection" that presumably would already be mapped, I would need to open a
screen dialogue window of sorts to see what those extra functions might be.
At this point it then becomes a question of: "Hello, these are the extra
functions that can be mapped to a keyboard accelerator" followed by a list
of easily editable keys as suggested by the author mapped to the new
functions.  Again, by the time we have reached this point what is the real
difference between "_null_" and "é" outside of the fact that I have a harder
time accessing the "é" character from my American keyboard?  Why again does
the author need to be guessing a potential keystroke?

> And by default, the author's title and
> key-hint were offered (assuming it is in the current keymap), along
> with a simple mechanism for getting to the key by activating the mode
> and then using arrows to select from the short list of accesskeyed
> controls? 

If I understand you here however, this does not fully address the cognitive
load issue (IMHO).  If I have included <... title="Wonderful custom feature
- access key = é" /> then once again we have the same problem that I had
when we wrote to the screen "...and to access the wonderful custom feature
use access key <span style="text-decoration:underline">é</span>".  Yes, it
can still be edited and modified, but a null or empty value can also be
edited and modified.

> Keeping the simple things simple, as well as the difficult things
> possible, is an important goal, IMHO. Having to assign things to
> random and perhaps confusing roles doesn't qualify to me as simple.

It seems to come down to discovering and changing a mapped key vs.
discovering a mapable function and allowing the end user to choose a mapping
from the get-go.  

It seems to me that at some point the user-agent needs to do pretty much the
same amount of work, and the only real net result is that the end user
chooses to either change "é" to "Q", or "__" to "Q".  If it is a random or
confusing (non-standard) role, the end user will need to have some kind of
understanding of it before they can take advantage of the non-standard
key-mapping anyway, so I don't see how this really would concern the user
agent greatly.

> Asking a browser maker to guess about a default setup twice so...

See, that's the point, we don't want *anyone* guessing, we want that the end
user chooses.  They are the *only* person who knows best what works best for
them, every time, all the time.  As enablers, whether as content authors or
technology providers, it would seem to me that this is the best choice, and
I have not heard a reason why this cannot be the default.  If we remove the
author's ability to set a mapping, then this becomes the de facto setting.
All of the other auto-discovery and editable mapping settings can (and
should) remain: simply remove the author's ability to guess wrong.

Cheers!

JF

Received on Monday, 4 December 2006 06:19:28 UTC