[kde-guidelines] Possible guidelines for buttons with menus

[Aurélien Gâteau]

Le lundi 5 août 2013 15:05:31 Heiko Tietze a écrit :
> Am Montag, 5. August 2013, 13:43:54 schrieb Thomas Pfeiffer:
> > Of course a split button should never be the only way to do something.
> > However, I think they can be a good compromise between menu entry and
> > toolbar button, or a shortcut.
> 
> A toolbar is used for fast access to frequently used function and not to
> present all features. Menu buttons are the opposite to this functionality.

That is true. Menu buttons provides access to less-used features in situations 
where it is impractical to add a menubar. I think this is handy, especially in 
dialogs.

> In respect to your kmail example: extra functions are moved to main menu
> (where they already should be available too), and a new contact would be
> created by Alt+N+C, or the like.
> 
> But another argument: How do you provide accessibility? I guess the button
> can be reached by tab (if it's not a toolbar button, of course), and then
> cursor down invokes the menu? And again cursor down goes through the items,
> with enter to execute the function? Does it work with a screen reader?

If a splitted button is made of two separated buttons, then when the main part 
is focused, its text will be read by the screen reader, and it can be 
triggered like a classic button.

Pressing tab is going to focus the down-arrow part, which can be triggered to 
reveal the menu like a classic button. We could nevertheless provide better 
accessibility by defining an accessible label for this part because getting 
"down arrow" from the screen reader is not helpful.

Then the menu is visible and focused. Since it is a standard QMenu, Qt 
provides proper accessibility for it.

Aurélien