E-mail List Archives

Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus

for

From: Michael Tangen
Date: Aug 28, 2014 12:26PM


Thanks all for the helpful feedback. Would you be willing to take a look
at the menu with the changes? http://designbymichael.com/test/menu/

One issue I found, though — I know that typically it's the <UL> tags that
should be assigned the role="menu" attribute, but I noticed that JAWS would
*not* announce "has submenu" on the *first level* menu items that have
child menus — even if the actual first level menu item <A> tag has the
attribute aria-haspopup="true". But beyond the first level, JAWS would
announce "has submenu" to all subsequent child menus.

I found that if I add "role="menu" to the *first level* <LI> tags in
addition to (or instead of) the first <UL> tag, it would then announce "has
submenu" to notify the user of subsequent menus. Is this the correct way
to compensate for this?

Also, I noticed that by implementing it in a way that works within JAWS
causes it to no longer work with VoiceOver for Safari on the Mac. I
suspect it has something to do with defining the tabindex, but I haven't
been able to get it to work for both JAWS and VoiceOver. Any clues?




On Wed, Aug 27, 2014 at 1:46 PM, Daniel Tang (dtang) < <EMAIL REMOVED> >
wrote:

> Michael:
>
>
> I am delighted that you have developed accessibility for this.
>
> Regarding the issues on TAB, Shift and the arrows keys with JAWS, have you
> explored the possibility of adding another key combination (for example the
> control key).
> Press Control and an Arrow key together or Control Tab...?
>
>
> Best
>
>
>
>
>
>
> Daniel Tang
> <EMAIL REMOVED>
> Phone: +1 408 526 7814
>
>
>
>
>
>
>
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto:
> <EMAIL REMOVED> ] On Behalf Of Michael Tangen
> Sent: Friday, August 22, 2014 12:39 PM
> To: <EMAIL REMOVED>
> Subject: [WebAIM] resolving conflict between JAWS and key-press events for
> navigating large drop-down menus
>
> I have been toiling over this for weeks now, researching solutions that
> others have developed for fully keyboard-navigable menus (both for sited
> users that have physical impairments and for non-sighted users that rely on
> assistive technology such as JAWS). I have a drop-down menu script <
> http://designbymichael.com/test/menu/>; that I've built for our state
> agencies at the State of Minnesota and it works quite well....but I am
> having one problem: JAWS has reserved both the use of arrow keys and the
> space bar...and this is a problem from my perspective. While those keys do
> offer the user certain abilities, it does restrict my ability to allow a
> user to navigate through complex menu systems with arrow keys or to toggle
> the display of submenus. If there's one thing that state government are
> known for is vast layers of navigation to traverse through — and I'm trying
> to alleviate that a little.
>
> The example menu I hyperlinked below allows you to navigate through the
> entire menu one of two ways: using arrow keys to drill down through the
> menus and traverse back up again, or using a combination of the tab and
> shift-tab keys to navigate and the spacebar to toggle the visibility (and
> accessibility) of submenus. It works fine when you are just using a
> browser without JAWS or on the Mac if you use Safari along with VoiceOver.
> Furthermore with VoiceOver and Safari, you can navigate through the menu
> with either the arrow keys or the tab keys with space bar to toggle
> subnavigation visibility.
>
> So I'm at a loss as what to do for JAWS users. What keyboard event can I
> use to toggle the display of submenus without conflicting with keyboard
> shortcuts that are reserved by JAWS? My requirements:
>
>
> - Submenus must be hidden when not activated or needed, largely so the
> screen reader doesn't read dozens and dozens of links that the user may
> have no interest in hearing
> - Intuitive means of navigating through complex trees of navigation
> (arrow keys and/or (shift) tab keys)
> - If arrow keys are not available to the end user (I'm looking at you
> JAWS), an intuitive key choice to toggle the visibility of a submenu.
>
> I've taken all the known steps to ensure accessibility, but I'm at a loss
> with the conflict of what keys JAWS has assumed for itself with what keys
> are commonly used for navigational purposes.
>
> Thoughts?
>
> Test menu: http://designbymichael.com/test/menu/
>
> - Michael
> > > messages to <EMAIL REMOVED>
> > > >