iPhone Duo 無障礙測試怎麼做？2026 相容 iPhone 18 Pro 驗收清單

表單填到一半，裝置展開後 VoiceOver 跳回頁首，已輸入內容和提交按鈕也找不到，這不是「App 沒有閃退」就能算通過的無障礙驗收。

最快解法：先用 iPhone 18 Pro 驗證兩款裝置共用的核心任務，再在 iPhone Duo 加做內外螢幕切換、焦點連續性與狀態恢復；涉及交易、身份驗證或關鍵表單的流程，最後必須保留真機人工證據。

判斷：適合採用雙層驗收，不適合一開始窮舉所有輔助功能與裝置狀態。 這樣可以先處理共通缺陷，再把 iPhone Duo 真正新增的風險集中到真機測試。

這份 iPhone Duo 無障礙測試清單適合誰

通用 App 團隊可以用它建立兩款裝置共享的最低無障礙基線；金融、醫療、政企團隊則應把不可失敗的交易、身份驗證和審計證據另外列出。

QA 團隊可將人工檢查、Accessibility Inspector、XCTest 自動化回歸與真機操作分層安排，而不是把所有頁面都交給其中一種工具。

本文以 2026 年 9 月 17 日 的資料邊界整理；最後更新於 2026 年 9 月 17 日，資料核實自 Apple 的 iPhone Duo 開發資料、Apple 無障礙測試文件 與 Human Interface Guidelines 無障礙指南。iPhone Duo 已有官方開發與自適應布局資料，但各輔助技術在不同狀態下的實際表現，仍應以可用 SDK、模擬工具和真機結果為準。

先把兩款裝置的驗收邊界分開

我們會把測試拆成兩條軸線，而不是把 iPhone Duo 當成一部「較大的 iPhone 18 Pro」。

iPhone 18 Pro 的共同基線

• 動態字體放大後，標題、輸入欄、錯誤訊息和主要按鈕仍可理解。
• 粗體文字和按鈕形狀開啟後，控制項仍具有清楚的可見差異。
• VoiceOver 能按照合理順序讀出標籤、狀態、提示和操作結果。
• Voice Control、外接鍵盤與 Switch Control 可以到達登入、提交、購買、確認和退出等核心控制項。
• 表單輸入、列表選擇、錯誤修正和返回上一層時，任務不會因焦點或狀態問題中斷。

iPhone Duo 的追加驗收

• 裝置合起、展開或顯示尺寸改變後，焦點是否仍留在目前任務位置。
• 隱藏或移動的元件是否仍被 VoiceOver 讀取。
• 彈窗、導航層級、列表游標和輸入內容是否能在顯示切換後恢復。
• 內螢幕與外螢幕是否都能完成同一項核心任務，而不是只有其中一個狀態可用。

Apple 的 iPhone Duo 開發資料可作為布局和顯示狀態的設計依據，但不能替代對實際 VoiceOver 焦點的觀察。尤其是展開後元件重排、容器重建或導航堆疊改變的情況，團隊不能從普通 iPhone 經驗直接推定結果。

文字放大後，先驗收「操作能否完成」

動態字體問題通常不是單純的截字。真正嚴重的情況是主要按鈕被推到不可達位置、錯誤訊息與輸入欄失去關聯，或確認操作在螢幕上仍存在但無法被輔助技術找到。

我們會按以下順序測試：

1. 在 iPhone 18 Pro 開啟較大的文字尺寸，重新執行登入、編輯、結算和退出。
2. 開啟粗體文字與按鈕形狀，檢查按鈕標籤、邊界和狀態是否仍能辨識。
3. 在 iPhone Duo 外螢幕完成同一流程，再於內螢幕重新執行。
4. 將文字放大與螢幕切換疊加，觀察主要操作是否被截斷、遮蔽或推入不可滾動區域。
5. 對每一個失敗點記錄操作前狀態、操作後畫面、VoiceOver 讀取結果和構建號。

