WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Paul Bohman
Date: Jul 29, 2005 2:07PM

This is a long message, but hopefully it contains some ideas to make
people think about the issue of flyout menus:

The flyout menus by Brothercake are perhaps the best attempt that I've
seen to address a wide variety of accessibility problems that plague
most other attempts. I have not tested them extensively, but viewed them
in Windows versions of Firefox, IE 6.0, Netscape 8.0 and Opera 8.0. I
have not listened to them with a screen reader.

One of the most impressive features of these menus is that they work
just like operating system menus. Glenda asked about the possibility of
navigating flyout menus with the arrow keys. You *can* navigate these
with the arrow keys: forward, backwards, up down. They work. Well, they
don't work so well in Opera, but let me come back to that point a little
later.

If we look at this as a challenge of trying to create flyout menus that
are accessible and which act like operating system menus (which we
assume are accessible), these menus seem to have succeeded.

There are still a few issues left to consider:
1. Are flyout menus accessible on an abstract level (as opposed to in
technical terms in HTML-specific environments)?
2. What about browsers that don't support this method?
3. People aren't used to having HTML menu systems that work like
operating system menus.

1. So let's talk about the first issue: are flyout menus accessible on
an abstract level?

John Foliot alluded to this question when he complained of the problem
with many links and submenus. The fact that users can use the arrow keys
to move through these menus means that the "too many submenus" concern
is not as critical as it would be if the arrow keys did not perform this
function. Speaking abstractly, if operating system flyout menus are
accessible, these menus are accessible.

That doesn't totally answer the question though. The fact that
Brothercake's menus are dense is really irrelevant. You can make menus
sparse or dense. There are obviously some concerns about dense menus, in
terms of usability, comprehension, navigation, and so on, but if we say
that his flyout menu system is bad because people might add too many
links, that's like saying HTML is inaccessible because you can create
confusing web pages. Of course you can use technologies like HTML or his
flyout menus (which use HTML, CSS, and JavaScript) to create confusing
content. You can also create usable and accessible content with HTML,
and my guess is that you can create usable and accessible content with
his menus... as long as we all agree that flyout menus *can* be
accessible in an abstract sense. 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."


2. Browser support issues

The menus don't work in every browser. They work well in quite a few
modern browsers, but not in all of them. They certainly don't "work" in
older browsers that lack support for CSS, though the links and the
hierarchical structure are completely available in these older browsers
(and are therefore "accessible" in that sense), even if they are not so
fancy or attractive.

We could just say "well, they don't work in every browser, therefore, we
should not use them and should stop trying to use anything like that."
That's not very productive in my opinion. Let people experiment. HTML
and browsers are not perfectly robust. There's a lot that needs to
happen before we can reach the same level of accessibility for
interactive features which is not available in operating systems (though
I would add that operating system accessibility is still far from perfect).

With old technologies, we have to let them go at some point. We have to
be considerate of all users, but we can't access most websites on the
old Mosaic browser, or Netscape 1.0 anymore. That's progress, not a
problem, in my opinion.


3. Users don't know how to work the menus (i.e. they may not expect
tabbing to work and almost certainly won't know to use the arrow keys.

This is a real issue, but I use the same logic as in my response to the
previous concern. People don't know about it because they've been using
websites that were incapable of giving them that functionality. If we
invent a system/technology/method that works, shouldn't we promote it
rather than squashing it?

Having said this, it's a chicken and egg dilemma. People won't know to
expect the menus to work "correctly" until they experience sites that
use them "correctly." It is hard to justify implementing them on a site
until people know how to use them. At some point we have to draw the
line and start using new technologies and ideas. The conversion to CSS
websites has been slow, but it's coming around. Maybe the same will
happen with this type of menu... and maybe it won't.

All I'm saying is that we need to think forward and not just backward
when talking about accessibility.


--
Paul Bohman
Director of Training Products and Services
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu