專案已經加入 VoiceOver 修飾符，但購買流程中的自訂控制項仍然無法操作。

最快的處理方式是：不要按照程式碼中用了哪些無障礙 API 直接勾選標籤；只有使用者能借助對應功能完成登入、購買、設定與核心業務等常用任務，才可在 Accessibility Nutrition Labels 填寫時申報支援。未完成驗證的能力先保持未申報，並建立按裝置家族區分的測試矩陣。

這篇文章適合準備首次填寫 Accessibility Nutrition Labels、但不確定 Apple 判定標準的獨立開發者；也適合維護 iPhone、iPad 或 Mac 多端 App、需要分別驗證無障礙支援的小團隊。若本地 Mac 無法長期保留多個模擬器與測試狀態，文末也會說明如何規劃可重複的遠端測試環境。

01

申報範圍與時間判斷

截至 2026 年 9 月 7 日，Apple 官方資料確認 Accessibility Nutrition Labels 初期屬於自願提供的資訊，並表示未來會成為新 App 及更新提交時所需的資料；在列出的官方文件中，尚未公布統一的強制生效日期。這代表團隊現在不應等待某個未公布的截止日，也不應把「目前非強制」理解成可以隨意填寫。

Apple 對 Accessibility Nutrition Labels 的總覽說明要求開發者按照常用任務及實際支援的裝置家族評估。申報工作的基本判斷可以拆成三層：

  • 程式碼層：是否加入修飾符、標籤、輔助技術 API 或相關設定。
  • 頁面層：某個畫面是否能被 VoiceOver 或其他功能操作。
  • 任務層：使用者是否能完成下載 App 後真正需要做的事情。

只有任務層通過，才足以支持商店標籤的申報。單一展示頁可用，不等於整個 App 的登入、付款、設定與錯誤恢復流程都可用。

02

常用任務矩陣

先不要打開 App Store Connect 逐項勾選。建議先建立一份任務矩陣，把下載後必須完成的路徑列出，再為每項任務記錄裝置、系統設定、測試結果、失敗位置及申報決定。

至少應考慮以下任務：

  • 首次啟動、權限提示與新手導覽。
  • 帳戶註冊、登入、登出及重設密碼。
  • App 的核心操作，例如建立內容、搜尋、編輯或提交。
  • 購買、訂閱、恢復購買及付款錯誤處理。
  • 設定、通知、隱私選項與帳戶管理。
  • 網路中斷、欄位輸入錯誤、彈窗關閉及返回上一個流程。
驗收項目 測試對象 必須保留的證據 申報決定
常用任務 首次啟動至核心業務完成的完整路徑 任務清單、錄製或截圖、失敗節點 任一主要路徑不能完成，對應標籤先不申報
登入與帳戶 輸入欄位、驗證碼、錯誤提示、登出 測試帳戶說明、操作結果、錯誤恢復記錄 不只測試成功登入，還要驗證錯誤分支
購買流程 商品選擇、確認、付款結果、恢復購買 脫敏截圖、交易狀態、回復路徑 自訂控制項無法操作時，不可用其他頁面的通過結果代替
設定流程 顯示、通知、無障礙相關設定與返回 設定前後狀態、裝置家族、系統設定 只在實際支援的裝置範圍內申報

測試帳戶、App 名稱、Bundle ID、截圖中的個人資料和付款資訊都應脫敏。申報證據不是要把內部資料公開，而是讓團隊日後能回答「哪個版本、哪個裝置、哪條路徑得出這個結論」。

注意： 不要把程式碼搜尋結果當成驗收結果。即使專案中出現 accessibilityLabel 或其他修飾符，仍可能因焦點順序、遮罩層或自訂手勢而無法完成任務。

03

互動能力驗收

VoiceOver

VoiceOver 測試不能停留在「畫面會朗讀」。依照 Apple 的 VoiceOver 評估標準，應逐項檢查焦點順序、控制項名稱、角色、狀態、目前值和可執行操作，並沿著常用任務走完完整流程。

