E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 36 (In chronological order)

From: Lynn Holdsworth
Date: Fri, Jan 16 2015 6:59AM
Subject: Inaccessible mega menu and WCAG2
No previous message | Next message →

Hi all,

I'm working on a site that has a mega-menu that drops down on hover.
It's also reasonably usable with a screenreader, in that after tabbing
to an item on the top menu, I can tab through and activate its submenu
items.

But while tabbing through the submenus, these aren't visible on the
screen, so keyboard users are likely to think the page or perhaps even
the Tab key isn't working.

I can obviously fail this under 2.4.7 - Focus Visible.

And I think also 2.4.1 - Bypass Blocks.

But that doesn't seem to cover the issue properly. Where else can I fail it?

Thanks as always, Lynn

From: Patrick H. Lauke
Date: Fri, Jan 16 2015 7:05AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On 16/01/2015 13:59, Lynn Holdsworth wrote:
> Hi all,
>
> I'm working on a site that has a mega-menu that drops down on hover.
> It's also reasonably usable with a screenreader, in that after tabbing
> to an item on the top menu, I can tab through and activate its submenu
> items.
>
> But while tabbing through the submenus, these aren't visible on the
> screen, so keyboard users are likely to think the page or perhaps even
> the Tab key isn't working.
>
> I can obviously fail this under 2.4.7 - Focus Visible.
>
> And I think also 2.4.1 - Bypass Blocks.
>
> But that doesn't seem to cover the issue properly. Where else can I fail it?

I'd say 2.1.1 Keyboard as well, as the functionality of visibly opening
the menu is not available to a sighted keyboard-only user.


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: John Hicks
Date: Fri, Jan 16 2015 7:27AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

If you "click" (press enter) on the top level does the menu descend?



2015-01-16 15:05 GMT+01:00 Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:

> On 16/01/2015 13:59, Lynn Holdsworth wrote:
>
>> Hi all,
>>
>> I'm working on a site that has a mega-menu that drops down on hover.
>> It's also reasonably usable with a screenreader, in that after tabbing
>> to an item on the top menu, I can tab through and activate its submenu
>> items.
>>
>> But while tabbing through the submenus, these aren't visible on the
>> screen, so keyboard users are likely to think the page or perhaps even
>> the Tab key isn't working.
>>
>> I can obviously fail this under 2.4.7 - Focus Visible.
>>
>> And I think also 2.4.1 - Bypass Blocks.
>>
>> But that doesn't seem to cover the issue properly. Where else can I fail
>> it?
>>
>
> I'd say 2.1.1 Keyboard as well, as the functionality of visibly opening
> the menu is not available to a sighted keyboard-only user.
>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
> > > >

From: _mallory
Date: Fri, Jan 16 2015 8:11AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On Fri, Jan 16, 2015 at 03:27:52PM +0100, John Hicks wrote:
> If you "click" (press enter) on the top level does the menu descend?

I know the accessibility community feels otherwise, but if I am
always estatic if clicking on a top-level link takes me to the link.

It's an excellent fallback if, for some reason, some user, some combo
of OS/UA/AT/whatever, the dropdowns can't be activated, because the
link destination *should* have direct access to that stuff.

But, my opinion as a frustrated web user.

_mallory

From: Jonathan Avila
Date: Fri, Jan 16 2015 7:59AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

> I know the accessibility community feels otherwise, but if I am always estatic if clicking on a top-level link takes me to the link.

Mallory, I agree this makes perfect sense -- in practice we've had trouble fitting this into the menu/aria-expanded paradigm. One you indicate menu status as expand/collapse then activating the link to take you to another page no longer makes sense. In my opinion we are lacking a proper navigation paradigm in ARIA that would allow for this. We really need something like a button menu -- a composite control that can be activated directly and also has a pop up menu.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: John Hicks
Date: Fri, Jan 16 2015 8:10AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

I fully agree, but just wondering whether they had implemented *some* means
of displaying the menu via the keyboard.

I am faced daily with the conundrum of bloated and "SEO-motivated" mega
menus.... I hate them.

