Last modified: 2014-04-17 14:51:21 UTC
The page editing quicktags conflict with the shortcuts used for keyboard navigation in Mozilla Firefox. While editing a page in a wiki, I might decide I want to go somewhere else, and thus press ALT-D to focus my cursor in my Firefox address bar -- but instead the wiki asks me if I want to delete the page. I have "solved" this by unchecking the "Show edit toolbar" option, but some shortcuts are still clobbered. ALT-F focuses the Wiki search, instead of accessing the browser's File menu.
Is this a bug in Mozilla or in Mediawiki? They map document specific shortcuts (D => Delete) to the same modifier (Alt) than its menu bar shortcuts. To make things worse, Mozilla is available in different languages, using different shortcuts for the menubar (e.g., in German: D => Datei == File), so we can't simply avoid the characters used for the menu. Mozilla should use different modifiers for different tasks. Or we should disable shortcuts to avoid user irritations.
It would be fine with me if there were a user preference to disable all keyboard shortcuts within MediaWiki. I'm sure many people use them; but I don't.
JeLuF, this is a known problem with MediaWiki: it overrides lots of shortcut keys which it should not which interferes with editing in different ways on various browsers.
Brion: I know, we shouldn't use features that break some browsers. I think it's a Mozilla bug nevertheless, they shouldn't allow overloading of their keyboard shortcuts. Other browsers solved this in a better way: Alt for browser shortcut, Ctrl for document shortcuts. (Did I mention that I opposed using keyboard shortcuts before they were added?)
This also happens with IE: alt+D was originally an IE shortcut, and often-used. I often find myself with a "delete this page?" message when just trying to go to another address when using IE.
First off I'd like to point out that "page editing" on a wiki in this use means "general browsing". If anybody has been paying remote attention to accessibility concerns, this accessibility failure has definitely done well to negate that effort. (In reply to comment #1) > Is this a bug in Mozilla or in Mediawiki? /style/wikibits.js function akeytt I'm fairly sure this is where the keys get mapped and it looks like the default modifier is alt... which seems like a terrible default given that every Windows, Gtk (meaning GNOME also), and KDE application uses the 'alt' modifier to access the application menu. Why on earth would would anyone want to possibly default to an option that could potentially "break" most browsers? Meanwhile I'll also be registering with Bugzilla soon to poke my nose around their business. Given that the core browser and the the browser application are two different projects, I can imagine some difficulty on their behalf to work around this kind of issue. (In reply to comment #4) > Brion: I know, we shouldn't use features that break some browsers. I think it's > a Mozilla bug nevertheless, they shouldn't allow overloading of their keyboard > shortcuts. Other browsers solved this in a better way: Alt for browser shortcut, > Ctrl for document shortcuts. if(is_safari || navigator.userAgent.toLowerCase().indexOf( 'mac' ) + 1 ) pref = 'control-'; if(is_opera) pref = 'shift-esc-'; No, the other browsers apparently didn't handle shortcuts better, the script just made sure not to break them.
(In reply to comment #6) > > Is this a bug in Mozilla or in Mediawiki? > > /style/wikibits.js > function akeytt > > I'm fairly sure this is where the keys get mapped and it looks like the default > modifier is alt... No, no, no! The modifier keys are added using an HTML attribute called, I believe, "accesskey"; MediaWiki does not specify any modifier key at all. That JavaScript is just so that the *tooltips* show the right hint of how to use the shortcut, which varies from browser to browser. This is very much an issue with how Mozilla chooses to assign shortcut keys, and not a MediaWiki bug. (Not that I was involved in coding the feature, so correct me if I'm wrong; but there definitely is such an attribute, and it does just define what letter to use, not the modifier to go with it). > Why on earth would would anyone want to possibly default > to an option that could potentially "break" most browsers? Quite. Go shout at some Mozilla developers for making this mistake. > Meanwhile I'll also be registering with Bugzilla soon to poke my nose around > their business. Given that the core browser and the the browser application are > two different projects, I can imagine some difficulty on their behalf to work > around this kind of issue. I don't see why; all they need to do is change the key mappings, wherever they are in the code - if it's in different places in different branches (SeaMonkey, Firefox, Camino, etc) then there'll be multiple changes to make, but that's not really difficult. The awkwardness will be that the behaviour will change for the end-user, which leads to potential confusion, but if they get it right, it's largely a change for the better, and gets rid of confusion... > if(is_safari || navigator.userAgent.toLowerCase().indexOf( 'mac' ) + 1 ) pref = > 'control-'; > if(is_opera) pref = 'shift-esc-'; > > No, the other browsers apparently didn't handle shortcuts better, the script > just made sure not to break them. Wrong again. Unless I'm very much mistaken that code has *nothing whatsoever* to do with defining the key combination needed. It just sets a string to tell the user (in the tooltip) what key combination the *browser* has defined - which in that example is apparently the odd combination "Shift-Esc-<accesskey>", which at least is unlikely to conflict with anything else! (Glancing at that bit of code confirms this: 'pref' is used to define 'ak', which is then used to define 'n.title'; 'title' being the HTML attribute used for tooltips).
(In reply to comment #7) Tested; you are correct. My apologies to everyone for chunking up this bug report. I'll be taking my harping elsewhere to more appropriate locations. I'm shocked that this is actually a "feature" of Mozilla and Firefox.
Shouldn't this be marked as INVALID since it's really a Mozilla problem and not ours.
The spec is broken by design, and it's our fault for using them when we know they conflict five ways to sunday.
I'd suggest that the use of accesskeys, which is fine for mediawiki as an "app", gets in the way of mediawiki sites as websites. So I'd suggest that they be removed from the "non-author" use cases, such as just wanting to to to a website and read stuff. IOW, I'd suggest that either 1) make it configurable, or 2) take out the accesskeys on the search box and the edit tab, since those seem to hit most people the most. FYI, internally I've hacked the akeytt() function to return early, as I have 20x more readers than authors.
*** Bug 2430 has been marked as a duplicate of this bug. ***
*** Bug 3963 has been marked as a duplicate of this bug. ***
What is the argument against turning the use of accesskeys into a user option, switched off for anonymous users? It seems clear that the feature is only useful for heavy editors and that currently anonymous users are often bitten by the unfortunate and unexpected interaction of Mozilla and Mediawiki. The legalistic insistance on "it's their bug, not ours" forgets that our first and foremost job is to serve our readers.
Local communities could edit the Mediawiki:monobook.js to include only bare minimum of accesskeys and guide users how to add them into their username/monobook.js. There is some accesskey which come from Mediawiki:accesskey-*, but they can be disabled (for everyone) nowdays. So basically the bug is in Firefox and Mediawiki is triggering the bug with default settings, but it can "be turned off" without developer interaction. Isn't that good enough? In my opinion this is WONTFIX, but I assume there is others who want the default behaviour to be changed.
The bug is that: 1) The accesskeys functionality in HTML is poorly defined and inconsistently implemented, such that it's very hard to pick access keys with any assurance that they won't conflict with existing shortcuts. 2) The access keys chosen for use in MediaWiki were particularly poorly chosen, and are known to conflict with existing keyboard shortcuts in many browsers. We should *not* use these conflicting shortcuts. That's wrong, and it's OUR FAULT AND NO ONE ELSE'S. We can complain that it's poorly defined, fine. We can complain that it's poorly implemented, fine. But *WE* are the ones using this known-bad system in a known-bad way, and *WE* have the responsibility to fix it up, either to non-conflicting alternates or otherwise. This is *not* a WONTFIX.
There have been several complaints of the acces key functions interfearing with users of IE as well as other browsers, and that the default behavior preempts very standard key sequences (such as Alt-F for the file menu; and Ctrl-W for window switching. This has been raised several times on the General Complaints page on en, and at the en Village pump. I think that the default behavior should not interfear with known default key assignments by major browsers. If this were made a prefernce item, switched off for user not loged in, that would be a very different matter.
Restored from flood attack.
Is the point of this bug to change the accesskeys, rewriting the list (http://meta.wikimedia.org/w/index.php?title=-&action=raw&gen=js) altogether, or to make the accesskeys user-controllable? Should a separate bug be opened to allow a user to control accesskeys? At least a preference checkbox to turn off keyboard shortcuts altogether (override the "ta" array in the site-wide javascript with "ta = false;"); at most a new [[Special:Preferences]] page to rewrite or disable individual keys. See also: [[Wikipedia:Keyboard_shortcuts#Disabling_or_changing_shortcuts]] [[Help:User_style#Changing_access_keys]]
The point of this bug, IMO, is that the dafault behavior should not conflict with standard default shortcuts on major browsers. This could be accomplished by rewriting the list to use only keys which do not so conflict; or by a user preference checkbox to turn the shortcuts on/off (which should IMO default to OFF); or by providing a preference page that allows the user to fully configure shortcuts. The third option would IMO be ideal, but if either of the first two would be simpler/easier/quicker, they would solve the problem.
This is a long-standing and common situation, and it doesn't seem reasonable for a web site to ask a browser developer to conform to their access-key scheme. May as well get after Microsoft for making control keys operate keyboard shortcuts. As a rule, using numbers for accesskeys is safer, and there are some attempts to standardize the scheme. See: * [http://diveintoaccessibility.org/day_15_defining_keyboard_shortcuts.html Dive Into Accessibility Day 15: Defining keyboard shortcuts] * [http://www.cs.tut.fi/~jkorpela/forms/accesskey.html Jukka Korpela: Using accesskey attribute in HTML forms and links]
See also bug 5051: Accesskeys should not require Javascript.
(In reply to comment #14) > What is the argument against turning the use of accesskeys into a user option, > switched off for anonymous users? > > It seems clear that the feature is only useful for heavy editors and that > currently anonymous users are often bitten by the unfortunate and unexpected > interaction of Mozilla and Mediawiki. > > The legalistic insistance on "it's their bug, not ours" forgets that our first > and foremost job is to serve our readers. Agreed. (In reply to comment #21) > As a rule, using numbers for accesskeys is safer That screws with Numpad entry of Unicode for Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=257478).
> That screws with Numpad entry of Unicode for Firefox (see > https://bugzilla.mozilla.org/show_bug.cgi?id=257478). Actually, I believe it screws with Unicode entry in Windows -- isn't it a problem in MSIE too? Mac Firefox doesn't work this way, but instead relies on Mac OS's Unicode facility. I don't know about Unix/Linux Firefox, and I don't know about other Windows browsers, however.
vBulletin has numbers as accesskeys. Entering characters via the numpad works fine in IE, entering them in Firefox screws things up. Furthermore, according to that bug entry, the behavior is a Firefox regression. So I don't think it's Windows-related in any way.
I think the accesskeys are horrible! I'm using Safari on OS X, and have gotten very used to using shortcuts like ctrl-a (go to the start of current line) and ctrl-e (go to the end of a line). None of these work as expected when editing a page in a Wiki, and I have lost what I've written several times when hitting ctrl-e (which when editing a page will reload that same edit dialog, but with all the changes gone). I've been fiddling around with user:me/monobook.js and setting "ta = false;", but to no avail. Please, please, please add a preference to turn off the accesskeys.
Don't Home and End work for going to the start and end of a line? . . .
... yes, but that's not the point. We should not require our users to unlearn their long-term habits. That's like asking someone to wear their watch on the other wrist.
Well, no, of course not. I'm just saying. Probably Mr. Vesterheden would be well-served by switching anyway, since other sites may use those keys as well, but that's not really relevant to the bugginess here. (I must say that Apple is pretty obnoxious for hogging accesskeys like that, though. There should be an RFC about which accesskeys should be reserved for websites, which for programs, and which for content like websites. If people followed that, it would be really handy.)
There are no access keys reserved for web sites. The access key mechanism, while well-meant, is totally non-portable and unreliable.
*** Bug 6945 has been marked as a duplicate of this bug. ***
*** Bug 7088 has been marked as a duplicate of this bug. ***
Default Firefox 1.5 shortcuts that we might conflict with: B D E F G H T V 0-9 Default Windows IE 6 shortcuts that we might conflict with: A D E F H T V Default Safari shortcuts that we might conflict with: A B D E F H K L N O P T V at least, possibly more (anyone want to help out here?) So these could be reassigned if desired per-browser, or we could work around all of them at once (assuming we don't need more than 12 keys, because that's all we have). Characters that appear to be unconflicted are C I J M Q R S U W X Y Z; we could also make use of punctuation marks if desired. Of course, this set might narrow a bit when other browsers enter the picture, or when I get a fuller picture of Safari. (Opera, by the way, is the one browser that is not completely retarded about shortcut keys; we can't conflict with them. Surely there's a Firefox bug requesting a similar system?)
I don't think there are any shortcuts which use the control key at all in Safari, so there should be no conflict in that browser: they all use the command (clover) key, plus shift and option in some cases. The situation looks the same in Firefox/Mac according to a quick look at the menus, but I'm not so familiar with that browser. Other Mac browsers are probably similar.
Proposed remapping: My talk page: n -> , Watchlist: l -> ' My contribs: y -> \ Log in/out: o -> [ Talk page: t -> ] Edit/view source: e -> ; History: h -> < Delete/undelete: d -> - Search: f -> " Related changes: k -> ~ Special pages: q -> _ Diff: v -> > Preview: p -> ` Any I missed? The others I saw were among the twelve letters I noted before as being possibly unconflicted, or they were punctuation marks. If there are no objections I'll write up a patch (which will be harder than it should be due to localization and splitting accesskey code into at least two parts, but that's neither here nor there).
I would appreciate an option in preferences to turn off all Wikipedia shortcut keys. I don't want to sound like a jerk, but how can any self-respecting development team make a decision like this? How do you just take functionality away from the browser being used to render your site? How does one assume that everyone uses a mouse and no one uses the keyboard? Is it possible that Wiki developers are mouse-centric users, all of them? I'm baffled. I'm sorry for the language. I really enjoy Wikipedia and I think its design is great, in all respects except this one. This one just seems like a big mistake. (check Gmail for a keyboard shortcut scheme that doesn't conflict with browser shortcuts)
I have to agree with DJ. I cannot believe that this breaks common functionality, such as Alt+F. Other people are complaining about losing information via Alt+E. ...losing data because someone decided that a common shortcut should mean something different? Ouch. And we are being told that this cannot be changed or fixed, and we should use alternate shortcuts, such as pressing Alt by itself first, and THEN pressing the second key... ...but, it doesn't work that way. We've already been programmed what must happen when we want an action to occur. It's second nature. We don't think 'Alt+E', we think 'Edit menu'. People will use what they've learned regardless if you tell every last user that they should do it differently. I will never start pressing F after I release Alt. I couldn't if I wanted to. There's only one webpage I use where Alt+F doesn't work, and it's not enough to make me unlearn over a decade of learned behaviour. This is why such shortcuts as Shift+Insert still work within any application made by programmers that understand why this is SO important. I highly recommend the following read for people who disagree. It will be eye opening, I promise. Please spend 10 minutes to do so. Especially if you are involved in the design of an interface that affects millions of people. You will be very satisfied that you did, and you'll have a better, more usable product in the end. Now, who can complain about that? User Interface Design for Programmers Chapter 5: Consistency and Other Hobgoblins http://www.joelonsoftware.com/uibook/chapters/fog0000000061.html
FYI: more detail about Mac keyboard shortcuts: All of the core keyboard shortcuts (undo, cut, copy, paste, etc.) use the command key (a.k.a. clover key or apple key). They don't conflict with web site access keys. (Isn't there a Windows key some of you guys can use for something?) A partial list is here: http://docs.info.apple.com/article.html?artnum=75459 Control keys are for the most part reserved for application shortcuts. However, with the Unix tradition brought from NeXt into OS X, some emacs-style control keys are used in the standard text-editing field, and this is used in the Safari and Opera textarea, which is why Jonas Due Vesterheden is frustrated (Firefox and Camino textareas don't use the emacs shorcuts, so they don't conflict with control-E, etc.). This problem will affect hardcore computer users, but not the average Mac user (who would use command-right-arrow and command-left-arrow instead of control-a and control-e). List here: http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html
For anyone who's having troubles in Firefox 2.0 with accesskeys not working: goto about:config and set "ui.key.generalAccessKey" to eg. 18 (alt) instead of -1.
Using an accesskey shortcut like Alt is what *causes* this bug.
Wooohoooo!! It looks like Firefox 2.0 doesn't let websites take ownership of its built-in shortcut keys. Fantastic!
*** Bug 8145 has been marked as a duplicate of this bug. ***
control-h is conventionally used for backspace+delete, equivalent to delete, or an alternative when delete is used for another purpose (e.g., kill character.) I think its roots and use predate the web and web browsers -- any discussion in terms of web browsers only is missing the scope of the disruption, and just how careless it is to break such a consistently-followed and useful convention. Most applications, including web browsers, adopt the convention, and at worst, ignore control-h. Discussing web browsers, or any particular application or vendor is missing the point. The Bug 477 Summary misses the point in this way. Better: Accesskeys break computer industry keyboard conventions. A glaring bug.
By convention in the "computer industry", do you mean in Windows or Unix, or both? Control-h is not a conventional shortcut in Mac OS X or its predecessors. The Mac (1984) and NextStep (1989) were designed to preserve the control key for its traditional use in terminal applications, so browser accesskeys don't break any common OS keyboard shortcuts.
I'm a died in the wool Emacs users, and Ctrl-A/-E to move to the start/end of a line are what I use. These habits make it infuriating to edit Wikipedia pages. Please please please provide a simple preference to disable all access keys. I don't care whether it's on by default or not, just so long as I can turn them all off.
LOL... do you guys ever actually use WikiPedia, or simply work on it's source code? See: http://en.wikipedia.org/wiki/Accesskey As a principle of that Canadian company, I can tell you that there are really no "safe" accesskeys left. http://www.wats.ca/show.php?contentid=43 However, if the "functionality" that accesskeys provides is so important, than there are scripts out there to hands the mapping to the end user - who should be the one person defining the mapping in the first place. See: http://juicystudio.com/article/user-defined-accesskeys.php and: http://golem.ph.utexas.edu/~distler/blog/archives/000723.html
*** Bug 11864 has been marked as a duplicate of this bug. ***
This is hopeless. We should create user preferences allowing remapping of keystrokes, maybe, and/or turning them off entirely. We can't help conflicting with *something* *somewhere* on *some* platform.
I support the idea of letting the user choose the access-keys. Many of the modern softwares have implemented costumization of keyboard shortcuts in their newer versions, and MediaWiki (as a web software) can do so as well.
In continuatin of bug 11864 (duplicate of this bug) and about the conflict of ALT+SHIFT+P with Windows Media Player: This conflict only happens when Windows Media Player toolbar is switched on. Switching that off will solve the problem. Link: http://www.tech-archive.net/Archive/Media/microsoft.public.windowsmedia.player/2005-09/msg00481.html
the value of navigation via keystroke shorcuts surely cannot be missed on programmers, engineers, techies. Why then has the issue of a Wiki browser misbehaving on access to standard browser shortcuts not been resolved in 4 years?
*** Bug 16718 has been marked as a duplicate of this bug. ***
(In reply to comment #51) > the value of navigation via keystroke shorcuts surely cannot be missed on > programmers, engineers, techies. Why then has the issue of a Wiki browser > misbehaving on access to standard browser shortcuts not been resolved in 4 > years? There *are* no "standard browser shortcuts". That's the problem. Every browser decides on its own shortcuts and decides on what shortcuts to allow web pages to use for accesskeys, in a totally inconsistent, incompatible, and unpredictable manner that changes between different browsers, different platforms, and different versions of the same browser. To even avoid all conflicts *now* we would likely have to change most of our accesskeys to confusing and unmemorable things like punctuation marks. That would be an unreasonable burden on people who use browsers like Firefox and Opera that aren't stupid enough to let websites take over browser shortcuts, and it *still* wouldn't help if IE9 or some new browser extension or who knows what decides to use one of the previously unconflicted keys starting tomorrow.
WebKit (Safari) on Mac is apparently switching from Control to Control+Option to avoid the conflict with Emacs keybindings... unless VoiceOver is enabled, in which case Control+Option conflicts, so it will then use Control! http://trac.webkit.org/changeset/38211 Hurrah for predictability. :P
Safari 4 beta has been released, and the accesskeys meta is changed from control+ to control+option+, to reduce conflicts with OS shortcuts (at least the Mac version; I haven't tested it on Windows). The metakey for accesskeys is in the application's realm, and one application developer has just addressed this issue. Now file your bug reports with Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=303192) and Microsoft. This is not a website bug. If we change a key to accommodate one web browser, we will just break it in some other browser, handheld, or OS that we have never heard of. this bug should be closed INVALID or WONTFIX.
Mozilla fixed this long ago by moving to Alt-Shift-. Opera has always behaved sanely by using Shift-Esc- or something. Now (surprise!) only IE seems to still be causing problems.
(In reply to comment #55) <snip> > This is not a website bug. If we change a key to accommodate one web browser, > we will just break it in some other browser, handheld, or OS that we have never > heard of. this bug should be closed INVALID or WONTFIX. The real bug is that these access keys can be neither changed nor disabled by the user. If they were made a preferece item, particularly if they default to OFF, that would deal with the matter. If a logged-in user could edit the mappings, that would be even better, but that might be technically tricky, i don't know. but disabling them per user shouldn't be hard. if it is, disable them for everyone. don't mark this WONTFIX, fix it by giving the user control. This was asked for three yers ago. -DES
(In reply to comment #57) > The real bug is that these access keys can be neither changed nor disabled by > the user.If they were made a preferece item, particularly if they default to > OFF, that would deal with the matter.If a logged-in user could edit the > mappings, that would be even better, but that might be technically tricky, i > don't know. but disabling them per user shouldn't be hard. if it is, disable > them for everyone. Why should it be off? As the browsers are being fixed, less and less people are running into the problem. I'm pretty much sure they are in the minority already. > don't mark this WONTFIX, fix it by giving the user control. This was asked for > three yers ago. Users have control over their web browsers, we don't. As for the solution, we could add check into Linker::accesskeyAndTooltip of similar. The bad thing is that lots of code is not using it.
(In reply to comment #58) > Why should it be off? As the browsers are being fixed, less and less people are > running into the problem. > I'm pretty much sure they are in the minority already. IE users are still a majority . . . > As for the solution, we could add check into Linker::accesskeyAndTooltip of > similar. The bad thing is that lots of code is not using it. Probably not much. grepping for "accesskey" would turn it up, anyway.
This isn't all about IE users. I am a Safari user, and Safari has emacs command bindings in its windows, which I am accustomed to after decades of using the Emacs text editor for pretty much every character I type. So when I do control-P to go to the previous line, Wikipedia's software, with the best of intentions, previews my composition. There are a few emacs command characters routinely used for me to move around the page that actually invoke Wikipedia commands to zap all of my work and then I have to start over or give up. This is a serious problem for an admittedly tiny minority of people who used the old Emacs editor and have the key bindings tattooed to their fingertips. Being able to turn off those keys, which do me no good whatsoever, would be truly appreciated. Thank you for listening. D
Please note a workaround for disabling the access keys is available on English Wikipedia, and possibly other wikis as a customized gadget setting. Go to [[Special:Preferences]], look in the "Gadgets" tab and click "Disable access keys". (For power users, disabling access keys would make the wiki less accessible by keyboard, so we're in no rush to just run around killing the extremely, extremely, extremely useful access keys when there's no agreement on any details.)
Thank you, Brion! That addressed my question and objection. D
(In reply to comment #60) > This isn't all about IE users. David, it will be very soon. Safari 4 changes the accesskey meta key to control-option. You can download the beta now at apple.com/safari/.
So the final status of this bug is that it has, over the past four years, been reduced to Yet Another Reason Not To Use Internet Explorer...?
Accessibility review of these access keys: Keyboard shortcuts (access keys) are a complicated matter. This feature, in it's current implementations was temporarily abandoned in W3c's WCAG 2.0 guideline. Notably because it conflicts with the shortcuts of assistive technologies. Usage of access keys is currently discouraged in the online contents and applications. But presence of access keys are also a W3c's [[Authoring Tool Accessibility Guidelines]] (ATAG) requirement - the ATAG approach is particularly relevant in MediaWiki's case - where this matter is looked into thoroughly. In particular, ATAG requires the possibility to customize shortcuts. This feature should be implemented in MediaWiki. Currently, their presence in Wikipedia's interface can be problematic for some users and can be useful for others. But more importantly, it misleads developers into thinking that the interface is keyboard accessible. Requirements that needs to be fulfilled in order to be keyboard accessible are not related to keyboard shortcuts ([http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G90 G90], [http://www.w3.org/TR/WCAG-TECHS/F42.html F42], [http://www.w3.org/TR/WCAG-TECHS/SCR35.html SCR35], [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F58 F58], [http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F61 F61]).
*** Bug 30102 has been marked as a duplicate of this bug. ***
Adding some accessibility champions to this report, which seems to be the oldest|relevant a11y bug we have still open. Is this still a problem in MediaWiki 1.23? The report filed by Nemo upstream months ago hasn't moved a bit.
