[whatwg] Accesskey in Web Forms 2

[Thomas O'Connor]

Internet Explorer has the proprietary CSS property accelerator to indicate a accesskey [1].  However, I do realise that this isn't
the same as what you are looking for.

[1] http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/accelerator.asp

Thomas O'Connor
me at ocoth.id.au
----- Original Message ----- 
From: "James Graham" <jg307 at cam.ac.uk>
To: "Matthew Thomas" <mpt at myrealbox.com>
Cc: "WHAT WG List" <whatwg at whatwg.org>
Sent: Monday, November 15, 2004 1:24 AM
Subject: Re: [whatwg] Accesskey in Web Forms 2


> Matthew Thomas wrote:
>
> > On 11 Nov, 2004, at 4:26 AM, James Graham wrote:
> >
> >> Matthew Thomas wrote:
> >>
> >>>
> >>> More common, perhaps, would be for UAs to automatically create (and
> >>> display on the page) shortcuts for form controls that had been used
> >>> frequently in the past.
> >>
> >> ...
> >>
> >>> (Well, it's a problem, but only because UA vendors haven't bothered
> >>> to implement the necessary underlining, not because of any spec
> >>> deficiency.)
> >>
> >> ...
> >>
> >>> UA vendors have had over six years to come up with non-awkward
> >>> support for accesskey=.
> >>
> >>
> >> I don't understand. What makes you think that vendors would implement
> >> the complex code/UI needed to enble custom, per-site accesskeys when
> >> you note that they've already failed to implement simple enhancements
> >> that would make the current accesskey scheme more user friendly?
> >
> >
> > Good question. History has shown that UA vendors find it much easier
> > to implement UI features (tabbed windows, download managers,
> > customizable toolbars, etc) than to implement layout engine features
> > (full HTML4 support, full CSS2 support, a "Fit to Window" function,
> > smart table header scrolling, etc). (This is probably also why there
> > are many more graphical UAs today than there are layout engines.)
>
> This is probably because UI features sell the product in ways that
> support for anything beyond basic layout features do not. Accesibility
> features, sadly, don't have the kind of mas-market appeal needed to make
> implementing complex enhancements a priority.
>
> > Unfortunately, implementing accesskey underlining would require a new
> > layout engine feature -- a :-foobrowser-accesskey pseudo-class, which
> > could then be selected for underlining -- which is apparently why UA
> > vendors haven't bothered.
>
> There are other ways of alerting the user to the presence of acceskeys.
> Indeed the solution you propose would not, in general, work because
> accesskeys can be placed on elements where underlining is not a
> possibility (form fields, images, etc.) or where the author style of the
> element is underlined (e.g. many links). A better approach would be to
> provide a list of accesskeys and a visual indication of the function of
> each (e.g. placing a temporary border on the element in question)
>
> > Implementing the automatic shortcut key creation scheme I described
> > above, however, would require only CSS2 generated content (to display
> > the shortcut in the document), and that is already supported in all
> > major layout engines except for Trident.
>
> It would also involve breaking page layouts which is a big no-no. It
> would also involve the browser having a good idea of which key
> combinations are avaliable which, in Mozilla (or Firefox) at least, is
> almost impossible at present (one could, I suppose, implement some
> system so that addons could register the shortcuts they used). Indeed,
> it's hard to imagine that any browser can be certian that some other
> desktop level application (a window manager, for example), is not using
> a particular combination. So the 'solution' wouldn't solve the problem;
> it would still be possible for conflicts to occur (and UI for sorting
> out such conflicts has not yet been developed and shows no sign of being
> developed). Moreover, if one did develop such UI, it would presumably
> work per-page rather than per site (since there is no good way of
> defining a site). This would lead to inconsistent user-experience since
> accesskeys that worked on one page would not on another on the same
> site. Automatically defining accesskeys would only make this last issue
> worse since the keys could not even be expected to exist on the second page.
>
>
>