[whatwg] Accesskey in Web Forms 2

[James Graham]

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.