WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Burger Menus and necessary ARIA support

for

From: Beranek, Nicholas
Date: Sep 14, 2017 7:34AM


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

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Fischer, Johannes
Sent: Thursday, September 14, 2017 3:36 AM
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Burger Menus and necessary ARIA support

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 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 REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Vemaarapu Venkatesh
Sent: Tuesday, September 12, 2017 10:28 PM
To: <EMAIL REMOVED>
Subject: 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
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.