Last modified: 2007-01-10 06:04:05 UTC
Basic assistive technology like accesskeys should be in page HTML, available
added as part of a skin.
site- and/or user-preference interface that would change the HTML would be
more widely accessible.
This should be treated as a bug, not a requested enhancement, since it compromises basic
accessibility. I refer to the following WCAG accessibility checkpoints:
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are
turned off or not supported [priority 1] -- the page is usable, but accessibility is reduced
11.1 Use W3C technologies when they are available and appropriate for a task and use the
accesskeys in HTML
8.1 Make programmatic elements such as scripts and applets directly accessible or
compatible with assistive technologies [Priority 1 if functionality is important and not
presented elsewhere, otherwise Priority 2] -- accesskeys in HTML would make keyboard
9.5 Provide keyboard shortcuts to important links (including those in client-side image
maps), form controls, and groups of form controls. [Priority 3] -- again, there's no reason
Changing the title back. This is not about customizability, this is about the unnecessary and
visually display information about accesskeys fails in some browsers, presumably
E.g. the CSS in [[Wikipedia:Keyboard shortcuts#Visual display of shortcuts]] works in
Firefox, but doesn't work on the initial page load in Safari: the shortcuts show up
individually when you mouseover them, or all at once when you go ''back'' to a page.
See also: Bug 5376
Access keys do not work in JAWS versions below 6.0 without the virtual cursor on,
CSS work in JAWS versions below 6.0 using the virtual cursor. Those versions of
JAWS are old (before about September 2004), but they cost hundreds of dollars to
upgrade, and they have some advantages over the newer JAWS versions. Navigating
on the Internet without the virtual cursor is slow and difficult, although it has
some advantages; the virtual cursor was introduced in September 1999 to JAWS
3.31, so most blind computer users who were introduced to JAWS after that time
would find it difficult, if not impossible.
since there is already a way provided for disabling them. There are a few accesskeys
disable those as well. So forcing more access keys on me without an option for
disabling them is not what I consider "fixing a bug".
Access keys (in the browsers I've used that support them, FireFox and IE on Win32)
break basic functionality that I use constantly. Alt-E and Alt-F in particular have
long-standing and nearly universal meaning across most of the Win32 AI, and preventing
these from working when looking at certain web pages is truely annoying.
Until such time as the accesskey feature has matured to the point that popular
browsers realize this problem and support user control over this potentially
distruptive feature, their use should be limitted and, if at all possible, user
I'm "happy" that the inventors of the feature are so tickled with their own creation
that they've published recommendations that it be used heavily. However, nobody
should be surprised that new technology has unforeseen drawbacks or that a feature's
designer / implementor may have a blind spot to its faults.
the existing feature of being able to configure (or at least disable) them. Please
Sorry to hear that the needs of physically handicapped computer users are ruining the Web for you. But you're in luck. Even
convenience, using the same interface.
Fixed in r17297.
Incomplete patch rolled back and branched, should be recommitted in a week or less.
One small separate thing with r17297 is that the accesskey attribute on the <li>
element breaks HTML validity, and gives Tidy warnings.
Results of running W3C validation on a SVN checkout made before r17297 was
Below are the results of checking this document for XML well-formedness and
1. Error Line 142 column 72: there is no attribute "accesskey".
...View the content page [c]" accesskey="c" class="selected new"><a
And results of running Tidy on the same page with the accesskeys:
line 136 column 6 - Warning: <li> proprietary attribute "accesskey"
line 137 column 6 - Warning: <li> proprietary attribute "accesskey"
<...snip 13 other warnings, all the same...>
From http://www.w3.org/TR/html4/interact/forms.html#adef-accesskey , it looks
like the accesskey should be on the <a href>, not the <li>. With that it should
(if I'm reading correctly) be valid HTML and keep Tidy happy too.
According to the spec, accesskey in HTML 4.01, the following elements support the
accesskey attribute: A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.
(XHTML spec is only a diff from HTML4, and I couldn't find anything about accesskey.)
Fixed again in r19036 (slightly more than "a week or less", but oh well). And XHTML validity
ensured, hopefully, in r19045.