aria-orientation + menu

121 views
Skip to first unread message

Scott González

unread,
Apr 7, 2011, 11:34:30 AM4/7/11
to jQuery Accessibility
Hans, Jörn and I were discussing the menu and menubar implementations and we got stuck on the handling for arrow keys. Since nested menus require movement in both directions (horizontal and vertical), the left/right arrow keys can't be treated the same as the up/down arrow keys like they are in many other widgets. We were thinking that we could pick the appropriate keys based on the orientation, but aria-orientation isn't listed as being valid for menu and menubar roles. Is there a recommended solution that makes sense for both sighted and blind users?

r...@mit.edu

unread,
Apr 7, 2011, 12:38:56 PM4/7/11
to jquer...@googlegroups.com
As a blind user, my perspective is that orientation shouldn’t matter – a menu is a menu is a menu and it should work the same way no matter how it looks.
To that end, maybe it makes sense to forget about the “menubar” concept and just treat menus as trees from the keyboard perspective.
 
- up/down moves from sibling to sibling
- left/right opens/closes currently focused  submenu
- enter executes the command at a leaf node, or opens the submenu
- escape closes all menus and moves you out of the widget to next sibling in the dom
 
Does this make sense?
-- Rich
--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.

Hans Hillen

unread,
Apr 7, 2011, 12:49:33 PM4/7/11
to jquer...@googlegroups.com
Hi Rich, 

the problem is that a menubar is normally oriented horizontally, so it  makes sense both visually and programmatically to use up and down arrow keys  for expanding the menu and navigating submenus, while the left and right arrow keys are used to move to the adjacent sub menus in the menubar. But with a vertical menu bar that behavior would be the opposite, because  the menubar items are now below each other instead of next to each other. If we always use the same arrow key configuration regardless of orientation it would very confusing for sighted keyboard users. Note that this issue only applies for the menubar itself, the expanded sub menus would always behave the same way.

Regards,

Hans Hillen

r...@mit.edu

unread,
Apr 7, 2011, 1:02:34 PM4/7/11
to jquer...@googlegroups.com
Does this mean that the vertical style would be more like a tree?  If this is the case, then you could use tree-related roles for vertical menus and the menu/menubar related roles for horizontal menus. 
 
The other possibility might be to use aria-label to specify the orientation to the user so they can know how to operate it.  Without this info, I think the blind user will be very confused.  Most people have encountered trees before (windows explorer, outlook, outlookexpress, etc), so if vertical menus can be made to feel like trees, then blind users will know how to use them.
 
-- Rich

Hans Hillen

unread,
Apr 7, 2011, 1:09:54 PM4/7/11
to jquer...@googlegroups.com
I agree on the confusion part, but using tree markup isn't sufficient either. A tree implies that one more branches can be kept open indefinitely, while only one submenu can be opened at a time and will automatically collapse once the menubar loses focus. I guess we just need to set up a working version of a vertical menubar and see what the most intuitive solution is.

Hans

Chris Blouch

