E-mail List Archives

Search E-mail List Archives for

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

From: Joseph Sherman
Date: Mon, Jan 09 2017 2:19PM
Subject: Mega Menu
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Mon, Jan 09 2017 4:24PM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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.

From: Detlev Fischer
Date: Tue, Jan 10 2017 4:03AM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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.
> > > > >

From: Birkir R. Gunnarsson
Date: Tue, Jan 10 2017 5:02AM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.

From: Detlev Fischer
Date: Tue, Jan 10 2017 6:04AM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.
> > > > >

From: Rakesh P
Date: Tue, Jan 10 2017 6:09PM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> > > > > > > > > >
>
> > > > >

From: Birkir R. Gunnarsson
Date: Wed, Jan 11 2017 7:58AM
Subject: Re: Mega Menu
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.

From: Detlev Fischer
Date: Fri, Jan 13 2017 10:05AM
Subject: Re: Mega Menu
← Previous message | Next message →

Just noting that this example may not be built with mobile UA and AT in mind, but not sure if others fare better in that respect. I just looked at it on iOS with Voiceover on and activating the main menu items (like 'about') doesn't seem to toggle expanded state. Menu items report 'expanded' even if they aren't (not sure whether this is mobile or even iOS specific behaviour).

Sent from phone

> Am 11.01.2017 um 02:09 schrieb Rakesh P < = EMAIL ADDRESS REMOVED = >:
>
> 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
>>> >>> >>> >>> >>>
>>
>> >> >> >> >>
> > > >

From: Joseph Sherman
Date: Fri, Jan 13 2017 3:01PM
Subject: Re: Mega Menu
← Previous message | Next message →

Thanks. If the sub-menus open when focused, does Tab go into the sub-menu or just to main items?
Also, how does a screen reader user know it's a sub-menu or that it's expanded?
For example on https://www.joedolson.com/



Joseph

>

From: Detlev Fischer
Date: Fri, Jan 13 2017 11:20PM
Subject: Re: Mega Menu
← Previous message | Next message →

Just tested the Deque Mega Menu https://dequeuniversity.com/library/aria/menus/megamenu# <https://dequeuniversity.com/library/aria/menus/megamenu#>
quickly on a Mac with Safari. The submenus expand when activated, not when focused, which is fine (and they expand on mouseover).
What's different from what I expected is that the focus automatically moves to the first subindex item after activation.
This is one way of emphasising that the menu is no open - you don't need to tab or arrow onwards to get to the first item. The drawback is that the action on the main menu item is not a simple toggle action. But you can get back to the collapsed state (and your former focus point on the main menu items) hitting ESC.

> On 13 Jan 2017, at 23:01, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks. If the sub-menus open when focused, does Tab go into the sub-menu or just to main items?
> Also, how does a screen reader user know it's a sub-menu or that it's expanded?
> For example on https://www.joedolson.com/
>
>
>
> Joseph
>
>>

From: _mallory
Date: Wed, Jan 18 2017 5:51AM
Subject: Re: Mega Menu
← Previous message | Next message →

It's in Dutch, but I've wondered how the menu at vanbeekdesign.nl does.
I feel it's main drawback for screen reader users is that while the
submenus appear on focus (hitting Enter would activate the link like
normal), you would have to try arrowing around to know whether there
IS a submenu. Someone recommended aria-haspopup once for that, but
not sure if that makes sense for things without menu roles.

The main drawback for sighted keyboard users is they would have to know
to switch to arrow keys. On the other hand, that makes tabbing through
the menu fast (the subs are much much too large but the client insisted
on stuffing everything under the sun in the submenus) compared to having
all the subs' anchors themselves in the tab order.

The main menu items themselves are fallbacks if for any reason a user
can't reach the subs, or doesn't see them, since the main links go to
category pages anyway, from which one can eventually reach everything
also listed in the subs. I'm still not sure how intuitive it is percieved
by most users, and I'm pretty sure pure screen reader users miss the subs
entirely anyway.

cheers,
_mallory


On Sat, Jan 14, 2017 at 07:20:49AM +0100, Detlev Fischer wrote:
> Just tested the Deque Mega Menu https://dequeuniversity.com/library/aria/menus/megamenu# <https://dequeuniversity.com/library/aria/menus/megamenu#>
> quickly on a Mac with Safari. The submenus expand when activated, not when focused, which is fine (and they expand on mouseover).
> What's different from what I expected is that the focus automatically moves to the first subindex item after activation.
> This is one way of emphasising that the menu is no open - you don't need to tab or arrow onwards to get to the first item. The drawback is that the action on the main menu item is not a simple toggle action. But you can get back to the collapsed state (and your former focus point on the main menu items) hitting ESC.
>

From: Joseph Sherman
Date: Wed, Jan 18 2017 7:42AM
Subject: Re: Mega Menu
← Previous message | Next message →

