Designer wrote: > Can we just step back a moment, and consider what we are doing. As I > write this reply, I am typing the content of this mail IN A NEW > WINDOW.[....] > Do those who proclaim annoyance at having 'new windows forced on them' > apply the same thinking to mail, Dreamweaver (and all the other > programs).
Okay, stepping back for a moment, I would first of all admit that I quoted somewhat selectively from the WCAG in order to make it seem like it was absolutely wrong to open up a new window when a person clicks on a link. In a more even-handed moment, I might have pointed out that the issue is not necessarily the opening up of a new window, but rather the *method* one uses for opening up a new window and whether one can make a user aware of what behaviour to expect when they click on a particular link. So although I would advise against it, it is nevertheless technically possible and within accepted web standards to code a link in such a way that it will open up a new window, provided that you notify your users that such behaviour will occur. Since we're looking at this from a "web standards" perspective, there are other web standards that come into play. For instance, although target="_blank" is regularly used to open a new window, I would argue that this code is actually part of the HTML code intended for use with FRAMES, and therefore, the use of this code to create pop-up windows in a non-frame environment is an abuse of the HTML code. In XHTML 1.1 Strict, of course, "target="_blank" has been removed entirely in order to make such use impossible if one wants to write valid XHTML code -- and I would suggest that part of the reason it has been removed is precisely because of the abuse of its intended use within a frames environment. There remains, however, the possibility of using JavaScript to create new windows. And I would admit that there are certain contexts when such usages are valuable for a user -- especially in those instances where a website is attempting to serve more like a web application than a static, information-only site. But whenever you use JavaScript to code some behaviour, you should from the very beginning be thinking about how you can emulate that behaviour in a non-JavaScript environment -- if only because a certain percentage of users will have JavaScript disabled. With the wildly popular use of AJAX and other scripting technologies to make web sites behave more like standalone programs, there is a temptation to compare the two and draw similarities between them. I would note however that there remain deep, structural and perceived differences between web-based "applications" and stand-alone "programs" that run on one or two operating systems. For instance, assistive technology like screen readers can tap directly into an operating system's API or interface so that when a modal/dialog box pops up it can always, without fail notify a user in the exact same way every time. By contrast, on the web, there are many different methods of simulating the opening up of such modal windows, and despite a decade of development, screen readers still cannot reliably communicate to their users when such pop-ups occur and how to navigate through them. If there were a web standard that required that all pop-up windows be created using the exact same specific coding method, then I am sure that screen reader software could be written to predict and communicate such activity. The challenge for those who create AJAX/dynamic-scripting web "applications", then, is to find ways of ensuring that those sites are usable by ALL users with CURRENT, or even somewhat-out-of-date, user agents (since users with disabilities in particular are often financially disadvantaged as well, and so are unable to purchase the latest versions of their preferred assistive technologies). With respect to the use of multiple windows and learned web behaviour generally, I think there is some confusion. Like you, I also use multiple windows when browsing the web, and they are an integral part of my web experience. My annoyance with links that are coded to always open up in a new window is that such coding actually gets in the way of my experience. My web browser allows me to choose whether I want to open a link in a new window or not. When someone codes a site so that those links are forced to open up in a new window, then it *breaks* my browsing experience. Some less experienced users may also get frustrated because such links *break* their "back" button: there is no way "back" when you open a new window -- you have to close the window in order to get "back". In general, this makes my browsing experience less predictable, and it discourages a user who knows exactly what they want and what the fastest way is for them to get it. The problem is not then with the use of multiple windows, but with the lack of predictability and control over those windows. In an operating system environment, I only have to learn about a handful of different programs and how they use "pop-up" windows or dialog boxes, and in almost every single case, those pop-up windows behave almost identically. By contrast, every single website I visit could have a different kind of pop-up window and I may or may not be able to use my TAB button to navigate it or be able to bookmark it or be able to do other web-like things to it. Although these windows may appear the same, then, they are actually very different. Phil. ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
