顧客橫放或直放螢幕，都能完成同一項操作嗎？

由顧客要完成的工作入手

顧客常以直向手機瀏覽，但不能假設人人都能轉動裝置。平板可能固定在支架上，手機可能裝在輪椅，亦有人因身體狀況難以轉動設備。若網站要求顧客「請旋轉手機」才可看產品、預約或提交查詢，就把身體動作變成使用條件。WCAG 2.2 的 1.3.4 準則要求內容在直向與橫向均可觀看和操作，只有某一方向確屬必要時才有例外。一般網店及查詢流程應先以兩種方向都可完成工作為設計前提。

測試前先寫出顧客流程。例如買家尋找產品、選擇款式、閱讀送貨資料、核對總額，最後送出訂單；查詢者閱讀服務頁、填表、修正錯誤，再看到清楚確認。若頁面橫向可開啟，最後的提交鍵卻被遮住，顧客仍無法完成工作。兩個方向測試時，應使用相同入口、登入狀態、語言和測試資料，才不會把不同流程造成的差異誤判成方向問題。

這項準則並不要求橫向與直向每個像素都保持同一位置。響應式頁面可以把側欄移到文章下方，或將寬闊選單換成較精簡的控制項；重點是內容和操作仍可使用。方向問題是網站本身強制某一方向，或令另一方向無法使用。小畫面排版或重排失效也要修正，但問題紀錄應準確指出是方向鎖、版面缺陷，還是兩者同時存在，讓負責人知道要改甚麼。

交給開發人員的要求應說明預期行為，而非只指定某個斷點：兩種方向都要能到達訂單核對與提交步驟，驗證錯誤出現後亦一樣。具體版面可由實作團隊選擇，但完成後應請未參與設計的人重走流程。若新增供應商頁面或改動固定工具列，亦應重做這項檢查，避免舊版通過紀錄被誤用於新流程。

找出限制來自哪一層

明顯的方向鎖會把內容側轉、顯示「請旋轉裝置」的阻擋畫面，或不讓顧客繼續。較隱蔽的情況是全屏介面只按寬畫面設計，直向時操作鍵落在可見範圍以外；第三方結帳框架亦可能與網站其他部分表現不同。測試應走過接近實際的完整流程，包括付款交接、登入提示、對話框及錯誤狀態；只看首頁，很容易漏掉最影響顧客的限制。

先檢查瀏覽器和作業系統設定：使用者可能自行鎖定裝置方向。W3C 清楚區分使用者設定與網站作者強加的限制。若系統已鎖定橫向，而頁面跟隨橫向顯示，不能單憑這點指責網站。若裝置容許旋轉，網站仍堅持直向，便要檢查頁面、應用程式及第三方元件有沒有強制設定、阻擋層或令控制項無法到達的排版。請負責元件的人示範兩個方向的完整操作，而非只交一張截圖。

「必要」例外的範圍很窄。W3C 舉出的例子包括銀行支票或鋼琴應用程式，因為內容本身可能依賴特定方向。商品照橫向較好看、宣傳影片比例較合適，或表格直向較易開發，都是設計偏好，不能證明顧客必須轉動裝置。若團隊主張例外，應記錄具體功能、為何其意義或操作必須依賴該方向，以及周邊流程能否另行完成；最好請非開發該功能的同事質疑理由。

讓兩種方向都能完成工作

一般網站流程應移除阻擋訊息或強制轉動畫面，讓版面隨可用視窗調整。文字與控制項要有可伸縮空間、容許垂直捲動，關鍵步驟亦要維持可達次序。寬闊比較表可能需要可操作的橫向捲動區，或另設小畫面呈現方式；不應因此把整個購買流程鎖成橫向。對話框要能在視窗內顯示或捲動。若旋轉後固定在底部的工具列蓋住主要按鈕，就要修改排版或留白，並用鍵盤和觸控再次驗證。

以預約流程為例：日曆在橫向平板填滿畫面；直向時日期格仍看得到，但確認鍵落在固定高度面板外，面板也不能捲動。團隊或會想加上「請旋轉平板」提示，較好的修正是容許面板伸展或捲動，以精簡摘要顯示已選日期，並讓確認操作在閱讀次序上接續選擇步驟。測試時還要放入較長的服務名稱和錯誤訊息，因為實際文字會佔用空白原型未曾顯示的空間。

W3C 也記錄了一種做法：內容若原本限制方向，可提供讓使用者切換顯示方向的控制項。這可能適合真正特殊的體驗，但控制項必須在使用者被困住之前就找得到、用得到。對一般中小企網站，直接避免限制並尊重系統選擇通常較簡單。若切換鍵藏在方向阻擋畫面之後，便不能解決問題。另一種顯示方式也應保留相同資料、控制項、已填內容及結果，否則只是表面選擇。

驗收上線流程，而非只看設計稿

驗收時使用可旋轉的真實裝置，必要時再以瀏覽器模擬不同視窗形狀。先直向開始、流程中途旋轉並完成任務，再用新狀態由橫向重做。選單開啟時、表格已有資料時及錯誤出現後，都要試旋轉；檢查焦點有否消失、欄位會否意外清空，以及下一步是否清晰。英文和繁體中文版本要分別測試，較長標籤可暴露只在其中一種語言才會發生的擠壓。驗收紀錄要寫明裝置、瀏覽器、頁面形態、任務與實際觀察。

問題應按顧客後果處理，而不是只打美觀分數。若橫向限定畫面令使用固定裝置的顧客不能完成查詢，應指出受阻步驟並指定修正負責人；若兩個方向都可操作，只是裝飾照片裁切不同，優先次序便不一樣。通過方向測試不等於整個網站已無障礙，鍵盤、放大、重排、對比和錯誤提示仍須另行驗證。這次放行的具體問題是：在可用的兩個方向，顧客能否觀看並完成同一任務；例外是否真的由內容本質所需？

每個受阻步驟應留一行證據：顧客原本要做甚麼、當時的方向及頁面狀態、畫面顯示甚麼、哪個控制項無法到達，以及修正後的實際行為。這能把含糊的「做好響應式」變成可重現的驗收工作。測試要包括較窄的橫向視窗與直向平板，不只兩張常見手機截圖。若限制來自第三方結帳頁，就把同一組觀察步驟交給供應商，並追蹤真實付款交接；只改自家頁首的外觀，不能修好仍強迫顧客旋轉的付款頁。