Is there a way to indicate to screen readers the existence of a sub-menu when the sub-menus open when focused? Usually I would use haspopup or expanded/collapsed, but those imply user action to open/close.

Joseph

>

From: Jeremy Anderson
Date: Wed, Jan 18 2017 9:00AM
Subject: Re: Mega Menu
← Previous message | Next message →

If the menu opens on focus, does the submenu have to be hidden from the screen-reader in the first place? (Or did you mean active, rather than focused?)

Jeremy.

> On 18 Jan 2017, at 14:42, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>
> Is there a way to indicate to screen readers the existence of a sub-menu when the sub-menus open when focused? Usually I would use haspopup or expanded/collapsed, but those imply user action to open/close.
>
> Joseph
>
>>

From: Joseph Sherman
Date: Wed, Jan 18 2017 10:02AM
Subject: Re: Mega Menu
← Previous message | Next message →

The menus open when hover and focus is on the top level item. They are not "hidden" from screen reader users, who can tab or arrow down to sub menu items, but the structure of top level and sub menus is not communicated to screen reader.

Would making top level menu items h2 be enough to inform screen reader users there are sub items?

Joseph

On Jan 18, 2017 11:01 AM, Jeremy Anderson < = EMAIL ADDRESS REMOVED = > wrote:
If the menu opens on focus, does the submenu have to be hidden from the screen-reader in the first place? (Or did you mean active, rather than focused?)

Jeremy.

> On 18 Jan 2017, at 14:42, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>
> Is there a way to indicate to screen readers the existence of a sub-menu when the sub-menus open when focused? Usually I would use haspopup or expanded/collapsed, but those imply user action to open/close.
>
> Joseph
>
>>

From: Birkir R. Gunnarsson
Date: Wed, Jan 18 2017 10:21AM
Subject: Re: Mega Menu
← Previous message | Next message →

