HTML accesskeys should require key combination (and show overlaid visual indicator in the middle)

NEW
Unassigned

Status

()

Core
Keyboard: Navigation
--
major
12 years ago
4 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

(Depends on: 1 bug, {access})

Trunk
x86
Linux
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
I think our HTML accesskey implementation is generally harmful to keyboard
accessibility.  (Not that any other browsers do it better.)  The most serious
problem is that accesskeys allow the Web page to take over the application-level
shortcuts typically used to access the menubar, which breaks user expectations
and muscle memory and can lead to erroneous and unintentional input into form
controls.  A secondary problem is that there is no visual indication of the
presence of accesskeys, which means they are unlikely to be discovered except
when *unintended*.

Both of these problems could be solved by making accesskeys require a series of
keystrokes.  In particular, the way I think it should work is roughly the following.

Current behavior:
  Currently, the accesskey "Z" is triggered when the user presses Alt+Z.
  Gecko does not add any visual indication of the presence of the accesskey.

Proposed behavior:
  The accesskey "Z" should be triggered by the sequence Ctrl+K, Z.  (I'm
  using Ctrl+K because it's obvious.  Firefox already uses it for the
  search box, but maybe we could get it back.  But if other sensible keys
  are available that would be great.)
  Furthermore, when Ctrl+K is pressed, we should display a visual indication
  of what accesskeys are present by showing each accesskey letter at the
  position of the control that it activates (perhaps with the letter on a
  circular or square background, the whole thing at some opacity).
The whole point of HTML accesskeys, as I understood it, was to provide speedy
keyboard access to web-app features using familiar shortcuts. Putting a "get
into web app accesskey mode" step in there seems to pretty much defeat the
purpose, and make accesskeys somewhat irrelevant. (Also, on platforms like Mac
where HTML accesskeys are obtained through CTRL instead of ALT, this would be an
unneccessary step)

Your points are all valid, but I'd prefer trying to find a solution  one where
we only make this an issue for the user in cases where accesskeys conflict, and
further one where we try and keep that set of conflicts to a minimum. The former
can perhaps be handled with some sort of visual indication of the conflict
(maybe a transparent overlay) and a mechanism for resolving it (maybe pressing
ALT+ALT+acesskey for the HTML one, if we think the OS level ones should take
precedence?) The latter should be handled by making it clear to web developers
which accesskeys the browser needs, and which they shouldn't override.
(Reporter)

Comment 2

12 years ago
The accesskeys the browser needs vary by localization and by browser, so it's
effectively all of them.

I sure hope we've given up on the idea that a Web app should be
indistinguishable from a native app.  It's a security nightmare, and I think a
usability nightmare as well.
Indistinguishable, no, but that doesn't mean that we should throw up barriers
that make web apps less functional in terms of UI than native apps.

What about using an additional modifier, instead of a sequence? So Alt+Shift for
accesskeys on w32/linux, Ctrl on Mac.

Also: I like the idea of some visual indicator, especially if it's subtle and
just declares the presence of the accesskeys, but then does something clever
like show a list of available accesskeys in a transparent overlay when the user
presses and holds the invoking modifier (i.e.: Alt+Shift)
(Reporter)

Comment 4

