顧客密碼欄應否提供顯示與隱藏按鈕？

先判斷顧客需要甚麼

密碼欄預設遮蔽文字，可以減少旁人在共用空間偷看到內容；但顧客輸入錯字時，也較難自行發現。提供顯示按鈕，讓顧客在需要核對時主動選擇，才是這個功能的目的。它應屬登入及建立密碼流程的一部分，不只是裝飾性的眼睛圖示。團隊要確認顧客能顯示已輸入內容、再次隱藏，而且過程中不會清空欄位。英國政府設計系統建議密碼預設隱藏，再由使用者決定是否顯示。香港網站也應按目前頁面語言寫清楚按鈕動作，避免只靠圖案猜測。

可用一個具體情況檢驗設計：顧客從密碼管理工具貼上一段長密碼，登入失敗後懷疑多貼了一個空格。他應可直接檢查原本欄位，毋須轉到另一個畫面，也毋須再複製一次密碼。另一位顧客可能坐在擠迫的車廂，全程都想維持遮蔽。只要顯示功能由顧客自行啟用，而且可以立即還原，兩種需要便能兼顧。不能因為加入顯示功能，就要求逐字手打、禁止貼上，或把正常密碼欄改成奇怪的分段輸入。

把圖案變成清楚的操作

密碼欄旁邊應有真正可操作的按鈕，名稱直接說明下一步，例如「顯示密碼」；顯示後改為「隱藏密碼」。按鈕本身不應意外提交整份表格。密碼欄仍須有可見標籤，而按鈕要明確對應該欄位。眼睛圖案可輔助辨認，卻不應成為唯一說明。英語與繁體中文版本都要在切換前後實際測試：名稱究竟是描述目前狀態，還是描述按下後會發生的事？若兩者混淆，顧客可能在公開場所誤把密碼打開。

切換顯示狀態時，要保留原有輸入值及顧客的操作位置。若每按一次便重建整個欄位，游標、焦點、自動填入、錯誤提示和讀屏器所理解的欄位關係都可能受影響。測試時可把游標放在示例密碼中間，來回切換，再檢查字元是否完整、是否仍可繼續修改。密碼管理工具填入內容後，以及表格出錯後，也要重試。若畫面同時有現有密碼與新密碼，兩個按鈕必須分別指明對應欄位；重複兩個籠統的「顯示」容易令顧客開錯內容。

保持原有密碼流程可靠

頁面初次載入時，欄位應保持一般密碼輸入用途。登入時使用適當的現有密碼自動填入提示；建立或更改密碼時則標示新密碼用途。英國政府設計系統與 W3C 的指引都說明，清楚標記的欄位有助瀏覽器及密碼管理工具辨認。複製和貼上也應繼續可用，因為有些顧客使用獨立的密碼管理工具，必須從剪貼簿轉入內容。禁止貼上會增加記憶及抄寫負擔。顯示按鈕只是輔助檢查，不能取代正常的密碼欄；若腳本失效，基本的遮蔽欄位與提交流程仍應可理解。

顯示出來的密碼仍然是秘密。切換必須由顧客主動觸發，而且只影響他選定的欄位。不要把密碼寫入日誌、分析事件或錯誤訊息，也不要複製到另一塊提示區。英國政府的元件指引亦建議，提交表格時若密碼仍在顯示，應把欄位類型改回密碼，以免瀏覽器日後把它當作普通文字處理。顯示按鈕只協助使用者核對輸入，不能當成帳戶安全保證；登入驗證、傳輸及伺服器處理另有責任。在多人看得到螢幕的場所，是否顯示應由顧客自行決定。

處理錯誤時避免額外洩露

至少要分開測試兩類錯誤。欄位留空時，可直接提示顧客輸入密碼；若登入憑證不正確，則不宜透露究竟是帳戶名稱還是密碼錯誤。英國政府指引指出，這類細節可能協助攻擊者，其示例亦會在登入失敗後清除已輸入密碼。顧客下次嘗試時仍可使用顯示按鈕。欄位標籤、錯誤說明與按鈕名稱要各司其職，避免讀屏器連續讀出一串難以理解的詞。決定失敗後如何重設按鈕前，應分別測試原本隱藏及暫時顯示的情況。

