On Spawned Windows

Inform users when new browser windows will be opened. For example, include "link opens new window" with the link that opens the new window.

This page covers:

• WCAG 1.0, Checkpoint 10.1 is an accessibility guideline covering spawned windows
• Accessibility and usability issues describes some of the problems that people have with spawned browser windows
• Accessibility solution options describes several different ways to meet the guideline to inform users of spawned windows
• Usability guidelines are recommendations to improve the usability of spawned windows for all users, with and without disabilities
• Related issues lists other things to address when considering using spawned windows

Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]

Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/WCAG/)

Usability studies show that novice users (including those without disabilities) often do not understand the concept of stacked windows and think only one window is open at a time. They can be confused with multiple windows. Another potential problem is that opening new windows "breaks" the browser's Back button, or previous page functionality.

Many browser provide functionality for users to open links in new windows themselves. For example, in Internet Explorer, if you right mouce click on a link, you can select "Open in New Window" from the pop-up menu. This option is also "broken" by some ways of making the link open a new browser window.

Sometimes when a new window is opened, the user will look at the new window, and then go back to the first window without closing the second. The first window then sends new information to the second window but the user does not see the update because the second window doesn't get focus if it's already created. In such a case, the user will often think the site is broken.

Screen reader issues

While most screen readers will automatically shift focus to a new window, they don't inform the user that the window changed. Therefore, non-visual users may not know that a new window was opened. This can lead to significant confusion, and render the web site unusable.

In certain situations, there are good reasons to open new browser windows, such as providing related information without interrupting workflow. As an example, consider a multi-step registration process. The user may decide during the process to view the privacy policy. Opening the privacy policy in a new window lets the user see the policy without interrupting the sequence of steps in the registration process, or losing already entered data. It also makes it possible to more efficiently serve up content that does not need to be encrypted - the registration process can be in a secure window, while the privacy policy can appear in a second, non-secure window that draws content from a different server.

Checkpoint 10.1 does not prohibit spawned windows; rather, it requires that users be informed of them. There are several options for informing users of spawned windows.

One option for informing the user of a new window is to inform them with the action that opens the new window, with either text or an icon with ALT text.

• Text with link option:
  Help (link opens new browser window)
• Icon with ALT text example:
  Help

While the options shown above have the advantage of informing the user before the action is taken, both add a bit of visual clutter to the rendered page.

Another option is to inform the user in the spawned window itself and in any instructions or site help.

1. In the new window itself, include a notice that it is a new window. For example, at the top of the window, display the text "This is a new browser window" in the spawned window itself. More elegant, although less explicit, is to provide a way to close the window, for example:
   Close Help window, return to Order Form
2. Inform the user up front by including an explanation of the use of spawned windows in any instructions, such as those given when the user signs up for a service. Include in any tips for screen reader users.

There are good reasons to use spawned windows, such as to provide help for a form without losing data and context. However, because of the drawbacks to spawned windows (addressed in Accessibility and Usability Issues above), they should be used only when there is a compelling reason that outweighs the disadvantages.

In cases where a spawned window is warrented, there are several things that you can do to help users recognize that it is a new browser window. Pop-up dialog boxes are familiar to graphical user interface users, and this metaphor can be uses

• Inform the user of the new window, as addressed in Accessibility solution options above
• Size and position the window based on primary window content and interaction, and new window content. In most cases, open the window in the middle of the screen and size it to as small as needed to display the content in common configurations. (Leave browser features, letting the user re-size the text and the window, for example, in case they have low vision.)
• Include a Close Window button. While the window can be closed by other means, the close button is a subtle reinforcement that it is a new, secondary window.

Other considerations (that is, potential usability and accessibility problems) related to spawned windows include:

• Using JavaScript (rather than HTML) to open the new window
• Hiding browser menus and toolbars
• Disabling window scrolling and sizing