Re: implemeting an improved access key [was Re: Q4 2009 Accessibility Goals]
"Charles McCathieNevile" <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.seamonkey,gmane.comp.mozilla.accessibility |
|---|---|
| Organization | Opera Software |
| Message-ID | <[email protected]> |
On Thu, 17 Sep 2009 23:01:53 +0200, Gregory J. Rosmaita <[email protected]> wrote: > aloha, david! > > one of the items that need to be considered is that HTML5 dropped > accesskey as it was defined in HTML 4.01 -- the PF (Protocols & > Formats) working group at the W3C has a long-standing list of > accesskey replacement requirements, drafted by RichS, and available > at: > > http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements > > perhaps there can be som synthesis of effort on this? mozilla > could be an integral aspect of fixing accesskey, Actually, HTML5 re-added accesskey, with some improvements on the original spec (the markup is OK, but the implementation advice was seriously broken). Basically, accesskey needs to be modally seperated from things like find-as-you-type or general single-key shortcuts. Opera has had this for a while (since 9.5? try shift-esc on a page with accesskeys), although there are more things we want to do... The user agent should be responsible for deciding what the activation is for things with accesskey. In some cases a gesture with a mouse might be more appropriate, in others a gesture on a touch screen, in others the key that the author thought was memorable. The HTML 5 draft is meant to allow this. It's also meant to deal with stuff like assigning a voice command, or just changing the activation key to one the user actually has available (or more readily available, if you know the keyboard layout). Accesskeys also need to be discoverable, and since the user agent decides how they work, the UA really needs to take responsibility for exposing them, rather than having the traditional author page of accesskeys listed with half-baked instructions for using them (which tend to go out of date or be plain wrong). The benefit of doing this instead of going the whole XHTML2 <access> element hog is that it is completely compatible with existing sites that use accesskey - which generally seem to come out at a bit over 1% of the web at large, and the vast majority of the usage is correct by spec. So seeing Mozilla do something that helps fix accesskey would indeed be nice. 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: http://www.opera.com _______________________________________________ dev-planning mailing list [email protected] https://lists.mozilla.org/listinfo/dev-planning