Description:
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.

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.

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

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.

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

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.

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.

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

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.

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.

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.

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:

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

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

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.

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?

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:

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

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.

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.

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?

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!

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.

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.

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.

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

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.

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA); code is available under the GNU General Public License (GPL) or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer · CC-BY-SA · GPL