[whatwg] accesskey

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.

The intended replacement is the XHTML Role Access
Module<http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule>.
It works in a manner similar to accesskeys, but attempts to resolve some of
the original shortcomings. I'm afraid I'm not intimately familiar with it,
but I believe it also resolves the original multi-mapping problem you
brought up.

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.
> Moreover, serious damage is often caused by the way in which the attribute
> has been implemented in browsers: it uses key combinations that override
> built-in functionality in browsers and other software.
>
> Unfortunately, browser support to the attribute is limited, and rather
> primitive. 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. Moreover, browsers do not indicate that
> access keys are available.
>


http://en.wikipedia.org/wiki/Access_keys

In the summer of 2002, a Canadian Web Accessibility consultancy did an
> informal survey to see if implementing accesskeys caused issues for users of
> adaptive technology <http://en.wikipedia.org/wiki/Adaptive_technology>,
> especially screen reading technology used by blind and low vision users.
> These users require numerous keyboard shortcuts to access web pages, as
> "pointing and clicking" a mouse is not an option for them. Their research
> showed that most key stroke combinations did in fact present a conflict for
> one or more of these technologies, and their final recommendation was to
> avoid using accesskeys altogether.
>
> The World Wide Web Consortium <http://www.w3.org/>, the organization
> responsible for establishing internet standards, has acknowledged this
> short-coming, and in their latest draft documents for a revised web
> authoring language (XHTML 2<http://www.w3.org/TR/2005/WD-xhtml2-20050527/>),
> they have deprecated (retired) the ACCESSKEY attribute in favor of the XHTML
> Role Access Module<http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule>
> .


http://www.wats.ca/show.php?contentid=32

*So while it seems that Accesskeys is a great idea in principle,
> implementation brings with it the possibility that it either will not be
> available to all users, or that the keystroke combination encoded within the
> web page may conflict with a reserved keystroke combination in an adaptive
> technology or future user agent.*
>
> This potential problem was subsequently brought to the attention of the
> Canadian Common Look and Feel Access Working Group (who had previously
> suggested the use of Accesskeys M, 1 and 2), and after consideration the
> Access Working Group reversed it's recommendation and now suggest *not* to
> use Accesskeys on Government of Canada Web sites.
>

Thanks,
Jerason

On Jan 25, 2008 10:43 PM, Jean-Nicolas Boulay Desjardins <
jnbdzjnbdz at gmail.com> wrote:

> Why are there removing accesskey?
> http://www.w3.org/TR/html5-diff/#absent-attributes
>
> I though it was recommended to be used by WAI...
>
> What are we should we use? Because its not said what accesskey is replace
> with...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080125/c8c30e2d/attachment.htm>

Received on Friday, 25 January 2008 21:41:55 UTC