RE: Question about a menubutton with a default action

I second Matt´s suggestion.

I have done a lot of end user training myself, and people never got the hang of interacting with these Firefox pop-ups.

Firefox’s default action, at least on links, is to execute them, but this does not happen with the buttons.

Also we should not mix two interaction batterns into a single control, however tempting it may sound.

As an instructor as well as an end user I understand the problems and frustration with that.

When you are deeply involved with the code, such as a tester or developer, you get so immersed in it, and you work so much with it, that things become obvious and natural to you that really are a complete enigma to the novice user trying to get your software to work.

So the toolbars sound great!

Thanks Marco for actively promoting accessibility in Firefox, that work affects millions of people for the better.

 

 

From: Marco Zehe [mailto:marco.zehe@gmail.com] 
Sent: Friday, August 8, 2014 1:10 PM
To: Matthew King
Cc: W3C WAI Protocols & Formats
Subject: Re: Question about a menubutton with a default action

 

Hi Matt,

thanks for your input! This makes a lot of sense! I will wait a bit for other ideas to come up, but making these into sort of mini-toolbars makes a lot of sense. The trick with other buttons in regular toolbars is to not clutter the keyboard tab order like -- for example, and sorry -- in IE. It would certainly drive me crazy as a keyboard user to tab ten or more times from the address bar again before I reach the content area. At the moment, it's two, maybe sometimes three, presses of the tab key in Firefox.

Marco

 

 

On Fri, Aug 8, 2014 at 6:52 PM, Matthew King <mattking@us.ibm.com> wrote:

Marco, 

The fact that there are 2 click targets with 2 different purposes is a very important aspect of this problem to consider. There really are 2 controls, not one. I think we need to be very careful with the idea of combining them into one control for keyboard users. It creates high potential for user mistakes. Each of these functions (performing a command like remember password and opening a menu of other related commands) needs its own focusable element in the UI just like it needs a separately clickable target. For clarity, each function needs its own label and properties. 

I strongly agree that there are implementation problems with this kind of control in Firefox. However, I think the two biggest problems are: 
1. access to the buttons is time dependent; the buttons seem to disappear, or at least access to them goes away. 
2. An access key is required. There is a general lack of keyboard access and discovery for not only buttons like remember password but all toolbar buttons in the header area of the browser. 

I do not think the fact that there are 2 tab stops for the remember password control is necessarily a problem. It is certainly not ideal, but the way to improve it 
depends on how keyboard access to the toolbar area in Firefox would be designed. 

I would like to see a single tab stop for each functional set of buttons in the header frame. Within a set, which would have role toolbar, the user would left/right arrow to the different buttons within that toolbar. Tabbing from address bar would go to search then to the first button in the first toolbar. The remember password command button would be in one of these toolbars in the header. The "Other password options" menu button, which would look like a down arrow,  would be right next to the remember password button. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329 <tel:%28503%29%20578-2329> , Tie line: 731-7398 
mattking@us.ibm.com 



From:        Marco Zehe <marco.zehe@gmail.com> 
To:        "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, 
Date:        08/08/2014 06:04 AM 
Subject:        Question about a menubutton with a default action 

  _____  




Hi there!

I need some advice here... You know in Firefox, we have these doorhangers that pop up when, for example, a site asks you if you want to save a password. The button to save the password is actually a menu button with a default action, and a downward pointing arrow to open a menu of more options. That menu doesn't currently contain the default action. So the mouse interaction is: Click on the left side, e. g. the button label, performs the default action of saving the password. Clicking on the downard pointing arrow will open the popup menu.

The current keyboard interaction is buggy at best. The access key doesn't work correctly, and the button has two tab stops, one for the menu button piece, one for the default action.

Now, I've read up on the default expected behavior for menubuttons <http://www.w3.org/TR/wai-aria-practices/#menubutton> , but these don't cover the case of a menu button that also has a default action. Nor is there a different role available in IA2 or other platform APIs that I know of that would cover this scenario in a way that the end user immediately knows what's going on.

My first reaction to the question of how this interaction should be, was this:

1.        Pressing the access key should focus the menubutton, but not activate anything. 
2.        Space should activate the default action. 
3.        Down Arrow should open the menu.

The problem here is that current best practices suggest that both space and down arrow pop up the menu. And there is no good way to actually tell the user that space would, in this case, do the default action and set focus back on the page afterwards. 

Any ideas or suggestion on how to best solve this would be appreciated. We could do an ARIA description for this particular button that tells the users on focus that space will submit the default action, and down arrow opens the menu for more options. But the best way would be if we had a best practices guide somewhere that would include this special scenario, or settle on a good way forward for these in general. 

Welcoming your comments! 

Marco