607224 - Need the ability to have certain menu items appear only for keyboard access

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Currently 12 traditional menu items in Firefox are redundant with controls in the main window, and these menu items are currently only present so that they can be accessed by users who rely on a screen reader or keyboard access.

The 12 menu commands are:

File > Open Location
File > Close Window
File > Close Tab
Edit > Delete (available through a context menu on a text field)
Edit > Select All (available through a context menu on a text field)
Edit > Find Again
View > Stop
View > Reload
History > Back
History > Forward
History > Home
Tools > Web Search

To streamline the Firefox interface, we would like to only display these 12 menu commands if the user is actively using a screen reader, or if they invoked the traditional menu using the alt key.

All of the yellow items in this mockup are planned for removal from the traditional menu once we have the ability to display certain menu items based on the presence of a screen reader or keyboard access: http://people.mozilla.com/~faaborg/files/20100718-firefoxButtonDetails/menuMigration-i1.png

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

This will significantly streamline the Firefox interface if we get this ability, so I'm tentatively requesting blocking to find out if this is something that we want to target for Firefox 4. (we'll likely need more details on how difficult doing this is before we can make a call for that).

Comment 2

[James Teh [:Jamie]]

(In reply to comment #0)
> these menu items are currently only present so that they
> can be accessed by users who rely on a screen reader or keyboard access.
All of these are accessible in other ways. Even if the shortcut isn't known, the option can be accessed (and the shortcut thence discovered) via the keyboard using tab/f6, context menus, etc.
> To streamline the Firefox interface, we would like to only display these 12
> menu commands if the user is actively using a screen reader, or if they invoked
> the traditional menu using the alt key.
I don't think anything specific needs to be done for screen reader users. First, this is all accessible and discoverable in other ways; see above. Second, screen reader users, like any other keyboard user, may well hit alt to invoke the traditional menu, in which case the latter criterion is satisfied. I think screen reader specific UI changes should be avoided, especially given these arguments.

> All of the yellow items in this mockup are planned for removal from the
> traditional menu once we have the ability to display certain menu items based
> on the presence of a screen reader or keyboard access:
When you say "traditional menu" here, do you mean the menu bar or the new Firefox menu? If you mean the former, how else can you invoke it? I thought you had to use the alt key, as the menu bar is hidden by default.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

>I don't think anything specific needs to be done for screen reader users.

Sure, the main consideration is trying to keep the interface consistent for these users, but if they are accessing it only through hitting alt (which makes sense now that I think about it) we can certainly use that as the single criteria for if the redundant commands are shown or not.

>When you say "traditional menu" here, do you mean the menu bar or the new
>Firefox menu? If you mean the former, how else can you invoke it? I thought you
>had to use the alt key, as the menu bar is hidden by default.

traditional menu = xp/2000 menu bar.  The only way to access these commands in Windows 7 is to hit the target in the main window (back/forward buttons, location bar, etc.)  Or to invoke the traditional menu bar with the alt key.

The removal of these commands is primarily for the traditional menu bar on XP and 2000 when it is accessed with the mouse (to simplify the interface).

Comment 4

[James Teh [:Jamie]]

(In reply to comment #3)
> Sure, the main consideration is trying to keep the interface consistent for
> these users,
Again, I'm not sure this is really necessary, since this is all accessible and discoverable through other means. Interfaces do change over time. However, I guess you also mean consistent with other 2000/XP applications.

> but if they are accessing it only through hitting alt (which makes
> sense now that I think about it) we can certainly use that as the single
> criteria for if the redundant commands are shown or not.
Right. To give you some context in case you didn't know, I'm a screen reader developer and user. :) Note that it's also possible to bring up the menu bar with f10 and a menu on that bar can be brought up directly by pressing, for example, alt+f for File. I guess the redundant items should be shown in that case also.

> traditional menu = xp/2000 menu bar.
Ah, so the menu bar is shown by default in XP/2000. I assume the Firefox menu is not shown on those operating systems?

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

>Again, I'm not sure this is really necessary, since this is all accessible and
>discoverable through other means. Interfaces do change over time. However, I
>guess you also mean consistent with other 2000/XP applications.

Also just backwards consistency with how Firefox has previously behaved.  People who rely on screen readers and keyboard only access are likely to be more frustrated with significant UI changes (and rightfully so, since discoverability and memory play such a larger role when you can't very quickly explore an interface or use the mouse to access a target that has moved).

While some of these commands are available elsewhere (like the context menu of the page itself), I generally don't think keyboard and screen reader users are going to be very happy if they lose core functionality on the menu bar.  Removing these redundant commands only really makes sense when the menu bar is viewed as a secondary interface, and the user is expected to usually rely on the surface of the main window for primary actions.  For keyboard only users and users of screen readers, the menu bar becomes a primary interface.  For instance, we tab straight to the location bar, bypassing the back and forward buttons.

>Ah, so the menu bar is shown by default in XP/2000. I assume the Firefox menu
>is not shown on those operating systems?

yeah, the Firefox menu is available as an option, but it is not the default interface on XP and 2000 (for external consistency with the surrounding platform).

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

So we're basically looking for some way to know if a screen reader is attached to our Window, and tie that to some form of selector (JS or CSS) which we can use to determine whether or not the various XUL elements should be created, right?

That's the capability, as I understand it, that we're looking for in comment 1.

Comment 7

[Neil Deakin]

Yes, a selector could be added that could be used to hide/collapse certain menuitems when the menubar was activated using the keyboard. I don't know how to detect whether a screenreader is active but that could be tied to the same selector.

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

I believe it is safe for us to assume that if the user is employing a screen reader, then they are also accessing the menu by using the keyboard, so we can collapse this down just to keyboard access.  Adjusting the summary.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>Yes, a selector could be added that could be used to hide/collapse certain
>menuitems when the menubar was activated using the keyboard. 

Would this have any impact on direct keyboard shortcuts for the otherwise invisible menu items?

Comment 10

[Neil Deakin]

(In reply to comment #7)
> Yes, a selector could be added that could be used to hide/collapse certain
> menuitems when the menubar was activated using the keyboard. 

Actually, this approach isn't feasible as a selector can't be based on some state of a frame. I'll need to think of some other solution.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

If you do resurrect the idea of a selector please consider privacy concerns, especially if we are detecting screen reader usage (not just keyboard). Fortunately it seems everyone is in agreement this bug is really just about keyboard access.

Aside: folks here might also be interested in bug 492557 (post FF4).

Comment 12

[Neil Deakin]

Attachment: implement a menu.openedWithKey flag

This adds a property menu.openedWithKey which can be checked during a popupshowing handler to see if the menubar was activated/opened with a key or not. Note that the indicator is only valid for menus on menubars, but this could be extended later, for instance, to other menus such as context menus.

To demonstrate, the patch shows and hides the Edit->Delete command using this flag.

Thoughts on this api?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 487121 [details] [diff] [review]
implement a menu.openedWithKey flag

>diff --git a/browser/base/content/browser-menubar.inc b/browser/base/content/browser-menubar.inc

>             <menu id="edit-menu" label="&editMenu.label;"
>-                  accesskey="&editMenu.accesskey;">
>+                  accesskey="&editMenu.accesskey;"
>+                  onpopupshowing="document.getElementById('menu_delete').collapsed = !this.openedWithKey">

I imagine we'd likely want onpopupshowing="this.setAttribute('openedWithKey', this.openedWithKey)" and use CSS to actually do the hiding?

Does openedWithKey as-implemented in this patch work on Mac (e.g. what is its value if I use Ctrl+F2+Left+Down to open the menu?)

Does this property only reflect the initial opening of any menu in the menubar? I.e., if I Alt+F to open file, but then mouse over "Edit", what is the value of openWithKey in the edit menu's popupshowing handler? What about when I mouse back over to "File"?

Comment 14

[Neil Deakin]

(In reply to comment #13)
> I imagine we'd likely want onpopupshowing="this.setAttribute('openedWithKey',
> this.openedWithKey)" and use CSS to actually do the hiding?

I wasn't. I expected one to set the hidden property similar to the way the context menu or other popupshowing handlers do.


> Does openedWithKey as-implemented in this patch work on Mac (e.g. what is its
> value if I use Ctrl+F2+Left+Down to open the menu?)

It doesn't. Josh or Steven or someone would likely need to implement that.


> Does this property only reflect the initial opening of any menu in the menubar?
> I.e., if I Alt+F to open file, but then mouse over "Edit", what is the value of
> openWithKey in the edit menu's popupshowing handler? What about when I mouse
> back over to "File"?

The openWithKey flag is set to true when a menu is opened via Alt+Key, or if a key is used to navigate between top-level menus. It is not cleared until the menubar is no longer in use.

I notice I still need to add support for using the F10 key to activate the menubar.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

We want to hide multiple menu items per menu, so setting a "hideforkeyboard" attribute on the menuitem itself (which can be selected using something like "menubar[openedWithKey=true] menuitem[hideforkeyboard] { display:none }") would be easier to maintain than multiple popupshowing handlers that hides menuitems by ID.

Comment 16

[Neil Deakin]

Well, if you want to use:

 onpopupshowing="this.setAttribute('openedWithKey', this.openedWithKey)"

instead as you suggested, you certainly can.

Comment 17

[Neil Deakin]

Attachment: Add F10 support as well

Comment 18

[[e-mail]]

(In reply to comment #15)
> We want to hide multiple menu items per menu, so setting a "hideforkeyboard"
> attribute on the menuitem itself (which can be selected using something like
> "menubar[openedWithKey=true] menuitem[hideforkeyboard] { display:none }") would
> be easier to maintain than multiple popupshowing handlers that hides menuitems
> by ID.
[Does that actually work on the Mac?]

Comment 19

[Neil Deakin]

I don't think this should do anything on Mac and would always show the items. Personally, I don't think we should implement this at all on any platform.

Comment 20

[Alex Faaborg [:faaborg] (Firefox UX)]

We really don't need commands like History > Back (regardless of the OS) unless that is the main way the user actually goes back.  All of the commands in question are redundant with large targets in primary UI.

Comment 21

[[e-mail]]

Comment on attachment 489271 [details] [diff] [review]
Add F10 support as well

I found one case where this didn't work - use Alt on its own to activate the menu (like F10) then hit an access key. (Incidentally this works with F10.)

One thing I realised I forgot to check was hitting F10 twice then clicking.

Apart from that the patch looks OK.

Comment 22

[[e-mail]]

(In reply to comment #21)
> One thing I realised I forgot to check was hitting F10 twice then clicking.
This works, of course.

The property openedWithKey only applies to whether the menubar was opened by key; I assume it's available on all the menus as a convenience method, and/or because the menubar doesn't have a box object available to expose it.

Comment 23

[Neil Deakin]

(In reply to comment #22)
> The property openedWithKey only applies to whether the menubar was opened by
> key; I assume it's available on all the menus as a convenience method, and/or
> because the menubar doesn't have a box object available to expose it.

That's correct. In the future the property could be expanded to support other sorts of menus.

Comment 24

[Neil Deakin]

Attachment: Also add Alt by itself support

Comment 25

[[e-mail]]

Comment on attachment 490558 [details] [diff] [review]
Also add Alt by itself support

>diff --git a/layout/xul/base/src/nsXULPopupManager.cpp b/layout/xul/base/src/nsXULPopupManager.cpp
Given that the premise of the property is specific to whether the initial menubar activation was by keyboard, I'd prefer that this change isn't made.

Comment 26

[Neil Deakin]

Attachment: For checkin

Comment 27

[Dietrich Ayala (:dietrich)]

Per comment #1, this isn't critical, so not blocking on it. Will a+ the patch though.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Alex: it's unclear to me what the desired end-user goal is here. I believe that it's that:

 - we want the keyboard shortcuts to continue to work
 - we want to remove the commands from the menus so they're not cluttered
 - we want the commands to show up in the menus if there is a screenreader

Is that right?

Comment 29

[David Bolter [:davidb] (NeedInfo me for attention)]

My impression is that this bug is about all keyboard users (as opposed to screenreader users specifically) as per comment 8.

Comment 30

[Alex Faaborg [:faaborg] (Firefox UX)]

>Alex: it's unclear to me what the desired end-user goal is here.

1) this should have absolutely no effect on direct access keyboard shortcuts, like accel-t, accel-p, etc.

2) when the traditional menu is invoked using the mouse, certain items should not appear (scroll to the bottom of this mockup, note the pink items: http://people.mozilla.com/~faaborg/files/firefox4Mockups/visualBugs/firefoxMenu/firefoxMenu.htm )

3) when the traditional menu is invoked with the keyboard (alt, alt-f, alt-e, etc), those menus items in pink should appear in the menu.

Comment 31

[Alex Faaborg [:faaborg] (Firefox UX)]

Can we get this checked in?

Comment 32

[Benjamin Smedberg]

This patch involved an IID change, which requires special approval from release drivers after API freeze (beta7). It looks to me that this could have been done with nsIMenuBoxObject_MOZILLA_2_0 and avoid the IID change this late in the game. I think this should be backed out.

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think it was checked in, so it can't be backed out.

We should rewrite it with the new API, though.

Comment 34

[Dão Gottwald [:dao]]

(In reply to comment #33)
> I don't think it was checked in, so it can't be backed out.

http://hg.mozilla.org/mozilla-central/rev/e1a695a10138

Comment 35

[Neil Deakin]

Attachment: patch

This patch uses a separate interface. I didn't use the 2.0 form as I think this interface may want to be implemented by menubars/popups in the future. But maybe that doesn't matter.

Comment 36

[Dietrich Ayala (:dietrich)]

Neil, is the new patch ready for review?

Comment 37

[Alex Faaborg [:faaborg] (Firefox UX)]

Does this patch cover all platforms?

Comment 38

[Neil Deakin]

I'm still debating whether to just use the special 2.0 temporary interface form.

This patch covers Windows and Linux. It isn't possible to implement this on Mac.

Comment 39

[Neil Deakin]

Attachment: Patch with _MOZILLA_2_0_BRANCH instead

Comment 40

[[e-mail]]

Comment on attachment 503472 [details] [diff] [review]
Patch with _MOZILLA_2_0_BRANCH instead

>+interface nsIMenuBoxObject_MOZILLA_2_0_BRANCH : nsISupports
Why not make this inherit from nsIMenuBoxObject?

Comment 41

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/b27366868c80

Comment 42

[Alex Faaborg [:faaborg] (Firefox UX)]

Follow up bug 626825 for actually hiding the menu commands.

Comment 43

[Harald Dunkel]

I do not see that the "Close window" menu option is redundant. Maybe I am too blind to see, but where can I find this option in the main window?

Is there some config option to get the old behavior back?

Comment 44

[[e-mail]]

I use the close window option all the time.

Consistency is often part of a good user interface.  Removing commands "because you can access them in other ways and this makes it less cluttered" is stupid.

Comment 45

[Wild Willy Kredentser]

I'm not sure if this is the right place to make this comment -- there's so many bugz containing gripes against this keyboard vs mouse activation of menus issue -- but it seems relevant after comment 44.  There is a situation I encounter regularly in which it would be nice if the mouse-clicked File menu always had a Close or Close Tab selection (Ctrl+F4 equivalent).  When I visit a page that contains a Java applet, if I click something within the confines of the applet, control gets trapped within the applet.  There are no keyboard combinations that allow you to escape the applet to navigate the web page outside the applet, nor can you activate anything off the Menu Bar via the keyboard alone.  The problem is aggravated when you have only a single tab going in the current window, so you DO NOT HAVE the little tab thingy at the top of the page with the X you can click with the mouse to close the tab.  I have also found that clicking around on the page outside the applet doesn't always "get you out of jail" from the applet.

There is a combination problem with this.  I have found (this may no longer be true but habits are hard to break) that if you click the Windows control X in the upper right corner of the window or, equivalently, the Close selection on the drop down menu from the icon in the upper left corner of the window, this makes FFx reopen this window next time you launch the browser, as if it thinks it needs to resume an interrupted session.  What's that called?  Session restore?  FFx treats a "brute force" window close as reason to restore the session on your next browser launch.  If, on the other hand, you Ctrl+F4 out of a page, FFx doesn't put the page into the Session Restore candidate list (or whatever the terminology for this is -- I hope I'm making myself clear).

Try it yourself.  Here's one page where I encounter the problem daily.

http://www.global-view.com/forex-trading-tools/usindex_charts.html

So the bottom line is that the Ctrl+F4 equivalent selection really would be nice to have in the File menu no matter how you drop the menu down.