WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Mega Menu

for

From: Birkir R. Gunnarsson
Date: Jan 11, 2017 7:58AM

Implementing complex page controls is always tricky, especially when
retrofitting them for accessibility.
The interaction design is often done, and coding may even be partially
completed by the time you get an accessibility opinion in.
I thik correctly using a slightly modified version of the megamenu
(modified in the sens that the menu triggering items are in focus
order and display the submenus when users put focus on them with the
tab key) is not a bd interaction design. Granted, as you said, that
all the screen reader menu roles and attributes are placed correctly.
It is a popular concept in interactive design to have large lists of
navigation links look like menus and placing them in the header.
For mouse users, the idea of mousing over the triggering element
causes its associated menu to be displayed is popular.
At this point we can either have the user tab through all the items in
submenu one before getting to submenu 2, changing the interaction
design to accordion style icons (which visual designers are not happy
with if they have designed the menus differently), or implement some
sort of a megamenu construct.
Basically, there is no right answer, we often have to make the best of
tricky situations, and sometimes the solutions turn out very good,
sometimes less so.




On 1/10/17, Rakesh P < <EMAIL REMOVED> > wrote:
> I was recommending Deque University mega menu example for a couple of years
> now. https://dequeuniversity.com/library/aria/menus/megamenu
>
>
> On Tue, Jan 10, 2017 at 6:34 PM, Detlev Fischer < <EMAIL REMOVED>
>> wrote:
>
>> Hi Birkir,
>> The main point is that the menu is not just one tab stop and supports
>> tabbing rather than arrow navigation. Navigation submenu items as a simple
>> list of links (i.e. not with ARIA role menuitem) then seem to suffice and
>> make for lighter code / less opportunities to get some ARIA mark-up wrong.
>> But I am happy to be corrected if there are advantages I haven't thought
>> of.
>> Best, Detlev
>>
>> --
>> Detlev Fischer
>> testkreis c/o feld.wald.wiese
>> Thedestr. 2, 22767 Hamburg
>>
>> Mobil +49 (0)157 57 57 57 45
>> Fax +49 (0)40 439 10 68-5
>>
>> http://www.testkreis.de
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>> Birkir R. Gunnarsson schrieb am 10.01.2017 13:02:
>>
>> > Detlev
>> > How is the markup you describe different from ARIA menus (with the
>> > alteration that the main menu items or menu triggers are in the tab
>> > order)?
>> >
>> >
>> > On 1/10/17, Detlev Fischer < <EMAIL REMOVED> > wrote:
>> >> I would advise against using the ARIA menu construct for navigation
>> menus.
>> >> From years of experiencing other sites, many users expect to be able to
>> tab
>> >> through the main navigation items. Submenus may then open on focussing
>> the
>> >> main menu items or after hitting Enter, the latter giving the advantage
>> that
>> >> focus can be moved quickly through the main menu items (and beyond).
>> >> I would reserve the ARIA menu construct for application style menus
>> where
>> >> using arrow keys will be more expected.
>> >>
>> >> Detlev
>> >> --
>> >> Detlev Fischer
>> >> testkreis c/o feld.wald.wiese
>> >> Thedestr. 2, 22767 Hamburg
>> >>
>> >> Mobil +49 (0)157 57 57 57 45
>> >> Fax +49 (0)40 439 10 68-5
>> >>
>> >> http://www.testkreis.de
>> >> Beratung, Tests und Schulungen für barrierefreie Websites
>> >>
>> >> Birkir R. Gunnarsson schrieb am 10.01.2017 00:24:
>> >>
>> >>> Joseph
>> >>> It all depends on the nature of the menu and, quite frankly, testing
>> >>> with the users, I have not come across a clearcut answer.
>> >>> The menu construct is a little tricky and screen reader support is not
>> >>> perfect, though pretty good.
>> >>> Actually Jaws in IE repeats each menu item twice (for no reason),
>> >>> Firefox handles it correctly.
>> >>>
>> >>> The menu role forces screen readers to go into forms mode, so they
>> >>> start depending on you having done all the right keyboard navigation
>> >>> and focus management.
>> >>> It also depends on the users knowing the keyboard shortcuts.
>> >>> * Pressing enter or space bar on a menu item with submenu opens the
>> >>> submenu and puts focus on the first menuitem.
>> >>> * arrow keys up and down cycle through menu items.
>> >>> * escape key dismisses the menu and puts focus back on the menuitem.
>> >>> * If this is a whole menubar (menu of menus) arrow keys right and left
>> >>> navigate between adjacent menu triggers.
>> >>>
>> >>> The spec says that the whole menu construct should be a single tab
>> stop.
>> >>> I have found that this is not intuitive so I have made each menu
>> >>> trigger a tab stop, though users can also use arrow keys to navigate
>> >>> between them.
>> >>> You can go to http://www.statefarm.com and play with the navigation
>> >>> menu in the header to see if you like that kind of construct better
>> >>> than one that minimizes use of ARIA and uses more links and lists with
>> >>> some keyboard navigation.
>> >>> The cool thing about the State Farm menu construct, for sighted
>> >>> keyboard only users, is that the menus drop down as soon as the
>> >>> trigger (insurance, finances, claims, customer care) receives focus.
>> >>>
>> >>> I personally don't have a clear answer or pference, though I have gone
>> >>> with the full menu markup on a few of the constructs I have worked on.
>> >>> Cheers
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 1/9/17, Joseph Sherman < <EMAIL REMOVED> > wrote:
>> >>>> Against the ARIA specs, the Adobe Mega
>> >>>> menu<http://adobe-accessibility.github.io/Accessible-Mega-Menu/>;
>> chooses
>> >>>> not
>> >>>> to use role="menu" for the menu container and role="menuitem" so
>> links in
>> >>>> the global navigation will show up when a screen reader user executes
>> a
>> >>>> shortcut command to bring up a list of links in the page.
>> >>>>
>> >>>> Which is preferred by users?
>> >>>>
>> >>>> Joseph
>> >>>>
>> >>>> >> >>>> >> >>>> >> >>>> >> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Work hard. Have fun. Make history.
>> >>> >> >>> >> >>> >> >>> >> >>>
>> >>
>> >> >> >> >> >> >> >> >> >>
>> >
>> >
>> > --
>> > Work hard. Have fun. Make history.
>> > >> > >> > >> > >> >
>>
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.