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