購入画面の自作ボタンだけVoiceOverで操作できず、プロジェクトには無障害対応の修飾子が追加されています。
最短の判断は、APIの有無ではなく、ログイン・購入・設定・主要機能を対応する支援機能で完了できるかを確認し、未検証の項目は申告しないことです。
対象読者と今週の作業
このチェックリストは、初めてAccessibility Nutrition Labelsを記入する独立開発者と、iPhone・iPad・Mac向けに別々の検証が必要な小規模チームを対象にしています。
手元に常設の検証環境がなく、macOS上で再現可能な無障害回帰環境を用意したい開発者にも適しています。今週はまず、Appの常用タスクを列挙し、端末ファミリーごとに「完了・失敗・未検証」を記録してください。
AppleのAccessibility Nutrition Labelsに関する概要でも、判断の基準はコードに属性が存在することではなく、利用者が実際のタスクを完了できるかという考え方で整理されています。
Accessibility Nutrition Labelsの記入をAPI確認で終わらせない
無障害対応の判定には、少なくとも次の段階があります。
- コードにアクセシビリティ用の修飾子や属性がある
- 1つの画面を支援機能で閲覧できる
- 1つの操作を完了できる
- ログイン、購入、設定変更、主要機能を含む常用タスクを最後まで完了できる
- 公開する端末ファミリーとバージョンで、その結果が再現する
最初の二つだけを確認してラベルを付けると、トップ画面は読み上げられても、購入確認のモーダルやエラー復帰で操作が止まる問題を見落とします。AppleのHuman Interface GuidelinesにおけるAccessibilityの原則も、個別のコントロールではなく、利用者が製品を使える体験全体を重視しています。
申告判断の比較
| 判定材料 | 確認できること | ラベル申告の扱い | 次の作業 |
|---|---|---|---|
| APIや修飾子の存在だけ | 実装意図がある | 申告しない | 常用タスクを実機またはシミュレーターで実行 |
| 単一画面の表示 | その画面の一部が読める | 申告の根拠として不十分 | 画面遷移、入力、エラー復帰を追加確認 |
| VoiceOverなどで主要タスクを完了 | 対応機能が実利用に結び付いている | 対応範囲に含めて検討 | 証拠と端末別結果を保存 |
| 一部の端末だけ完了 | 端末ファミリー間に差がある | 全端末への一括申告は避ける | 対応する端末範囲を分けて再判定 |
この比較で「単一画面は使えるが、購入まで完了できない」に該当する場合、コードを増やす前に失敗した操作経路を特定します。申告の可否は、実装量ではなく常用タスクの到達結果で決めます。
常用タスクを先に固定する
最初にテスト対象を画面単位ではなく、利用者の目的単位で書き出します。たとえば、ニュースAppなら「初回起動から記事を検索して本文を読む」、サブスクリプションAppなら「アカウントを作成してプランを購入し、設定から解約手順を確認する」といった形です。
最低限、次の経路を含めます。
- 初回起動と権限案内
- ログイン、ログアウト、パスワード再設定
- 検索、一覧から詳細への移動
- 購入、復元、決済失敗時の再試行
- 設定変更、通知設定、アカウント削除
- 通信失敗、入力エラー、空状態からの復帰
次のようにタスク台帳をテキストで管理すると、開発ブランチと公開版の差分を追いやすくなります。
task_id: purchase-recovery
platform: iPhone
assistive_technology: VoiceOver
path: 商品詳細 -> 購入確認 -> 決済失敗 -> 再試行
result: failed
evidence: evidence/iphone/purchase-recovery-voiceover.mov
decision: do_not_declare
動画やスクリーンショットには、アカウント名、App名、Bundle ID、テスト用メールアドレスなどを残さないでください。証拠は「何を操作したか」「どの環境か」「どこで失敗したか」が追える最小限の内容にします。
VoiceOverとVoice Controlは別の能力として判定する
VoiceOverでは、焦点が自然な順序で移動するか、ボタン名と役割が理解できるか、選択状態や値が読み上げられるかを確認します。標準のボタンだけでなく、カード全体をタップさせる自作コントロール、ページャー、シート、アラート、ドラッグ操作も含めてください。
AppleのVoiceOver評価基準に沿って、次の経路を別々に記録します。
- 画面を順番に移動する
- 入力欄へ移動して値を入力する
- 自作コントロールの状態を変更する
- モーダルを開き、閉じ、元の位置へ戻る
- エラー内容を読み取り、修正して再送信する
Voice Controlは音声で要素を呼び出せるか、名称が区別しやすいか、複数の同名要素がある場合に選択できるかを確認します。VoiceOverが通ってもVoice Controlが成立するとは限りません。両者の結果を同じ欄にまとめず、Voice Controlの評価基準を参照して別の結論を出します。
文字、色、動きは常用タスクの中で確認する
Dynamic Typeを実装したという事実だけでは、Larger Textへの対応を証明できません。文字を大きくした状態で、購入金額、エラー内容、主要ボタン、表形式の情報が切り取られず、重なりもなく、必要な位置までスクロールできるかを確認します。判定時はAppleのLarger Text評価基準を参照してください。
色については、通常表示とダークな外観の双方で、状態が色だけに依存していないかを見ます。選択済み、警告、失敗、無効の状態には、文字、形、位置、アイコンなど別の手掛かりが必要です。Accessibility Inspectorの監査結果は補助材料として使い、実際のタスクで表示が崩れないことを別に確認します。
Reduced Motionは、アニメーションを停止したときに操作の意味や状態変化が失われないかを判定します。画面遷移が速くなるだけでなく、読み込み中、成功、失敗、次の操作可能状態が分かるかを確認し、Reduced Motionの公式基準と照合します。
注意：Accessibility Inspectorの監査で問題が見つからなくても、カスタムジェスチャー、フォーカス移動、決済エラーからの復帰まで自動的に保証されるわけではありません。監査結果と常用タスクの手動記録は別の証拠として保存します。
字幕と音声解説はコンテンツがある場合だけ申告する
App内の動画や音声が、主要機能の完了に使われているかを先に確認します。単なるテキスト説明が存在するだけでは、字幕や音声解説に対応しているとは限りません。
字幕では、発話だけでなく、必要な効果音や話者の区別など、内容理解に必要な情報が取得できるかを確認します。音声解説では、映像だけで伝わる重要な操作や状態が、音声で補われているかを確認します。
言語切り替え、再生中の表示、全画面化、途中再開、通信が不安定な場合も含め、主要メディア経路を覆えないなら該当ラベルは申告しません。Captionsの評価基準とAudio Descriptionsの評価基準で、字幕と音声解説を別々に判定します。
端末ファミリー別のテスト行列を作る
iPhoneで完了した結果を、そのままiPadやMacへコピーしてはいけません。画面分割、横向きレイアウト、キーボード入力、ポインタ操作、プラットフォーム固有のコントロールが、常用タスクの完了可否を変えるためです。
検証環境には、少なくとも次の列を用意します。
- 端末ファミリー
- OSとAppのビルド
- 使用した支援機能
- 常用タスク
- 結果と失敗位置
- 証拠ファイル
- 公開時の申告判断
アクセシビリティに関する情報をApp Store Connect APIで扱う場合も、無障害申告を設定する公式API文書を参照し、APIに登録できることと、実際の利用者検証が済んでいることを混同しないようにします。
ローカルMacに複数のシミュレーターや検証状態を長期間残せない場合は、NodeMiniのMacレンタル環境を独立した回帰環境として使う方法もあります。遠隔環境では、画面共有の遅延や入力方法が実機と異なる可能性があるため、最終判定に必要な実機操作を代替できると決めつけず、環境名と制約を証拠に明記します。
公開前の5段階チェック
公開直前は、次の順番で確認すると申告漏れと過剰申告を分けやすくなります。
- Appの主要機能から常用タスクを固定し、初回起動、認証、購入、設定、エラー復帰を含めます。
- iPhone、iPad、Macなど、実際に提供する端末ファミリーごとに同じタスクを実行します。
- VoiceOver、Voice Control、文字拡大、外観変更、動きの軽減、字幕、音声解説を適用範囲に応じて別々に記録します。
- 失敗した経路、修正したビルド、最終確認結果を、脱敏済みの動画、画像、ログ、台帳で結びます。
- App Store Connectで申告する内容が、公開予定バージョンの実装と一致するか確認し、未検証項目は保留します。
この作業を自動化する場合でも、自動化は証拠の収集と回帰の補助に限定します。NodeMiniの遠隔Mac運用に関する案内を確認しながら、Xcode、シミュレーター、Accessibility Inspectorの状態を固定し、毎回同じビルドとテストアカウントを使える構成にすると、再検証の差分を追いやすくなります。
FAQ
Accessibility Nutrition Labelsは今すぐ必須ですか？
2026年9月7日時点で、Appleは初期段階では任意で提供する情報と説明しています。ただし、将来は新規Appや更新提出に必要になる予定です。Appleが統一された必須化日を公式資料で示すまでは、未検証の項目を先回りして申告せず、検証済みの範囲だけを正確に登録します。
端末ごとに別の申告判断が必要ですか？
必要です。iPhone、iPad、Macではレイアウト、入力方式、フォーカス移動、システムコントロールが異なるため、同じラベルを機械的に複製できません。App Store Connectで提供対象になっている端末ファミリーを確認し、各端末で常用タスクが完了するかを個別に記録します。
VoiceOverはどのタスクまで通れば対応を申告できますか？
起動直後の画面や一つの読み上げ経路だけでは足りません。ログイン、主要機能、購入、設定変更、エラーからの復帰など、利用者がAppを使ううえで必要な一連のタスクを確認します。自作コントロール、ポップアップ、ジェスチャーを含めて操作できない経路があれば、対応範囲を再判定します。
ラベルを公開したのに表示されないのはなぜですか？
App Store Connectで保存した申告内容、審査対象のビルド、公開済みバージョンの表示は同じタイミングで変わるとは限りません。処理状態と対象バージョンを確認し、開発中の修正版を公開済みの機能として扱わないことが重要です。表示が反映されるまで、申告内容と証拠を保持して再確認します。
現地Macと遠隔Macをどう使い分けるか
手元のMacだけで複数のシミュレーター、Xcodeの各状態、検証用アカウントを維持すると、ディスク容量の圧迫、環境の作り直し、別担当者との状態共有が負担になります。特に短期間の公開前回帰では、常用タスクの記録より環境維持に時間を取られやすくなります。
一方、遠隔Macは画面共有の入力遅延、実機接続の制約、回線断、端末固有の挙動を別途確認しなければなりません。長期の高負荷ビルドを常時固定したい場合や、物理iPhone・iPadの接続を必須とする場合は、自前のMacや実機環境の方が適しています。
ただし、公開前だけ独立したmacOS環境を確保したい場合、ローカル環境の状態を毎回消して再構築するより、期間単位で遠隔Macを借りて検証用のXcode、シミュレーター、証拠ファイルを分離する方が管理しやすいケースがあります。まず実際の常用タスクを完了できるかを確認し、その結果が揃ってからApp Store Connectのラベルを更新する運用が安全です。
必要な期間だけmacOSの検証環境を確保したい場合は、NodeMiniのMacレンタル案内を確認し、実機が必要な工程と遠隔Macで完了できる工程を分けて計画してください。