- From: John Foliot <foliot@wats.ca>
- Date: Fri, 1 Dec 2006 17:15:49 -0800
- To: "'Charles McCathieNevile'" <chaals@opera.com>, "'Lachlan Hunt'" <lachlan.hunt@lachy.id.au>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>
- Cc: "'WAI IG'" <w3c-wai-ig@w3.org>
Charles McCathieNevile wrote: > Guess John (at least) was wondering where I was. Couple of thoughts... Na, I figured you were busy, but would get back at it <grin>. > > The basic idea is that accesskey, > as it exists in HTML 4 (but not in the b0rken FF or even worse MS > implementations) is workable. There is nothing intrinsically wrong > with an author giving a hint for a key - although the user agent > should decide to accept or replace it... It is kind of rough to > expect someone using a device with a joystick in hindi to find the > ÙR key is a useful shortcut. But Chaals, there *is* a cognitive issue if I, as a content author state: "To do _foobar_ use accesskey <span style="text-decoration: underline;>¨¦ </span>" (é) How many English speaking users know how to access that key? Is that really an appropriate accesskey in the first place? It troubles me greatly that a content author presumes to know which key should be the best for the end user - "hinted" or not. Your own example reveals the folly in categorically suggesting that a specific key is the "proper" key. I get that you envision it as a hint primarily to the user-agent, but what system is in place for those who cannot use the hint? There may be a technical/mechanical solution, but if I indicate that a specific key does something (either by stating it, or "visually hinting" it by underlining a letter), and it is over-ridden, how do we deal with the "confusion" factor? I have not heard the "graceful fallback" solution to this conundrum. > > This means > the guys writing the implied japanese site in my accesskey example > above don't have to worry in advance about whether WHATWG, W3C, > microformats.org or whoever can read their explanation of what their > particular value means, because you have a way of applying it > afterwards that is lightweight enough to implement in a browser if > you want to provide real-time discovery. OK... But if there is "real-time discovery" capability in the browsers, why again do we even need to hint a key? onLoad: "Prompt: Attention user, would you like to map a keystroke shortcut to this function?" - user selects key - "Alert: that key is already taken by _foo_, are you sure you wish to change it?" Yes/No; else "Alert: Thank you, that key has now been mapped to _bar_" (or whatever... You get the idea) - and onward we go... Does the condition that triggers the initial prompt have to be an @key? One would think not. >>> I personally like the idea of role as it more closely defines what >>> we are talking about, but if one of the goals of HTML 5 is to >>> re-use as much of what we have now (rather than starting over >>> again) then REL works too... >> >> That's sums it up nicely! > > Yep, in general. I think the decentralised and distributed > extensibility story is really important, but there are plenty of ways > to skin that cat. All without directly telling the end user what to do, only that the capacity to do so exists. Cheers! JF
Received on Saturday, 2 December 2006 01:26:09 UTC