If your menu expands on mouse over, then it should do so also on keyboard
focus. ... but what if you don't want to look at that menu but another one
.... ESC to close and push the focus to the next top level element? Would
be good, but I have never seen it working and it would not be intuitive to
a blind user... (unless you put it in writing).


2015-01-16 16:11 GMT+01:00 _mallory < = EMAIL ADDRESS REMOVED = >:

> On Fri, Jan 16, 2015 at 03:27:52PM +0100, John Hicks wrote:
> > If you "click" (press enter) on the top level does the menu descend?
>
> I know the accessibility community feels otherwise, but if I am
> always estatic if clicking on a top-level link takes me to the link.
>
> It's an excellent fallback if, for some reason, some user, some combo
> of OS/UA/AT/whatever, the dropdowns can't be activated, because the
> link destination *should* have direct access to that stuff.
>
> But, my opinion as a frustrated web user.
>
> _mallory
> > > >

From: Jonathan C. Cohn
Date: Fri, Jan 16 2015 8:17AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Jonathan,

Sorry, but I am confused as to what you think is a good implementation of a drop down menu system. Do folks feel that the drop down implmentations that are generally supported by theaccessibility development community where the menu system is one tab stop and ARIA tags are suppported so the interface looks essentially like a native application are more usable by the end community then the menu at a site like
www.TempleRodefShalom.org?
Thanks,


Sent from my iPhone

On Jan 16, 2015, at 9:59 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:

>> I know the accessibility community feels otherwise, but if I am always estatic if clicking on a top-level link takes me to the link.
>
> Mallory, I agree this makes perfect sense -- in practice we've had trouble fitting this into the menu/aria-expanded paradigm. One you indicate menu status as expand/collapse then activating the link to take you to another page no longer makes sense. In my opinion we are lacking a proper navigation paradigm in ARIA that would allow for this. We really need something like a button menu -- a composite control that can be activated directly and also has a pop up menu.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>

From: Don Mauck
Date: Fri, Jan 16 2015 8:25AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

I'd like to give my two cents for what it's worth. For me, I like the way menus and submenus currently work as it is the way most application menus work.

From: Jonathan Avila
Date: Fri, Jan 16 2015 8:31AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

> Sorry, but I am confused as to what you think is a good implementation of a drop down menu system

I haven't found a perfect menu. I like the Adobe Mega menu (http://adobe-accessibility.github.io/Accessible-Mega-Menu/) but it's not perfect. For example, when you open the menu nothing is indicated by the screen reader. Pressing enter on the expanded menu doesn't close it but takes you to the page link. Escape does close the menu though.

There is also no good way to indicate aria-selected on a navigation link with the current specification as aria-selected can't be used on role link. So, all I'm saying is that despite an excellent ARIA specification there are practical implementation problems that need to be figured out for navigation structures. I.e. you can use the menu roles and all of the baggage associated with it or you are left with list and list items in nav element but without use of aria-haspopup or aria-selected or other attributes that are not allowed on links. The protocols and formats working group ARIA task force is working to draft ARIA 1.1. so I hope some of these concerns can be addressed.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Lynn Holdsworth
Date: Fri, Jan 16 2015 8:36AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Thanks everyone.

No, it's not possible to open the menu or get to a different
destination by activating one of the links in the top menu.

2.1.1 looks like a good point to fail it on - thanks Patrick.

I worked on a menu system for a while, and it functioned pretty much
exactly like native menus: left/right arrows move across the top or
open/close sub-submenus; down arrow opens a submenu or moves through
its options; Esc closes a submenu, etc., and I liked it a lot. But it
wasn't possible to create an implementation that worked across all
screenreaders. And we were never sure whether we should indicate that
an item could be expanded if pressing Enter moved the user to a
different page. So I'm very interested in this discussion and what you
all think.

Best, Lynn

On 16/01/2015, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:
> I'd like to give my two cents for what it's worth. For me, I like the way
> menus and submenus currently work as it is the way most application menus
> work.
>
>

