michael wrote:

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
without scripts
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts

11.1 Use W3C technologies when they are available and appropriate for a task and use the
latest versions when supported. [Priority 2] -- Javascript is being used, instead of basic
accesskeys in HTML
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-latest-w3c-specs

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
shortcuts accessible to browsers which don't use Javascript
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-directly-accessible

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
to keep this from non-Javascript browsers
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-shortcuts

michael wrote:

Changing the title back. This is not about customizability, this is about the unnecessary and
undesirable dependence of this accessibility feature on Javascript technology. For the other, see
bug 477.

michael wrote:

Another problem with accesskeys being added by Javascript, is that the use of CSS to
visually display information about accesskeys fails in some browsers, presumably
because CSS content property is applied to the DOM before it is modified by Javascript.

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.

Wiki.Melancholie wrote:

See also: Bug 5376

Access keys do not work in JAWS versions below 6.0 without the virtual cursor on,
unless forms mode is on. In fact, no MediaWiki features requiring javascript or
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.

nothingisobvious wrote:

<p>
I hate accesskeys and don't want them, so I prefer having them added by javascript
since there is already a way provided for disabling them. There are a few accesskeys
at wikipedia that are not added by javascript and I'd really like to have a way to
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".
</p><p>
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.
</p><p>
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
configurable.
</p><p>
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.
</p><p>
In summary, if accesskeys are moved out of javascript, then please (please!) preserve
the existing feature of being able to configure (or at least disable) them. Please
also allow configuration / disabling of those that are already not done via javascript.
</p>

michael wrote:

Sorry to hear that the needs of physically handicapped computer users are ruining the Web for you. But you're in luck. Even
if accesskeys were embedded in the HTML, Javascript could just as easily be used to alter or remove them for your
convenience, using the same interface.

The problem here is ''requiring'' Javascript for basic assisting technology to work.

ayg wrote:

Fixed in r17297.

ayg wrote:

Incomplete patch rolled back and branched, should be recommitted in a week or less.

nickpj wrote:

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

rolled back:

Below are the results of checking this document for XML well-formedness and
validity.

1. Error Line 142 column 72: there is no attribute "accesskey".
   
   ...View the content page [c]" accesskey="c" class="selected new"><a

href="/wiki/

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.

michael wrote:

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

http://www.w3.org/TR/html4/interact/forms.html#adef-accesskey

ayg wrote:

Fixed again in r19036 (slightly more than "a week or less", but oh well). And XHTML validity
ensured, hopefully, in r19045.