特別容易漏測的地方包括：

  • 自訂按鈕、滑桿、分段選擇器與拖曳控制項。
  • 登入或付款完成後才出現的動態內容。
  • 彈窗開啟後焦點是否移入，關閉後是否回到合理位置。
  • 表單錯誤是否被讀出，以及使用者能否回到錯誤欄位修正。
  • 只依賴滑動、長按或拖曳的操作是否有可替代方式。
  • 網路錯誤、付款失敗和空白狀態是否提供可理解的下一步。

VoiceOver 通過，不代表 Voice Control 也通過。兩者的結果必須分開記錄。

Voice Control

依照 Apple 的 Voice Control 評估標準，測試重點是使用語音完成控制項定位、啟動、文字輸入和流程返回。自訂元件如果沒有清楚可辨識的名稱，或多個控制項使用相同名稱，可能在觸控操作正常時仍無法用語音完成。

可以用以下方式記錄結果：

任務：登入
裝置：iPhone
功能：VoiceOver
結果：通過；焦點順序、錯誤提示與提交按鈕可理解

任務：登入
裝置：iPhone
功能：Voice Control
結果：未通過；兩個自訂按鈕名稱相同，無法穩定指定目標
申報決定：VoiceOver 與 Voice Control 分開判定

這類輸出比「無障礙已支援」更有價值，因為它指出失敗的是哪個功能、哪項任務和哪個裝置。修正後也能直接重跑同一條路徑。

04

視覺適配與動態效果

文字、顏色、深色介面和動態效果應分開判定，不能因為專案已接入 Dynamic Type 就視為大字體支援完成。

較大文字的驗收應沿著真實任務進行，包括登入、搜尋、購買和設定。需要觀察文字是否被截斷、按鈕是否被遮住、表格是否能捲動，以及錯誤訊息是否仍能被完整閱讀。判定條件應以 Apple 的 Larger Text 評估標準為準，不要自行建立未獲官方支持的像素或比例門檻。

深色介面則應檢查文字、圖示、分隔線、輸入狀態和錯誤狀態。顏色不能成為唯一的狀態提示，例如只用紅色表示錯誤，卻沒有文字、圖示或其他可辨識差異。Apple Human Interface Guidelines 的 Accessibility 指引可用來核對介面設計與輔助技術的基本方向。

Accessibility Inspector 適合用來發現標籤、對比、元素層級及部分介面問題，但檢查器輸出不能代替常用任務測試。建議同時保存：

  • 系統無障礙設定畫面。
  • Accessibility Inspector 的檢查結果。
  • 任務操作前後的脫敏截圖。
  • 發生截斷、遮擋或焦點錯誤的頁面。
  • 修正後重新測試的結果。

減少動態效果也要在實際任務中檢查，例如頁面切換、載入動畫、彈窗出現和錯誤提示。可參考 Apple 的 Reduced Motion 評估標準，不要只測試 App 啟動畫面。

05

媒體內容與字幕判定

字幕和音訊描述只適用於 App 內確實存在、而且完成常用任務所需要的影片或音訊內容。普通文字說明、影片逐字稿和完整字幕不是同一件事；有逐字稿也不代表影片中的對話、音效及關鍵資訊都已在播放時同步提供。

可以先問三個問題：

  1. 使用者是否必須觀看影片或聆聽音訊，才能完成核心任務？
  2. 內容是否包含對話以外、但會影響理解的聲音或畫面資訊？
  3. 不同語言、播放狀態、全螢幕模式及載入失敗時，使用者是否仍能取得關鍵內容？

字幕應對照 Apple 的 Captions 評估標準；音訊描述則應對照 Audio Descriptions 評估標準。若主要媒體路徑仍有內容無法取得，就不應為了「有文稿」而勾選完整支援。

媒體情境 可申報的判斷依據 常見錯誤
App 沒有完成任務所需的影片或音訊 先確認該標籤是否適用，再依 App Store Connect 當前選項處理 因為產品頁有文字介紹就宣稱有字幕
有影片且對話影響任務 在播放、暫停、全螢幕及不同語言下檢查字幕 只測試影片開頭，未檢查字幕同步
畫面資訊對理解不可或缺 確認音訊描述能傳達必要的視覺內容 把普通旁白當作完整音訊描述
媒體只屬於次要宣傳內容 依實際常用任務和官方標準判定適用範圍 把某個宣傳頁的能力套用到整個 App
06

裝置家族與測試環境

