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?
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
From: Scott González Sent: Thursday, April 07, 2011 11:34 AM To: jQuery Accessibility Subject: aria-orientation + menu
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 jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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.
> 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
> From: Scott González > Sent: Thursday, April 07, 2011 11:34 AM > To: jQuery Accessibility > Subject: aria-orientation + menu
> 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 jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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
From: Hans Hillen Sent: Thursday, April 07, 2011 12:49 PM To: jquery-a11y@googlegroups.com Subject: Re: aria-orientation + menu
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.
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
From: Scott González Sent: Thursday, April 07, 2011 11:34 AM To: jQuery Accessibility Subject: aria-orientation + menu
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 jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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.
> 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
> From: Hans Hillen > Sent: Thursday, April 07, 2011 12:49 PM > To: jquery-a11y@googlegroups.com > Subject: Re: aria-orientation + menu
> 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.
>> 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
>> From: Scott González >> Sent: Thursday, April 07, 2011 11:34 AM >> To: jQuery Accessibility >> Subject: aria-orientation + menu
>> 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 jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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
> 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 jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
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 <cblo...@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
> 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 jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> 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?
-- Rich
From: Hans Hillen Sent: Thursday, April 07, 2011 1:09 PM To: jquery-a11y@googlegroups.com Subject: Re: aria-orientation + menu
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.
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
From: Hans Hillen Sent: Thursday, April 07, 2011 12:49 PM To: jquery-a11y@googlegroups.com Subject: Re: aria-orientation + menu
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.
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
From: Scott González Sent: Thursday, April 07, 2011 11:34 AM To: jQuery Accessibility Subject: aria-orientation + menu
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 jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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.
> > 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?
> -- Rich
> From: Hans Hillen > Sent: Thursday, April 07, 2011 1:09 PM > To: jquery-a11y@googlegroups.com > Subject: Re: aria-orientation + menu
> 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.
>> 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
>> From: Hans Hillen >> Sent: Thursday, April 07, 2011 12:49 PM >> To: jquery-a11y@googlegroups.com >> Subject: Re: aria-orientation + menu
>> 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
>> On Apr 7, 2011, at 6:38 PM, r...@MIT.EDU wrote:
>>> 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
>>> From: Scott González >>> Sent: Thursday, April 07, 2011 11:34 AM >>> To: jQuery Accessibility >>> Subject: aria-orientation + menu
>>> 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 jquery-a11y@googlegroups.com. >>> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >>> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. >>> To post to this group, send email to jquery-a11y@googlegroups.com. >>> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >>> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
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" optionelected”).attr (“value”); See the demo at: http://www.mit.edu/~rjc/aria/selectList.html 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
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?
On Thu, Jul 21, 2011 at 3:43 PM, <r...@mit.edu> wrote: > 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" option[image: Confused smile]elected”).attr (“value”);
> 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
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
