W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2008

[whatwg] accesskey

From: Charles McCathieNevile <chaals@opera.com>
Date: Mon, 28 Jan 2008 18:39:17 +1100
Message-ID: <op.t5l1n4ezwxe0ny@widsith>
On Sat, 26 Jan 2008 16:41:55 +1100, Jerason Banes <jbanes at gmail.com> wrote:

> 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.

An alternate view is that there is no inevtability that accesskeys  
interfere with normal browser operation, you just have to make an  
intelligent activation and discovery method (well, not the actually very  
stupid one suggested in HTML 4 at any rate).

> 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.

It's one of the proposals - one of the more comple new ones that involves  
ignoring all the existing markup. There's another one on the HTML-WG list  
that uses existing marup, doesn't interfere with browser function, can  
work on an iPhone with zero keys or a desktop with lots, ...

http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html is the  
initial mail proposing implementation techniques. That page links to the  
proposed spec changes, and other stuff.

cheers

Chaals

> 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...
>>



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
Received on Sunday, 27 January 2008 23:39:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:00 UTC