From: Patrick H. Lauke
Date: Fri, Jan 16 2015 8:53AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On 16/01/2015 14:59, Jonathan Avila wrote:
> Mallory, I agree this makes perfect sense -- in practice we've had
> trouble fitting this into the menu/aria-expanded paradigm. One you
> indicate menu status as expand/collapse then activating the link to
> take you to another page no longer makes sense. In my opinion we are
> lacking a proper navigation paradigm in ARIA that would allow for
> this. We really need something like a button menu -- a composite
> control that can be activated directly and also has a pop up menu.

Would having a link (to the top-level page) followed by a discrete
secondary link (which acts as disclosure widget for the menu itself) be
problematic? I know it splits the functionality in two, but seems a fair
compromise to me (and for mouse interaction, make both open the menu on
hover)

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Lynn Holdsworth
Date: Fri, Jan 16 2015 9:06AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

I think having two links might be confusing for screenreader users,
especially if the text on both links says the same thing.

On 16/01/2015, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 16/01/2015 14:59, Jonathan Avila wrote:
>> Mallory, I agree this makes perfect sense -- in practice we've had
>> trouble fitting this into the menu/aria-expanded paradigm. One you
>> indicate menu status as expand/collapse then activating the link to
>> take you to another page no longer makes sense. In my opinion we are
>> lacking a proper navigation paradigm in ARIA that would allow for
>> this. We really need something like a button menu -- a composite
>> control that can be activated directly and also has a pop up menu.
>
> Would having a link (to the top-level page) followed by a discrete
> secondary link (which acts as disclosure widget for the menu itself) be
> problematic? I know it splits the functionality in two, but seems a fair
> compromise to me (and for mouse interaction, make both open the menu on
> hover)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Lynn Holdsworth
Date: Fri, Jan 16 2015 9:09AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Apologies - I lied :-)

It *is* possible to get to a new page using the top menu links. And
the new page contains all of the submenu items.

But it's still confusing for keyboard users to be tabbing through a
bunch of invisible links. So presumably 2.1.1 isn't pertinent here.
But focus visible doesn't feel like quite the right fit.

Any thoughts on this?

Thanks, Lynn

On 16/01/2015, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks everyone.
>
> No, it's not possible to open the menu or get to a different
> destination by activating one of the links in the top menu.
>
> 2.1.1 looks like a good point to fail it on - thanks Patrick.
>
> I worked on a menu system for a while, and it functioned pretty much
> exactly like native menus: left/right arrows move across the top or
> open/close sub-submenus; down arrow opens a submenu or moves through
> its options; Esc closes a submenu, etc., and I liked it a lot. But it
> wasn't possible to create an implementation that worked across all
> screenreaders. And we were never sure whether we should indicate that
> an item could be expanded if pressing Enter moved the user to a
> different page. So I'm very interested in this discussion and what you
> all think.
>
> Best, Lynn
>
> On 16/01/2015, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:
>> I'd like to give my two cents for what it's worth. For me, I like the
>> way
>> menus and submenus currently work as it is the way most application menus
>> work.
>>
>>

From: Patrick H. Lauke
Date: Fri, Jan 16 2015 9:12AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On 16/01/2015 16:06, Lynn Holdsworth wrote:
> I think having two links might be confusing for screenreader users,
> especially if the text on both links says the same thing.

Of course, the text must be different - also, I said links but in fact I
should have said button (with appropriate aria-expanded, aria-controls,
etc), my fault. Was thinking something like...

<ul>
<li><a href="...">About</><button aria-expanded="false"
aria-controls="aboutmenu" aria-haspopup="true">About menu</button>
<ul id="aboutmenu" ...>
...
</li>
...
</ul>

with the button visually hidden by default, but made visible (perhaps
just as a discrete icon) on focus...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Jan 16 2015 9:15AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On 16/01/2015 16:09, Lynn Holdsworth wrote:
> Apologies - I lied :-)
>
> It *is* possible to get to a new page using the top menu links. And
> the new page contains all of the submenu items.
>
> But it's still confusing for keyboard users to be tabbing through a
> bunch of invisible links. So presumably 2.1.1 isn't pertinent here.
> But focus visible doesn't feel like quite the right fit.

