[whatwg] Accesskey in Web Forms 2

[Ian Hickson]

On Sat, 28 Aug 2004, Matthew Thomas wrote:
> On 27 Aug, 2004, at 5:39 AM, Ian Hickson wrote:
> > On Sun, 22 Aug 2004, Matthew Thomas wrote:
> > ...
> > > (Though as I said before, I'd prefer that the spec discourage UAs 
> > > from paying attention to the attribute at all, and authors from 
> > > using it, in lieu of actually removing it.)
> > 
> > What do you do for users who can't use pointing devices?
> 
> For navigating across small distances, normal Tab navigation. For 
> navigating across large distances, let the UA provide access mechanisms 
> that are appropriate for the particular device and operating 
> environment. So as not to be accused of "allowing 'user agent vendors to 
> create their own solutions' [while] there is no practical solution for 
> the platforms some user agents are running on", I'll give an example 
> that could work for all graphical UAs.
>
> Graphical UAs could provide a "Set Shortcut..." menu item (though its 
> keyboard equivalent would be used more often than the menu item itself), 
> for you to invoke when focus was on a control that you would often want 
> to focus in the future. The UA would ensure (in a way Web authors 
> cannot) that the shortcut you entered was not a reserved one. The UA 
> would then display the shortcut at the end of the <label> (or in the 
> absence of a <label>, perhaps immediately *following* the element so as 
> to run the least risk of disturbing its alignment relative to other 
> controls). Ideally UAs would display it in a way that didn't look like 
> an accesskey, because accesskeys are something else.
> 
> Then whenever you visited a page apparently belonging to the same 
> application (i.e. a page which contained a <link rel="parent"/"up"> or 
> an <a rel="parent"/"up"> with the same href value, or failing that, 
> which contained a <link rel="home"/"front"/"top"> or an <a 
> rel="home"/"front"/"top"> with the same href value, or failing that, 
> which had the same host), a form control on that page with the same 
> id/name would retain the same shortcut.
> 
> (A minor benefit of this approach is that shortcuts you set yourself are 
> more likely to be remembered than accesskeys set by an author.)

Yeah, that makes sense. So we're saying access keys should be completed 
deprecated in HTML?


> > The problem is that, well, people want keyboard access shortcuts. This was
> > mentioned in another thread; Pine, for instance, has very fast key-based UI,
> > and it would suck if there was no way to do something as quick in HTML.
> 
> If this is suckiness, WF2's repetition model -- or any repetition model, 
> come to that -- is irretrievably sucky: you can't expect every row to 
> have unique accesskeys no matter how many rows are added. (Cf. 
> <http://bugzilla.mozilla.org/show_bug.cgi?id=49334#c65>.)

Indeed not, but you could have keys for adding or removing rows.

People want to be able to do stuff with the keyboard, e.g. GMail wants to 
be able to implement Pine-like keys. Clearly, that won't work across all 
devices. Just as clearly, we can't rely on users to set up all these 
keybindings themselves. Unfortunately I just don't see any other way to do 
it which would not have flaws.

Maybe this is one case where we just want a half-assed solution?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'