Re: Looking for access to keyboard shortcuts for web apps

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