WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inaccessible mega menu and WCAG2

for

From: Birkir R. Gunnarsson
Date: Jan 17, 2015 3:42PM

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


--
Work hard. Have fun. Make history.