[whatwg] accesskey

[Michael(tm) Smith]

Jerason Banes <jbanes at gmail.com>, 2008-01-25 23:41 -0600:

> Long story short, accesskeys were an idea that worked better on paper than
> they did in practice. They inevitably interfered with normal browser
> operation as well as other accessibility features in such a way as to *
> reduce* the accessibility of many web pages.

Another long story short: accesskey mark is already in use in a
significant amount of existing content, so leaving it unspec'ed
for implementors does not seem like a practical option -- not if
we care about trying to ensure that behavior of that content is
consistent/ interoperable across UAs.

To elaborate a bit: A class of content in which accesskey markup
is in particularly wide and effective use (effective as far as its
content providers and users of it are concerned) is content
intended for viewing, as one of its possible delivery contexts, on
mobile handsets.

Most handsets don't have keyboards or real pointing devices that
let you quickly point and click on links; instead they just have
numeric keypads and "5-way" directional pads that are basically
the equivalent of arrow keys plus an enter key/mouse button.

In the context of delivering content to those devices, it's useful
to provide numbered access keys for quick access to certain links
on a page -- to save users the time and trouble of needing to use
the 5-way on the handset to scroll to the links and activate them.

And that's why there's a large body of existing content that has
accesskey markup: sites that takes browsing from mobile handsets
into consideration as one of their possible delivery contexts.

> The intended replacement is the XHTML Role Access
> Module<http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule>.

I think it might be more accurate to say that's one proposal for
providing a better means to meet the same requirement that
accesskey was originally intended to meet.

> A few links on the subject:
> 
> http://www.cs.tut.fi/~jkorpela/forms/accesskey.html
> 
> The original version of this document had a much more positive attitude to
> > the accesskey attribute. Experience and analysis has shown, however, that
> > the idea of author-defined shortcuts is generally not useful on the Web.

I guess this is a case where anybody making that assessment might
need a little more experience -- and need to do a little more analysis
that involves looking at the existing content I mentioned above.

The use case of accesskey for Accessibility considerations
(targeted to improve accessibility of content intended in the
context of using it from a computer that has a full keyboard or
equivalent) is not the only use case it should be judged on.

Whether it's turned out that accesskey markup has failed to be
effective for that use case is something that doesn't really
matter. Because it's clearly not the only case for which it has
come into use in existing content.

And even if we make the determination that HTML5 will ultimately
not make the accesskey conformant for authoring, we would still
need to have it spec'ed for implementors in HTML5 if we want the
existing content that already uses to remain usable/interoperable.

[quoting Jukka]
> > Unfortunately, browser support to the attribute is limited, and rather
> > primitive.

Not true now since many/most browsers on mobile handsets support
it (and note that Jukka says on that page that he wrote that part a
long time ago).

[quoting Jukka]
> > The accesskey attribute tends to mask out the functionality of
> > a browser's predefined keyboard control, which is often much more important
> > than page-specific access keys.

Whether for a particular site the access keys provided by site or
the browser's predefined keys are more important is something for
users of that site to decide. What's needed is for browsers to be
made smarter so that they can provide a way for users to be able
to access both.

[quoting Jukka]
> > Moreover, browsers do not indicate that access keys are
> > available.

That doesn't matter for the case of numbered access keys in the
class of content I've mentioned. Because those sites don't expect
the browser to indicate that access keys are available. Instead,
they put a numbered image inline next to each link that has a
numbered access key.

There are of course other ways that a browser can make access keys
discoverable. As far as desktop browsers, Konqueror does it by
displaying tooltip-like popups next to the links when you press
and release the Control key (without pressing any other key in
combination with it).

Anyway, all that said, I'm not a fanboy for accesskey. I think
in hindsight it's clear to all of us now that it should probably
have been better thought out before it got spec'ed originally and
put into a standard. But then so should have a lot of other things.

The general problem we face with that what-we-now-see-as-bad-legacy
markup now is that because it did make it into a standard and
authors and content providers ended up using it in their content,
we are stuck with figuring out a way to spec that markup -- that
is, if we want users to be able to access that content without
breaking how the content providers using it are expecting that
markup to work in browsers.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2237 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080126/1038b582/attachment-0001.bin>