- From: Matthew King <mattking@us.ibm.com>
- Date: Sun, 10 Aug 2014 10:14:39 -0700
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: James Craig <jcraig@apple.com>, Marco Zehe <marco.zehe@gmail.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-ID: <OF63AD3561.21AB3054-ON88257D30.004F30DA-88257D30.005EB99E@us.ibm.com>
I strongly recommend against another button role for split buttons.
Instead, if we develop a design pattern that treats the split button as a
single menubutton for keyboard users but as a button with 2 click targets
for mouse users, it can be both keyboard accessible and simple for screen
reader users to understand.
For mouse users, nothing would change. There is one target for the default
command button and another for the menu down arrow icon. Mouse users have
the somewhat dubious advantage of a single click path to execute the
default command.
However, in this pattern, for keyboard users, there is a single focusable
element that includes both the command button and the down arrow. This
element is marked up as a menu button. Pressing enter, space, or down opens
the menu (equal to clicking down arrow) and sets focus on the menuitem for
the default command. Pressing enter or space again activates the default
command. Up/down moves to the other menu options.
With this implementation, a keyboard user need only press enter or space
twice to execute the default command. This is a negligible inconvenience
that would save users from having to learn about a completely new kind of
control that gives them no real advantage. Even more, it saves all of us
from the complexity of implementing a new role in all the accessibility
APIs that would not provide any clear benefit to end users.
This pattern would stray from what is currently recommended for the Windows
platform by Microsoft. But, I do not think there would be any confusion
caused by the variation because it is simply reuse of already
well-understood and very well supported patterns. Perhaps Microsoft would
consider adopting it.
The pattern does require that the the command button part of the split
button would need to be a click target with no keyboard handler. We can
work on ways of coding this that would still work with validaters.
Basically, the accessible control is the down arrow and the command button
portion is mere eye-candy for keyboard users.
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: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Marco Zehe <marco.zehe@gmail.com>,
Cc: James Craig <jcraig@apple.com>, W3C WAI Protocols & Formats
<public-pfwg@w3.org>
Date: 08/09/2014 12:33 AM
Subject: RE: Question about a menubutton with a default action
Personally, I’d recommend the same as Matt.
The problem with the split button functionality, is that it’s not intuitive
and there is no indication to the user how it is supposed to work. Case in
point, I’ve been using Win7 for a couple of years now and have shut down my
computer thousands of times in that time, but never knew this dual
functionality existed till you mentioned how to use it.
From: Marco Zehe [mailto:marco.zehe@gmail.com]
Sent: Friday, August 08, 2014 10:57 PM
To: Bryan Garaventa
Cc: James Craig; W3C WAI Protocols & Formats
Subject: Re: Question about a menubutton with a default action
Sorry about that! ;) Any suggestions on how to proceed? Should I just see
that we expose this as a split button somehow, and count on users to know
how to interact, or should I try and push for a change to what Matt
suggested? I personally would feel better with the latter, but am not sure
how hard this fight might become. Moreover, there is no ARIA role for split
buttons AFAIK. At least I didn't find one. And in Windows 8.1, this thing
is no longer a split button, it has no role whatsoever, but acts like a
normal menu button.
Suggestions still welcome!
Marco
On Sat, Aug 9, 2014 at 7:48 AM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:
Ah, I see what you mean, I just shut down my computer twice by accident
trying to test this thing using Space and Enter…
It’s not the Down arrow that opens the popup menu items, but Right arrow,
which makes it act like a submenu of a parent menu item.
I guess it’s theoretically possible to do this using ARIA on a menu item,
if a proper description is added, but this would only work within a menu,
and not on a standalone button, because the modes of navigation are
totally different.
From: Marco Zehe [mailto:marco.zehe@gmail.com]
Sent: Friday, August 08, 2014 10:29 PM
To: Bryan Garaventa
Cc: James Craig; W3C WAI Protocols & Formats
Subject: Re: Question about a menubutton with a default action
Hi Bryan,
no, he is referring to the split button that is in the start menu. In
fact, another colleague chimed in that this control is meant to be a clone
of Microsoft's split button rather than menu button. He also quotes
(although without an actual reference) that Microsoft suggest Space to
perform the default action, and DownArrow to open a menu of the default +
other options. The access key should open the menu, with the default
option highlighted.
I just checked, and WAI-ARIA doesn't mention split buttons at all, neither
in the spec nor in the authoring practices.
Marco
On Fri, Aug 8, 2014 at 9:18 PM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:
Is he referring to the dialog that pops up if you press Alt+F4 when the
desktop has focus?
This is a “combo box” in the Accessibility Tree, not a button.
From: Marco Zehe [mailto:marco.zehe@gmail.com]
Sent: Friday, August 08, 2014 12:09 PM
To: James Craig
Cc: Bryan Garaventa; W3C WAI Protocols & Formats
Subject: Re: Question about a menubutton with a default action
Hi Matt, Birkir, and Bryan,
any thoughts on the example one of our developers gives in comment 24 of
the relevant Mozilla bug? Namely the example that aaparently stood model
for our interaction: the Windows 7 shutdown button menu thingie on the
Start panel.
Windows 8.1 no longer has that, it's a regular menu button there that
opens on press of the Space bar.
Marco
On Fri, Aug 8, 2014 at 7:41 PM, James Craig <jcraig@apple.com> wrote:
I was going to echo Matt's sentiment here. These are two controls, a
button and a second popup button that launches a menu (aka menu button).
When each is focused, Spacebar or Return should activate either. When the
menu is launched, focus should move into the menu and arrow keys should
manipulate the selected menu item.
As for the authoring guide:
|-------------------------------------------------------------------------|
| · |
| With focus on the button and the drop-down menu open, |
| pressing Down Arrow will move focus into the menu onto the |
| first menu item. |
|-------------------------------------------------------------------------|
That needs to say "selected menu item or first menu item."
On Aug 8, 2014, at 10:24 AM, Marco Zehe <marco.zehe@gmail.com>
wrote:
Bryan, I totally second your view that Space should open the menu
as well. It always drives me nuts if a menu button does not do it,
like some on FaceBook, for example. The ones on Google like in
Gmail don't require me to switch out of virtual mode to get them
popped up, on FaceBook, they do.
I would, therefore, second a change to the authoring guide to this
effect. Strongly! :)
Marco
On Fri, Aug 8, 2014 at 7:15 PM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:
Regarding the use of the Down arrow to trigger a menu, I believe
this exposes an issue in the ARIA authoring guide at
http://www.w3.org/TR/wai-aria-practices/#menubutton
Where it states:
|------------------+--------------------------------------------------------|
|Keyboard | Space or Enter - With focus on the button pressing|
|Interaction: | Space or Enter will toggle the display of the |
| | drop-down menu. Focus remains on the button. |
| | Down Arrow - |
| | With focus on the button and no drop-down |
| | menu displayed, pressing Down Arrow will |
| | open the drop-down menu and move focus into |
| | the menu and onto the first menu item. |
| | With focus on the button and the drop-down |
| | menu open, pressing Down Arrow will move |
| | focus into the menu onto the first menu |
| | item. |
| | Up and Down Arrow - With focus on the drop-down |
| | menu, the Up and Down Arrow keys move focus within|
| | the menu items, "wrapping" at the top and bottom. |
| | Escape - With focus on the drop-down menu, |
| | pressing Escape closes the menu and returns focus |
| | to the button. |
| | Tab - |
| | With focus on the button pressing the Tab |
| | key will take the user to the next tab |
| | focusable item on the page. |
| | With focus on the drop-down menu, pressing |
| | the Tab key will take the user to the next |
| | tab focusable item on the page. Note that |
| | this may be difficult to achieve on a web |
| | page. |
| | Typing a letter (printable character) key moves |
| | focus to the next instance of a visible node whose|
| | title begins with that printable letter. |
|------------------+--------------------------------------------------------|
If focus remains on the button when the Enter or Space key is
pressed, there is no indication that a menu has opened for an AT
user, which is why setting focus to the first menu item works best
for invoking the correct navigational mode as well as for
indicating that an action has occurred. Also, the paradigm for
invoking a menu on the platform always moves focus into a menu, so
that the arrow keys can be immediately used for navigation.
Additionally, if the Down arrow is used to invoke a menu, it
doesn’t account for ATs like screen readers that use virtual
offscreen models such as JAWS and NVDA, where the Down arrow moves
to the next line in the virtual buffer, and is never passed
through to the button.
From: Marco Zehe [mailto:marco.zehe@gmail.com]
Sent: Friday, August 08, 2014 3:58 AM
To: W3C WAI Protocols & Formats
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
, 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
--
Indifference towards people and the reality in
which they live is actually the one and only
cardinal sin in design. — Dieter Rams
Attachments
- image/gif attachment: graycol.gif
Received on Sunday, 10 August 2014 22:40:21 UTC