E-mail List Archives
Thread: Burger Menus and necessary ARIA support
Number of posts in this thread: 10 (In chronological order)
From: Fischer, Johannes
Date: Mon, Sep 11 2017 12:19PM
Subject: Burger Menus and necessary ARIA support
No previous message | Next message →
Hi all,
I am wondering if navigation burger menus need a lot of ARIA elements to be accessible.
There is a button with attributes tabindex="0", role="button" (or instead it is a <button> element) as well as aria-label="Navigation", but other attributes like aria-haspopup or aria-controls are not used. When you click on the button or press Enter, a menu (<ul>/<li>) gets visible and menuitems are <a>-Elements for links or <button>-elements for submenu-buttons without role or aria attributes. Clicking or pressing enter leads you to the linked site or their submenu gets visible/unvisible. By keyboard you can navigate through the menu by tabulator key, not the arrow keys. If you don't open the navigation menu or submenus, pressing tab key will not lead to the menuitems, but they are skipped.
To distinguish between navigation visible or not, either the value of aria-label should change between "open Navigation" and "close Navigation" or the attribute aria-expanded should be available.
In contrast W3C describes a Menu Button with more WAI-ARIA attributes (aria-haspopup, aria-controls, aria-expanded) here: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html
Would you rate my example still as accessible according to WCAG or is it very important to do it like the W3C example?
Thanks,
Johannes
Johannes Fischer
BIKOSAX - IT Accessibility Service in Saxony
Accessible Websites - Test, Consulting, Training
Deutsche Zentralbücherei für Blinde (German Central Library for the Blind, DZB)
Gustav-Adolf-Straße 7, 04105 Leipzig, Germany
Tel.: +49(0)341 7113-162, Fax: +49(0)341 7113-125
E-Mail: = EMAIL ADDRESS REMOVED =
Internet: www.dzb.de
Follow DZB: www.facebook.com/dzb.de | www.twitter.com/punktschrift
From: Vemaarapu Venkatesh
Date: Tue, Sep 12 2017 11:28PM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Hi Fischer,
If you are using <button> element, tabindex="0" and role="button"
attributes need not to be used as <button> itself have the implicit role of
button and also your tab key takes you to the button though tabindex="0" is
not used.
Strictly do not use aria-label="navigation" on <button> unless it says your
button name because it override your accessible button name and I am not
sure for what purpose you are doing that. If it is to indicate navigation
region do this
<nav role="navigation"> All your navigation menu buttons </nav>
If aria-haspopup="true" or aria-haspopup="menu" is not used screen readers
doesn't convey that the button has a attached menu. Also aria-expanded is
required to make screen readers announce the state of the menu i.e.
collapsed or expanded so no need to define explicit states like open/ close
navigation if aria-expanded is used.
aria-controls is necessary to build relationship between your button and
attached menu.
I expect the links in the menu should be navigable with up and down arrow
keys as it is a submenu.
So without all these things I don't think so the menu gives usable
experience.
Thanks,
Venkatesh
From: Fischer, Johannes
Date: Wed, Sep 13 2017 12:13AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Hi Venkatesh,
thanks for your opinion. It is not a <button> element with role="button" and tabindex="0". It is either a <button> element (best solution) or it is a <div> element with role="button" and tabindex="0". aria-label is used because it's a button with an icon font or background image, so there is no other accessible button name (except perhaps a title attribute for mouse users who can see it).
Definitely I would use aria-expanded. And ok, aria-haspopup and aria-controls are not really optional for the menu button. If there are 5 items in the menu and 2 of them have a submenu with again some items, would you use aria-haspopup and aria-controls on the 2 items containing a submenu as well (of course, aria-expanded is used)? It would make sense to me.
When I look at another example (https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html), Example 1, Menu "About", Submenu "Fact", aria-expanded and aria-haspopup are used, but aria-controls not. But perhaps they just forgot to add it.
Johannes
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag von Vemaarapu Venkatesh
Gesendet: Mittwoch, 13. September 2017 07:28
An: = EMAIL ADDRESS REMOVED =
Betreff: Re: [WebAIM] Burger Menus and necessary ARIA support
Hi Fischer,
If you are using <button> element, tabindex="0" and role="button"
attributes need not to be used as <button> itself have the implicit role of
button and also your tab key takes you to the button though tabindex="0" is
not used.
Strictly do not use aria-label="navigation" on <button> unless it says your
button name because it override your accessible button name and I am not
sure for what purpose you are doing that. If it is to indicate navigation
region do this
<nav role="navigation"> All your navigation menu buttons </nav>
If aria-haspopup="true" or aria-haspopup="menu" is not used screen readers
doesn't convey that the button has a attached menu. Also aria-expanded is
required to make screen readers announce the state of the menu i.e.
collapsed or expanded so no need to define explicit states like open/ close
navigation if aria-expanded is used.
aria-controls is necessary to build relationship between your button and
attached menu.
I expect the links in the menu should be navigable with up and down arrow
keys as it is a submenu.
So without all these things I don't think so the menu gives usable
experience.
Thanks,
Venkatesh
From: Vemaarapu Venkatesh
Date: Wed, Sep 13 2017 3:03AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Hi Fischer,
If the purpose is served with the use of native HTML controls, it is always
best to use them instead of re purposing them using ARIA and that is what
even first rule of ARIA conveys. Your implementation with <div> will also
be OK if the button is keyboard accessible because ARIA doesn't provide any
keyboard accessibility like how HTML does.
If aria-haspopup="true" is used along with aria-expanded="false" NVDA
announces "<name of menuitem> collapsed submenu" which is very clear
otherwise it announces "<name of menuitem> collapsed". In either cases I am
not finding any impact but it is more about enhancing users experience.
Along with you even I am curious to hear from other experts how it impacts
screen reader users if aria-controls or aria-owns are not used on certain
widgets like menu buttons, tablists, treeviews etc.
Thanks,
Venkatesh
From: Jonathan Cohn
Date: Wed, Sep 13 2017 10:51AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
I found it interesting that target.com does not use aria-expanded or
aria-haspopup but instead just modifies the aria-label. At least that was
my experience on a Macintosh system earlier this week. I suppose this could
run one into difficulties with translation or other technologies.
Certainly when not paying strict attention, I would have trouble telling
the difference between f implementing all the aria states vs changing a
label.
On Wed, Sep 13, 2017 at 1:28 AM Vemaarapu Venkatesh <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi Fischer,
>
> If you are using <button> element, tabindex="0" and role="button"
> attributes need not to be used as <button> itself have the implicit role of
> button and also your tab key takes you to the button though tabindex="0" is
> not used.
> Strictly do not use aria-label="navigation" on <button> unless it says your
> button name because it override your accessible button name and I am not
> sure for what purpose you are doing that. If it is to indicate navigation
> region do this
> <nav role="navigation"> All your navigation menu buttons </nav>
>
> If aria-haspopup="true" or aria-haspopup="menu" is not used screen readers
> doesn't convey that the button has a attached menu. Also aria-expanded is
> required to make screen readers announce the state of the menu i.e.
> collapsed or expanded so no need to define explicit states like open/ close
> navigation if aria-expanded is used.
>
> aria-controls is necessary to build relationship between your button and
> attached menu.
> I expect the links in the menu should be navigable with up and down arrow
> keys as it is a submenu.
> So without all these things I don't think so the menu gives usable
> experience.
>
> Thanks,
> Venkatesh
> > > > >
From: Lovely, Brian (CONT)
Date: Wed, Sep 13 2017 10:54AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Huh, yeah, they just toggle the aria-label from "menu - shows more content" to "menu - hide content". That seems like an odd decision to me.
From: Bryan Garaventa
Date: Wed, Sep 13 2017 11:40AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Hi,
If all you want is a triggering element that expands a list of links that you tab through, you don't need to use ARIA Menu markup at all for this besides the use of aria-expanded on the button to convey this and possibly a named region if you wish around the links. There is nothing that is not accessible about this simple implementation.
When you apply ARIA Menu attributes however, that is when it becomes complicated, which then requires a whole bunch of keyboard functionality requirements, focus handling plus role matching, plus proper attribute usage to accomplish to ensure accessibility, because incorrect ARIA usage will actually make such controls totally inaccessible if misapplied. Here is a live example of one that is a simple vertical dropdown ARIA Menu construct:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20(Internal%20Content)/demo.htm
Notice how screen readers like JAWS and NVDA convey these roles when arrowing around within this menu after activating the menu button.
This follows the mapping guidance documented here
http://whatsock.com/training/matrices/#menu
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: Fischer, Johannes
Date: Thu, Sep 14 2017 1:35AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Hi,
ok, thank you for your comments and the examples. Like I thought at the beginning it's not strictly regulated, it's rather a recommendation to do it like in the ARIA Authoring Practices. Bryan, you suggested not to use whole ARIA Menu markup if the menu button just expanded some links to tab through. Of course, aria-expanded is important. The question is, when is it just expanding some links and when is it a menu which always needs more ARIA attributes? I read out of your comments that this depends on the complexity and you have to think about it in every particular case. But of course, you can always recommend to use more ARIA attributes even if using less ARIA attributes not always fails a WCAG success criterion.
Regards,
Johannes
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag von Bryan Garaventa
Gesendet: Mittwoch, 13. September 2017 19:41
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Burger Menus and necessary ARIA support
Hi,
If all you want is a triggering element that expands a list of links that you tab through, you don't need to use ARIA Menu markup at all for this besides the use of aria-expanded on the button to convey this and possibly a named region if you wish around the links. There is nothing that is not accessible about this simple implementation.
When you apply ARIA Menu attributes however, that is when it becomes complicated, which then requires a whole bunch of keyboard functionality requirements, focus handling plus role matching, plus proper attribute usage to accomplish to ensure accessibility, because incorrect ARIA usage will actually make such controls totally inaccessible if misapplied. Here is a live example of one that is a simple vertical dropdown ARIA Menu construct:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20(Internal%20Content)/demo.htm
Notice how screen readers like JAWS and NVDA convey these roles when arrowing around within this menu after activating the menu button.
This follows the mapping guidance documented here
http://whatsock.com/training/matrices/#menu
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: Beranek, Nicholas
Date: Thu, Sep 14 2017 7:34AM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | Next message →
Like Bryan said, the ARIA menu is notoriously difficult to code. Not only do you have to include the proper ARIA roles, states, and properties, but you have to deal with managing focus and all of the keyboard event listeners. I am totally on board with using aria-expanded on the menu button and ditching aria-haspopup connected to an ARIA menu.
I, too, would like to hear about what others think are the differences between a menu and a list of links in this context.
Nick Beranek
Capital One
From: Bryan Garaventa
Date: Thu, Sep 14 2017 12:27PM
Subject: Re: Burger Menus and necessary ARIA support
← Previous message | No next message
"of course, you can always recommend to use more ARIA attributes even if using less ARIA attributes not always fails a WCAG success criterion."
I understand the desire to do this, but unfortunately this often leads to greater issues down the road when developers copy and paste code fragments that end up contradicting one another and they don't know enough to fix them. Personally I always recommend using the least amount when possible, and if needed then make sure that everything is ironclad including all required attributes and necessary focus handling. Mixing these two concepts together often leads to even more confusion by mainstream developers in my experience, because they end up sprinkling roles and attributes in places where they have no business being. I'm not suggesting that you are recommending this, but I've found that when I've deviated into doing this myself in the past, even though what I was suggesting was totally clear to me, it often picked up a life of its own when introduced by differing dev teams with variable levels of experience and it typically didn't have any relation to what I was originally saying to begin with. So, I found it was simplest to say don't do it, or if you need to do it, you 'must' do it like this. It solved a lot of problems for me anyway.
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com