- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 16 Jun 2009 23:11:34 +0200
- To: "Jeff Ganyard" <jeff.ganyard@macspeech.com>, "James Craig" <jcraig@apple.com>
- Cc: wai-xtech@w3.org
On Tue, 16 Jun 2009 20:09:44 +0200, Jeff Ganyard <jeff.ganyard@macspeech.com> wrote: > On Tue, Jun 16, 2009 at 10:30 AM, James Craig <jcraig@apple.com> wrote: > >> Hi Jeff, this sounds like a reasonable idea. Perhaps this is one >> potential solution to the #9 request on the following page. >> >> http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements > > If all 9 of those items were adopted and actually implemented, I would be > more than content! But addressing #3, #4 & #9 are the most critical from > the our perspective as a developer of an external process to a browser > trying to improve the user's experience within the browser. Actually, the current HTML 5 draft probably deals reasonably well with requirement 9. >> A couple initial nits with the format though: >> >> 1. Since we're talking about keystrokes and keycodes, perhaps being >> plist-based (<key>) overly complicates the readability of the markup. >> It may be better to define a custom XML DTD or Schema, rather than just >> a simple plist. > > Certainly. That was just something quick to get the concept seeded. From my personal preferences, almost anything is better than the plist format :S But in practice I think that HTML 5 currently gives the ability to do this in simple javascript, actually providing a DOM attribute explaining which keys the browser assigned. I think that this is still under-specified, but a huge improvement on HTML 4, and with the significant advantage over the XHTML access element that it is more or less compatible with what works today. (I have pumped some comments through Opera internally on things that I think need to be fixed still, but I feel that HTML 5 is now heading in the right direction and is farther along than anyone else). >> 2. How would you define the down arrow key? You may need a reserved >> NMTOKEN or to use '40' as the keyCode. However, defining some >> characters as accesskeys (@, $, %, &) may be more difficult to define >> with keyCodes since they may require a modifier key and tend to change >> key positions depending on locality. >> If you continue on this path, start thinking about possible NMTOKENs >> that may be useful in addition to the literal characters you've >> defined for keystrokes. > > There are definite issues with characters requiring modifiers to be > produced. And even more issues once you start getting into encodings. (We > wrestle with these pretty much constantly in terms of reading and writing > text.) Unfortunately, I don't have a good answer but can certainly > suggest that simpler is better, and a primary consideration is to avoid > key-combos that the would be intercepted by the browser. So perhaps an > initial, smaller character set might be worth considering. 10 years of research has shown that the key-combos which are not used by the browser is exactly the empty set. So accesskey activation has to take browser UI into account and not interfere. This means it comes down to each browser to determine how this is done. Opera for desktop can be set to use the entire keyboard, including all modifier combinations, iCab by default left virtually all the bare keys for accesskeys. The HTML 5 approach already goes a long way towards dealing with this - and with what happens when moving from desktop (with 30-odd cyrillic characteres and 10 digits all available as single keystrokes) to Opera mini on a typical 12-key phone, to a device with a touch screen and no keys at all. The issue of what keys are *actually* available to a user is a critical one, and HTML5 actually provides the first intelligent approach inside a spec to solving that. The answer is that a bunch of things have to be left to the implementation - which also places on the implementation the responsibility to say what it did - which is where the HTML 5 version is really nice already. One of its current shortcomings is that it expects single unicode codepoints as values, which I think is not necesary nor ideal (as a UA/language requirement - it probably is a good authoring practice). 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
Received on Tuesday, 16 June 2009 21:12:26 UTC