[whatwg] Accesskey in Web Forms 2

[James Graham]

Derek Featherstone wrote:

>On Wednesday, November 10, 2004 10:13 AM, Matthew Thomas wrote:
>
>  
>
>>Non-conflicting keyboard shortcuts could be created by the user with
>>the help of the UA (as in my original example), or by the UA with the
>>help of the user (as in my example above). What accesskey= does,
>>however, is to place the responsibility of creating shortcuts on the
>>author -- *the only party* involved who can't possibly know enough to
>>do a decent job of it. 
>>    
>>
>
>That's exactly what I've been saying all along, though nobody ever seems to
>agree with me. The concept of keystroke access is what needs to be
>preserved. The concept of author defined keystrokes needs to be coupled with
>user defined - the author needs to have sole responsibility for that
>decision to be removed from their realm.
>
>I still like the XHTML 2 proposal of the access attribute:
>
>For single page:
>1. Authors define key access points for items in their documents (their
>search form, individual form fields, other forms, whatever)
>2. Authors provide a list of keystrokes as suggestions for keys that bind to
>those access points (an XML file perhaps?)
>3. User Agents provide the ability for a power user to accept those keys or
>override them and store that preference. This could be on a site by site
>basis for situations where you are doing data entry on a specific
>application over and over. This would account for conflict, and for user
>preference -- some users may choose different keystrokes based on their
>dominant hand, for example.
>
>  
>
What's the difference between that and the current situation? As far as 
I can tell you've effectively recreated accesskey except:
a) The keybindings are suggestions rather than absolutes (a trivial 
change to the existing semantics of accesskey)
b) You've invoked a seperate file for UAs to load and parse to get 
accesskey information
c) You've lost backward compatibility

I still haven't seen any eveidence that the problems with accesskey are 
more than just over-specific language in the html 4 spec. Unless there 
is a major problem I haven't noticed, /all/ the WebApps spec needs to do 
is to state that
a) The author provided keybindings are suggestions, not absolutes (I 
feel a UA should ignore accesskey entirely if the UA authors believe 
this serves the needs of the user-base better)
b) The UA should act in such a way as to avoid key conflicts

Specifying that UAs _must_ allow per-site keybindings and so on is going 
into the realm of specifying UA design. The spec should constrain UA 
authors less  - so they can develop solutions that meet the needs of 
their users - not more. In fact, I think my earlier examples were a 
little strongly worded (using _should_ where "may wish to" would be 
better). The only _should_'s I would have are _should_ provide a 
mechanism to avoid key conflicts (e.g. by reassigning author-specified 
accesskeys to unused combinations) and _should_ provide information 
about the accesskeys defined on the current page.