WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Superfish-like drop-down menus?

for

From: Matt King
Date: Jun 16, 2017 1:14PM

> We need a solution for web menus
> (aria menus are just not right for this).

Mallory, we can make anything you like with ARIA; any kind of web menu you like. However, we may or may not use the menu role. Please don't confuse the ARIA role name with the street name of a component. Menu is a word with a nearly infinite number of meanings. But, in ARIA, it has a very specific set of meanings.

> so far in my work I've run into multiple *things*
> that, on the surface, look like they might be aria-menu-pattern-following things:
> buttons that when you click them, a sort of menu popups open underneath.
> However, aria menus are extremely limited in what goes inside these things.
> And the teams asking my advice are putting *whole damn forms* inside these.
> Anything that can't be a menuitem, menuitemcheckbox, or menuitemradio don't really fit into the aria menu pattern,
> even if a *lot* of it, but not all of it, would make sense.

Very often these mega menu type of experiences that include inputs, filtering, tabs, etc., can be implemented very nicely using the ARIA dialog as a container.

> I'm wondering if the aria specs need to
> consciously stop completely trying to imitate "what desktop applications do"
> because that world is being left behind FAST.

While ARIA 1.x is limited to a role-mapping construct, due to the nature of accessibility APIs at this time, that does not necessarily limit your designs to desktop-like experiences. Nearly all web designs can be fairly easily broken down into some set of ordinary ARIA components. And, creative manipulation of those components, in ways that are consistent with the intent of the spec, expands the universe to cover nearly anything. So, move design forward. I believe that ARIA is flexible enough to move with you ... for the most part. Exceptions are hard to find.

Hopefully in ARIA 2.x, we will also have some way of expressing control patterns or something like that as well.

> Similar to someone recognising a triangle on its side *within a video context* knows that probably means "Play"
> but not having any idea what a sideways triange is in any other context,
> we're finding in user testing that people don't know how to use these things,

Are you saying that if you label your play icon "Play" and give it a button role and make it work like a button that screen reader users don't know how to operate it? Or, am I misreading this?

Matt King