第十六天：不要开出新视窗
几乎每个网页使用者都知道“上一页”这个按钮。这几乎也是浏览网页的必备动作了。连到某个链结，回到上一页；浏览某个搜寻结果，然后回到上一页。就连我老爸也知道可以这样用，而他本人现在还因为第一次成功地在“ Internet ”图示上双击成功而兴奋不已。
在所有的主流浏览器里，如果你用了 <a target="_blank"> 标签，就会强迫链结开出一个新视窗而让“上一页”按钮失效。这个新视窗不会保有前一个视窗的浏览历程，所以“上一页”按钮将会失去功效。即使是对有 10 年网页经验的我来说，这都会造成严重的混淆。在 2002 年的今天人们还会这样子用，实在是太不可思议了。别这样做。别强迫链结开启新视窗。
请注意这个诀窍是针对网页设计师所提出的，而非针对网页使用者。如果你想要在你浏览网页的时候开出新视窗，请用后述的方法。在 Windows 上的 Internet Explorer 里，按下链结时同时按住 Shift 键，就可以把连结开到新视窗去。在 Netscape 6 和 Mozilla 里的话，则是同时按住 Control 。在 Mac 上的 Internet Explorer 里则需要按住 Command 。（另外像是 Opera 的某些浏览器，还支援进阶组合键，像是 Control + Shift + 点选，这样会在背景开出连结的新视窗。）这里的重点在于是否要开出新视窗应该要由使用者来选择，而不是由网页设计师。
谁因此获益？
Jackie 从中获益了。虽然 JAWS 会在连结开出新视窗时唸出“ New browser window ”，但仍然容易在它唸出链结文字和新页面内容之间被漏掉。 Home Page Reader 提供了更好的解决方案：每当有新视窗开启时，它就会播放某个指定的声音。另外一个叫 Window Eyes 的荧幕朗读软体则完全不会提示有新视窗。
无论如何，“上一页”按钮就此烂掉。如果 Jackie 没有听到“ new browser window ”的话，就没办法瞥见工作列上开了两个浏览器视窗了。于是她就得去读整个已开启视窗清单；可能是透过 JAWS 指定的视窗清单快速键 INSERT+F10 或标准的 ALT+TAB 。
Lillian 从中获益了。因为她的 Internet Explorer 视窗总是最大化（这样她才看得见），所以新视窗开启的时候也会预设变成最大化。除此之外 Windows XP 还会把同一个应用程式的多个视窗群组整理在工作列上，所以在视觉上就更难发现有新视窗被开出来了。突然之间，“上一页”按钮莫名其妙地失效了，而 Lillian 完全不知道为什么会这样。如果你预期她会很高兴地阅读连结后的内容，倒是可以略过这个问题。
- Bill 从中获益了。他妹妹把 Mozilla 设定成多页浏览模式，所以 Bill 可以看到分页，然后很快地记住他开的是那个视窗，并且在那些分页间切换（在他灵巧华丽的延伸键盘上用 CTRL+PAGEUP 和 CTRL+PAGEDOWN ）。被强迫开出新视窗的连结会开出另外一个全新的 Mozilla 视窗。这不仅仅会推翻分页浏览的偏好，还会让所有已开启的视窗都不见；因为新的视窗上不会有任何前一个视窗的分页。
怎么做
- 不要用
<a target="_blank">来强迫连结开出新视窗。 - 如果你一定得要把某个连结开到新视窗，请务必明确地警告读者。这祇是个不理想的权变方案，通常是随着某些“不得与外部内容相关联”的商业政策而来的。举例来说， CNN 的“相关站台”页面就是这样。
- 如果你看到“在新视窗开启链结”的核选框，请确定它按照预设值而处于关闭的状态。
延伸阅读
- Jakob Nielsen: The Top Ten New Mistakes of Web Design. "#1: Breaking or Slowing Down the Back Button. #2: Opening New Browser Windows."
- W3C Web Accessibility Initiative: Example for Checkpoint 10.1 举例说明了当某个链结一定得开启新视窗时，你该如何警告使用者。
- W3C Validator mailing listl: Re: opening a link in a new window. 身为关心此类事情的人，你应该知道
<a>标签中的target属性是被反对使用的，而且会使得你的页面无法通过 HTML 4.01 Strict, XHTML 1.0 Strict 或任何未来版本的认证。 - WebAIM mailing list:
mailto:links open new windows. 这里提出mailto:链结并非亲和力障碍，因为这个行为完全可以由用户端判断。网页介面的电子邮件表单（像是 Radio 所用的）也许是提供亲和力的更完整解决方案。网页介面的表单可以无须整合电子邮件用户端就让访客使用（而且不会有组态不当或情境不允许等问题，像是实验室的公用电脑），同时也可以在不使用不亲和的 Javascript 伎俩的情况下就保护你的电子邮件地址免遭垃圾信发送机器人的攻击。另一方面，有一些人会因为熟悉感、功能（像是内建拼字检查）或能够整理寄出的讯息等原因真的喜欢他们自己的电子邮件用户端软体；在这种情况下，我就不会建议你考虑这种方法了。