顯示功能可以減少部分輸入錯誤，卻不代表網站可以暗中截短密碼或改動字元。英國政府指引提醒，若用最大長度屬性直接限制，貼上或自動填入的內容可能被截掉而沒有清楚提示。若系統確有技術限制，建立密碼和日後登入時都要一致說明，超出限制亦須有明確錯誤訊息。顯示密碼時，不應啟用自動大寫或拼字修正；顧客看到的內容應與系統提交的一樣。手機瀏覽器可能自帶顯示功能，也要檢查會否與網站按鈕重複或出現狀態不一致。

測試完整顧客路徑

驗收時先完全不用滑鼠，透過鍵盤切到密碼欄，輸入無害的測試字串，再切到顯示按鈕，啟用、隱藏及提交。焦點順序要合理，按鈕不能變成表格提交鍵。再用讀屏器確認欄位名稱清楚，而且切換後讀出的按鈕動作會跟著更新。有語音輸入使用者時，也要獨立測試該操作。繁體中文版本應實際聆聽畫面上的名稱，不能只看翻譯表格。驗收重點是顧客在輸入當下能否作出清楚選擇，而不只是程式碼裡有一個按鈕。

同一套測試應涵蓋自動填入、貼上及登入失敗。建立或更改密碼時，試用密碼管理工具產生的值，確認切換顯示不妨礙儲存；登入時則用既有憑證，確認自動填入提示指向正確用途。失敗後檢查頁面文字、開發者訊息及客服紀錄，不能出現原密碼。再以窄螢幕模擬公共場所使用：顧客能否找到按鈕，又能否迅速重新隱藏？若有兩個密碼欄，逐一確認按鈕只影響自己的欄位。遇到瀏覽器自帶按鈕與網站按鈕重疊，要記下實際裝置與情況，安排修正。

決定交付標準

小團隊可用一份簡短的驗收紀錄作交付決定：預設遮蔽、清楚標記且可還原的按鈕、完整保留輸入值及焦點、可貼上及自動填入，以及不洩露內容的錯誤狀態。這些檢查比爭論眼睛圖示是否熟悉更實際。紀錄中應列明英語和繁體中文按鈕文字、測試過的瀏覽器及輔助科技、仍待處理的狀態不一致問題。若實作無法穩定保留密碼，或按鈕名稱不能正確更新，就應先修好。顧客不應為了核對輸入而犧牲可靠的登入流程。

還有一種容易漏掉的情況：顧客先在私人電腦使用網站，之後轉到共用手機。顯示密碼應是當下選擇，不宜成為跨裝置保存的帳戶偏好；手機初次開啟時仍應遮蔽。重新載入頁面或完成登入後，按鈕亦應回到預設狀態。若程式在切換頁面時沒有移除原畫面，要檢查顧客返回後會否再次看到早前顯示的密碼。這項審閱關乎旁人實際能看到甚麼，不能只看最初 HTML 寫了哪種欄位類型。可用無害測試憑證，試離開頁面、返回、旋轉手機及重新打開分頁。

交接給下一位開發者時，實作備註應具體列明：哪個元件持有密碼值、哪個按鈕切換顯示、按鈕名稱如何更新，以及提交或出錯時怎樣處理。只截取預設遮蔽畫面並不足夠，因為風險常在使用者互動之後才出現。若內部流程容許，可保存測試環境中的簡短操作紀錄或文字步驟，但不得錄下真實密碼。日後更換登入元件時，也要重新檢查密碼管理工具及瀏覽器自帶顯示功能在不同裝置上的表現。交付決定應根據整段流程的實測結果，不應宣稱這個設計可以防止所有憑證外洩。