W3C home > Mailing lists > Public > wai-xtech@w3.org > March 2008

RE: Future of accesskey in DHTML based Widgets

From: John Foliot - Stanford Online Accessibility Program <jfoliot@stanford.edu>
Date: Wed, 19 Mar 2008 10:38:18 -0700
To: "'Schnabel, Stefan'" <stefan.schnabel@sap.com>, <wai-xtech@w3.org>
Cc: "'Keim, Oliver'" <oliver.keim@sap.com>, "'Evans, Donald'" <Donald.Evans@corp.aol.com>, <Thomas.Wlodkowski@corp.aol.com>
Message-ID: <008701c889e8$05774660$942442ab@stanford.edu>

Schnabel, Stefan wrote:
> In
> http://www.w3.org/html/wg/html5/
> accesskey attribute is missing. I assume intentionally because of
> browser issues (different implementations etc.). 
>
> We find in
> http://www.w3.org/TR/html5-diff/
> 3.5. Absent Attributes
> Some attributes from HTML 4 are no longer allowed in HTML 5. If they
> need to have any impact on user agents for compatibility reasons it
> is defined how they should work in those scenarios.
>  
>        accesskey attribute on a, area, button, input, label, legend
> and textarea. 
>
> I believe that accesskey attribute support in content is crucial for
> ease of navigation of business applications in contemporary browsers,
> even for people without AT.  
>
> In addition, it will reduce the amount of JS coding for developers of
> widget toolkits. 
>
> Any other opinions?


As someone who has fought and preached against using accesskeys for over 6
years now, I find myself actually agreeing with you (to the surprise, I'm
sure, of many).

The "current" implementation of accesskey continues to be horrendous in the
market leader browser, but the other browsers are getting better, with Opera
leading the way.

I had originally thought that the proposed @access of XHTML2 would be the
better route, but after discussing it extensively with my good friend Chaals
McCathieNevile, I've come around to his perspective: given that accesskey is
already being used in some instances, it is easier to fix the browsers than
re-teach a generation+ of web developers to abandon one construct in favor
of another that essentially does the same thing.

The key is that the browsers *MUST* allow end users to re-map "hot keys" to
match the needs of individual users; anything short of that introduces
usability and accessibility issues that have already been well documented.
Interim solutions such as that developed by Gez Lemon[*] illustrates that
this can be done quite easily, but rather than having developers consciously
add code to allow this, the browsers should natively do this.

Given that HTML5 is being driven (force fed?) by the major browser
developers, I believe that the responsibility rests with them to revisit
accesskey and continue to support it's intent, but correctly this time
(please).

JF

* http://juicystudio.com/article/access-key-companion.php
  http://juicystudio.com/article/user-defined-accesskeys.php
Received on Wednesday, 19 March 2008 17:40:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:45 GMT