RE: DHTML drop down menus ADA compliant

I agree with the fact that the entire script itself is not fully accessible,
but the fact of the matter is that it can be used in an accessible website.
If the user is able to select the each of the menus (not the fly-outs) and
the menu is able to take them to another page that has all the options
available through the fly-outs...the page site is accessible.  Isn't it?

You can set up both the fireworks and opencube scripts so they can be used
without javascript...if you remember to link up each menu to another page
that has all the options of the fly-out.  And both scripts can be used in a
way that the site is completely inaccessible if you don't touch the html
after you follow the regular directions.

The script simply provides a shortcut to 3rd level pages for those who have
JavaScript enabled.  A site can be accessible with inaccessible scripts as
long as the user is able to get to the content without using the script.  

Am I wrong for saying this? 

Just curious.

::  Juan C. Ulloa |   x2487 
 
 

> -----Original Message-----
> From: Mirabella, Mathew J [mailto:Mathew.Mirabella@team.telstra.com]
> Sent: Wednesday, January 14, 2004 2:45 PM
> To: w3c-wai-ig list
> Subject: RE: DHTML drop down menus ADA compliant
> 
> 
> All.
> 
> I have looked at the Open Cube menus and they do not seem to be very
> accessible at all.  They are quite cross browser compatible, but they are
> not, for example, screen reader accessible.  The Macromedia menus are
> somewhat better in this respect, but there is a requirement for the latest
> version of FLASH and the latest Jaws etc.  I am not sure how they work
> with the Linux text environment using emacspeak etc.  However, my main
> concern is the inaccessibility of DHTML menus.
> 
> I understand that accessibility can be somewhat achieved for DHTML menus
> if:
> 1.  The menus themselves (not the flyouts) are generated as normal html
> with standard <a> elements to form links, potentially with onClick but
> also with keyboard events if JavaScript is to be used at all here.
> 2.  The flyout parts of the menus may need to be generated with
> JavaScript, but the flyout functionality should not be dependent on
> mouseOver or some specific device dependent event.  I.E. while mouseOver
> could be used, there must be other ways to get the menu to fly out (i.e.
> using the keyboard).
> 3.  The menus themselves (not the flyout parts) should be selectable to
> load up a page which contains a set of static links (possibly in an
> unordered hierarchy list) which provides hyperlink access to the menu
> items.  I.e. an alternative navigation structure.
> 4.  There may also be a menu-map option which brings up a page with a
> complete list of all the menus and their sub items etc in a hierarchy list
> in the same way as for the single menus.  This is like a site map, but is
> just a map of the menu functionality.
> 5.  All presentational elements should be done with css.  All menus should
> be coded as unordered lists with sub lists for submenus and the way in
> which they are displayed controlled by css (and JavaScript where
> required).
> 
> 1, 3, 4 and 5 should mostly be available with JavaScript turned off or not
> supported.  SO 2 (the flyout itself) is the only thing that "requires"
> JavaScript, but the content is still available without it.
> 
> I have seen a lot of menus on the web that cover all the issues above,
> except for 2 - the flyouts.  I have not seen an example on the web where
> the flyouts themselves have been made to be device independent and screen
> reader accessible.  While this does not mean that users don't have access
> to all of the content (by virtue of 1, 3, 4 and 5), it does mean that the
> "menus (flyouts)" are inaccessible themselves as they cannot be fully
> operated by the screen reader user.
> 
> While screen reader and keyboard access is not the only issue of concern,
> it is a good test of the accessibility of features such as menus which are
> traditionally mouse driven.
> 
> So can anyone provide an example of a menu system in DHTML that is
> accessible to the keyboard, to screen readers, compliant to the WCAG (as
> much as possible) and where the menus themselves are operable by the
> screen reader / keyboard (non-mouse) technology?
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Jim Ley [mailto:jim@jibbering.com]
> > Sent: Thursday, January 15, 2004 7:03 AM
> > To: w3c-wai-ig@w3.org
> > Subject: Re: DHTML drop down menus ADA compliant
> >
> >
> >
> > "Juan Ulloa" <julloa@bcc.ctc.edu>
> > > You can have a website with DHTML dropdown menus that is
> > accessible.  Some
> > > things you need to keep in mind are.
> > > The menu's (not the dropdowns) themselves cannot be generated by
> > javascript.
> >
> > The menus could be generated by javascript but it may well
> > not be the most
> > efficient (they could rewrite links from another place on the
> > page, perhaps
> > moving the dynamic menus to a different logical position, or
> > just adding
> > extra navigation to the partial navigation in the document -
> > for example
> > adding links to sub-topics instead of just topics.
> >
> > > And if javascript is turned off, you should be able to
> > click on the menu
> > > item and allow you to go to webpage that has the options
> > listed on the
> > > dropdown.
> >
> > I'm slightly concerned by your description here, it seems a
> > rather narrow
> > restriction on alternative mechanisms for providing the same
> > functionality
> > to the user.  My concern is generally more about keyboard and
> > voice browser
> > access to the menus in an accessible manner (ie can you tab
> > to each menu
> > item in a sensible order, and does the voice browser render the links
> > distinct enough and in a sensible order.)
> >
> > > Two dropdown menu scripts that can be used in an accessible
> > website are:
> > the
> > > one generated by Macromedia Fireworks and the one created
> > by Opencube.com
> >
> > I'd be interested in the definition of accessible in the
> > cases of the above
> > 2 menus, neither (unless they have been consideralby improved
> > in recent
> > times) would be considered accessible by me.
> >
> > Jim.
> >
> >
> >

Received on Thursday, 15 January 2004 10:46:05 UTC