jeluf wrote:

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.

skippy wrote:

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.

jeluf wrote:

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

tom wrote:

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.

tsylverwind wrote:

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.

rowan.collins wrote:

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

tsylverwind wrote:

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

avarab wrote:

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.

david.ascher wrote:

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.

Siegel wrote:

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.

artslave wrote:

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

Siegel wrote:

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.

michael wrote:

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]

michael wrote:

See also bug 5051: Accesskeys should not require Javascript.

ayg wrote:

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

michael wrote:

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.

ayg wrote:

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.

jonasduevesterheden wrote:

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.

ayg wrote:

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.

ayg wrote:

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.

ayg wrote:

*** Bug 6945 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 7088 has been marked as a duplicate of this bug. ***

ayg wrote:

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

michael wrote:

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.

ayg wrote:

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

donavaughn wrote:

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)

mediazilla wrote:

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

michael wrote:

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

alphasigmax wrote:

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.

ayg wrote:

Using an accesskey shortcut like Alt is what *causes* this bug.

donavaughn wrote:

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

morel=mz wrote:

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.

michael wrote:

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.

rich wrote:

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.

jfoliot wrote:

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

ayg wrote:

*** Bug 11864 has been marked as a duplicate of this bug. ***

ayg wrote:

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

brucesubscription wrote:

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

ayg wrote:

(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

michael wrote:

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.

ayg wrote:

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.

Siegel wrote:

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

ayg wrote:

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

david wrote:

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

david wrote:

Thank you, Brion! That addressed my question and objection.

D

michael wrote:

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

happy.melon.wiki wrote:

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.

Ctrl-option-e (Mac), formerly used to edit or view the source of a page, is not working in Mozilla Firefox either, although it works in Chrome. Could that be due to a conflict with some feature native to the browser? Or is it a bug in MediaWiki?

Thanks, that still doesn't work but you're right it's a new issue.