- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Mon, 2 Jan 2006 11:14:31 -0500
- To: "'David Poehlman'" <david.poehlman@handsontechnologeyes.com>
- Cc: "'Charles McCathieNevile'" <chaals@opera.com>, <wai-xtech@w3.org>
David Poehlman wrote: > John, > > Charles does have a point though, what if the user agent needs a > specific key binding bbecause it does not support the technology > which replaces access key? > S.O.P. - user agents that do not support a particular element or attribute ignores said element or attribute. Look at <q> in Internet Explorer... End users live with it, or upgrade accordingly. When you seek to bind a key, you end up with the same mess that we have with accesskey today. Which key David? And what about conflict resolution? Accesskey has no means of conflict resolution today, which is one of the reasons that I continue to advocate not using accesskey (and thankfully today I am not alone). There are other reasons too, but I will stay on topic... You've read and heard my rants in the past. The ACCESS element and @role and @key attributes are newly proposed for XHTML 2; user agents that will support this new Recommendation will conceivably support these concepts natively - this is yet again another reason to get this right the first time. I argue that the real need for @key does not exist - that the reasoning for it's inclusion is flawed. JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053
Received on Monday, 2 January 2006 16:14:44 UTC