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
> >
> > -----Original Message-----
> > From: <EMAIL REMOVED>
> > [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R.
> > Gunnarsson
> > Sent: Saturday, January 17, 2015 5:42 PM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Inaccessible mega menu and WCAG2
> >
> > If submenus become visible with mouse action, but do not when tabbed to
> with
> > keyboard, that is a violation of 2.1.1, since you need a mouse to make
> > submenus visible, device dependence.
> > I have also failed a similar construct under 2.4.3, as you cannot call a
> > focus order where user tabs 5, 7, or 10 times without any visible chance
> on
> > the page, as logical focus order. Sighted keyboard only user keeps
> tabbing
> > and nothing appears to happen, how does he even know he is moving through
> > the page, unless he is patient enough to keep trying.
> > and 2.4.7 is obvious, though it is a level AA criterion.
> > The button/menu construct is a difficult one, and I have tried to figure
> it
> > out myself.
> > I wish we could have a spec that more clearly states that with focus on a
> > triggering element of a menu, user could press enter key to activate the
> > link and go to that page, or user can press arrow down to open an
> associated
> > menu (slight alternations to the menubutton construct in the ARIA
> authoring
> > practices might achieve this, though the ARIA attributes would not
> clearly
> > indicate this to user, at least when I see a button with aria-haspopup I
> > assume I need enter key to activate it and bring focus into the menu).
> > I will bring the issue up in the W3C PFWG and ARIaA authoring taskforce.
> > Thanks
> > -B
> >
> > On 1/17/15, Roger Hudson < <EMAIL REMOVED> > wrote:
> >> While I like the fact that you can move around the Adobe Mega Menu
> >> with either the tab or arrow keys, I am concerned that two different
> >> functions are associated with the main menu navigation items. When on
> >> an item, if you press enter the sub-menu opens and tab takes you to
> >> the first item in the menu. However, if you want to go to the page
> >> directly linked to by the item you need to press the enter key again
> >> rather than tab. While it would be relatively easy to communicate
> >> these different behaviours to screen reader users, it will be more
> >> difficult to do for keyboard users who don't use a screen reader.
> >>
> >>
> >>
> >> I have thought about this problem several times over the years and
> >> wrote a short article about it in 2010:
> >> http://usability.com.au/2010/08/accessing-nav-drop-downs/
> >>
> >>
> >>
> >> Personally I don't like mega menus and feel they should be avoided.
> >> However,
> >> that said, I can think of two ways we might make them easier of
> >> keyboard users to understand and use:
> >>
> >> 1. If the main item is to have two functions, provide a
> >> clearer
> >> visual indication of these different functions. For example, include
> >> an icon or symbol, such as a chevron, next to the navigation label
> >> (e.g. Operable ▼). The first tab press would take the user to the
> >> navigation label, and if selected the landing page would be presented.
> >> If not selected, the next tab press would take the user to the
> >> chevron, which would cause the drop-down (sub-menu) to be presented
> >> when selected. These different functions would be easy to communicate
> >> to screen reader users, and since they are separated, a little easier
> >> for sighted keyboard users to understand.
> >>
> >> 2. Provide only one function for the main navigation item,
> >> namely
> >> to open the drop-down sub-menu. Since you will no longer be able to go
> >> directly to a page by clicking the main navigation label, it will be
> >> necessary to repeat this label as the first item in the sub-menu. From
> >> a keyboard and screen reader perspective this maybe the better option,
> >> but repeating the navigation label maybe slightly confusing for some
> >> users.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Roger
> >>
> >> > >>
> >> > >> http://list.webaim.org/ > >> <mailto:webaim-forum@list.
> >> webaim.org> <EMAIL REMOVED>
> >>
> >>
> >>
> >>
> >>
> >> Roger Hudson
> >>
> >> Web Usability
> >>
> >> Mobile: 0405 320 014
> >>
> >> Phone: 02 9568 1535
> >>
> >> Web: www.usability.com.au
> >>
> >> Blog: www.dingoaccess.com
> >>
> >> Twitter: http://twitter.com/rogerhudson
> >>
> >> Email: <EMAIL REMOVED>
> >>
> >>
> >>
> >>
> >>
> >> > >> > >> list messages to <EMAIL REMOVED>
> >>
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > messages to <EMAIL REMOVED>
> > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > >