WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: drop down menus

for

From: John Foliot
Date: May 29, 2009 12:50PM

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