Apple 的 Dynamic Type 與排版指南 可用來核對文字縮放和排版方向，但驗收標準仍應回到任務結果：是否能提交表單、完成購買、確認選擇和安全退出，而不是只看畫面是否「大致整齊」。

內外螢幕切換時，焦點與狀態要分開觀察

焦點中斷和資料遺失經常同時出現，但它們不是同一個缺陷。VoiceOver 可能仍然有焦點，卻讀到錯誤的元件；表單內容可能仍在記憶體中，卻沒有可操作的控制項可以回到該位置。

我們會把每次切換拆成三個觀察點：

• 焦點位置：是否回到頁首、落在已隱藏的控制項，或跳到與目前任務無關的容器。
• 上下文連續性：回到列表時是否保留目前項目、篩選條件和導航層級；開啟彈窗後是否能返回觸發它的控制項。
• 任務資料：輸入文字、選中項目、錯誤提示和媒體播放位置是否保持一致。

Apple 對 布局變化通知的說明 可協助開發者理解布局更新後如何通知輔助技術，但通知本身不代表焦點一定落在正確位置。模擬器和自動化工具能提前揭露元素層級或狀態管理問題，最終焦點行為仍應由真人在 iPhone Duo 上以 VoiceOver 操作確認。

輔助輸入要以真實任務排優先級

不必機械遍歷所有頁面，也不要只檢查控制項是否存在。我們會先選出三個不可失敗任務，例如登入、結算和編輯，再為每個任務測試以下輸入方式：

• Voice Control 能否以穩定名稱找到並啟動主要按鈕。
• 外接鍵盤能否按照合理順序進入輸入欄、選擇項目和提交表單。
• Switch Control 是否能循序到達核心控制項，並提供清楚的選取或完成回饋。
• 介面是否仍依賴拖曳、懸停、雙指精細手勢或只有視覺使用者才理解的狀態。
• 控制項的標籤、順序、焦點外觀和操作結果是否前後一致。

Apple 的鍵盤互動指南 可作為外接鍵盤檢查的參考。對企業 App 而言，最重要的不是宣稱支援多少種輔助輸入，而是讓真實使用者在核心任務中不必改用未文件化的手勢或尋求人工代辦。

用三層流程縮減雙機回歸容量

測試矩陣過大時，直接增加 Mac 或遠端執行緒只能緩解構建與並發排隊，不能代替輔助技術使用者的人工驗收。我們建議分成以下三層：

第一層：靜態檢查

檢查標籤、特徵、可操作狀態、文字縮放約束、鍵盤順序和布局容器。這一層適合在提交變更時執行，目標是盡早阻止明顯結構缺陷進入回歸佇列。

第二層：模擬器與自動化回歸

用固定的核心任務驗證導航、輸入、錯誤處理、狀態保存和返回流程。XCTest 文件 可作為自動化測試的技術依據，但測試通過只代表腳本走完預期步驟，不代表 VoiceOver 使用者能理解每個狀態。

第三層：真機人工驗收

在 iPhone 18 Pro 先跑共同基線，再在 iPhone Duo 執行內外螢幕切換。身份驗證、交易、不可重做的表單和播放進度必須保留操作錄影、裝置狀態、系統版本、構建號與缺陷重現步驟。

如果目前環境出現構建排隊、模擬器不足或遠端協作互相等待，應先計算每次版本需要占用的構建與測試時段，再決定是否建立獨立驗證通道或臨時雲端 Mac 環境。擴容解決的是等待時間，不會自動產生無障礙合格證據。

發布前可直接勾選的驗收清單

