CSS Menus

For some reason, Dave Shea's posting to this list hasn't shown up on 
the Web site, so I'll forward it now. Contact him at the usual 
coordinates (dave at mezzoblue dot com).

>  > I am certainly aware that these css techniques have been
>>  around... they are not really new and daring.  However,
>>  there still does not seem to be a satisfactory example of
>>  these dynamic menus being accessible to most browsers and
>>  most adaptive technology.  e.g. they don't seem to work with
>>  Jaws in a satisfactory way and the css versions don't work
>>  with IE in a satisfactory way.  Many of the issues are to do
>>  with browser support of css etc.
>
>To view this new generation of CSS-based menus in a proper 
>historical context, you'll want to do a quick Google for 'DHTML 
>menus' and view the code that's been used previously, and even now 
>in 2004. Not only would menu items have been scripted, the actual 
>links would be buried deep within scripts that have no chance of 
>running on anything but IE and/or Netscape. 'Hiermenus' is one of 
>the more popular variations, though it's heavily licensed (as 
>ridiculous as that sounds).
>
>Go back to the link Joe posted -- http://www.clagnut.com/blog/277/
>Richard Rutter's menus are the best of our collective knowledge at 
>this point. They'll be the touchstone for the rest of this reply.
>
>>  That is, user agent developers, adaptive technology
>>  developers, and the w3c specifications for technologies
>>  and accessibility of these technologies need to be moving
>>  in the same direction at much the same pace.
>
>This is the way *everything* should work. But it doesn't, so let's 
>talk about the issue at hand.
>
>>  So can you provide an example on the web (or one you have
>>  coded yourself) of a set of dynamic flyout navigation menus
>>  that do all of the following:
>
>These don't exist. There are no flyout menus that do everything 
>you've requested.
>
>But let's explore what the new crop of CSS-based menus CAN do:
>
>>  1.  Supported in full by most of the recent browsers.  (Must
>>  work in at least IE and Netscape).
>
>Why Netscape? Netscape is dead. What you meant was, must work in at 
>least modern, standards-capable browsers. That list includes 
>Mozilla, Safari, Opera, and even Netscape.
>
>Richard's menus do this. The better of the old-school DHTML menus do this.
>
>>  2.  Work with most adaptive technology.  (Must at least work
>>  with Jaws and Window-Eyes and the screen enlargers)
>
>Richard's menus are unproven yet. Us web developers would love 
>access to people who can test our concepts for cases like this, but 
>we frequently have a hard time finding them. The DHTML menus don't 
>have a chance.
>
>>  3.  Use css as much as possible with JavaScript only used where
>>  absolutely necessary (hopefully not at all).
>
>Richard's menus do this. It's fully possible to build a similar menu 
>system using CSS only, but IE does not support it so it's a futile 
>endeavour at this moment in time. The DHTML menus don't have a 
>chance.
>
>>  4.  Graceful transformations into lists etc. where the
>>  browser does not or is set not to support scripts and/or css.
>
>Richard's menus do this. The DHTML menus don't have a chance.
>
>>  5.  Good colour contrast etc, and fully customisable by css
>>  etc.
>>  6.  Works well with various screen resolutions and fonts and
>>  sizes, etc.
>
>Richard's menus do this. The DHTML menus offer customization, but 
>nine times out of ten it's not through CSS. They can work across 
>different resolutions and font sizes.
>
>>  7.  Device independent in as much as the keyboard can be used
>>  alone to navigate the menus, (this is with or without a screen
>>  reader active).  So it may need to use a set of keyboard
>>  shortcuts etc.
>
>Richard's menus do this to a certain degree. It's been mentioned 
>that Safari has issues, but this is more a design flaw in Safari's 
>handling of keyboard events than anything to do with the menus. The 
>DHTML menus don't have a chance.
>
>>  8.  Has redundant pages of links accessed from the menu
>>  itself (as we have discussed on list recently).
>
>If I understand what you're requiring here, this is independent of 
>the menuing system, and purely a best practice for the document 
>author.
>
>So in summary, counting the various 'almosts' as halves, that's a 
>score of 5.5/7 (disregarding point 8) for Richard's, and 1.5 or 2/7 
>for the DHTML menus. Clearly we're on the right path.
>
>>  It is worth noting that many of the recent examples I have seen
>>  on this mailing list cover the vast majority of these points quite
>>  well.  It is just one or two that seem to be missing in each example.
>>  I admit that one of the problem issues is IE support of hover on
>>  other elements...
>
>Well, then the question is where's the middle ground? Page authors 
>are doing are best to be responsible, given the tools at our 
>disposal, but they need to get their job done.
>
>Where did you get the list of requirements from, Mathew? If some 
>menu systems fall short, maybe the problem isn't the menu systems 
>themselves, maybe the requirements expect too much out of today's 
>technology.
>
>d.

Received on Tuesday, 20 January 2004 13:27:48 UTC