[ARIA] Another round on combobutton

Several months ago I posted about combobuttons and dropDown buttons and 
there was a discussion thread [1]. After discussions with others what was 
finally implemented in the Dojo toolkit for the button widgets was the 
following:

DropDown Button is a button with a menu.  It has an ARIA role of button 
with a property of haspopup=true.   The dropdown button is in the tab 
order and clicking on it, or pressing enter or space with focus on the 
button will open the menu and set focus to the first menu item.

Combo button is a button with two parts. The first part is a button with 
the default action. The second part is a dropdown button with additional 
choices.  The keyboard implementation was to make two visually joined 
buttons - both are in the tab order. The first part is the default action 
and it behaves as a standard button and is invoked via click, space or 
enter key press. It has an ARIA role of button.  The second portion is a 
dropdown button and works as described above.  The combobutton is 
implemented using table markup with the appropriate ARIA roles. 

The two tab stops for the combobutton is not ideal but was used because 
there is no ARIA role for this type of button.  The dropdown button 
already uses button with haspopup.  Now that Dojo is creating a toolbar, 
the two tab stop behavior of the combobutton is causing problems.   The 
dojo toolbar uses the arrow key to move from button to button within the 
toolbar.  Disabled buttons are not included in the navigation (this is how 
the Mac works and there is no precedent in Windows as I can not find an 
example of a keyboard accessible toolbar).  So, when in a toolbar, the 
combobutton will work via the arrow keys, the user will press the arrow to 
move from the default portion of the button to the dropdown portion of the 
button.   When not in a toolbar the tab key will still be used to navigate 
the combobutton.

But, I still do not think the problem is solved because there is no way to 
indicate to the screen reader user the nature of the combobutton - that it 
is a two part button with a default action and a drop down portion.  I 
really think we need to consider an additional ARIA role for this type of 
button.  I realize the that accessibility API's don't have an existing 
role but we need to start somewhere and perhaps ARIA can be the first 
step. 

Or does someone have other ideas about how we can make this type of button 
accessible today? 

In Dojo we have considered treating the combobutton like a mini-toolbar 
and using the arrow keys to move between the button parts. We could mark 
up the combo button with the ARIA role of toolbar. The "toolbar" would 
contain a regular button and a dropdown button.  But, this could get 
confusing when the combobutton was included in a toolbar - it would be odd 
to have a toolbar within a toolbar. 

Dojo also considered adding support for the down arrow key to the 
combobutton but I don't know how we would distinguish this from a dropdown 
button?   How can we indicate to a screen reader user that a button has a 
default action on click/enter/space AND a set of options with down arrow? 
We might be able to use describedby to add the information but this has 
implications for internationalization.

comments?
thanks,
-becky

[1] http://lists.w3.org/Archives/Public/wai-xtech/2007Feb/0002.html

Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
blog: WebA11y

Received on Monday, 17 September 2007 19:40:14 UTC