Last modified: 2007-01-10 06:04:05 UTC
Basic assistive technology like accesskeys should be in page HTML, available to all users of all wikis. It should not require Javascript, and should not be added as part of a skin. The selection of accesskeys could still be ''overridden'' using Javascript, but a 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 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
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.
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.
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.
<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>
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.
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 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.
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
Fixed again in r19036 (slightly more than "a week or less", but oh well). And XHTML validity ensured, hopefully, in r19045.