I'd either still mark it as a (mild) failure of 2.1.1, or a pass - but
in both cases I'd clarify that something needs to be done. Either remove
the menu and its containing links completely from the focus cycle (using
display:none instead of whatever off-screen hiding method they're
presumably using), or make it work and show up for keyboard users.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Lynn Holdsworth
Date: Fri, Jan 16 2015 9:57AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Thanks Patrick. The suggested solution isn't an issue for me, but
they're more likely to fix it if they know it fails WCAG2. To me it
doesn't fit comfortably in 2.1.1, but I guess it's the best there is,
so thanks for that.

As regards the double menu link/button, I think it might cause more
confusion than it resolves. I think perhaps the accessibility
community needs to agree on the paradigm that is the best compromise,
settle on it, and start using it out there in the wild.

If we're afraid keyboard users won't know the shortcuts to use a menu
system, how do we deal with that? By adding info to the accessibility
page?

More questions than answers here :-)

Best, Lynn

On 16/01/2015, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 16/01/2015 16:09, Lynn Holdsworth wrote:
>> Apologies - I lied :-)
>>
>> It *is* possible to get to a new page using the top menu links. And
>> the new page contains all of the submenu items.
>>
>> But it's still confusing for keyboard users to be tabbing through a
>> bunch of invisible links. So presumably 2.1.1 isn't pertinent here.
>> But focus visible doesn't feel like quite the right fit.
>
> I'd either still mark it as a (mild) failure of 2.1.1, or a pass - but
> in both cases I'd clarify that something needs to be done. Either remove
> the menu and its containing links completely from the focus cycle (using
> display:none instead of whatever off-screen hiding method they're
> presumably using), or make it work and show up for keyboard users.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Cliff Tyllick
Date: Fri, Jan 16 2015 10:47AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Lynn, once a submenu is exposed, do you enter it on the next tab, or do you have to use the down arrow?

If it takes the down arrow—or anything other than tab—then you are probably all right. But if the submenu is exposed on tab, then the interface is technically accessible but probably not highly usable to sighted people who navigate with a keyboard pr keyboard equivalent. As you noted, those invisible links will confuse them.

In this case, if at all possible, I would do a usability test. Find several people who fit this profile and don't know the design. Then ask them to find several items that could be reached through the hidden-when-using-tabs level of the menus. And them have them find several items that are visible on the page but are beyond the megamenu in the tab order.

Have your doubters observe the test—remotely if possible; gagged and straightjacketed if necessary to keep them quiet.

See if any of the participants get confused. (My guess is that they all will.) If not, you're probably OK. If you want to be absolutely sure, have a few more people test the page. If you get up to 25 or 30 participants and still have not seen a participant encounter problems, then your design is probably OK.

If the audience can't use it for any reason, surely your organization would want to fix that. If that reason is in any way a hindrance for people with disabilities, I would at least say that it fails the related success criterion.

After all, accessibility isn't about creating paths that properly programmed robots can follow. It's about removing hindrances experienced by real people. If that hindrance is due to or exacerbated by a disability, then in my book the interface is inaccessible, even if I have to stretch a success criterion to designate it as such.

Cliff Tyllick

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Jan 16, 2015, at 10:09 AM, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>
> Apologies - I lied :-)
>
> It *is* possible to get to a new page using the top menu links. And
> the new page contains all of the submenu items.
>
> But it's still confusing for keyboard users to be tabbing through a
> bunch of invisible links. So presumably 2.1.1 isn't pertinent here.
> But focus visible doesn't feel like quite the right fit.
>
> Any thoughts on this?
>
> Thanks, Lynn
>
>> On 16/01/2015, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks everyone.
>>
>> No, it's not possible to open the menu or get to a different
>> destination by activating one of the links in the top menu.
>>
>> 2.1.1 looks like a good point to fail it on - thanks Patrick.
>>
>> I worked on a menu system for a while, and it functioned pretty much
>> exactly like native menus: left/right arrows move across the top or
>> open/close sub-submenus; down arrow opens a submenu or moves through
>> its options; Esc closes a submenu, etc., and I liked it a lot. But it
>> wasn't possible to create an implementation that worked across all
>> screenreaders. And we were never sure whether we should indicate that
>> an item could be expanded if pressing Enter moved the user to a
>> different page. So I'm very interested in this discussion and what you
>> all think.
>>
>> Best, Lynn
>>
>>> On 16/01/2015, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:
>>> I'd like to give my two cents for what it's worth. For me, I like the
>>> way
>>> menus and submenus currently work as it is the way most application menus
>>> work.
>>>
>>>