• [ ] 已選定三個不可失敗的使用者任務，並寫明成功條件。
• [ ] 已在 iPhone 18 Pro 驗證動態字體、粗體文字和按鈕形狀。
• [ ] 已檢查表單提交、購買、確認、錯誤修正和退出不會因文字放大而不可達。
• [ ] 已在 iPhone 18 Pro 以 VoiceOver 完成共同核心流程。
• [ ] 已在 iPhone Duo 外螢幕和內螢幕各執行一次核心流程。
• [ ] 已在展開、合起或尺寸變化後記錄 VoiceOver 的焦點位置。
• [ ] 已確認焦點沒有落在隱藏元件，也沒有無故跳回頁首。
• [ ] 已核對輸入內容、選中項目、錯誤提示和媒體位置是否保留。
• [ ] 已以 Voice Control、外接鍵盤或 Switch Control 測試核心控制項。
• [ ] 已將靜態檢查、自動化回歸和真人操作的證據分開保存。
• [ ] 已記錄裝置狀態、系統版本、構建號、測試時間和重現步驟。
• [ ] 已將缺陷分為阻斷核心任務、明顯降低可用性和一般視覺瑕疵三類。
• [ ] 阻斷項已在發布前關閉；未關閉項目已有降級方式、負責人和復核版本。

用發布門檻判定「可交付」而不是「沒有閃退」

阻斷核心任務包括無法登入、無法提交交易、無法完成身份驗證、焦點進入不可見區域，或切換螢幕後輸入內容無法恢復。這類問題必須在發布前關閉。

明顯降低可用性包括標籤不穩定、列表位置丟失、錯誤提示無法讀取、外接鍵盤無法到達主要操作。若因版本時程無法修正，必須留下明確降級方式、負責人和指定復核版本。

一般視覺瑕疵則可能是間距、裝飾或非核心畫面在放大文字後不理想，但仍要確認它不會遮蔽操作、不會改變閱讀順序，也不會讓輔助技術誤判控制項狀態。

Apple Accessibility Inspector 官方文件 適合用來發現屬性、標籤與層級問題；它不能取代人工 VoiceOver、輔助輸入和任務連續性測試。這個界線應寫進團隊的發布規範，避免把「檢查器沒有報錯」誤當成「使用者可以完成任務」。

常見決策的實際答案

不需要每次回歸都使用兩款真機，也不需要把所有輔助功能和顯示狀態做成完整排列組合。共同問題先在 iPhone 18 Pro 固定驗證；只有涉及 iPhone Duo 的內外螢幕差異、布局重排、焦點重新定位和任務恢復，才加入追加真機案例。

同樣地，Accessibility Inspector 不能替代真人 VoiceOver。它可以降低早期檢查成本，卻無法回答「使用者是否知道自己目前在哪一層」、「是否能找回剛才輸入的位置」和「錯誤提示是否足以支援下一步操作」。

若 iPhone Duo 的特定輔助技術行為尚未被 SDK、模擬工具或真機確認，驗收紀錄應寫成「待驗證」或「目前觀察結果」，不要把普通 iPhone 的經驗寫成正式相容性承諾。

目前方案與 Mac 驗證環境的取捨

只依賴現有本機環境，常見缺點是構建與人工驗收互相搶占時段、模擬器回歸和真機操作難以並行，以及遠端團隊無法在同一個版本上重現焦點與狀態問題。只增加機器數量也有局限：它能處理並發和排隊，卻不能替代真人使用 VoiceOver、Voice Control 或 Switch Control。

因此，若團隊只是偶爾驗證一個版本，本機或既有雲端流程可能已經足夠；若需要在短期內完成 iPhone 18 Pro 共同基線、iPhone Duo 內外螢幕測試和跨角色複核，租用 zekmac 的 Mac 環境通常比臨時採購、配置並維護一套專用 Mac 更容易控管。它不會自動讓 App 通過無障礙驗收，但可以把構建、模擬器和遠端協作的等待問題從真人驗收時段中移開。

對長期穩定重負載、需要固定實體周邊或必須持有專用測試裝置的團隊，自購 Mac 仍可能更合適；若只是臨時版本驗收、短期擴充並行能力或需要隔離驗證環境，zekmac 的租用方式則更貼近這類交付節奏。