Re: Accesskey - spec proposal

Sander Tekelenburg <st@isoc.nl>, 2007-07-04 20:03 +0200:

> At 20:19 +0900 UTC, on 2007-07-03, Michael(tm) Smith wrote:
> > Access-key markup on mobile sites is already in wide use for
> > mobile-specific sites in Japan at least. It works quite well and
> > users depend on it. The way that it's handled is that if you mark
> > up an element with an access key, a 0-9 numbered button or star or
> > hash button is rendered inline next to the displayed content of
> > element. By convention that has grown up around it, the elements
> > with access keys are generally grouped at the bottom of each page,
> > and the mappings/bindings are consistent across all pages at the
> > site.
> 
> That sounds like it is used a lot for general site navigation (home, next,
> previous, up, toc, search, help, etc.)

In part -- but in the above, I omitted/elided over another common
use case for it, which is in lists in the main text flow.

> I must say that rel is much more appropriate for that. accesskey
> could then be used for a login form for instance.

I definitely agree about that. It would be a great thing if it
were common for browsers to have support for rel that was exposed
to users in a way that made it easy to find for them.

But I don't think we can say we're there yet -- not even in the
case of common desktop browsers, let alone for the cases of myriad
of other devices/browsing contexts whose use cases we need to
address: browsers on portable gaming devices like the Sony PSP and
Nintendo Wii, browsers on home gaming devices like the Nintendo
Wii and on set-top boxes, where the UI is a so-called "3-meter UI"
or "10-foot UI" (you're 3 meters away from screen when using it),
browsers accessible from back-of-seat screens on airplanes, etc.

In the case of mobile browsers on handsets, since handsets have at
least three (left, center, and right) "soft key" buttons that
applications functions are commonly assigned to, and those are
commonly used to provide popup menus/submenus in the application
chrome, browsers could put the rel targets into a submenu that's
activated by one of those soft keys.

But we would still be left with the case of how to make it easier
for users of keypad/5-way UIs to navigate quickly through lists.

And beyond that, we would still need to deal with the mass of
existing content that already uses accesskey. Which seems to me to
imply that regardless of anything else, we need to have accesskey
spec'ed in such as way to address those use cases -- if we want to
try to provide interoperable handling of that existing content
across implementations.

I think it would be extremely helpful for the spec to outline
preferred alternatives to accesskey when and where we have them,
but that doesn't exclude the need to address how to support them
interoperably as they are found already in the wild in existing
content.

> What I like about Chaals' proposal is that, although it mostly /speaks /of
> accesskeys, it gives preference to rel. With rel, and standardised values for
> it, users can get a UI that is *consistent across sites*. accesskey can only
> provide consistency within a site.

I agree. I am not advocating support in the spec for current
accesskey use cases because I think accesskey is the ideal
technical solution to address those use cases. I'm personally not
particularly satisfied with accesskey as a good solution for
navigation. But that's irrelevant -- if we have a requirement to
handle HTML as it is spoken, I seems like we need to spec out
interoperable behavior around that, regardless of whatever else we
do/add to provide alternative markup and authoring guidance that
better addresses the use cases.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/