- From: John Carpenter <John.Carpenter@pdms.com>
- Date: Fri, 7 Jan 2005 09:32:07 -0000
- 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 UTC