Open Bug 303192 Opened 19 years ago Updated 2 years ago

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

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

Desktop
All
enhancement

Tracking

()

Tracking Status
firefox-esr91 --- affected
firefox94 --- affected
firefox95 --- affected
firefox96 --- affected

People

(Reporter: dbaron, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: access)

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

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?
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?
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.
(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?
(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
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)
(If you disagree with what I'm saying, please mark the bug wontfix, don't morph
it into something totally different.)
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)
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".
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
Closed: 19 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?
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?
Why is dropping the feature entirely acceptable when making it slightly slower to use is not acceptable?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.)
*** Bug 330400 has been marked as a duplicate of this bug. ***
(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).
Status: REOPENED → ASSIGNED
Assignee: nobody → pilgrim
Status: ASSIGNED → NEW
(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).
Assignee: pilgrim → zeniko
Keywords: access
*** Bug 332795 has been marked as a duplicate of this bug. ***
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
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?
> 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.
I didn't understand the distinction between content accesskeys and html accesskeys (and general accesskeys?).  My apologies for the tangential add.
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?
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.
That doesn't belong in this bug.  It should probably be filed as its own bug unless there's an appropriate one already.
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.
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.
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.
This would be the best way to solve bug 359638 comment 59.
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: 824478
Component: Keyboard: Navigation → User events and focus handling

This bug was always an enhancement suggestion.
It applies to all main OS types (Win 10, Mac OS 11, Ubuntu 20).
Testpage: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

Relevant to 1st suggestion: Unknown if any shortcuts from local-level / browser-level / web content-level overlap considering the more complicated shortcut keys; see info in test page.
Relevant to 2nd suggestion: There still is no visual representation (other than the button press feedback).

Confirming as an enhancement. Feel free to close if the suggestions reported are invalid.

Severity: major → S3
Type: defect → enhancement
OS: Linux → All
Hardware: x86 → Desktop
You need to log in before you can comment on or make changes to this bug.