- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Fri, 3 Jun 2005 08:38:01 -0400
- To: "'Charles McCathieNevile'" <chaals@opera.com>, <w3c-wai-ig@w3.org>
Charles McCathieNevile wrote: > > I agree that the author should not be setting "the" key to be > used. Hey! That's what I said... > But > since the author knows something about the random important > thing (it > shouldn't be a common enough function that there is a rel > attribute value > already defined, otherwise accesskey is the wrong tool for > the job that is > better done by the rel attribute). So they are the person > most likely > (IMHO) to have an idea of what might seem a useful mnemonic. ...and I am please to see this new attribute of "role"; it may in fact answer a lot of this issue. The previous spec allowed for expansion of the rel attribute's values, but was painfully vague on *how* exactly (http://www.w3.org/TR/1998/REC-html40-19980424/types.html#h-6.12). By observation most people just "made them up" and hoped for the best... For example, I have yet to see a formal profile (definition?) for <link rel="P3Pv1"... Even though the W3C has an automated checker for P3P policies (http://www.w3.org/P3P/validator.html). Oops... (Off Topic, if one does exist, can somebody point it out to me please?) > > The problem is that this key may not be available. Many > common letters > such as the range [a-zA-Z] are not so easy to get on an > arabic keyboard, > for example, and I will bet that fewer than 1 in 10 readers > of this list > know how to generate a hungarian double-accented-o in a way > that makes it > a feasible shortcut. Hey! Aren't these *my* arguments? > It is also true that a and A are, > according to the > current spec, two different accesskeys. > > So a part of any sensible answer (and this has been discussed > for years - > I am particularly upset that SMIL 2.1 still doesn't have it > in its new > candidate recommendation draft) is that the author proposes, > but the user > disposes. See, here's where I am concerned. Why have the author propose anything; rather just mark-up the intent and leave it to the user agent to expose and allow the keystroke bindings? This really shouldn't be *that* difficult, especially if, under most circumstances, the "role" being indicated is from the 'standardized' list. Expanding that (by defining the "new" role via RDF) may be more taxing (I have visions of multiple look-up scenarios: load page, find RDF declaration - look that up- return it to user agent for subsequent end user exposure/discovery and then mapping... Seems onerous to me but I might be missing something) > Via their user agent in the first instance - the > user agent may > well re-map the keys to things that are commonly available in > the current > setup which it knows much better than the author. Yes... These are definitely *my* arguments <grin>. Except for the concept of "re-mapping". I suggest simply "mapping" based upon mark-up. Why have the user/user-agent undo something first? Is it not more user friendly and less intrusive to simply "do", instead of "undo, then re-do"? > The onus is > then on the > User Agent to explain which keys are assigned to what, not > the author. In > addition, the user agent should (must if it is going to do a > good job) ...so let's insist on MUST > provide a mechanism for reconfiguring the keys, or otherwise > giving access > to just those things marked with an accesskey attribute. Well, given the wholesale re-working of this, perhaps seeing the return of "access" to a proposed attribute (as opposed to an element) might not be the better way, or dump the whole thing and just make the concept of "role" the hook that keystroke bindings could be mapped to. It would force one and all to re-think, re-learn, re-address. Chaals, do you honestly see the browser manufacturers re-jigging to use accesskey differently? I don't (well, maybe one, if you have any influence <grin>) > > The good thing about this approach would be that while it > requires changes > to the spec as written, Which I have said in the past. But is this realistic? Will W3C re-write parts of HTML 4.01/XHTML 1? Highly unlikely... So work must be concentrated on XHTML 2, which is supposed to be a watershed Recommendation. So, it brings me back to my point: ignore the broken attribute (or try repairing it - I am curious to see your idea reach fruition), and work for a real, usable solution in the next iteration (XHTML 2). > and fixing user agent > implementations, it doesn't > interfere with existing good user agent implementations and > it doesn't > require changes to the content of any existing conformant document. Well, here I would agree... Although I wonder out-loud how many web documents (in the grand scheme of things) already have accesskeys implemented? And since the likelihood of *all* user-agents re-addressing accesskey is dubious, a strong argument could also be made to walk away from "accesskey" and towards something new. (precedence: <strong> vs. <b> and/or {font-weight: bold;}) > > Which is the friendly way to make the world better. Which, despite my apparent rage of yesterday is the real goal. > We are currently > looking at userJS and CSS to prototype some ideas for how to > make Opera's > accesskey impementation more useful - feel free to tell us about it. Feel free to consider me a beta tester. Cheers! 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 Friday, 3 June 2005 12:38:12 UTC