Re: toolbar keyboard navigation

Matthew,
> I do not know that there are significant differences among these 
> approaches to representing the visual semantics with ARIA markup. 
> Perhaps they are all acceptable. 
OpenOffice supports turning on and off various named toolbars.  Examples 
include "3D-Settings", "Align", "Form Controls", and so on.  It also 
allows reordering the toolbars by dragging them to different locations 
within the toolbar docking zone. I suspect that kind of functionality 
will make its way into DHTML eventually, since allowing users to 
configure their user interface is the trend these days.  But, if there 
is only one large toolbar, users can only turn that one on and off, and 
all the groupings within will go with it.  My intuition remains the same 
as before: that this tool bar should be broken up into a set of 
toolbars, visually stacked.  A 40 control toolbar is visually cluttered, 
making it difficult to find the control I want.  As a visual user, I'd 
like to see this toolbar better organized.

As for the generic group role vs. the more specific toolbar role:  As 
Rich pointed out, "toolbar" inherits from the group role.  In brief, 
then, it's a group of tools.  The inner groups that are proposed are 
also groups of tools.  But, they aren't described as toolbars, just as 
generic groups.  I find that unintuitive.

Finally, regarding the use of nested groups within a single toolbar: as 
a sighted user, I'd find the navigation scheme annoying.  As I arrow 
through the toolbar, I suddenly start wrapping at the group boundaries.  
To escape that boundary, I must now press the tab key.  Why can't I 
continue to arrow through this toolbar?  Why do I have to switch to tab 
now?   If they were separate toolbars stacked vertically, then that 
wouldn't be as much an annoyance, since I could see clearly that one 
toolbar ends and another begins.  For a quick and dirty example of 
stacked toolbars, see, 
http://clown.atrc.utoronto.ca/Fluid/aria/toolbar/MozRTEditDemo2.html 
(might require FireFox, since that's the only browser I've tested it with).

However, if the upshot of this is to nest groups within toolbars, I 
suggest a minimum size of 7-10 tools to mitigate the wrapping within a 
group.

> With this option, I would suggest that we also give the div containing 
> all the toolbars a role of group or region and a label. This is much 
> like option 1 except that the containing div is a group instead of a 
> toolbar as in option 1. This approach is covered by the DSG. 

Yes, something like this is going on in desktop apps.  In OpenOffice, 
there's a grey region that holds the toolbars ("docked", as it were).  
It would be useful in a web app too as you describe.  It might be useful 
to introduce a role of toolbargroup, but, perhaps the group role is 
sufficient.  I'm not sure.

> To accommodate these options, a possible suggestion for wording in the 
> DSG is:

This sounds like reconvening the style guide group and discussing the 
various options.  Is that the next step?

-- 
;;;;joseph

'Clown control to Mao Tse Tung.'
  - D. Bowie (misheard lyric) -

Received on Friday, 7 May 2010 21:53:15 UTC