12 years ago
Double-modifier combinations tend to duplicate shortcuts in the system, window
manager, etc.  Alt+Shift *might* be acceptable on Windows (I haven't used
Windows much for about 6 years, so I've forgotten many of the shortcuts); I know
that Ctrl+Shift and Ctrl+Alt+Shift aren't, since the user can create global
shortcuts using them.  There's probably still too much variation in the X11
world to pick any multiple modifier combination, although I could be wrong. 
(GNOME defaults on FC3 include one Ctrl+Alt combination.)
FWIW, after some quick testing it seems that Alt+Shift == Alt on XP.

I note that the HTML 4.0 spec is pretty light on recommendng ways for browsers
to invoke accesskeys, other than to say that they should just use the default OS
mechanism.

Comment 6

12 years ago
I think Alt+shift is acceptable on Windows and Linux, for content accesskeys,
would be acceptable. This was discussed in another bug and the reaction was good.

David, is this something you want to propose for Firefox 1.5 because of security?

Comment 7

12 years ago
David, the highlight HTML accesskeys is bug 56701. It is a tough layout problem.
I proposed a number of patches when I fixed XUL checkbox and radio button
accesskey highlighting that also fixed bug 56701 but those attempts were
rejecting as changing too much of layout. Want to take a look at that problem?

Comment 8

12 years ago
alt-shift is something that windows shortcut keys use (open a properties for a 
shortcut, click the shortcut key field, press and hold shift-alt, note the key 
field changes to "Shift + Alt + ").

shift alone would be fine with me, and for the time being, how about we just 
fix the code to allow shift [i filed this bug somewhere a long time ago] (don't 
hook it up to be used)? crossing the bridge of actually connecting whatever can 
be done later after the paths are available.

Comment 9

12 years ago
(In reply to comment #8)
> alt-shift is something that windows shortcut keys use (open a properties for a 
> shortcut, click the shortcut key field, press and hold shift-alt, note the key 
> field changes to "Shift + Alt + ").
You can put any hotkey there. In that case we shouldn't use Ctrl+shift either.

> shift alone would be fine with me, and for the time being, how about we just 
> fix the code to allow shift [i filed this bug somewhere a long time ago] (don't 
> hook it up to be used)? crossing the bridge of actually connecting whatever can 
> be done later after the paths are available.
That's too confusing. What if you have a <select> <input type="text"> or
<textarea> focused?

Comment 10

12 years ago
(Resummarizing since highlighting is already covered by ye olde bug 56701.)
Summary: HTML accesskeys should require key combination (and show visual indicator in the middle) → HTML accesskeys should require modifier(s) other than Alt
(Reporter)

Comment 11

12 years ago
No, the highlighting this bug is proposing is *very different* from what is
proposed in bug 56701.  Bug 56701 is proposing highlighting that is always
present.  That's hard, and involves messing with the display of the page in very
limited ways.  This bug is proposing an overlay that is present only when the
initial key sequence is pressed.
Summary: HTML accesskeys should require modifier(s) other than Alt → HTML accesskeys should require key combination (and show visual indicator in the middle)
(Reporter)

Comment 12

12 years ago
(If you disagree with what I'm saying, please mark the bug wontfix, don't morph
it into something totally different.)
(Reporter)

Updated

12 years ago
Summary: HTML accesskeys should require key combination (and show visual indicator in the middle) → HTML accesskeys should require key combination (and show overlaid visual indicator in the middle)

Comment 13

12 years ago
I don't own the Keyboard Navigation component, so I'm not wontfixing 
anything. But from a usability POV, "highlight access keys too late for it 
to be useful" would be best as a duplicate of "highlight them all the time".
(Reporter)

Comment 14

12 years ago
The power to morph bugs into something completely different and the power to
mark wontfix are essentially equivalent, so marking wontfix for mpt, who seems
to fear the power of the wontfix button, and who seems to agree with the other
commenters.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
For what it's worth, the fact that our accesskey key combination conflicts with our own keyboard shortcuts means that pages with accesskeys make the browser itself much less usable.  For example, I can't get to the Edit menu on this very bug page because there's an accesskey for "e" in the page.

mpt, aaronlev, beltzner, since you don't like dbaron's proposal (which is the ONLY one I've seen in a few years now that promises to make accesskeys somehow coexist with our own UI), what are your suggestions for making this suck a little less?

Comment 16

12 years ago
As far as I know, every non-Mac browser has become less usable in direct proportion to the degree it has tried to make accesskey= usable. A page containing accesskey="d" breaks Alt+D's normal function in Windows Internet Explorer and Firefox identically; Opera solves this problem using Shift+Escape, but at the expense of making accesskey= much slower to use. My best ideas for making accesskey= usable on non-Mac platforms have been described for the past five years in bug 51940 comment 4 and bug 56701, but if they are not enough (which wouldn't surprise me, since they don't solve the Alt+D problem), my next suggestion is to drop support for accesskey=. I don't think there should be any shame in saying "sorry, the W3C specced it, and we tried it, but it just wasn't practical".
I think making accesskeys slower to use (which was the suggestion made in this bug) sounds ok to me.  Hence me commenting on this bug.
(In reply to comment #15)
> mpt, aaronlev, beltzner, since you don't like dbaron's proposal (which is the
> ONLY one I've seen in a few years now that promises to make accesskeys somehow
> coexist with our own UI), what are your suggestions for making this suck a
> little less?

Of all of these, I've kind of liked timeless' simple "use Shift" idea, although it does require that focus isn't in a text input area of the page. Aaronlev, does that truly screw things up from an accesibility perspective?
(Reporter)

Comment 19

12 years ago
Why is dropping the feature entirely acceptable when making it slightly slower to use is not acceptable?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 20

12 years ago
Because once something has been made sufficiently slow or non-obvious, the majority of times it is used will be accidents. And unfortunately, I don't think any accesskey modifier or mode exists that would be both fast enough and obvious enough to be used more often intentionally than unintentionally. (Meanwhile, find-as-you-type followed by (Shift+)Tab could be made to perform this function a little more slowly, but much more universally.)

Comment 21

11 years ago
*** Bug 330400 has been marked as a duplicate of this bug. ***

Comment 22

11 years ago
(In reply to comment #16)
> As far as I know, every non-Mac browser has become less usable in direct
> proportion to the degree it has tried to make accesskey= usable.

the mac is no exception here; accesskeys still override emacs keybindings.

> Opera solves this problem using Shift+Escape,
> but at the expense of making accesskey= much slower to use. 

not really, since Shift+Escape can be changed to anything else via keyboard customization.  e.g. [ctrl-space, key] seems to me to be just as good as [ctrl-mod2+key] (s/ctrl/alt/g for windows/GliNUx).

Updated

11 years ago
Status: REOPENED → ASSIGNED

Updated

11 years ago
Assignee: nobody → pilgrim
Status: ASSIGNED → NEW

Comment 23

11 years ago
(In reply to comment #5)
> FWIW, after some quick testing it seems that Alt+Shift == Alt on XP.

That's due to a limitation in our accesskey handling code which could quite easily be fixed (see the attachments to bug 340902 and attachment 226623 [details] [diff] [review] to bug 128452).

Updated

11 years ago
Assignee: pilgrim → zeniko
Keywords: access

Comment 24

11 years ago
*** Bug 332795 has been marked as a duplicate of this bug. ***

Comment 25

11 years ago
I'd rather WONTFIX this bug in favor of bug 340902 (using the hardly used Alt/Ctrl+Shift modifier combination for content accesskeys).
Assignee: zeniko → nobody
Here are a few URLs that uses accesskeys systematically.
http://www.robodesign.ro/site/index.php
http://www.pixl8.co.uk/index.cfm/pcms/site.home/
http://www.nhm.ac.uk/index.html
http://www.northyorks.gov.uk/public/site/NYCC/menuitem.1df599f14619e9412ff8911040008a0c
http://www.micatholicconference.org/
I have a WIP that implements this. It traverses the document collecting
elements that has an 'accesskey' attribute and builds a popup-menu from that.
The menu items get the same accesskey, so you can just type the key without
modifiers to activate it. If the element has a 'title' attribute then
that is added to the label too. It's very much like the menu in Opera 9
that you get with Shift+Esc.  Here's a screenshot:
http://img221.imageshack.us/my.php?image=303192vd0.png

Comments?

Comment 28

11 years ago
> Furthermore, when Ctrl+K is pressed, we should display a visual indication
> of what accesskeys are present by showing each accesskey letter at the
> position of the control that it activates (perhaps with the letter on a
> circular or square background, the whole thing at some opacity).

Konqueror implements this, IMHO, perfectly.  Tap Ctrl to display the accesskeys, then strike the desired accesskey.  In addition, it assigns unassigned accesskeys dynamically to other controls on a first-seen-first-served basis.  This way:

* The web site can assign accesskeys to the most common links/controls, and
  konqueror can fill in some of the rest (up to the rest of the unassigned
  [a-z0-9] bindings).
* No chording needed (which seems disabled-friendly)
* Completely avoids the conflict with existing key combinations.
* Works so well for me that that I fall back on it when konqueror's
  find-as-you-type (which works excellently in Firefox and Opera) is flaky.
* Also works well enough that I can usually navigate 'prev' and 'next'
  links, even when those haven't been assigned 'link' attributes or
  accesskeys.  Opera has bindings for 'prev' and 'next', firefox has
  'linktoolbar'; konqueror doesn't have these, but its accesskey
  implementation is usually good enough to use instead. 
* See also http://bugs.kde.org/show_bug.cgi?id=123319 for something it
  could implement to make it even better.

Comment 29

11 years ago
I didn't understand the distinction between content accesskeys and html accesskeys (and general accesskeys?).  My apologies for the tangential add.

Comment 30

10 years ago
Krishna: Content accesskeys == HTML accesskeys. General accesskeys are those that Firefox itself uses (like Ctrl+F for find, Alt+F for File menu etc.)

I quite like Mats' approach shown in comment #27. It's still way slower than Alt+Shift+Something, but way better than nothing. Ant it would work in ALL cases independently of keyboard layout and other factors. Maybe it could find its way into the interface, after some retouching (e.g., try to underline an existing capital letter first, then small letter, and only in case both are absent, state the accesskey letter explicitly). Maybe this could become a submenu of the context menu, or a separate item in main menu?

Comment 31

10 years ago
Well, since this bug is showing NEW, even though it's 2 years old, I assume *it* is not the bug which engendered the 2.0.0.9 release notes entry:

HTML Access Keys now require Shift-Alt

?

I'm one of the people who, while understanding perfectly well what the implications might be of allowing HTML "apps" to override browser-default hotkeys, also believes that the whole point of HTML apps is that you have to be able to make them work like traditional local apps, or the training hill is too hard to get people over.

So *which* application of the Principle of Least Astonishment is the more important one not to screw with?  Well, I'd say that's the domain of the person who installed the browser.

Can we at least get an about:config knob to return to the old Alt- behaviour, at the users option?  Best would be a list of sites for which it works that way, I suspect, but that's an even bigger implement.
(Reporter)

Comment 32

10 years ago
That doesn't belong in this bug.  It should probably be filed as its own bug unless there's an appropriate one already.

Comment 33

10 years ago
Ok.  I put a thinko in my opening sentence.  So I can't bitch about that reply.  I'll try again, though:

Is *this* the bug which caused that change in 2.0.0.9?

If not, can anyone more effectively than I identify which bug it *was* so I know where to comment?

I've already commented to Hendrix that the release notes should include bug numbers.  I'll comment to you that your response is a bit sharper than is strictly necessary.  I *opened* with "where should i put this?"; I really did.

Even if I can't type.
(Reporter)

Comment 34

10 years ago
I don't know the answer to "where should I put this?" but the answer is definitely NOT here.  Please don't add further comments to this bug, as it just makes this bug more confusing and less likely to be fixed.

Comment 35

10 years ago
The question wasn't "where should I put this".  

Clearly, I'm not going to get an answer to the actual question, even from someone who appears a) to be a developer b) in the area of the issue I care about, so c) I'm off the CC list, and you have a nice day.

Updated

10 years ago
Duplicate of this bug: 395203
This would be the best way to solve bug 359638 comment 59.

Comment 38

8 years ago
FYI: Safari 4 beta just came out, and it has changed the accesskeys meta from ctrl+ to ctrl+opt+ (that's ctrl+alt+ to some), to reduce OS keyboard shortcut conflicts.
Depends on: 728103

Updated

4 years ago
Depends on: 824478
You need to log in before you can comment on or make changes to this bug.