E-mail List Archives
Thread: Re: Drop-down menus
Number of posts in this thread: 1 (In chronological order)
From: Terence de Giere
Date: Mon, Aug 04 2003 3:39PM
Subject: Re: Drop-down menus
No previous message | No next message
Joe
I have to admit that the Cascading Style Sheets (CSS) menus eliminate a
number of problems associated with scripted drop down menus, as you
pointed out:
* Uses no JavaScript and dead-simple HTML
* Works in every reasonably-modern browser
* Small codebase etc
Still, I think the actual implementations of this method are still a bit
immature. Mozilla/Netscape works fine. The positioning in Opera is a bit
askew. One of the samples you listed was very quirky in Opera.
Unfortunately I do not have the OSes to try Konqueror or Safari. Most
users will be using Internet Explorer, which does not support the method
at all as yet, so the drop down information would not be accessible to
most visual users, which is the point of these menus. Only a small
percentage of users can make use of them, namely the Mozilla/Netscape
group (which often includes me).
I think your analysis of the use of :hover and :focus needs to be
rethought. :focus is rendered rather differently in the current
implementations, and is the supposed device-independent analog of :hover
- it will work with the keyboard - keyboard and mouse should produce the
same effect when the item is highlighted either way. Since this
functionality is normally going to be used with links, the normal
behavior that users will expect is a single click of the mouse on a
link, or pressing the ENTER key will activate the link, and the main
link before the menu drops down should go to a page that has the same
links. If :hover and :focus are given different functionality, this will
go against user expectations.
The following is from the W3C document
http://www.w3.org/TR/css3-selectors/ :
-----
* The :hover pseudo-class applies while the user designates an element
(with some pointing device), but does not activate it. For example, a
visual user agent could apply this pseudo-class when the cursor (mouse
pointer) hovers over a box generated by the element. User agents not
supporting interactive media do not have to support this pseudo-class.
Some conforming user agents supporting interactive media may not be able
to support this pseudo-class (e.g., a pen device).
* The :active pseudo-class applies while an element is being activated
by the user. For example, between the times the user presses the mouse
button and releases it.
* The :focus pseudo-class applies while an element has the focus
(accepts keyboard or mouse events, or other forms of input).
-----
As for coordination problems, I agree, as long as the user can enlarge
the font size on the page, problems with dexterity and readability will
decrease, but they are not eliminated.
I have not tried these with a screen reader yet. Some readers behave and
speak differently when different reading or navigation modes are
activated. The example, http://www.serve.com/apg/workshop/cssMenu.html
you posted, with the addition of real links and a dummy page to go to
would do for some preliminary testing.
As for the consensus view that is has always been that drop-down menus
are generally not a good idea, I still think that is the consensus, and
there are obviously those in the full spectrum of views, such as yours,
that do not agree; they appear to be in the minority so far. A minority
might be 49 percent versus 51 percent of views. I do not think we need
to get into a discussion of what a consensus means, but I think it will
take more than one person to tip the scales. Clearly on the designers
side of the equation, drop-down menus might be the favored approach to
navigation.
The desire for drop-down menus that are accessible certainly seems to be
constant, or even increasing, so I doubt this discussion is going to
fade away. For me, the mechanisms of the CSS menus appear to be too
quirky for a good cross platform-browser implementation without the
addition of JavaScript at this time.
If a truly accessible dynamic menuing system beyond regular links are
desired, how do you think they might be implemented? One thing I would
like to see is some method that would allow assistive technology to be
able to replicate the behavior of expanding menus in some way so the
additional links would not be experienceable unless the user did
something, and then the user would get just the links associated with
that menu item, not none or all as is now the case. This would require a
specification that requires some specific programming for just this
functionality for all user agents to adopt, which is complicated by
screen readers which are ancillary to user agents. The question I am
posing is, would this be any better than just following regular links
page-to-page without dynamic menus?
Terence de Giere
= EMAIL ADDRESS REMOVED =
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/