653226 - Improve keyboard accessibility of type="menu-button" buttons

Status: RESOLVED WONTFIX

(Toolkit :: UI Widgets, defect)

Description

[:Margaret Leibovic]

From bug 616136 comment 5 (part of a list of accessibility problems with popup notifications):

4. When tabbing through the notification, focus cycles between two buttons: a
menu button (class: "popup-notification-menubutton") and a child button (class:
"box-inherit button-menubutton-button").
4.1. Both have the same label.
4.2. The menu button reports an accelerator, but not the child button.
4.3. Nothing I do with the menu button seems to activate any sort of menu - at
least, not an accessible menu.
4.4. I honestly can't figure out how I'm supposed to interact with this thing
at all, except pressing the accelerator.

Comment 1

[Neil Deakin]

The menu-button is supposed to be a button with a default command with an attached menu with additional commands.

It could be treated as either:

- an element that is a button followed by a menu
- a button, but with a separate means of opening the menu
- a menu, where the button's default command is simply treated as the first option on the menu

Comment 2

[James Teh [:Jamie]]

(In reply to comment #1)
> - an element that is a button followed by a menu
I assume this means there'd need to be a second button in the tab order to open the menu. If this is the chosen option, I think the button which opens the menu needs to have a different accessible name like "More options" to distinguish it from the main action button.

> - a button, but with a separate means of opening the menu
Personally, I like this option the best. For keyboard users, the menu could be opened either by pressing the context menu key (the applications key in Windows) or down/up arrow. Out of curiosity, how does a sighted person open the menu?

> - a menu, where the button's default command is simply treated as the first
> option on the menu
I don't really follow this. Isn't this the same as the second option or would there be no way of opening the menu from the keyboard?

Comment 3

[:Margaret Leibovic]

(In reply to comment #2)
> > - a button, but with a separate means of opening the menu
> Personally, I like this option the best. For keyboard users, the menu could
> be opened either by pressing the context menu key (the applications key in
> Windows) or down/up arrow. Out of curiosity, how does a sighted person open
> the menu?

A sighted person opens the menu by clicking on a dropdown icon on the right side of the button. There is a divider in the middle of the button that makes it look and act more like two buttons, one with a label that performs a main command and one with a dropdown icon that opens a menu.

Comment 4

[James Teh [:Jamie]]

(In reply to comment #3)
> A sighted person opens the menu by clicking on a dropdown icon on the right
> side of the button. There is a divider in the middle of the button that
> makes it look and act more like two buttons, one with a label that performs
> a main command and one with a dropdown icon that opens a menu.
Thanks Margaret. Even given this, I still think one button (with additional functionality to open the context menu) makes most sense for keyboard users.

Comment 5

[Neil Deakin]

> For keyboard users, the menu could be opened either by pressing the context menu key.

I don't think a context menu is quite right here.

The menu-button is fairly similar to a combobox type field, where instead of a textbox, you have a command button. In the former, there could be a context menu as well as the normal combobox menu. How is this type handled? It would make sense to handle it in a similar manner.

Comment 6

[James Teh [:Jamie]]

(In reply to comment #5)
> I don't think a context menu is quite right here.
> The menu-button is fairly similar to a combobox type field, where instead of
> a textbox, you have a command button.
Perhaps, except that a combobox doesn't normally perform an action by itself; i.e. there is generally a button as well. I know there are exceptions to this, but it'd be fairly rare for a combobox to, for example, dismiss a dialog, which is essentially what this would do.

> In the former, there could be a
> context menu as well as the normal combobox menu.
Are you suggesting that menu-buttons could have two menus: a context menu and a combobox style popup?

> How is this type handled?
> It would make sense to handle it in a similar manner.
In a combobox, pressing down/upArrow changes the value immediately without any confirmation. As I understand it, this makes no sense at all for menu-buttons. Pressing alt+down/upArrow expands the combobox and allows you to select a choice which is only accepted once you confirm by pressing enter.

Comment 8

[Marco Zehe (:MarcoZ)]

To get this moving again, I've comprised all available info and a proposed solution on this wiki page:
https://wiki.mozilla.org/Accessibility/MenuButton_Keyboard_Navigation

Comment 9

[Neil Deakin]

> With focus inside that menu with all options present, allow the user to navigate up and down through the available options.
> Allow pressing of Enter to select the desired option.
> Make sure those options are menu items, not buttons, when they are communicated to accessibility, and that menu start/end events are fired.

All of this is already true, so I'm not clear what changes you want for these.

It seems like all you are asking for is for space to open the menu when the button is focused. Currently, on Windows one opens the menu with Alt+Down or F4. (On Mac, Space can already be used as well as Up/Down).

Comment 10

[Marco Zehe (:MarcoZ)]

(In reply to Neil Deakin from comment #9)
> All of this is already true, so I'm not clear what changes you want for
> these.

1. Tab should not be able to focus two elements that have a name of "Save password". Ones role is "menu button", the second is just a "button". This is inconsistent.
2. Opening a menu button with Alt+Down arrow is, iMO, a bit unusual from a keyboard interaction model for Windows. A button is usually expected to be pressed with Space, only that in this case it opens a menu instead of just executing a function.

> It seems like all you are asking for is for space to open the menu when the
> button is focused. Currently, on Windows one opens the menu with Alt+Down or
> F4. (On Mac, Space can already be used as well as Up/Down).

Yes and that tab doesn't focus the single button (see above).

Comment 11

[James Teh [:Jamie]]

The button behaves as a button as well as a menu button; i.e. it can either activate an action or pop up a menu. The default action is not available in the menu; the menu only lists secondary actions. For example, the "Remember Password" menu-button only provides the options "Never Remember Password for This Site" and "Not Now". Therefore, I think space should activate the button (Remember Password) and up/downArrow should pop up the menu. In addition, it'd be nice if the applications key could also pop up the menu on Windows.

Comment 12

[Neil Deakin]

I think it should behave like other combination menu + buttons on windows. The button acts like a single widget with only one tab stop. While focused, pressing space activates the default button behaviour and pressing up/down opens the menu. In some usages on Windows, such as the shutdown button, left/right is used instead, although I don't think we need to replicate this in general. Other keys such as F4 and alt+down could remain as alternatives.

The main issue is that the menu-button is currently implemented as an weird button inside a button. It should be implemented instead as a single widget with one label.

The application key should not open the menu. It should only be used to open a context menu.

Some examples of menu buttons on Windows I see are:
 - shutdown button on the start panel
 - view button on topright of the toolbar in a file list explorer
 - the zoom button in IE, if the toolbar is customized to show it

What do accessibility tools show for the type and interactions available for these?

Comment 13

[James Teh [:Jamie]]

(In reply to Neil Deakin from comment #12)
> I think it should behave like other combination menu + buttons on windows.
> The button acts like a single widget with only one tab stop. While focused,
> pressing space activates the default button behaviour and pressing up/down
> opens the menu.
Right.

> In some usages on Windows, such as the shutdown button,
> left/right is used instead, although I don't think we need to replicate this
> in general.
In this case, the button itself is inside a menu of sorts. This isn't the case here, so I think up/downArrow is more appropriate.

> The application key should not open the menu. It should only be used to open
> a context menu.
Fair enough. A popup menu on a button feels similar to a context menu to me, hence my suggestion, but I'm not going to argue the point.

As far as accessibility exposure is concerned, the current implementation (minus the inner widget) is fine. Arguably, it could have a role of menubutton instead of button, but it already has the haspopup state, which basically indicates the same thing. (Even if the role is menubutton, haspopup still needs to be exposed.)

Comment 14

[Neil Deakin]

Attachment: patch

This patch:
 - removes the inner button from the tab order
 - allows the space key to activate the button portion, and up/down (or their platform-specific equivalents) to open the menu
 - make some style changes that make the button somewhat better. This still needs work but I don't think I would be one that could do this.

Comment 15

[Neil Deakin]

Attachment: possible patch

Missed a file in the last patch

Comment 16

[James Teh [:Jamie]]

Any chance of getting this moving again? This is really ugly for screen reader users and it's a pretty important part of the UI.

Comment 17

[Marco Zehe (:MarcoZ)]

As per Gijs's request, NI'ing him on doorhanger-keyboard-accessibility-related bugs.
This one relates to all of the ones used in the doorhangers that both have an own action, but also pop up a menu, for example the Save Password magic thing.

Comment 18

[:Gijs (he/him)]

I'd like to get this moving again. I'm not a good reviewer for the (by now probably bitrotted :-( ) patch on here, but as far as I can tell it is pretty extensive and there might not be too much missing from it? Neil would know better than me.

Gavin, can we get this included in an upcoming iteration? We're using more of these doorhangers for webrtc, and with our push for loop and the screen-sharing work, I think we should put in the required effort to get this over basic sec508 compliance thresholds, at a minimum.

Comment 19

[Marco Zehe (:MarcoZ)]

I sent an inquiry for ideas about these to the public-pfwg list[1], and got one reply back so far[2]. This idea makes a lot of sense, since we're essentially indeed dealing with two functionally different pieces here. This thread should be watched for more ideas, but the idea sounds pretty sane.

[1] http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0020.html
[2] http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0021.html

In our case, the interaction would be:
1. The container becomes a role "toolbar". It receives an aria-label with sensible text like "Save password options".
2. The first piece, the button that does the default action, is a regular button, no menu button, no fuzz.
3. The downward pointing arrow becomes keyboard focusable, too, gets a role of button and an aria-haspopup as the menu button piece does not, and it gets an aria-label like "More options".
4. Tab lands on the first item in the toolbar, the item from 2. Space activates it and does the default magic.
5. Right arrow switches to the downward pointing arrow in 3. Space and DownArrow activate the menu. Right Arrow does nothing, LeftArrow goes back to 4.
6. To make it easier, escape should perform the "Close this message" action when the menus are not opened. If the menus are opened, close the menu and return focus to the item in 3.
7. Finally, tab should move to the next focusable item *outside* this toolbar.

Thoughts?

Comment 20

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #19)
> I sent an inquiry for ideas about these to the public-pfwg list[1], and got
> one reply back so far[2]. This idea makes a lot of sense, since we're
> essentially indeed dealing with two functionally different pieces here. This
> thread should be watched for more ideas, but the idea sounds pretty sane.
> 
> [1] http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0020.html
> [2] http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0021.html
> 
> In our case, the interaction would be:
> 1. The container becomes a role "toolbar". It receives an aria-label with
> sensible text like "Save password options".
> 2. The first piece, the button that does the default action, is a regular
> button, no menu button, no fuzz.
> 3. The downward pointing arrow becomes keyboard focusable, too, gets a role
> of button and an aria-haspopup as the menu button piece does not, and it
> gets an aria-label like "More options".
> 4. Tab lands on the first item in the toolbar, the item from 2. Space
> activates it and does the default magic.
> 5. Right arrow switches to the downward pointing arrow in 3. Space and
> DownArrow activate the menu. Right Arrow does nothing, LeftArrow goes back
> to 4.
> 6. To make it easier, escape should perform the "Close this message" action
> when the menus are not opened. If the menus are opened, close the menu and
> return focus to the item in 3.
> 7. Finally, tab should move to the next focusable item *outside* this
> toolbar.
> 
> Thoughts?

What about the access key?

Comment 21

[Neil Deakin]

I'm unclear why you think it should work differently than other similar buttons on Windows.

Comment 22

[Marco Zehe (:MarcoZ)]

(In reply to Neil Deakin from comment #21)
> I'm unclear why you think it should work differently than other similar
> buttons on Windows.

I am not aware of any such buttons that have two different click targets in *one* control. As far as I know, and also from the feedback I got from others, this kind of interaction model is pretty unique to Firefox and a constant cause of confusion for both keyboard and screen reader users.

Comment 23

[Marco Zehe (:MarcoZ)]

(In reply to :Gijs Kruitbosch from comment #20)
> What about the access key?

The access key should, I think, focus on the first item in this toolbar, but not activate. Essentially as if the user had just tabbed into it.

Comment 24

[Neil Deakin]

I gave some examples of this UI in comment 12. The most obvious is the Shutdown button on the start panel (I am using Windows 7.) Pressing the button shuts down. Pressing the arrow opens a menu with other commands, and the shutdown option is not in this list. While focused, pressing space shuts down and pressing the right arrow key opens the menu. Most other similar buttons open the menu on cursor up/down which is what we should do.

I'm pretty sure this is what my patch above implements.

Comment 25

[Fabian]

Marco, you wrote "The problem here is that current best practices suggest that both space 
and down arrow pop up the menu." I think that's because it is describing menubuttons, which is another control.

Microsoft's UX guide distinguishes menu buttons (with only one effect on clicking: opening a dropdown menu) and split buttons (having a main action and an arrow that exposes further options in a menu). According to Accprobe, Internet Explorer exposes menu buttons with accessible role "pushButton" and split buttons as "splitButton".

It seems that a single focusable control with the role of button (not menubutton) combined with haspopup best conveys to AT that space will invoke a default action (as always on a button) while a popup menu is available through other keystrokes. Exposing as menubutton causes the confusion as to what space will do.

As for the access key, couldn't we just let it open the menu, making sure we add the default action as the first autofocussed menu item? Repeating the main action is also what Microsoft's own UX guide suggests ("Display the default command using bold text in the menu. Doing so makes it easier for users to find the default command"), even though they apparently don't follow it everywhere.

Comment 26

[Marco Zehe (:MarcoZ)]

(In reply to fv_moz from comment #25)
> Microsoft's UX guide distinguishes menu buttons (with only one effect on
> clicking: opening a dropdown menu) and split buttons (having a main action
> and an arrow that exposes further options in a menu). According to Accprobe,
> Internet Explorer exposes menu buttons with accessible role "pushButton" and
> split buttons as "splitButton".

There are several problems with split buttons. After you pointed me to what this thing here is supposed to be, I did some investigation. Both the split button in the start menu, as well as those in the Windows 7 explorer to sort columns ascending or descending, are implemented in such a buggy way that the user gets no notification that a sub menu opens with right arrow, when the meu opens, and what happens when the menu is closed with escape. In short, the implementation done by Microsoft itself sucks so badly that probably no blind end user has ever figured these out properly. Considering that these came in during the Windows XP times, but for example, can be fund less in Windows 8.1 than in 7, suggests that Microsoft themselves seem to think they weren't such a good idea after all.

Evidence of how badly these suck can be seen in this message by Bryan Garaventa, a blind power user who also tested these after I described to him what our control iss supposed to be, and where he could find one:
http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0032.html

In short, he accidentally shut his computer down twice while testing it.

Second, WAI-ARIA does not have definitions for a split button. Neither a role, nor a guide how to implement them. So we'd have to hack something together to make these work in XUL especially for Windows, because other platforms don't know about these controls, either.
> It seems that a single focusable control with the role of button (not
> menubutton) combined with haspopup best conveys to AT that space will invoke
> a default action (as always on a button) while a popup menu is available
> through other keystrokes. Exposing as menubutton causes the confusion as to
> what space will do.

Again, a split button is a control with a very bad implementation history in Windows itself, and it seems to be on the retreat. The same Shutdown control in Windows 8.1, for example, is not such a split button any more.
> As for the access key, couldn't we just let it open the menu, making sure we
> add the default action as the first autofocussed menu item? Repeating the
> main action is also what Microsoft's own UX guide suggests ("Display the
> default command using bold text in the menu. Doing so makes it easier for
> users to find the default command"), even though they apparently don't
> follow it everywhere.

If we absolutely must stick with this error-prone control, then yes.

However, my preferred way of doing this is to go with the different layout as I described in comment #19. Feedback that was provided on the list by others who have end user training experience suggests that this is the much better thing to do rather than to work with this convoluted concept of a split button.

Comment 27

[Fabian]

> "If we absolutely must stick with this error-prone control [...] and it seems to be on the retreat"

This seems to sum it up. Microsoft haven't done a good job in documenting and standardizing this control, offering two keyboard/AT interaction ways itself in various of its programs. However, you're suggesting a third, which will then co-exist besides the OS, the Office suite, further increasing the difficulty that users have in learning to use this control.

Might I suggest simply making it an ordinary menu button then? If not throughout (in visuals and for mouse users as well), then at least for keyboard focus and AT exposure. That seems to take away all problems you're correctly identifying with split buttons without introducing new ones.

Summarizing, that would be:
- One tab stop, on a button with type "Menu button"
- One action on Space/Enter/Down/Up/Alt+down/Alt+up or hitting the access key, namely to show the foldout menu
- Repeating the main action as the first and prefocused item on that menu

Would there be any remaining discoverability or accessibility concerns?

Comment 28

[Marco Zehe (:MarcoZ)]

(In reply to fv_moz from comment #27)
> Might I suggest simply making it an ordinary menu button then? If not
> throughout (in visuals and for mouse users as well), then at least for
> keyboard focus and AT exposure. That seems to take away all problems you're
> correctly identifying with split buttons without introducing new ones.
> 
> Summarizing, that would be:
> - One tab stop, on a button with type "Menu button"
> - One action on Space/Enter/Down/Up/Alt+down/Alt+up or hitting the access
> key, namely to show the foldout menu
> - Repeating the main action as the first and prefocused item on that menu

Let's do it this way! And btw, this is in line with Matt King's latest suggestion in the discussion on the W3c Public PFWG list. Almost word by word. So if we can indeed settle on this, it would be tremendously helpful and unambiguous.

Comment 29

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

(I added this bug to the submission queue for upcoming iteration planning)

Comment 30

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #28)
> (In reply to fv_moz from comment #27)
> > Might I suggest simply making it an ordinary menu button then? If not
> > throughout (in visuals and for mouse users as well), then at least for
> > keyboard focus and AT exposure. That seems to take away all problems you're
> > correctly identifying with split buttons without introducing new ones.
> > 
> > Summarizing, that would be:
> > - One tab stop, on a button with type "Menu button"
> > - One action on Space/Enter/Down/Up/Alt+down/Alt+up or hitting the access
> > key, namely to show the foldout menu
> > - Repeating the main action as the first and prefocused item on that menu
> 
> Let's do it this way! And btw, this is in line with Matt King's latest
> suggestion in the discussion on the W3c Public PFWG list. Almost word by
> word. So if we can indeed settle on this, it would be tremendously helpful
> and unambiguous.

In e.g. the doorhangers, we use this button for the "default" action (e.g. share webcam/audio in a webrtc doorhanger, save your password in a remember password prompt, etc.). For mouse users, I wouldn't want to change the massive click target and single click acceptance into 2 clicks - that'd be a massive UX regression. Looping in Philipp for some UX input.

We could obviously also consider switching away from these buttons to something similar to what we do for notification bars, ie one prominent 'default' button, and an 'options' button which drops down other options.

Comment 31

[Neil Deakin]

For mouse users, clicking the button area will trigger the default action. Clicking the arrow area will open the menu.

The difference here is that the keyboard user must use the menu to trigger the commands, and the default command must be in the menu.

In this regard, this element behaves the same as the menu-buttons found on ribbons, such as the Paste button in Wordpad/Paint.

Comment 32

[Marco Zehe (:MarcoZ)]

Just an FYI: There are no split buttons on either Mac or Linux, so users there won't know how to use this type of control.
Second, there are at least 3 different ways in Windows to open the split button menu on Windows:
- The Windows 7 start menu uses Right Arrow.
- The Paste split button in WordPad uses Alt+DownArrow, and *only* that.
- The explorer split buttons use DownArrow I think, and RightArrow in addition. I mean the column headers.

Comment 33

[Neil Deakin]

> Second, there are at least 3 different ways in Windows to open the split
> button menu on Windows:

I think they use a different arrow button depending on the context they are in and how one would expect to navigate them. For our purposes where the menu always opens vertically, up/down arrow should be used.
 
> - The Paste split button in WordPad uses Alt+DownArrow, and *only* that.

The menu can also be opened with Space or Enter.

Comment 34

[Marco Zehe (:MarcoZ)]

(In reply to Neil Deakin from comment #33)
> > Second, there are at least 3 different ways in Windows to open the split
> > button menu on Windows:
> 
> I think they use a different arrow button depending on the context they are
> in and how one would expect to navigate them. For our purposes where the
> menu always opens vertically, up/down arrow should be used.

But the problem is that there is no standard way to communicate which way a menu would fly out. We could use aria-orientation and hope this will be picked up by ATs.

> > - The Paste split button in WordPad uses Alt+DownArrow, and *only* that.
> 
> The menu can also be opened with Space or Enter.

Sorry for being nitpicky, but in this case, there is no way to perform the standard option with the keyboard without opening the button's menu, in which case, the purpose of the split button is completely defeated. Unless of course, you count Ctrl+V, which can be executed without even going into the ribbons first. So for the keyboard users, the Paste split button in WordPad is, in effect, a regular menu button.

Comment 35

[Neil Deakin]

> But the problem is that there is no standard way to communicate which way a
> menu would fly out. We could use aria-orientation and hope this will be
> picked up by ATs.

I'm not sure what problem you're referring to. The menu will open the in the same direction and manner as other menus.

> Sorry for being nitpicky, but in this case, there is no way to perform the
> standard option with the keyboard without opening the button's menu, in
> which case, the purpose of the split button is completely defeated.

No, for keyboard users there isn't a way to perform the default command without opening the menu if we assume these shortcuts. We could make a key for that, but I think you said earlier that there wasn't any way to convey this distinction to accessibility tools.

Comment 36

[Marco Zehe (:MarcoZ)]

(In reply to Neil Deakin from comment #35)
> > But the problem is that there is no standard way to communicate which way a
> > menu would fly out. We could use aria-orientation and hope this will be
> > picked up by ATs.
> 
> I'm not sure what problem you're referring to. The menu will open the in the
> same direction and manner as other menus.

The problem that there are so many different implementations in Windows 7 alone that the user doesn't have directions to draw from when interacting with our version of the split button for the first time. Is it right arrow to open the menu, down arrow, alt down arrow (all variants found in Windows 7 split buttons), or something else entirely? There's no way to tell them upfront.

> > Sorry for being nitpicky, but in this case, there is no way to perform the
> > standard option with the keyboard without opening the button's menu, in
> > which case, the purpose of the split button is completely defeated.
> 
> No, for keyboard users there isn't a way to perform the default command
> without opening the menu if we assume these shortcuts. We could make a key
> for that, but I think you said earlier that there wasn't any way to convey
> this distinction to accessibility tools.

Right, I was specifically referring to the Paste split button in Windows 7 WordPad, and that this fact kind of defeats it being a split button completely for keyboard users. Just adding to the inconsistencies this control exposes, defeating its own usefulness at every turn it takes. ;)

I really strongly suggest we go with the menu button approach set forth by MV in comment #27. It is unambiguous and straight forward.

Comment 37

[Neil Deakin]

> I really strongly suggest we go with the menu button approach set forth by
> MV in comment #27. It is unambiguous and straight forward.

That is what I am suggesting as well. However, mouse users can click the button area to activate the default command.

Comment 38

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

I'm not sure I understand what »making it a menu button« would mean visually.
Giving mouse users easy access to the most common action (i.e. what matters most to most people) is the reason for having split buttons. Losing that benefit isn't an option.

If this change would leave the appearance and behavior for mouse users unchanged, that would be fine (although I'd like to ui-r the patch just to be sure).

Any visual/functional change would have much wider consequences than just one panel and would need more UI-work upfront.

Comment 39

[Marco Zehe (:MarcoZ)]

(In reply to Neil Deakin from comment #37)
> > I really strongly suggest we go with the menu button approach set forth by
> > MV in comment #27. It is unambiguous and straight forward.
> 
> That is what I am suggesting as well. However, mouse users can click the
> button area to activate the default command.

That's fine.

(In reply to Philipp Sackl [:phlsa] from comment #38)
> If this change would leave the appearance and behavior for mouse users
> unchanged, that would be fine (although I'd like to ui-r the patch just to
> be sure).

That is the intent with a slight addition. The intended change would be for keyboard users, since split buttons have very inconsistent implementations throughout Windows for the keyboard. So the consensus also gathered from a community of web accessibility professionals is that for the keyboard, and therefore blind screen reader users, this should behave like a menu button, and the first option is the default action. So for mouse users, the only change would be that they, when clicking the down arrow on the right, will also see the default option as the first menu item from then on.

Comment 40

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #39)
> (In reply to Neil Deakin from comment #37)
> > > I really strongly suggest we go with the menu button approach set forth by
> > > MV in comment #27. It is unambiguous and straight forward.
> > 
> > That is what I am suggesting as well. However, mouse users can click the
> > button area to activate the default command.
> 
> That's fine.
> 
> (In reply to Philipp Sackl [:phlsa] from comment #38)
> > If this change would leave the appearance and behavior for mouse users
> > unchanged, that would be fine (although I'd like to ui-r the patch just to
> > be sure).
> 
> That is the intent with a slight addition. The intended change would be for
> keyboard users, since split buttons have very inconsistent implementations
> throughout Windows for the keyboard. So the consensus also gathered from a
> community of web accessibility professionals is that for the keyboard, and
> therefore blind screen reader users, this should behave like a menu button,
> and the first option is the default action. So for mouse users, the only
> change would be that they, when clicking the down arrow on the right, will
> also see the default option as the first menu item from then on.

Philipp, can you confirm this works from a UX perspective so we can move towards implementing this?

Comment 41

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

The duplication of the main action seems like a very unusual pattern, so we should avoid it.

Why is this the preferred solution? Currently, every button in that UI can be reached with the keyboard (at least on Windows), so if the problem is that the dropdown button doesn't have a screenreadable title, then we should add one (invisibly) like »More sharing options« for the device sharing doorhanger.

(I tried to re-read this thread but got lost in all the details, so let me know if this approach has already been discussed.)

Comment 42

[Fabian]

It was argued that two different keyboard shortcuts on the button (one to invoke the main action and one to open the dropdown with other actions) was a too difficult concept, both undiscoverable and non-standard across implementations and therefore prone to errors.

Given that premise, a solution would be to have only one action as a result of keyboard input on the button, namely to show the dropdown including all options (first and foremost the default one, preselected for easy click-through).

I don't think it is a very unusual pattern; compare the Windows context menu on a file in Explorer: the doubleclick / Enter action is also repeated in bold as the first item in the menu. Compare the ribbon in Microsoft Office, with the same logic on split buttons.

Comment 43

[James Teh [:Jamie]]

It's been years since this was discussed and things have changed since then. Bug 1267604 changed doorhangers so that they no longer use type="menu-button". Now, they have a button for the primary action, a button for the secondary action if applicable and a separate button to open the popup for other actions. For example, the password doorhanger has Save and Don't Save buttons, as well as a button to open a menu containing "Never Save". The button to open the menu should have a better label for accessibility, but that should be trivial to fix and can be addressed in a separate bug.

Neil, I'd suggest we close this bug, since the original use case for which this bug was opened is no longer relevant and I don't know of any other type="menu-button" buttons we care about. (From what I can see, I don't think this is used anywhere in production code any more, only in tests.) However, I'm not the triage owner here, so I'll leave this decision to you.

Comment 44

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381