E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Michael Tangen
Date: Fri, Aug 22 2014 1:39PM
Subject: resolving conflict between JAWS and key-press events for navigating large drop-down menus
No previous message | Next message →

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

From: Bryan Garaventa
Date: Fri, Aug 22 2014 2:02PM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

In looking at the code, the ARIA attribute markup isn't correctly applied, which is one reason why these differences are occurring. E.G the role=menuitem and aria-haspopup attributes are applied on elements that are not focusable while links are embedded within, which are. Also, the paradigm for a menu is to have one tab stop for one menu structure, as with a standard OS menu.

The guide at
http://whatsock.com/training/
Explains how to correctly implement ARIA menus, within the section " ARIA, Important Details".

From: Jonathan Avila
Date: Mon, Aug 25 2014 7:19AM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

Michael, I believe your ARIA roles could be on the wrong elements. Take a look at this mega menu implementation contributed by Adobe. http://adobe-accessibility.github.io/Accessible-Mega-Menu/

Best Regards,

Jonathan
SSB BART Group

From: Mallory van Achterberg
Date: Mon, Aug 25 2014 8:07AM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

I gotta say, I really like that Abode isn't using the whole menu/
menuitem role stuff. Reading the spec, that menu stuff sounds
entirely like an application/widget thingie, not a list of links
like all web navigation menus should be.

But as a sighted keyboarder, discoverablility hits me there.
If I didn't think to try mystery-meating with my arrow keys,
I as a "Typical Web Keyboarder User" would never, ever know
that there were any submenus. If I use tab or the left/right
arrows I move along as expected to the main menu items (sparing
me the Thousand Tabs of Death), and I see if yo *do* magically
happen to try using a top/bottom arrow key, then aria-expanded
and aria-hidden set to "false" should let users know there's an
existing, active, explorable submenu.

On the other hand, the Adobe menu mostly seems awesome as a web
menu, but what Michael describes seems an awful lot like a
complicated government-style menu with a lot of controlly thing...
in which case, I dunno, maybe he should be using the complicated
(and easy to mess up apparently) menu/menuitem role system.

_mallory
On Mon, Aug 25, 2014 at 01:19:00PM +0000, Jonathan Avila wrote:
> Michael, I believe your ARIA roles could be on the wrong elements. Take a look at this mega menu implementation contributed by Adobe. http://adobe-accessibility.github.io/Accessible-Mega-Menu/
>
> Best Regards,
>
> Jonathan
> SSB BART Group
>
>

From: Daniel Tang (dtang)
Date: Wed, Aug 27 2014 12:46PM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

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 ADDRESS REMOVED =
Phone: +1 408 526 7814

From: Michael Tangen
Date: Thu, Aug 28 2014 12:26PM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> Phone: +1 408 526 7814
>
>
>
>
>
>
>
>

From: David Farough
Date: Thu, Aug 28 2014 1:36PM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

Hi Michael:
Have you looked at the keyboard interaction for menus found in
http://www.w3.org/TR/wai-aria-practices/#menu
I noticed that using the left arrow when within a submenu does not
close the submenu, but moves up to the previous menu item instead. The
escape key and the left arrow should close the submenu placing focus on
the parent. I noticed that pressing escape closed the menu completely
regardless of the menu item with focus.

David Farough
coordonateur de l'accessibilité
/Application Accessibility Coordinator
Direction des services d'information technologiques /
Information Technology Services Directorate
Commission de la fonction publique /Public Service Commission
Courriel / Email: = EMAIL ADDRESS REMOVED =
Tél / Tel. (819) 420-8418


>>> Michael Tangen < = EMAIL ADDRESS REMOVED = > 02:26 PM Thursday, August
28, 2014 >>>
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/


>
Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.

>
This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.

From: Michael Tangen
Date: Thu, Aug 28 2014 3:35PM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | Next message →

Thanks for passing that along, David. I'll take a look and take that into
consideration. The keyboard behavior of the menu (as it is now) has been
deliberated about considerably by our team from a usability perspective
(what we know most end users would expect from a visual response).



On Thu, Aug 28, 2014 at 2:36 PM, David Farough < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi Michael:
> Have you looked at the keyboard interaction for menus found in
> http://www.w3.org/TR/wai-aria-practices/#menu
> I noticed that using the left arrow when within a submenu does not
> close the submenu, but moves up to the previous menu item instead. The
> escape key and the left arrow should close the submenu placing focus on
> the parent. I noticed that pressing escape closed the menu completely
> regardless of the menu item with focus.
>
> David Farough
> coordonateur de l'accessibilité
> /Application Accessibility Coordinator
> Direction des services d'information technologiques /
> Information Technology Services Directorate
> Commission de la fonction publique /Public Service Commission
> Courriel / Email: = EMAIL ADDRESS REMOVED =
> Tél / Tel. (819) 420-8418
>
>
> >>> Michael Tangen < = EMAIL ADDRESS REMOVED = > 02:26 PM Thursday, August
> 28, 2014 >>>
> 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/
>
>
> >
> Ce courriel est destiné exclusivement au destinataire mentionné en titre
> et peut contenir de l'information privilégiée, confidentielle ou
> soustraite à la communication aux termes des lois applicables. Toute
> divulgation non autorisée, toute reproduction ou réacheminement est
> interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
> pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
> par erreur, veuillez le mentionner immédiatement à l'expéditeur et
> supprimer le courriel et les copies.
>
> >
> This e-mail message is intended for the named recipient(s) and may
> contain information that is privileged, confidential and/or exempt from
> disclosure under applicable law. Unauthorized disclosure, copying or
> re-transmission is prohibited. If you are not a named recipient or not
> authorized by the named recipient(s), or if you have received this
> e-mail in error, then please notify the sender immediately and delete
> the message and any copies.
>
>
> > > >

From: Mallory van Achterberg
Date: Fri, Aug 29 2014 12:53AM
Subject: Re: resolving conflict between JAWS and key-press events for navigating large drop-down menus
← Previous message | No next message

On Thu, Aug 28, 2014 at 01:26:37PM -0500, Michael Tangen wrote:
> 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?

http://terrillthompson.com/blog/202

This is old, as it states at the top, because it seems he came to the
same conclusion many of us did-- that the menu/menuitem setup sucks for
"normal" web navigation. But, if you follow the rules in his post and
on the ARIA spec page, you can get JAWS to announce everything correctly.

Basically if you make any little mistake, assign the wrong role to the
wrong thing, it'll break.

So anyway you were on the right track setting role=menu on the li, as the
ul gets "menubar".

_mallory