E-mail List Archives
Thread: drop down menus
Number of posts in this thread: 15 (In chronological order)
From: Gary Williamson
Date: Fri, May 29 2009 12:40AM
Subject: drop down menus
No previous message | Next message →
Hi. I'm just trying to find some definitive answers to the accessibility of
drop down menus. Can anyone point me in the right direction? Are they
compliant with WCAG priority 2 guidelines?
Thanks
Gary
From: Benjamin Hawkes-Lewis
Date: Fri, May 29 2009 12:45AM
Subject: Re: drop down menus
← Previous message | Next message →
On 29/5/09 07:36, Gary Williamson wrote:
> I'm just trying to find some definitive answers to the accessibility of
> drop down menus. Can anyone point me in the right direction? Are they
> compliant with WCAG priority 2 guidelines?
You mean WCAG 1.0 rather than 2.0?
Usually not. Most aren't operable with the keyboard (Checkpoint 9.2 in
WCAG 1.0 and Guideline 2.1 in WCAG 2.0). But it depends on the
implementation.
--
Benjamin Hawkes-Lewis
From: Al Sparber
Date: Fri, May 29 2009 1:40AM
Subject: Re: drop down menus
← Previous message | Next message →
From: "Gary Williamson" < = EMAIL ADDRESS REMOVED = >
> Hi. I'm just trying to find some definitive answers to the accessibility
> of
> drop down menus. Can anyone point me in the right direction? Are they
> compliant with WCAG priority 2 guidelines?
They can easily be made so based on the quality of the script and the
deployment. So-called "pure" CSS menus are sometimes accessible, but never
usable.
Here is a brief article/example of an accessible deployment:
http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/
--
Al Sparber - PVII
http://www.projectseven.com
From: Peter Weil
Date: Fri, May 29 2009 6:10AM
Subject: Re: drop down menus
← Previous message | Next message →
On May 29, 2009, at 2:38 AM, Al Sparber wrote:
> So-called "pure" CSS menus are sometimes accessible, but never
> usable.
I know that this can be a provocative topic (previous threads on this
subject never seemed to arrive at satisfactory conclusion), but we are
also looking into the possibility of incorporating dropdown menus.
However, accessibility/usability is an absolute requirement -- it's
one of the reasons that we have avoided them in the past. Would you
please expand on why pure CSS menus are "never usable"? Is javascript
a necessary component?
Thank you.
--
Peter Weil, Web Developer
University Communications
University of Wisconsin-Madison
Phone: 608-262-6538
Email: = EMAIL ADDRESS REMOVED =
From: Jon Gunderson
Date: Fri, May 29 2009 8:45AM
Subject: Re: drop down menus
← Previous message | Next message →
Here is an example of a pull down menu with keyboard and ARIA support:
http://test.cita.illinois.edu/aria/menubar/menubar1.php
Jon
---- Original message ----
>Date: Fri, 29 May 2009 07:05:43 -0500
>From: Peter Weil < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] drop down menus
>To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>
>
>On May 29, 2009, at 2:38 AM, Al Sparber wrote:
>
>> So-called "pure" CSS menus are sometimes accessible, but never
>> usable.
>
>I know that this can be a provocative topic (previous threads on this
>subject never seemed to arrive at satisfactory conclusion), but we are
>also looking into the possibility of incorporating dropdown menus.
>However, accessibility/usability is an absolute requirement -- it's
>one of the reasons that we have avoided them in the past. Would you
>please expand on why pure CSS menus are "never usable"? Is javascript
>a necessary component?
>
>Thank you.
>
>--
>Peter Weil, Web Developer
>University Communications
>University of Wisconsin-Madison
>Phone: 608-262-6538
>Email: = EMAIL ADDRESS REMOVED =
>
>
>
>
>
>
From: Al Sparber
Date: Fri, May 29 2009 8:55AM
Subject: Re: drop down menus
← Previous message | Next message →
From: "Jon Gunderson" < = EMAIL ADDRESS REMOVED = >
> Here is an example of a pull down menu with keyboard and ARIA support:
>
> http://test.cita.illinois.edu/aria/menubar/menubar1.php
That's the most OS-like keyboard scripting I've ever seen. Excellent work.
My compliments to the script chef. It has a lot of rough edges for
able-bodied mouse users, though perhaps it's a work that's still in process.
--
Al Sparber - PVII
http://www.projectseven.com
From: Paul Collins
Date: Fri, May 29 2009 9:00AM
Subject: Re: drop down menus
← Previous message | Next message →
That doesn't work without Javascript, not sure if that's a problem or not.
I'm a bit confused with ARIA. Is it purely Javascript that is Accessible, or is it supposed to degrace gracefully also, like when you have scripts turned off? Would be great to have a drop down menu that is Accessible in all scenarios.
Cheers
From: ben morrison
Date: Fri, May 29 2009 9:10AM
Subject: Re: drop down menus
← Previous message | Next message →
On Fri, May 29, 2009 at 3:53 PM, Al Sparber < = EMAIL ADDRESS REMOVED = > wrote:
> From: "Jon Gunderson" < = EMAIL ADDRESS REMOVED = >
>
>> Here is an example of a pull down menu with keyboard and ARIA support:
>>
>> http://test.cita.illinois.edu/aria/menubar/menubar1.php
>
> That's the most OS-like keyboard scripting I've ever seen. Excellent work.
> My compliments to the script chef. It has a lot of rough edges for
> able-bodied mouse users, though perhaps it's a work that's still in process.
>
I tabbed to the first menu item, tabbed again to the content, tabbed
again and well. it didnt work FF2
--
Ben Morrison
From: Al Sparber
Date: Fri, May 29 2009 9:20AM
Subject: Re: drop down menus
← Previous message | Next message →
From: "Peter Weil" < = EMAIL ADDRESS REMOVED = >
> On May 29, 2009, at 2:38 AM, Al Sparber wrote:
>
>> So-called "pure" CSS menus are sometimes accessible, but never
>> usable.
>
> I know that this can be a provocative topic (previous threads on this
> subject never seemed to arrive at satisfactory conclusion), but we are
> also looking into the possibility of incorporating dropdown menus.
> However, accessibility/usability is an absolute requirement -- it's
> one of the reasons that we have avoided them in the past. Would you
> please expand on why pure CSS menus are "never usable"? Is javascript
> a necessary component?
JavaScript allows for the introduction of timing, which allows people
without the ability to perfectly aim a pointing device to "miss" a bit
without snapping a menu shut or causing the wrong menu to be revealed.
Imagine a menu section, 6 links long. Its first menu item triggers a
sub-menu to fly out to its right. The sub-menu has 10 items. The link you
want to execute is the 8th one down. In order to access this with a mouse or
pointing device, you must move straight across the trigger item until you
reach the fly out menu, then go straight down. The natural inclination is to
move at a diagonal from the trigger to the target link. When you do this,
you brush over the link below the trigger and the fly out menu snaps shut.
The "L-shaped" path one must take in this scenario is not natural and only
seems to be tolerated by web designers that are also proponents of pure CSS
menus and thus understand how they work. In the wild, these menus cause
severe frustration. We have done extensive usability testing that bears this
out.
It doesn't get any better. Scripted menus that are done well have many other
features that assist in usability. These include:
Edge detection that helps to ensure that if a menu's natural position would
have it go beyond the visible edge of the window, it is re-positioned
on-screen.
Link highlighting to mark a link in the menu that corresponds to the current
page.
Keyboard access - though I think the best multi-level menus eschew all
keyboard support and instead are deployed in the manner discussed in my
little example.
etc., etc.
CSS (at this time) is a presentational component, not a behavioral one. It
is likely that in the future, CSS and markup will be used in concert with a
browser's internal script engine to create behavior, such as menus that
operate precisely according to OS UI convention. That day is years in the
future though.
Hope this helps a bit.
--
Al Sparber - PVII
http://www.projectseven.com
From: Al Sparber
Date: Fri, May 29 2009 9:25AM
Subject: Re: drop down menus
← Previous message | Next message →
From: "ben morrison" < = EMAIL ADDRESS REMOVED = >
>> From: "Jon Gunderson" < = EMAIL ADDRESS REMOVED = >
>>
>>> Here is an example of a pull down menu with keyboard and ARIA support:
>>>
>>> http://test.cita.illinois.edu/aria/menubar/menubar1.php
> I tabbed to the first menu item, tabbed again to the content, tabbed
> again and well. it didnt work FF2
The problem with these approaches is that they work great for web developers
who understand what's going on :-) For real-world users, they are
mystery-meat and require a help file or user guide - which is the reason
that they are useless, in my opinion. An exercise in futility at worst.
--
Al Sparber - PVII
http://www.projectseven.com
From: John Foliot
Date: Fri, May 29 2009 12:50PM
Subject: Re: drop down menus
← Previous message | Next message →
Gary Williamson wrote:
>
> Hi. I'm just trying to find some definitive answers to the accessibility
of
> drop down menus. Can anyone point me in the right direction? Are they
> compliant with WCAG priority 2 guidelines?
>
>
So once upon a time, if anyone mentioned accesskeys.... (hi old timers!)
DROPDOWN MENUS:
Dropdown or fly-out menus are tricky in that they can pose multiple types
of access barriers when used indiscriminately. The issues can be:
Mobility impairments:
Some scripts/solutions are mouse dependant and/or do not respond well to
tabbing. Personally, my local bank's (Credit Union) website uses a
drop-down menu that also has very sensitive 'hotspots', and if you do not
click the top-row buttons in just the right way, the secondary selections
flicker in and out - very annoying. Multi-nested links can increase this
frustration level exponentially, and even when tabbing is done properly
can also frustrate users who can tab through the links, but are left
tabbing, tabbing, tabbing, tabbing, tabbing.... (you get the point)
Auditory clutter:
For users of screen reading technology, this can be a very significant
problem. The usual reason for these types of fly-out expand/contract type
menus is to reduce 'visual clutter' on screen - we don't want to bombard
the users with 106 links on the page, so we tuck them out of site until
needed. The problem of course is that when you do not 'see' links, but
instead have to listen to them, you still need to process those 106 links
- thus the audio clutter remains even if the visual one has been
addressed. While good semantic structure (using <h> tags!) and the
ubiquitous "skip nav" link help here (for repeat visitors), first time
visitors are not afforded any relief.
Cognitive issues:
Believe it or not, too many choices is actually less useful than fewer
choices. Often directly linked to the audio clutter issue noted above, it
can also impact users who have other cognitive impairments - dyslexia,
poor memory issues, etc. We've all encountered those automatic
switchboards from hell that start out with "Please listen carefully as
some of our options have changed..." - imagine if Suzy Automon then
proceeded to list 106 choices over the phone. THAT is the issue at hand.
There has been a fair bit of study surrounding optimal information
"chunks" that should be considered here, and I am linking to two good
jump-off points (both Wikipedia entries) to start with:
* http://en.wikipedia.org/wiki/Cognitive_load
* http://en.wikipedia.org/wiki/Chunking_(psychology)
...and so...
Depending on the 'solution' chosen you might be able to produce a fly-out
menu that meets technical merits of accessibility (tab-ability, nested
lists/CSS, etc., etc.) but the 'softer' issues as noted above can impact
on whether or not your menu is 'conformant' - however in this regard it is
a subjective call, as any final decision will likely require both a
technical and 'political' component.
Case in point; my workplace's main site has a compact/expand menu solution
which took a slightly different approach (www.stanford.edu), where a
'drawer' was used to offer the expanded choice levels. While not perfect
(we all need to take a little water with our wine sometimes), there were
some things considered when the site was at the design process:
* all choices are presented simultaneously, so that users with
cognitive issues can process all of their choices in a manner that better
suits their needs - it greatly reduces the cognitive/memory load for
sighted users (although non-sighted users still have that issue)
* the solution requires JavaScript, which some studies suggest has
a possible +/- 5% failure rate (i.e. approximately 5% of user-agents do
not support JavaScript or have it disabled
[http://www.thecounter.com/stats/2009/April/javas.php]). To address this
issue, the 'button' that expands and contracts the drawer is written
on-screen via JavaScript as well; if JS is not available, the button is
not there either (as opposed to a button that would be there but did
nothing)
* tab order was considered in the design: the 5 'parent' buttons
are the first five presented in the navigation tab order, and 'clicking'
(activating) those parent links will take the user to a page where the
subsequent 'children links' in the drawer are re-created as part of a
stand-alone page.
* most importantly, there is an in-house policy that strictly
limits the number of links that can exist in 'the drawer' - in our case
25. While this is far from perfect, it does reduce the 'creep' factor
that these types of menus foster... what starts out as 25 can often
balloon to significantly larger numbers, especially in large organizations
where everyone wants a link from the home-page. Having a policy that
limits the number of links here means that for a new link to be
'promoted', another must be 'demoted' - yes it creates a political
struggle, but that's another issue that is outweighed by the need to
remain usable/accessible.
To be clear, having the ability to keep your webpage 'tidy' has benefits
as well, including accessibility benefits (again in the cognitive realm),
but any solution that you choose needs to be well thought out and planned
- grabbing a script somewhere and just knocking out a fly-out menu is
exactly the wrong approach which likely will guarantee issues. Finally,
any site that needs to have 40 - 50 - 60+ links in their menu has
architecture issues that almost always will impact on usability for all
visitors, not just those with 'disabilities'.
Cheers!
JF
From: Gary Williamson
Date: Sat, May 30 2009 2:15PM
Subject: Re: drop down menus
← Previous message | Next message →
Thanks JF
That's a pretty definitive answer!
Cheers
Gary
From: Peter Weil
Date: Mon, Jun 01 2009 8:00AM
Subject: Re: drop down menus
← Previous message | Next message →
On May 29, 2009, at 1:48 PM, John Foliot wrote:
>> So once upon a time, if anyone mentioned accesskeys.... (hi old
>> timers!)
>
> DROPDOWN MENUS:
>
> Dropdown or fly-out menus are tricky in that they can pose multiple
> types
> of access barriers when used indiscriminately. The issues can be:
[snip]
Thanks John and Al for your answers. This gives us a lot of food for
thought. I think we'll try to shy away from trying any sort of multi-
level, drawer-type menus and stick with more simple dropdowns. A
little javascript doesn't necessarily bother me, as long as we create
something that degrades gracefully when javascript is disabled. And
the newer css properties (e.g., transitions) certainly offer a lot of
promise.
Does either of you (or anyone else) have an opinion on whether it's
better to have menus activated on rollover or by clicking a link? I
personally have always found most rollover menus to be obtrusive and
annoying, because they open up if you accidentally move the pointer
over the link, and then they often don't go away very quickly.
Thanks, Peter
--
Peter Weil, Web Developer
University Communications
University of Wisconsin-Madison
Phone: 608-262-6538
Email: = EMAIL ADDRESS REMOVED =
From: Juan Ulloa
Date: Mon, Jun 01 2009 1:20PM
Subject: Re: drop down menus
← Previous message | Next message →
>Does either of you (or anyone else) have an opinion on whether it's
>better to have menus activated on rollover or by clicking a link? I
>personally have always found most rollover menus to be obtrusive and
>annoying, because they open up if you accidentally move the pointer
>over the link, and then they often don't go away very quickly.
We use the superfish and hoverintent jquery plugins at http://bellevuecollege.edu. This combo allows us to make the menu keyboard accessible (via tabbing), minimizes the accidental popup of menus and gives us control over how long the menu will display after the user hovers away from the menu.
Hope this helps,
Juan C. Ulloa
Webmaster, Web Services, Bellevue College
= EMAIL ADDRESS REMOVED =
:-)
From: Al Sparber
Date: Mon, Jun 01 2009 1:25PM
Subject: Re: drop down menus
← Previous message | No next message
From: "Juan Ulloa" < = EMAIL ADDRESS REMOVED = >
> We use the superfish and hoverintent jquery plugins at
> http://bellevuecollege.edu. This combo allows us to make the menu
> keyboard accessible (via tabbing), minimizes the accidental popup of menus
> and gives us control over how long the menu will display after the user
> hovers away from the menu.
I think you might have missed some of the great points made, particularly by
John. Merely being keyboard (tab key) accessible is not necessarily a good
thing and may, in fact, be a bad thing. Having the menu work when script is
disabled is almost always a bad thing.
--
Al Sparber - PVII
http://www.projectseven.com