WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Keyboard Navigation Pattern for Navigation Menu with Submenu

for

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

From: Snahendu Bhattacharya
Date: Fri, Jun 24 2016 2:16PM
Subject: Keyboard Navigation Pattern for Navigation Menu with Submenu
No previous message | Next message →

Hi All!

I have one question regarding the keyboard navigation pattern for
navigation menu with submenu.

As per WCAG 2.1.1, it all functionality should be available through a
keyboard interface.

Necessarily it doesn't talks about the pattern on the keyboard navigation
order as that is more a usability issue rather than Accessibility.

*Current keyboard navigational pattern of the menu:*

>> As soon as user TABs to the menu, Submenu opens automatically.
>> If user tabs, focus goes to the next menu (not the submenu)
>> If user uses UP/DOWN arrow key they can navigate to the submenus.

Technically this is accessible as the functionality is accessible through
keyboard.

*Note:* For screen reader user appropriate roles, States, properties and
instructions are provided.

*Question is:*
Does this provide right user experience?
Does all the submenu need to be made available through TAB key?
(Considering the fact auto open functionality of the menu can't be changed)

*For the second question* my personal view is, if user is forced to
traverse through all the menus while pressing TAB (even if they don't want
to see those), would cause more usability issues.

*Can you please let me know your thoughts?*

From: Birkir R. Gunnarsson
Date: Fri, Jun 24 2016 2:53PM
Subject: Re: Keyboard Navigation Pattern for Navigation Menu with Submenu
← Previous message | Next message →

Your model/keyboard behavior looks good to me.
Make sue that, while user has focus inside submenu, pressing "escape"
key will close it and move focus back to the top level element.
I think a well constructed menu with arrow key support provides a much
better user experience than putting all links in the focus order.
There are a couple of scenarios that make this more of a chellenge though:
* A menu can only contain clickable actions (menu items can only be
the equivalent of links or buttons that perform one action when
clicked). If a submenu contains a form field, it is not eally a
submenu and the menu markup can cause serious accessibility issues for
screen readers.
* Frequently the top level menu item is coded to perform two
functions. When user mouses over it, the submenu pops up, if user
clicks it, it navigates to a different page. Mapping this to keyboard
(where pressing arrow down opens submenu and navigates to first item,
but pressing enter navigates user to a diffferent page) requires you
to warn the user. These dual purpose elements should be avoided when
possible, but sometimes it isn't possible.



On 6/24/16, Snahendu Bhattacharya < = EMAIL ADDRESS REMOVED = > wrote:
> Hi All!
>
> I have one question regarding the keyboard navigation pattern for
> navigation menu with submenu.
>
> As per WCAG 2.1.1, it all functionality should be available through a
> keyboard interface.
>
> Necessarily it doesn't talks about the pattern on the keyboard navigation
> order as that is more a usability issue rather than Accessibility.
>
> *Current keyboard navigational pattern of the menu:*
>
>>> As soon as user TABs to the menu, Submenu opens automatically.
>>> If user tabs, focus goes to the next menu (not the submenu)
>>> If user uses UP/DOWN arrow key they can navigate to the submenus.
>
> Technically this is accessible as the functionality is accessible through
> keyboard.
>
> *Note:* For screen reader user appropriate roles, States, properties and
> instructions are provided.
>
> *Question is:*
> Does this provide right user experience?
> Does all the submenu need to be made available through TAB key?
> (Considering the fact auto open functionality of the menu can't be changed)
>
> *For the second question* my personal view is, if user is forced to
> traverse through all the menus while pressing TAB (even if they don't want
> to see those), would cause more usability issues.
>
> *Can you please let me know your thoughts?*
> > > > >


--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Fri, Jun 24 2016 3:26PM
Subject: Re: Keyboard Navigation Pattern for Navigation Menu withSubmenu
← Previous message | No next message

Exactly. Also, if using ARIA Menu/Menubar roles, it is critical to ensure the correct elements receive focus and that such focus matches the same elements that include these role attributes. Otherwise your menu will not work correctly for screen reader users.

An example of this that you can download and examine is available at
https://github.com/accdc/aria-menubar

All the best,
Bryan


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Friday, June 24, 2016 1:53 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard Navigation Pattern for Navigation Menu with Submenu

Your model/keyboard behavior looks good to me.
Make sue that, while user has focus inside submenu, pressing "escape"
key will close it and move focus back to the top level element.
I think a well constructed menu with arrow key support provides a much better user experience than putting all links in the focus order.
There are a couple of scenarios that make this more of a chellenge though:
* A menu can only contain clickable actions (menu items can only be the equivalent of links or buttons that perform one action when clicked). If a submenu contains a form field, it is not eally a submenu and the menu markup can cause serious accessibility issues for screen readers.
* Frequently the top level menu item is coded to perform two functions. When user mouses over it, the submenu pops up, if user clicks it, it navigates to a different page. Mapping this to keyboard (where pressing arrow down opens submenu and navigates to first item, but pressing enter navigates user to a diffferent page) requires you to warn the user. These dual purpose elements should be avoided when possible, but sometimes it isn't possible.



On 6/24/16, Snahendu Bhattacharya < = EMAIL ADDRESS REMOVED = > wrote:
> Hi All!
>
> I have one question regarding the keyboard navigation pattern for
> navigation menu with submenu.
>
> As per WCAG 2.1.1, it all functionality should be available through a
> keyboard interface.
>
> Necessarily it doesn't talks about the pattern on the keyboard
> navigation order as that is more a usability issue rather than Accessibility.
>
> *Current keyboard navigational pattern of the menu:*
>
>>> As soon as user TABs to the menu, Submenu opens automatically.
>>> If user tabs, focus goes to the next menu (not the submenu) If user
>>> uses UP/DOWN arrow key they can navigate to the submenus.
>
> Technically this is accessible as the functionality is accessible
> through keyboard.
>
> *Note:* For screen reader user appropriate roles, States, properties
> and instructions are provided.
>
> *Question is:*
> Does this provide right user experience?
> Does all the submenu need to be made available through TAB key?
> (Considering the fact auto open functionality of the menu can't be
> changed)
>
> *For the second question* my personal view is, if user is forced to
> traverse through all the menus while pressing TAB (even if they don't
> want to see those), would cause more usability issues.
>
> *Can you please let me know your thoughts?*
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.