WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inaccessible mega menu and WCAG2

for

From: Sean Curtis
Date: Jan 18, 2015 4:37PM

We spent a considerable amount of time working on improving the
accessibility of our dropdown menu component last year. Considering we're
on the topic already, I'd love to know what you all think of it. I whipped
up a test page here: http://jsbin.com/zuwaco/1/

Some things I know that aren't perfect:
- the sub menu doesn't announce as a "level 2" menu (can you associate a
menu with another? I haven't tried using aria-owns yet).
- using VO + Space to trigger the submenu button doesn't place focus inside
it (this has been difficult due to browsers not often treating this as a
"click" event)
- VO doesn't read the group headings (looking at using aria-describedby on
each item to work around this)
- Chrome on OSX reads the checked state of checkboxes correctly, but VO +
Space announces the incorrect action on it (eg "Firefox, checked,
checkbox", VO+Space, "check Firefox, checkbox").

Any feedback would be greatly appreciated.

Cheers,

Sean Curtis

On Mon, Jan 19, 2015 at 6:26 AM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> Andrew
> My understanding was that the menu does not appear on keyboard focus
> even when the keyboard focus moves into it, and that the user keeps
> tabbing into it without seeing where he is tabbing. In that case the
> keyboard only user is not able to activate any of the items in the
> submenu without randomly hitting enter at some point and seeing what
> happens.
> In that case I would have a hard time saying the page is operable by
> the keyboard .. this is similar to having a bunch of links with a CSS
> background image and no accessible name (though of course it would be
> called under a different success criterion, i.e. 2.4.4 or 3.3.2
> depending on the control type, link or button) .. i.e. user has no
> idea what he is activating until he activates it.
> If the user sees that he can activate the menu by pressing enter on
> the triggering element, that is perfect.
> If the menu appears automatically when the triggering element receives
> focus .. well, assuming user has access to it, I think that is
> acceptable .. better than user having no idea that there is a context
> menu available , only he is not able to see it.
> Of course it is always hard to say specifically unless we are talking
> about a concrete example, there are so many subtleties involved that
> we might be thinking of this differently.
>
>
>
> On 1/18/15, Andrew Kirkpatrick < <EMAIL REMOVED> > wrote:
> > Birkir,
> > I disagree that the submenu needs to appear on focus when it appears on
> > mouse hover. What is required under 2.1.1 is that all functionality is
> > operable from the keyboard.
> >
> > The decision to not make the submenu appear on focus is deliberate and is
> > designed to same keyboard users the trouble of needing to tab through
> many
> > additional links. If a keyboard user wants to go into the menu this is
> easy
> > to do, but they don't need to tab through all submenu items or close each
> > submenu after it opens on tab, only to tab again and have another submenu
> > open that needs to be closed to progress.
> >
> > AWK
> >
> >