W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2005

RE: Javascript question

From: John Carpenter <John.Carpenter@pdms.com>
Date: Fri, 7 Jan 2005 09:32:07 -0000
Message-ID: <C5B5C6910E1E014F9A91396FCDDABE26C97586@cs002.castletown.pdms.com>
To: <w3c-wai-ig@w3.org>

Thanks very much to all the responses I received to my email - I'm
really pleased that I found this mailing list and really grateful for
you all taking the time to reply.

> But first, it is possible for you to create the same effect 
> of the pop up submenus without requiring the user to use 
> javascript.  One method is to use CSS instead of javascript 
> like the suckerfish menus done in A List Apart: 

I had forgotten about this technique.  However, I feel - and I might
well be totally wrong here - that this technique may not be more
accessible than a Javascript version.  My reasons for thinking this are:

- The "hover" effect does not appear to have a keyboard alternative as
far as I can tell.  Therefore the menu will only work with the mouse.

- The actual effect is not as attractive - in IE6 the list apart demo
flickers very badly (although this may not be anything to do with the
technique used).  In Javascript menus there is usually a time delay
before the menu disappears.  I think the latter might be particularly
useful for someone using magnifying software.

- In the case of www.gov.im the popup content is generated by the
Javascript.  I'm not sure if this is the correct way of doing it, but it
means that the page weight is smaller and users with Javascript disabled
do not need to wait for a menu that they cannot use to be loaded.

- Someone with, for example, motor control issues may decide to disable
Javascript which would remove the menus completely, leaving the site
still usable and maintaining the layout of the page.  Whereas with CSS
menus someone would need to disable CSS entirely to see the menu.

I can't help but feel that the CSS way is getting around the checkpoint
rather than actually solving the problem that the checkpoint is trying
to address.  But, please someone correct me if I'm wrong - which is very
likely!

> Others use a 
> javascript dropdown system but set it up so users who do not 
> have javascript enabled browsers can still easily navigate 
> through the site.

This is what we've tried to do for the gov.im home page.  As John Foliot
pointed out, some links are missing from the main content page (thanks
by the way - just trying to find out what it should be and then will
have it fixed).

What I have been asked to investigate is allowing these popup menus to
be generated across the entire site.  This is something I would
personally prefer not to do as I don't think it will really add anything
to the site, but it's up to me to advise, not decide.  Anyway, in this
case, both Javascript and non-Javascript menus would be driven by a
single set of data from our database and therefore this problem would
not recur.

It sounds like if I can ensure that there is no discrepancy between the
two menus that we would be compliant with "8.1 Make programmatic
elements such as scripts and applets directly accessible or compatible
with assistive technologies".

> >  "3.4 Use relative rather than absolute units in markup language  
> > attribute values and style sheet property values."
> >  
> >  Are pixels classified as relative units?  (For menu width, not font
> >  size)

It sounds like this is a bit of a dodgy one!  :)  I guess part of the
problem is that if you have Javascript menus, it's important not to have
the menus fall off the end of the screen, and therefore pixel
measurements might make more sense.  I think browsers would increase the
width of the menu if the text required it (i.e. due to being resized).

It strikes me that for a site to declare itself compliant with a
particular level of WCAG it is only really a matter of its own opinion
and it isn't possible to get an official verdict.  Is that right?

Any more thoughts would be very gratefully received.

Thanks,

John
Received on Friday, 7 January 2005 09:32:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:19 GMT