W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Accesskey in Web Forms 2

From: Matthew Thomas <mpt@myrealbox.com>
Date: Sat, 28 Aug 2004 19:54:42 +1200
Message-ID: <854ACA76-F8C7-11D8-8A8C-000A95AD3972@myrealbox.com>
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.)

> ...
> 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>.)

-- 
Matthew Thomas
http://mpt.net.nz/
Received on Saturday, 28 August 2004 00:54:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC