WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inaccessible mega menu and WCAG2

for

From: Birkir R. Gunnarsson
Date: Jan 18, 2015 12:26PM

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.