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

RE: Future of accesskey in DHTML based Widgets

From: Evans, Donald <Donald.Evans@corp.aol.com>
Date: Thu, 20 Mar 2008 09:17:19 -0400
Message-ID: <03D07FA9A6F1344081610CF5B15598F204F3BA@EXCHNVA01.ad.office.aol.com>
To: "Charles McCathieNevile" <chaals@opera.com>, "John Foliot - Stanford Online Accessibility Program" <jfoliot@stanford.edu>, "Schnabel, Stefan" <stefan.schnabel@sap.com>, <wai-xtech@w3.org>
Cc: "Keim, Oliver" <oliver.keim@sap.com>, "Wlodkowski, Thomas" <Thomas.Wlodkowski@corp.aol.com>


> -----Original Message-----
> From: Charles McCathieNevile [mailto:chaals@opera.com] 
> Sent: Wednesday, March 19, 2008 7:19 PM
> To: John Foliot - Stanford Online Accessibility Program; 
> 'Schnabel, Stefan'; wai-xtech@w3.org
> Cc: 'Keim, Oliver'; Evans, Donald; Wlodkowski, Thomas
> Subject: Re: Future of accesskey in DHTML based Widgets
> 
> On Wed, 19 Mar 2008 17:38:18 -0000, John Foliot - Stanford 
> Online Accessibility Program <jfoliot@stanford.edu> wrote:
> 
> > 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.).
> 
> Well, that's a draft - it doesn't have consensus in general 
> and in particular there is not apparent consensus that 
> accesskey should be dropped. Personally I ahve written a 
> proposal for the group, which I hope they get around to 
> considering in due time. Effectively that would allow for 
> accesskey as currently used in markup, but require the 
> browsers to expose it (and allow them to remap things where 
> the key that the author proposes isn't actually available).
> 
> ...
> >> 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.
> 
> These are pretty much in line with my opinions. I am hoping 
> that instead of building complex javascript-based keymaping 
> systems we can use accesskey to greatly simplify the tasks of 
> making things keyboard accessible and letting users keep 
> using their user interfaces.


I very much agree with this.  We spend a lot of time writing JS keyboard handlers, and they are not easy to write.  A properly functioning accesskey would make a difference.

---don


> 
> ...
> > 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.
> ...
> > 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).
> 
> Well, I am not sure that we are force-feeding the document, 
> and browser makers are one set of stakeholders among several 
> (content developers, producers of authoring tools, people who 
> write educational stuff that others use are all important 
> too) but yes, this is on the radar.
> 
> cheers
> 
> Chaals
> 
> --
> 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 Thursday, 20 March 2008 13:20:38 GMT

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