***** From aardvark ***** but i also disagree with your statement that you can't design for everyone... in fact, you can, perhaps past the 99% mark... you aren't doing that, though *** From .jeff ***** what's the reason for the warning? what is so complex about the site that it's likely to explode in some ugly fashion for non-standards compliant browsers (which, if this happens btw, you've dropped the ball by not doing your best to prevent that)? The reason the site won't work properly is because of the integration of the JS with the objects in the site. When I refer to objects I mean a group of images, or divs etc which contain specific content, eg all images with "_Rll" as part of the source. When the site was being built I faced the difficulty that I wasn't going to be the only one updating the site. However, the other people likely to do that didn't know as much a I did. (you can see that I'm no expert myself!) So what I needed to do was create some simple rules which they could apply to changes to make sure everything worked properly. For example, to add a rollover image, all that needs to be done is add an image with _Rll in the source. The js then allocates the appropriate event listeners. So, anyone who doesn't understand all the ins and outs of HTML can use DW to add the image, type an alt, type the src (including the Rll) and that is it. No DW behaviours, and the code (hopefully) still validates. Before anyone points out that this is an internal benefit which doesn't do anything for the user and by doing it we have disadvantaged some users (those outside the specific target audience) - Yes, but only those who don't have ie5+ ns6+ and were not looking for the latest releases (which everyone can access from the text page). As .jeff, aardvark and jacob point out - it is possible to design cross browser code that does DHTML, but to get the internal benefit I needed to assign event listeners through the JS. If I'd allowed people to add them through DW behaviours, it would have been harder to maintain the integrity of the code. Given the browsers we were targetting for the main site, we then decided to use a multiple level menu - unfortunately because the font had to be "gill sans" which we could count on few people to have, we had to develop images for each option and get those to act as a drop down. So - upshot is - unless the browser supports adding event listeners through the DOM and it has JS enabled, none of the DHTML will work. In this circumstance we decided a redirect was appropriate. (The wording obviously needs to be carefully thought about :)) This is similar to deciding to use flash, or java applets for navigation and/or the content. Many of those sites have an effective redirect - see www.chromeglobal.com.au for an eg. In other words, you can't pass go until you get flash. Other sites designed for specific browsers (eg document.all) may or may not have a redirect, some have wording that says you need ie4 or whatever. From an accessibility point of view I understand aural browsers choke on nested tables. Shouldn't there be a warning for aural browsers if a site contains nested tables then? Being in Oz, its always interesting to hear the latest law suit stories from the US. If a designer knows that particular browsers or groups of users (blind, color blind, partially sighted) aren't catered for - doesn't he have a responsibility at least to warn those users from entering the site? (Note: designers may not want to do that, but if a client says - flash, they want flash. someone will do it.) So what I am asking is - when is a redirect appropriate? Mark Cheng Financial Controller Ranger Minerals Ltd Phone 08 9364 8355 This email may be confidential and contain commercially sensitive information. Only the intended recipient may access or use it. If you are not the intended recipient please delete this email and notify us promptly. We use virus scanning software but exclude all liability for viruses or similar in this email or any attachment.