From: _mallory
Date: Sat, Jan 17 2015 5:46AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On Fri, Jan 16, 2015 at 04:10:23PM +0100, John Hicks wrote:
> I fully agree, but just wondering whether they had implemented *some* means
> of displaying the menu via the keyboard.
>
> I am faced daily with the conundrum of bloated and "SEO-motivated" mega
> menus.... I hate them.

Me too, all my menus must have thousands of links, because some SEOer
told them "people don't like to click" or "it's good for the Juice"
or some crazy thing.

Many of our customers don't seem to believe anyone has a small screen
like on a netbook along with a mouse without a scrollwheel. In those
cases, the submenu goes offscreen and you can never reach the lowest
level items anyway. With keyboard, you can always reach them.

_mallory

From: Jennifer Sutton
Date: Sat, Jan 17 2015 12:24PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

For what it's worth, I'd give Adobe's Megamenu, that Jonathan
referenced earlier, a +1.
It's the best implementation I've found to date.

Best,
Jennifer

From: Roger Hudson
Date: Sat, Jan 17 2015 1:57PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

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
$B"'(B). 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/ webaim.org> = EMAIL ADDRESS 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 ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Sat, Jan 17 2015 3:42PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>
>
>
>
>
> > > >


--
Work hard. Have fun. Make history.

From: Andrew Kirkpatrick
Date: Sun, Jan 18 2015 9:02AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Sun, Jan 18 2015 12:26PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

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

From: Sean Curtis
Date: Sun, Jan 18 2015 4:37PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

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

From: _mallory
Date: Mon, Jan 19 2015 12:39AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

On Sun, Jan 18, 2015 at 04:02:59PM +0000, Andrew Kirkpatrick wrote:
> 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.

Showing submenus visibly on focus does *not* require the keyboarder
to tab through all the submenu links, if the menu is built properly.

The advantage of showing submenus on focus is, as the other reply has
said, the user knows they exist. Having another separate functionality
like a separate "activate" button as proposed earlier has the
disadvantage that users never discover it, or get confused.

_m

From: _mallory
Date: Mon, Jan 19 2015 12:42AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Corrections, I hit "y" too fast
On Mon, Jan 19, 2015 at 08:39:57AM +0100, _mallory wrote:
> Showing submenus visibly on focus does *not* require the keyboarder
> to tab through all the submenu links, if the menu is built properly.
That should be, "does not necessarily require"
>
> Having another separate functionality
> like a separate "activate" button as proposed earlier has the
> disadvantage that users never discover it, or get confused.
Should be, "users may never discover it"

_m

From: Andrew Kirkpatrick
Date: Mon, Jan 19 2015 6:48AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

So, the way that the mega menu (http://adobe-accessibility.github.io/Accessible-Mega-Menu/) was designed:

1) tabbing to the menu does not open the submenu, but focuses the first menu heading.
2) tabbing when the menu is closed moves the focus to the next menu heading (this was a heavily debated topic - the other option is to have one tab stop for the entire menu system when closed).
3) when focus is on a menu heading, hitting down arrow or enter will open the menu.
4) when focus is on a menu heading left and right arrows will move the focus between menu headings
5) when a menu is open, escape will always close the submenu
6) when the submenu is open and focus is on the menu heading, the example implementation takes the user to a page containing links to the submenu items when you click on that link. This can be easily modified.
7) when a menu is open the user can move between menu items with tab or arrows, including left/right arrows
8) to tab past the menu system the user either needs to tab through the menu options until they reach the end, or close the submenu that is open and tab past the smaller number of menu headings into the content).

