WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Superfish-like drop-down menus?

for

From: Mallory
Date: Jun 16, 2017 8:53AM

The menu on pearson.com used to have this: website menu items that tried
to do double duty as both items you could click (as expected of menu
items) and something that opened a dropdown (they added a little button
next to the regular menu item). For sighted keyboarding through this
site on a laptop, it was *painful*. I would have rather that the
submenus appeared on focus (for all the problems that things appearing
on focus can cause) and have the link parts stay links that go places.
It was difficult to open and close submenus at will. It was difficult to
click links. It was just a pain in the ass to navigate. And I'm just
assuming this all would have been harder with a screen reader (I did go
through it with Orca once and I never made any sense of it there either;
however I can't put myself in the place of a usual-screen-reader-user).

We need a solution for web menus (aria menus are just not right for
this). We additionally need a solution for a separate issue: 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.

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. 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, despite the idea that this is already what they're using when it
comes to desktop application controls. The website menus are a good
example of this: we've beaned into users that on the web, menus work a
certain way, which is different from how app menus work.

Robert, thanks for your rant. It's lowering my cortisone levels as we
speak :P

cheers,
Mallory

On Fri, Jun 16, 2017, at 04:43 PM, Robert Fentress wrote:
> Following up on my previous post, see comment below
>
> On Fri, Jun 16, 2017 at 10:22 AM, Robert Fentress < <EMAIL REMOVED> > wrote:
>
> > The site navigation fly-out menu is not a system menu, and the expander
> > for a submenu is not really a button menu (I don't think).
> >
> >
> A reason why a button menu is not appropriate here is that these submenus
> may, themselves, have submenus. Though I don't think this is best
> practice, it is not unusual to see this multi-level menu pattern.
> Ideally,
> you'd want to accommodate that use case in whatever design you chose.
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer
> Assistive Technologies at Virginia Tech
> Electronic Business Card (vCard)
> <http://search.vt.edu/search/person.vcf?person54847>
> LinkedIn Profile
> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> > > >