WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: good examples of javascript "roll over" menus with an accessible alternative

for

From: Christian Heilmann
Date: Jul 29, 2005 2:53PM

> Are the flyout menu systems in MS Word
> accessible? (I'm referring to the main menus such as File, Edit, Tools,
> etc.) If you don't think those menus are accessible, then you won't
> think that *any* flyout menu system is accessible, no matter what. I
> tend to think that those menu systems qualify as being accessible. They
> are accessible by keyboard, by screen reader, by sight, and they seem to
> work quite well. I haven't heard too many people with disabilities
> complaining about those menu systems lately. Of course, I have seen
> software with confusing menu systems, or too many submenus, or confusing
> labels. Sure, these problems exist, and they do reduce accessibility,
> but it's not really the fault of the "flyout menu" technology per se.
>
> Should we dismiss attempts to replicate a convention (flyout menus) that
> is generally believed to be accessible in an operating system
> environment? In other words, if people don't complain about the
> accessibility of operating system menus (which definitely have flyout
> components and submenus), why should we complain about implementing them
> in HTML (provided that they are accessible)?
>
> Think about that one for a moment. I think you'll either have to say
> "operating system flyout menus are not accessible" or "HTML flyout menus
> could be made to be accessible if done right."

Objection your honour. What this reasoning forgets to take into
account is that a web site is not an own application but already
resides inside another application - the browser - which has flyout
navigations. If a screen reader is used then it also resides inside
yet another application. (This is also the big problem with accesskey
attributes - too many keyboard shortcuts are already taken up by the
other applications.)

So to compare Word and HTML we'd have to talk about VB enabled Word
documents with dropdown navigation to jump to the different pages. And
even in Word this is normally done by a generated TOC of links.

This also affects the visitor. Why should the document be navigated
like the options of the application it is opened in?

Maybe it is time to ask the users. On all the sites I maintained and
tested with real users I have yet to find a user that claimed that a
shortcut to any of the pages in the sitemap without leaving this page
would be great. Instead of navigating through three levels of
navigation they either used the sitemap or the search instead.

Am I not right to assume that visitors normally come to a site with a
certain goal in mind. "I want to buy some CDs" is more likely a driver
than "I want to see how deep this site is and what they offer me, and
I don't want a reload in between".
As stated before in this thread, if you want to offer that, why not do
so as an "enhanced navigation" feature. Let marketing go wild and call
it "KwikNav" or something like that.
Amazon.com for example finally realised that too many tabs are not a
good plan, and now have a dynamic popup navigation listing all sub
sections. Sadly enough it seems to be enabled by default.

Navigation is a tool, much like anything else, it should help the
visitor find her way through the things we offer. A lot of the
reasoning I read here is about defending popup navigation as it is a
pseudo standard. It is in application development, but a web site is
not an application, it is connected content. The question should never
be "how can we make this accessible", the question is "how do users
benefit from this navigation". It would be great to have a comparison
of different navigation systems with a wide range of users of
different abilities. My personal assumption is that if the site
indicates to be huge, most will use the search and just not bother
with the navigation system.