I do agree that even if the menus are in view that users don't need to be able to tab through all of the submenu links, but there does need to be a keyboard accessible way to access all of the submenu items. If a menu system is set up to enable arrow keys to access the items, then that should be fine.

Our example is surely not the only way, nor is it perfect, and depending on the specific menu system needed for the content it may or may not meet the needs of the site. However, we put it on GitHub as an example for people to look at, discuss, learn from, and if they choose, to fork and use for their own purposes (in keeping with the terms of the license, etc, etc).

AWK

From: Lynn Holdsworth
Date: Mon, Jan 19 2015 9:25AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Hi Andrew,

> 7) when a menu is open the user can move between menu items with tab or arrows, including left/right arrows

Just curious about the thinking behind using the left/right arrows to
move up and down the items in a submenu. In native implementations the
left/right arrow keys move the focus across the items in the menubar
at the top.

Cheers, Lynn

On 19/01/2015, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> So, the way that the mega menu
> (http://adobe-accessibility.github.io/Accessible-Mega-Menu/) was designed:
>
> 1) tabbing to the menu does not open the submenu, but focuses the first menu
> heading.
> 2) tabbing when the menu is closed moves the focus to the next menu heading
> (this was a heavily debated topic - the other option is to have one tab stop
> for the entire menu system when closed).
> 3) when focus is on a menu heading, hitting down arrow or enter will open
> the menu.
> 4) when focus is on a menu heading left and right arrows will move the focus
> between menu headings
> 5) when a menu is open, escape will always close the submenu
> 6) when the submenu is open and focus is on the menu heading, the example
> implementation takes the user to a page containing links to the submenu
> items when you click on that link. This can be easily modified.
> 7) when a menu is open the user can move between menu items with tab or
> arrows, including left/right arrows
> 8) to tab past the menu system the user either needs to tab through the menu
> options until they reach the end, or close the submenu that is open and tab
> past the smaller number of menu headings into the content).
>
> I do agree that even if the menus are in view that users don't need to be
> able to tab through all of the submenu links, but there does need to be a
> keyboard accessible way to access all of the submenu items. If a menu
> system is set up to enable arrow keys to access the items, then that should
> be fine.
>
> Our example is surely not the only way, nor is it perfect, and depending on
> the specific menu system needed for the content it may or may not meet the
> needs of the site. However, we put it on GitHub as an example for people to
> look at, discuss, learn from, and if they choose, to fork and use for their
> own purposes (in keeping with the terms of the license, etc, etc).
>
> AWK
>
>

From: Andrew Kirkpatrick
Date: Mon, Jan 19 2015 9:57AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Sorry, I may not have been clear. Left/right move the focus left and right within the megamenu, which contains multiple columns of items.
AWK

From: Lynn Holdsworth
Date: Mon, Jan 19 2015 11:04AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Aha! OK Andrew, that makes perfect sense. Thanks for clarifying.

On 19/01/2015, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Sorry, I may not have been clear. Left/right move the focus left and right
> within the megamenu, which contains multiple columns of items.
> AWK
>
>

From: Ryan E. Benson
Date: Mon, Jan 19 2015 12:50PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

>5) when a menu is open, escape will always close the submenu

I didn't read your instructions, but it took me about a minute to figure
this out, because i wasn't trying. In my experience, a lot of people who
use the keyboard, don't attempt to use the escape key. That being said, I
was happy the menu automatically closed after a second when focus moved
from the menu

--
Ryan E. Benson

On Mon, Jan 19, 2015 at 8:48 AM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:

