第十六天：不要開出新視窗
幾乎每個網頁使用者都知道「上一頁」這個按鈕。這幾乎也是瀏覽網頁的必備動作了。連到某個鏈結，回到上一頁；瀏覽某個搜尋結果，然後回到上一頁。就連我老爸也知道可以這樣用，而他本人現在還因為第一次成功地在「 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 伎倆的情況下就保護妳的電子郵件地址免遭垃圾信發送機器人的攻擊。另一方面，有一些人會因為熟悉感、功能（像是內建拼字檢查）或能夠整理寄出的訊息等原因真的喜歡他們自己的電子郵件用戶端軟體；在這種情況下，我就不會建議妳考慮這種方法了。