iPhone、iPad 和 Mac 不應共用一份未經核對的結論。相同功能在不同平台可能使用不同布局、鍵盤輸入、指標操作、視窗行為和系統控制項，因此必須按 App 實際支援的裝置家族建立矩陣。

建議將矩陣分成以下欄位：

裝置家族：
App 版本：
作業系統與系統無障礙設定：
測試功能：
常用任務：
完成結果：
失敗步驟：
截圖或錄製位置：
修正版本：
最終申報決定：

如果 App 在 iPhone 通過，但 iPad 的分欄布局讓 VoiceOver 焦點跳離主要內容，iPad 的結論就不能沿用 iPhone。若 Mac 版本改用滑鼠、鍵盤或視窗控制，也應重新驗證登入、購買、設定及錯誤恢復。

官方可用選項、標籤顯示範圍及管理流程可能隨 App Store Connect 更新而調整。提交前應查看 Apple 的 Accessibility Nutrition Labels 管理流程，不要按照舊截圖推測目前介面。

07

證據包與發布回歸

完成測試後，將下列內容放進同一份可追溯證據包：

  • 按裝置家族整理的常用任務清單。
  • 測試版本、建置來源和系統無障礙設定。
  • VoiceOver、Voice Control、文字、顏色和動態效果的獨立結果。
  • 失敗路徑、修復提交及修復後的重新驗證。
  • 不適用的標籤及其判斷理由。
  • 最終申報內容與當時線上版本的對照。

若團隊透過自動化流程產生測試版本，可參考 Apple 的無障礙声明 API 文件理解可配置的資料範圍；但 API 能建立或更新申報資料，不會替團隊判斷常用任務是否真的可完成。

本地 Mac 若無法長期保存多個模擬器、測試帳戶和系統設定，可以把每個裝置家族拆成獨立回歸工作區。需要遠端圖形操作時，可先查看 遠端 Mac 執行 iOS 模擬器的方案；若團隊同時維護建置與測試流程，也可把環境規劃納入遠端 Mac 的持續整合工作方式。

最小化的發布前流程如下：

  1. 凍結準備提交的 App 版本，避免測試分支和線上版本不一致。
  2. 按 iPhone、iPad、Mac 等實際支援範圍建立測試矩陣。
  3. 走完首次啟動、登入、核心功能、購買和設定等常用任務。
  4. 分別測試 VoiceOver 與 Voice Control，並記錄錯誤恢復。
  5. 使用較大文字、深色介面和減少動態效果重跑主要路徑。
  6. 只有在適用時測試字幕與音訊描述，不以文字稿代替媒體驗證。
  7. 整理失敗項、修復記錄和截圖，形成脫敏證據包。
  8. 依當前 App Store Connect 選項填寫標籤，發布後再檢查商店頁面的實際展示。
08

發布前可複製檢查表

[ ] 已列出下載後必須完成的常用任務
[ ] 已包含首次啟動、登入、購買、設定與錯誤恢復
[ ] 已按裝置家族分開測試
[ ] VoiceOver 結果已獨立記錄
[ ] Voice Control 結果已獨立記錄
[ ] 自訂控制項、彈窗、手勢和動態內容已測試
[ ] 較大文字下沒有截斷、遮擋或無法捲動
[ ] 深色介面與非顏色狀態提示已核對
[ ] 減少動態效果已在真實任務中重跑
[ ] 字幕與音訊描述只在適用媒體中判定
[ ] 失敗路徑、修復結果和測試環境已保存
[ ] 測試結論與目前線上版本一致
[ ] 標籤發布後已重新檢查商店展示

如果目前方案是在開發者自己的單一 Mac 上測試，常見缺點是裝置家族容易被混在一起、模擬器狀態會因日常開發而改變，而且團隊成員難以重現同一組 VoiceOver 或 Accessibility Inspector 條件。直接購買額外 Mac 又會把成本和長期硬體維護綁在一起，對只需要週期性驗收的獨立開發者未必划算。若本地環境無法長期保留多套測試狀態，租用 NodeMini 的遠端 Mac 可建立獨立的回歸工作區，先在真實任務通過後再更新 App Store 標籤；但若團隊需要長期高負載使用、固定接入實體 iPhone 或自主管理硬體，購買並維護自己的 Mac 仍可能更合適。