Last modified: 2007-01-10 06:04:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5051 - Accesskeys should not require Javascript
Accesskeys should not require Javascript
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Normal normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on: 5376
Blocks: 367
  Show dependency treegraph
Reported: 2006-02-20 22:04 UTC by Michael Zajac
Modified: 2007-01-10 06:04 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Michael Zajac 2006-02-20 22:04:10 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.
Comment 1 Michael Zajac 2006-02-21 16:39:19 UTC
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

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

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

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
Comment 2 Michael Zajac 2006-02-22 14:56:09 UTC
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.
Comment 3 Michael Zajac 2006-02-22 23:33:18 UTC
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.
Comment 4 Melancholie 2006-03-28 12:40:32 UTC
See also: Bug 5376
Comment 5 Graham87 2006-05-19 09:36:33 UTC
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.
Comment 6 Tye McQueen 2006-07-13 19:58:06 UTC
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".
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.
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.
Comment 7 Michael Zajac 2006-07-14 01:49:14 UTC
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.  
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-30 04:35:00 UTC
Fixed in r17297.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-30 17:27:22 UTC
Incomplete patch rolled back and branched, should be recommitted in a week or less.
Comment 10 Nick Jenkins 2006-10-31 01:12:52 UTC
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

   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 , 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.
Comment 11 Michael Zajac 2006-10-31 05:59:13 UTC
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.)
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-10 06:04:05 UTC
Fixed again in r19036 (slightly more than "a week or less", but oh well).  And XHTML validity 
ensured, hopefully, in r19045.

Note You need to log in before you can comment on or make changes to this bug.