WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Superfish-like drop-down menus?

for

From: Robert Fentress
Date: Jun 16, 2017 8:22AM

Thanks for your response, Matt. See comments inserted below.

On Fri, Jun 16, 2017 at 12:50 AM, Matt King < <EMAIL REMOVED> > wrote:

> > 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.
>

Glad to know I'm not alone.


>
> > 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.
>

Yes. My point, though, is that so many of the things that ARIA addresses
are things that should just be a part of the HTML standard. We have select
boxes, radio buttons, etc., which means developers don't need to create
custom controls for these widgets, and deal with all the attendant hassles
of handling the keyboard and touch interaction models, updating states,
etc. Why can't we have the same for menus (of multiple types), trees, tab
controls, and so on? I'm sure there are good reasons, but, if a way could
be found to just fold these things into HTML, that would be a better
solution, I think, than custom coding.


>
> > 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.
>

Yes, the Authoring Practices guide has been a life saver for some things,
and I refer to it--and refer others to it--often. However, as Lucy
mentioned, the menu pattern described there is not appropriate for site
menus, only application menus.


> 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.
>
>
Great!


> > 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.


I've seen this done before, but I think the idea of a click event on a menu
item pulling double duty as a trigger for the submenu (first click) and a
link that takes you places (second click) is really bad. I don't think it
really fits the menuitem role, either.


> 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.
>

The issue, as I see it, boils down to the fact that the interaction
patterns users have come to expect on the web don't track with the
system-level widgets that ARIA is attempting to map to. 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). That is why I tried
to use the disclosure pattern, as it seemed to be the most agnostic about
what it was doing and, I thought, wouldn't require me to manage focus or
the active descendent. I think web users expect to be able to tab between
links on a page, rather than have submenus function as composite widgets
that have to be navigated by using arrow keys. You can't meet all
expectations (thus the expander button), but this approach seemed,
intuitively (no data), to me, to meet the requirements and expectations of
the most users. These expectations being something like:

- Mouse users expect to hover over a menu link and have it expand, and
also to be able to click on that link and have it take them to the index
page for the submenu items.
- Keyboard users should be able to get to links in the menu without
having to tab through every link in the menu, though they also expect to be
able to tab between links, generally.
- Screen reader users should be able to navigate the links using as many
useful cues and affordances as possible, but without being provided cues or
affordances that are inaccurate. In other words, they should not map to
system-level widgets, but then not follow the expected behaviors of those
system-level widgets.
- And do so in a way that still works for users of touchscreen devices.

That's my thinking at the moment. I'm sure, if I read and studied more,
I'd have better insights, but that's where I'm at now after exploring this
space. I welcome feedback.

Thanks, again, Matt, for your comments, and for your efforts on the ARIA
practices task force in trying to make the web a better place for everyone.

Best,
Rob



--
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>