Last modified: 2014-04-17 14:51:21 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 477 - Accesskeys conflict with browser keyboard shortcuts
Accesskeys conflict with browser keyboard shortcuts
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low normal with 10 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility
: 2430 3963 6945 7088 8145 11864 16718 30102 (view as bug list)
Depends on:
Blocks: javascript
  Show dependency treegraph
 
Reported: 2004-09-13 15:51 UTC by Scott Merrill
Modified: 2014-04-17 14:51 UTC (History)
25 users (show)

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


Attachments

Description Scott Merrill 2004-09-13 15:51:05 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.
Comment 1 JeLuF 2004-09-13 16:10:26 UTC
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.
Comment 2 Scott Merrill 2004-09-13 16:13:18 UTC
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.
Comment 3 Brion Vibber 2004-09-13 19:13:19 UTC
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.
Comment 4 JeLuF 2004-09-13 19:18:14 UTC
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?)
Comment 5 Tom Gilder 2004-10-05 14:18:42 UTC
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.
Comment 6 Benjamin Rodgers 2004-11-17 04:22:36 UTC
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.
Comment 7 Rowan Collins [IMSoP] 2004-11-17 16:06:11 UTC
(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).
Comment 8 Benjamin Rodgers 2004-11-18 06:06:31 UTC
(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.
Comment 9 Ævar Arnfjörð Bjarmason 2005-04-14 22:42:37 UTC
Shouldn't this be marked as INVALID since it's really a Mozilla problem and not
ours.
Comment 10 Brion Vibber 2005-04-14 22:53:27 UTC
The spec is broken by design, and it's our fault for using them when we know they conflict five ways to 
sunday.
Comment 11 David Ascher 2005-05-02 23:04:22 UTC
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.
Comment 12 Brion Vibber 2005-06-17 02:20:49 UTC
*** Bug 2430 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2005-11-16 22:46:01 UTC
*** Bug 3963 has been marked as a duplicate of this bug. ***
Comment 14 Axel Boldt 2005-11-19 07:46:30 UTC
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.
Comment 15 Niklas Laxström 2005-11-19 18:50:46 UTC
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.
Comment 16 Brion Vibber 2005-11-19 19:38:19 UTC
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.
Comment 17 David E. Siegel 2005-11-21 22:29:18 UTC
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.
Comment 18 Brion Vibber 2006-01-22 04:17:14 UTC
Restored from flood attack.
Comment 19 Catherine Munro 2006-01-22 22:35:16 UTC
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]]
Comment 20 David E. Siegel 2006-01-23 01:08:11 UTC
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.
Comment 21 Michael Zajac 2006-02-20 21:55:04 UTC
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]

Comment 22 Michael Zajac 2006-02-22 14:56:50 UTC
See also bug 5051: Accesskeys should not require Javascript.
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-09 03:02:49 UTC
(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).
Comment 24 Michael Zajac 2006-04-09 03:41:12 UTC
> 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.
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-09 03:45:28 UTC
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.
Comment 26 Jonas Due Vesterheden 2006-04-24 00:46:34 UTC
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. 
Comment 27 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-24 18:06:23 UTC
Don't Home and End work for going to the start and end of a line? . . .
Comment 28 Mark Clements (HappyDog) 2006-04-24 18:23:44 UTC
... 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.
Comment 29 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-24 18:35:33 UTC
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.)
Comment 30 Brion Vibber 2006-04-25 01:54:44 UTC
There are no access keys reserved for web sites. The access key mechanism, while well-meant, is totally
non-portable and unreliable.
Comment 31 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-08 04:55:02 UTC
*** Bug 6945 has been marked as a duplicate of this bug. ***
Comment 32 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-21 21:11:55 UTC
*** Bug 7088 has been marked as a duplicate of this bug. ***
Comment 33 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-22 04:31:15 UTC
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?)
Comment 34 Michael Zajac 2006-08-22 04:52:09 UTC
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.
Comment 35 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-24 04:59:15 UTC
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).
Comment 36 DJ 2006-10-23 05:41:38 UTC
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)
Comment 37 Jason Doucette 2006-10-23 15:04:54 UTC
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
Comment 38 Michael Zajac 2006-10-23 18:13:18 UTC
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
Comment 39 Alphax 2006-11-10 08:10:40 UTC
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.
Comment 40 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-10 13:22:53 UTC
Using an accesskey shortcut like Alt is what *causes* this bug.
Comment 41 DJ 2006-11-10 15:03:00 UTC
Wooohoooo!!  It looks like Firefox 2.0 doesn't let websites take ownership of
its built-in shortcut keys.  Fantastic!
Comment 42 Brion Vibber 2006-12-04 07:42:59 UTC
*** Bug 8145 has been marked as a duplicate of this bug. ***
Comment 43 morel=mz 2006-12-04 09:22:37 UTC
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.
Comment 44 Michael Zajac 2006-12-04 19:05:19 UTC
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.
Comment 45 Richard Jones 2006-12-16 12:01:12 UTC
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.
Comment 46 John Foliot 2007-01-22 23:45:02 UTC
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
Comment 47 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-16 15:47:24 UTC
*** Bug 11864 has been marked as a duplicate of this bug. ***
Comment 48 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-16 15:49:39 UTC
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.
Comment 49 Huji 2007-11-16 19:29:41 UTC
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.
Comment 50 Huji 2008-02-19 21:16:09 UTC
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
Comment 51 BruceA 2008-12-19 23:24:47 UTC
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?
Comment 52 Brion Vibber 2008-12-19 23:46:47 UTC
*** Bug 16718 has been marked as a duplicate of this bug. ***
Comment 53 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-20 23:30:02 UTC
(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.
Comment 54 Brion Vibber 2008-12-22 01:31:12 UTC
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
Comment 55 Michael Zajac 2009-02-25 20:48:45 UTC
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.

Comment 56 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-26 00:03:49 UTC
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.
Comment 57 David E. Siegel 2009-02-26 00:47:19 UTC
(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
Comment 58 Niklas Laxström 2009-02-26 07:14:30 UTC
(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.
Comment 59 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-26 15:07:04 UTC
(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.
Comment 60 David H Dennis 2009-02-26 18:20:00 UTC
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
Comment 61 Brion Vibber 2009-02-26 21:20:10 UTC
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.)
Comment 62 David H Dennis 2009-02-26 21:47:54 UTC
Thank you, Brion!  That addressed my question and objection.

D
Comment 63 Michael Zajac 2009-02-26 21:48:32 UTC
(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/.
Comment 64 Happy-melon 2009-07-24 11:09:04 UTC
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...?
Comment 65 Rodan BURY 2010-09-26 16:36:43 UTC
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]).
Comment 66 Brion Vibber 2011-07-28 23:21:57 UTC
*** Bug 30102 has been marked as a duplicate of this bug. ***
Comment 67 Quim Gil 2014-04-17 14:51:21 UTC
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.

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


Navigation
Links