> So, the way that the mega menu (
> http://adobe-accessibility.github.io/Accessible-Mega-Menu/) was designed:
>
> 1) tabbing to the menu does not open the submenu, but focuses the first
> menu heading.
> 2) tabbing when the menu is closed moves the focus to the next menu
> heading (this was a heavily debated topic - the other option is to have one
> tab stop for the entire menu system when closed).
> 3) when focus is on a menu heading, hitting down arrow or enter will open
> the menu.
> 4) when focus is on a menu heading left and right arrows will move the
> focus between menu headings
> 5) when a menu is open, escape will always close the submenu
> 6) when the submenu is open and focus is on the menu heading, the example
> implementation takes the user to a page containing links to the submenu
> items when you click on that link. This can be easily modified.
> 7) when a menu is open the user can move between menu items with tab or
> arrows, including left/right arrows
> 8) to tab past the menu system the user either needs to tab through the
> menu options until they reach the end, or close the submenu that is open
> and tab past the smaller number of menu headings into the content).
>
> I do agree that even if the menus are in view that users don't need to be
> able to tab through all of the submenu links, but there does need to be a
> keyboard accessible way to access all of the submenu items. If a menu
> system is set up to enable arrow keys to access the items, then that should
> be fine.
>
> Our example is surely not the only way, nor is it perfect, and depending
> on the specific menu system needed for the content it may or may not meet
> the needs of the site. However, we put it on GitHub as an example for
> people to look at, discuss, learn from, and if they choose, to fork and use
> for their own purposes (in keeping with the terms of the license, etc, etc).
>
> AWK
>
>

From: _mallory
Date: Tue, Jan 20 2015 12:34AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Even being "web-aware" I expect usual tabby stuff and when that
fails, I start mashing on arrow keys, then special keys, and then
I probably grab the mouse if I have one :P

_m
On Mon, Jan 19, 2015 at 02:50:20PM -0500, Ryan E. Benson wrote:
> >5) when a menu is open, escape will always close the submenu
>
> I didn't read your instructions, but it took me about a minute to figure
> this out, because i wasn't trying. In my experience, a lot of people who
> use the keyboard, don't attempt to use the escape key. That being said, I
> was happy the menu automatically closed after a second when focus moved
> from the menu
>
> --
> Ryan E. Benson

From: Bourne, Sarah (ITD)
Date: Tue, Jan 20 2015 9:46AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

