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, 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
>
>