[whatwg] Accesskey in Web Forms 2
mpt at myrealbox.com
Sat Aug 28 00:54:42 PDT 2004
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.
More information about the whatwg