The www.mass.gov site has gone through a number of iterations of its mega menu, incorporating user feedback on each cycle. One version included a link to expand the menu on focus (i.e., "Expand Energy & Environment"), separate from the link to open the "category" page ("Energy & Environment'). The latest version is a bit more elegant, with thanks to Adobe from what we learned from their example.

One thing we observed is that keyboard-only users can have different views of how they are "supposed" to interact with application-like stuff on the web, especially when it comes to tab versus arrow keys. One of the nice things about the Adobe menu is that it works with both paradigms, so now the "customer" is always right.

As for Lynn's original question, the menu would seem to "fail" Principal 1 ("Information and user interface components must be presentable to users in ways they can perceive.") Who would think we would need a Guideline that content needs to be visible? Lacking that, I would cite 2.1.1 - If reading the menu items is a "function" and 2.4.7 - Visible focus

sb
Sarah E. Bourne
Director of IT Accessibility
Massachusetts Office of Information Technology
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd

From: Devarshi Pant
Date: Tue, Jan 20 2015 12:34PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Some observations regarding www.mass.gov menu:

1. For JAWS users, wouldn't it be ideal to navigate the menu in PC Cursor
(application) mode? It seems I have to go into application mode to navigate
through and within menuitems.

2. There should be cues to tell screen reader users how to navigate the
menu and where all submenu items exist -- e.g. ["Name" Menu, to move
through items move up and down arrow.]

3. There is a working example where role=application and role=menuitem is
used (http://oaa-accessibility.org/example/25/) -- seems to address issues
raised in 1 and 2 above.

3. Is there a standard way to navigate menus so that the user experience is
consistent? For example, use arrow keys to navigate and tab to skip the
menu bar, escape to close, voice cues, ...
On Jan 20, 2015 11:47 AM, "Bourne, Sarah (ITD)" < = EMAIL ADDRESS REMOVED = >
wrote:

> The www.mass.gov site has gone through a number of iterations of its mega
> menu, incorporating user feedback on each cycle. One version included a
> link to expand the menu on focus (i.e., "Expand Energy & Environment"),
> separate from the link to open the "category" page ("Energy &
> Environment'). The latest version is a bit more elegant, with thanks to
> Adobe from what we learned from their example.
>
> One thing we observed is that keyboard-only users can have different views
> of how they are "supposed" to interact with application-like stuff on the
> web, especially when it comes to tab versus arrow keys. One of the nice
> things about the Adobe menu is that it works with both paradigms, so now
> the "customer" is always right.
>
> As for Lynn's original question, the menu would seem to "fail" Principal 1
> ("Information and user interface components must be presentable to users in
> ways they can perceive.") Who would think we would need a Guideline that
> content needs to be visible? Lacking that, I would cite 2.1.1 - If reading
> the menu items is a "function" and 2.4.7 - Visible focus
>
> sb
> Sarah E. Bourne
> Director of IT Accessibility
> Massachusetts Office of Information Technology
> Commonwealth of Massachusetts
> 1 Ashburton Pl. rm 1601 Boston MA 02108
> 617-626-4502
> = EMAIL ADDRESS REMOVED =
> http://www.mass.gov/itd
> > > >

From: Jennifer Sutton
Date: Sat, Jan 24 2015 12:56PM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | Next message →

Greetings:

I don't think I've seen a link to this WAI tutorial on menus posted
to this list, so I thought I'd share it. Perhaps concepts will apply
and/or folks would like to follow up and provide their feedback on
the tutorial. It starts here:

http://www.w3.org/WAI/tutorials/menus/


And in case you've not been monitoring the preparation and
presentation of these tutorials, overall, you might want to start here:

http://www.w3.org/WAI/tutorials/


I especially like the one on carousels. Notice that I didn't say I
like carousels . . .
I'm definitely not meaning to start up that "fun" topic.

Best,
Jennifer

From: Birkir R. Gunnarsson
Date: Sun, Jan 25 2015 8:59AM
Subject: Re: Inaccessible mega menu and WCAG2
← Previous message | No next message

Jaws is expected to go directly into application mode when focus is
inside a container ith role="menu".
role="application" on the menu container should not be necessary.
That being said, Jaws does only go automatically into forms mode in IE
(tested with Jaws 16 and IE10), not in Firefox (tested with FF34).
So role="application" on the menu container element may be a necessary
screen reader experience enhancement extra.

Screen readers (and other a.t. apps) are still learning to expose ARIA
most effectively to end users; it is a process.
We often take it for granted that end users (whether it be users of
screen readers, keyboard or other assistive technology) know how to
interact with complex widgets.
Of course these are assumptions we have to make, or we have to leave
the specifics of teaching the end user how to use his assistive
technology with accessibly coded widgets, to others.
The excellent megamenu example from Adobe (Thanks Anderew and your
team for putting it together) has a few screen reader discovery
problems, at least I only started fully understanding the
functionality after reading the blog and Andrew's comments.
But at the same time I see no obvious way to use simple attributes to
make such functionality obvious to users ofvarious screen readers.
It again comes down to us having to assume that end users understand
the widget, how it works in their native OS, and start trying to
interact with it in a way that is consistent with their expectations.

Cheers
-B


On 1/24/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings:
>
> I don't think I've seen a link to this WAI tutorial on menus posted
> to this list, so I thought I'd share it. Perhaps concepts will apply
> and/or folks would like to follow up and provide their feedback on
> the tutorial. It starts here:
>
> http://www.w3.org/WAI/tutorials/menus/
>
>
> And in case you've not been monitoring the preparation and
> presentation of these tutorials, overall, you might want to start here:
>
> http://www.w3.org/WAI/tutorials/
>
>
> I especially like the one on carousels. Notice that I didn't say I
> like carousels . . .
> I'm definitely not meaning to start up that "fun" topic.
>
> Best,
> Jennifer
>
>
> > > >


--
Work hard. Have fun. Make history.