Going back to www.statefarm.com - the megamenu in the header was
optimized for keyboard only and screen reader user, taking advantage
of ARIA.
* The menu triggering itames (insurance, finances, claims, customer
service) are focusable, and when focused or hovered will display the
submenus. For screen readers, these are wrapped in an element with
role="menubar" to indicate they are part of a horizontal menu, and
have role="menuitem" and aria-haspopup="true" to indicate that they
have submenus.
You can get through them either by tabbing or arrow keys right/left
(the menubar role represents a horizontal presentation of a menu, so
screen readers should instruct the users to use left/right arrows.
To get from the top level menu items to the submenus you can press
enter, space bar or arrow down.
* You can navigate through submenus with arrow keys (up/down) and
activate an item with the enter key. If you choose not to activate any
you can press the escape key which closes the menu and puts focus back
up on the top level item.
Visually menus are closed when you tab away from the top level item.
* For screen readers each submenu is labeled by the top level item,
the full meu construct is used so screen readers cen tell users the
number of items in the menu as well as the relative position of
current item (3 ot 8, 4 of 8 etc.).

* The first item in each submenu is a link out to the landing page for
that category, if users prefer to explore by more traditional means.

I believe this presents a good example of using pure menu markup to
construct a navigation megamenu.
This works well when tested with keyboard or NVDA in Firefox, and
reasonably well with Jaws.
One must be careful to only use menu markup on all elements, don't use
headings and lits and links and buttons mixed In.
If using unordered lists as containers for submenus, mark the <ul>
eement as a menu and <li> elements as presentational.
<ul role="menu" aria-label="submenu x">
<li role="presentation"><a href="#" role="menuitem">Submenu item 1</a></li>
...
</ul>

It is not the only way to make navigation menus accessible, oh no
precious, but I think it is one way.




On 1/18/17, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> The menus open when hover and focus is on the top level item. They are not
> "hidden" from screen reader users, who can tab or arrow down to sub menu
> items, but the structure of top level and sub menus is not communicated to
> screen reader.
>
> Would making top level menu items h2 be enough to inform screen reader users
> there are sub items?
>
> Joseph
>
> On Jan 18, 2017 11:01 AM, Jeremy Anderson < = EMAIL ADDRESS REMOVED = >
> wrote:
> If the menu opens on focus, does the submenu have to be hidden from the
> screen-reader in the first place? (Or did you mean active, rather than
> focused?)
>
> Jeremy.
>
>> On 18 Jan 2017, at 14:42, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Is there a way to indicate to screen readers the existence of a sub-menu
>> when the sub-menus open when focused? Usually I would use haspopup or
>> expanded/collapsed, but those imply user action to open/close.
>>
>> Joseph
>>
>>>

From: Joseph Sherman
Date: Wed, Jan 18 2017 10:56AM
Subject: Re: Mega Menu
← Previous message | Next message →

The State Farm menu is nice, however, if you use menu and menuitem then the navigation items do not show as links in the list of links identified by assistive technology, which we didn't want. We also have the top level item (not first sub menu item) as the link to the landing page for that category.

We've done the keyboard support, I just was hoping for something to tell screen readers there is a submenu

Joseph


>

From: Birkir R. Gunnarsson
Date: Wed, Jan 18 2017 11:04AM
Subject: Re: Mega Menu
← Previous message | Next message →

You could use aria-expanded="false" n the top links, setting it to
"true" when the link receives focus and the submenu becomes visible.
How does the user get from the link to the "submenu", just by tabbing,
or have you implemented some sort of keyboard navigation shortcuts,
like arrow keys?


On 1/18/17, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> The State Farm menu is nice, however, if you use menu and menuitem then the
> navigation items do not show as links in the list of links identified by
> assistive technology, which we didn't want. We also have the top level item
> (not first sub menu item) as the link to the landing page for that
> category.
>
> We've done the keyboard support, I just was hoping for something to tell
> screen readers there is a submenu
>
> Joseph
>
>
>>

From: Joseph Sherman
Date: Wed, Jan 18 2017 11:18AM
Subject: Re: Mega Menu
← Previous message | Next message →

When user is on top level link with submenu open, tab and down arrow keys navigate through. ESC key brings user to top menu link item of current sub-menu. With focus on top link, left/right arrows navigate the menu.

We went back and forth on whether TAB should go across or down from top level item. We settled on down since there's not many sub-items so tabbing through isn't terrible, and users expected TAB to move through an open menu.

Joseph


>

From: Mallory
Date: Wed, Jan 18 2017 12:29PM
Subject: Re: Mega Menu
← Previous message | Next message →

In my case, they were display none normally (this prevents keyboarders
from hitting all those submenu links unless they're visible). The main
level link getting focus changes the display state of the submenu from
none to block.

_mallory

On Wed, Jan 18, 2017, at 05:00 PM, Jeremy Anderson wrote:
> If the menu opens on focus, does the submenu have to be hidden from the
> screen-reader in the first place? (Or did you mean active, rather than
> focused?)
>
> Jeremy.
>
> > On 18 Jan 2017, at 14:42, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Is there a way to indicate to screen readers the existence of a sub-menu when the sub-menus open when focused? Usually I would use haspopup or expanded/collapsed, but those imply user action to open/close.
> >
> > Joseph
> >
> >>

From: Jeremy Anderson
Date: Thu, Jan 19 2017 2:57AM
Subject: Re: Mega Menu
← Previous message | Next message →

Hi Joseph,

T o be honest, I wouldn't worry about including either hasPopUp or aria-expanded states because, as far as the screenreader is concerned, the text is visible, and there are no changes in display style status.

I may be reading this wrong, but it seems you are trying to describe what is visually happening on the page when, to a screen-reader, nothing is happening.

Massive apologies if I am mis-reading this.

Cheers,

Jeremy.

> On 18 Jan 2017, at 18:18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>
> When user is on top level link with submenu open, tab and down arrow keys navigate through. ESC key brings user to top menu link item of current sub-menu. With focus on top link, left/right arrows navigate the menu.
>
> We went back and forth on whether TAB should go across or down from top level item. We settled on down since there's not many sub-items so tabbing through isn't terrible, and users expected TAB to move through an open menu.
>
> Joseph
>
>
>>

From: Birkir R. Gunnarsson
Date: Thu, Jan 19 2017 4:39AM
Subject: Re: Mega Menu
← Previous message | No next message

I would use role="group" and aria-labelledby="top level item ID" on
the submenu link in this case.
<a id="mn1">about us</a>
<div role="group" aria-labelledby="mn1">
<ul>
<li><a href='"#">our history</a></li>
....</ul></div>
This will communicate to screen readers that the links in the menu are
grouped and the group is tied to the top level link.
This can be semantically important information when the user is trying
to understand the page layout.
Is the submenu visually hidden or completely hidden until users place
focus on the top level item?
If visually hidden, this is enough. If completely hidden, I am still a
bit worried that screen readers could be very confused, and I would
advice using aria-expanded in addition to this to indicate the display
state.
Else the screen reader user will have a hard time understanding what
is happening on the page.



On 1/19/17, Jeremy Anderson < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Joseph,
>
> T o be honest, I wouldn't worry about including either hasPopUp or
> aria-expanded states because, as far as the screenreader is concerned, the
> text is visible, and there are no changes in display style status.
>
> I may be reading this wrong, but it seems you are trying to describe what is
> visually happening on the page when, to a screen-reader, nothing is
> happening.
>
> Massive apologies if I am mis-reading this.
>
> Cheers,
>
> Jeremy.
>
>> On 18 Jan 2017, at 18:18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> When user is on top level link with submenu open, tab and down arrow keys
>> navigate through. ESC key brings user to top menu link item of current
>> sub-menu. With focus on top link, left/right arrows navigate the menu.
>>
>> We went back and forth on whether TAB should go across or down from top
>> level item. We settled on down since there's not many sub-items so tabbing
>> through isn't terrible, and users expected TAB to move through an open
>> menu.
>>
>> Joseph
>>
>>
>>>