unread,
Apr 7, 2011, 1:03:35 PM4/7/11
to jquer...@googlegroups.com
It's probably treading a bit into the area of an edge case as vertical
menubars aren't that common in the wild. That said, a screen reader user
will only know that it is a menu or menubar and will expect the typical
left-right bar navigation with up down to inspect items in a particular
category. Visual keyboard users might find it a bit odd to use
left/right to navigate a columnar menu, but the cognitive load shouldn't
be very high. I think if you flip the keys to make more sense to a
visual keyboard user it will have a very disorienting effect for screen
reader users as there is no standard way to inform them that the widget
is rotated. Lesser of two evils is to leave the keys as they are. We
didn't even consider vertical menus in the DHTML Style Guide
[http://dev.aol.com/dhtml_style_guide#menu] and I would have to wonder
if it isn't bad UI. See

http://www.smashingmagazine.com/2010/01/11/the-case-against-vertical-navigation/

At least it's not a familiar cross-pollination from the desktop where
all users are familiar with horizontal menus.

CB

On 4/7/11 11:34 AM, Scott Gonz�lez wrote:
> Hans, J�rn and I were discussing the menu and menubar implementations

Scott González

unread,
Apr 7, 2011, 1:40:02 PM4/7/11
to jquer...@googlegroups.com
What the average person considers a vertical menubar is indeed not common. However, during our discussion, I asked if there are actually any semantic differences between a menu and a menubar and Hans brought up the fact that when you assign the role of menu to an element, screen readers will announce that a menu has opened. The screen reader may also switch into a mode that is very confusing for the user as a result.

If you look at amazon.com, they have a navigation menu on the left. This is a very common design and the cause of most of our problems right now. The navigation menu is always visible and should not be announced during page load, but it should follow the standard interaction of a menu (hover to activate submenus). The fact that it's always visible and should not be announced suggests that it should be marked as a menubar from an accessibility standpoint. However, the fact that it reacts to hover suggests that it is a standard menu from a development standpoint.


On Thu, Apr 7, 2011 at 1:03 PM, Chris Blouch <cbl...@aol.com> wrote:
It's probably treading a bit into the area of an edge case as vertical menubars aren't that common in the wild. That said, a screen reader user will only know that it is a menu or menubar and will expect the typical left-right bar navigation with up down to inspect items in a particular category. Visual keyboard users might find it a bit odd to use left/right to navigate a columnar menu, but the cognitive load shouldn't be very high. I think if you flip the keys to make more sense to a visual keyboard user it will have a very disorienting effect for screen reader users as there is no standard way to inform them that the widget is rotated. Lesser of two evils is to leave the keys as they are. We didn't even consider vertical menus in the DHTML Style Guide [http://dev.aol.com/dhtml_style_guide#menu] and I would have to wonder if it isn't bad UI. See

http://www.smashingmagazine.com/2010/01/11/the-case-against-vertical-navigation/

At least it's not a familiar cross-pollination from the desktop where all users are familiar with horizontal menus.

CB


On 4/7/11 11:34 AM, Scott González wrote:
Hans, Jörn and I were discussing the menu and menubar implementations and we got stuck on the handling for arrow keys. Since nested menus require movement in both directions (horizontal and vertical), the left/right arrow keys can't be treated the same as the up/down arrow keys like they are in many other widgets. We were thinking that we could pick the appropriate keys based on the orientation, but aria-orientation isn't listed as being valid for menu and menubar roles. Is there a recommended solution that makes sense for both sighted and blind users?
--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.

r...@mit.edu

unread,
Apr 7, 2011, 2:14:15 PM4/7/11
to jquer...@googlegroups.com
>    I agree on the confusion part, but using tree markup isn't sufficient either. A tree implies that one more branches can be kept open indefinitely, ...
 
Can you makrup things with more than one role ( role=”tree menu” ) or some such?

Hans Hillen

unread,
Apr 7, 2011, 2:22:24 PM4/7/11
to jquer...@googlegroups.com
Hi Rich, 

No, only one role can be set at a time. I think at this point the best thing to do is to come up with a working example for you to try out, and we'll take it from there.

Hans

r...@mit.edu

unread,
Jul 21, 2011, 3:43:11 PM7/21/11
to jquer...@googlegroups.com, Hans Hillen
The change event fires only when you blur the list. To cause it to fire as you move through the list with arrow keys, you need to add a keypress handler to the chain.
 
$(“select”).trigger (function () {
// This fires when you click on an item with the mouse
// it does not fire when you use arrow keys to scroll through the list
// *unless* you open the list first with alt+downArrow
// however this requires extra keystrokes
}).keypress (function (e) {
if (e.keyCode == 38 || e.keyCode == 40)
$(this).trigger (“change”); // fire the change event whenever we press an up/down arrow
});
 
This all works very well, unless the list has been hidden. If you hide and subsequently unhide the list, then traverse with arrows, the selection is not reported correctly until the page is refreshed.
This happens when using DOM calls to retrieve the currently selected index, and when pure jQuery is used:
$(“select" optionConfused smileelected”).attr (“value”);
 
See the demo at:
 
Is this a jQuery bug, or a Firefox issue?  I cannot test in IE; the code does not work at all.
In Safari with VoiceOver, the list is always rendered as a dropdown menu. This is equivalent to first openeing the list with alt+downArrow in windows.
 
Hope this makes sense; this is a difficult issue to describe in words.
-- Rich
 
wlEmoticon-confusedsmile[1].png

Scott González

unread,
Jul 22, 2011, 10:26:11 AM7/22/11
to jquer...@googlegroups.com, Hans Hillen
This looks like a Firefox bug, but the keypress events don't do anything in Chrome either, so I'm not sure that this is a good approach to take anyway. Why do you want change events to be triggered while the user is just navigating through the items?


--
wlEmoticon-confusedsmile[1].png
Reply all
Reply to author
Forward
0 new messages