WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Superfish-like drop-down menus?

for

From: Matt King
Date: Jun 15, 2017 10:50PM

> ARIA makes my brain bleed. Why is this so hard?

Rob, I feel and understand your pain. I see the pain all around me. It is ubiqquitous.

That is why the ARIA practices task force is working furiously to get a full-fledged, thoroughly reviewed practices guide published -- something that has never existed. The lack of an authoratative practices guide has allowed mass confusion to ferment across the entire industry over the last several years.

BTW, we welcome more members and contributors. Please contact me if you wish to help.

> Why isn't the <menu> tag or something like it implemented in the browser, where all that keyboard stuff is taken care of by the user agent.

HTML menu tag is still experimental; that is not related to ARIA.

> How can we expect developers to write accessible code when a consensus hasn't yet been reached on the best way to handle these things? Or maybe it has and I just haven't gotten the memo.

Solving that is what the ARIA Practices guide is all about. The menubar, menu button, and menu patterns are here:

http://w3c.github.io/aria-practices/#menu

Note that the above is a link to the editor's draft.

Unfortunately, the WAI flyout menu tutorial is not yet well synchronized with ARIA practices. We still have a fair amount of work to get all the resources in sync. Highest priority for me right now is finishing ARIA Practices itself. I commented in the issue you raised so we can work toward improving alignment on this particular set of patterns.

> I'm currently playing around with modifying it myself, in my spare time (right). Basically, I make the button a sibling of the link and move aria-haspopup, and aria-expanded to it.

When you add aria-haspopup=true to a button, that tells the screen reader that it is a menubutton. This is one of those rare exceptions where a property changes the role that is exposed in the accessibility API. It probably would have been more clear if we would have never let properties change the role mapping, but that is a very old ARIA 1.0 decision that is not practical to change now.

A menu button, as you might guess, opens a menu widget.

> Then, I add aria-controls and (maybe) aria-owns to the button and associate this with the submenu, which I then have to explicitly provide an id attribute for.

No, please do not use aria-owns here; that is not valid. It will cause all kinds of problems.

You do not need aria-controls in the menu pattern. We do recommend it for a disclosure (button with aria-expanded).

> I guess I could then write code to handle the keyboard interaction, but that adds a whole other layer of complexity and screws up the elegant simplicity of the original approach.

If you are going to use the menu and menuitem roles, which are required with a menubutton, you are also required to manage focus, AKA write the javascript to move focus. Menus are composite widgets, and composite widgets are expected to manage focus.

> It's basically just functioning as a disclosure widget, at that point.

In that case, I recommend following the disclosure pattern, which is basically just a button with aria-expanded and aria-controls referring to the disclosure content.
http://w3c.github.io/aria-practices/#disclosure

Note that if you want to overload a single focusable element to both open a submenu and execute a link, that widget needs to be a menuitem, not a menu button. Generally, that means using a menubar. The authoring practices task force has an open issue for developing an example that demonstrates that type of behavior. With such menuitems, enter and space activate the link target and the appropriate arrow keys (depending on orientation) open the submenu. Such overloading isn't really the most understandable design.

Hth,
Matt King