App Storeアクセシビリティラベル：一般的なタスクの評価手順

App Storeのアクセシビリティラベルは、アプリにAPIや設定が一つ存在すれば「対応」と記載できるものではありません。対象のアクセシビリティ機能を使い、ユーザーがアプリの一般的なタスクをすべて完了できるかをデバイスごとに評価します。

Appleはラベルの提供を当初は任意としていますが、将来は新規アプリとアップデートの提出時にアクセシビリティ対応の共有を必須にする予定です。必須化の日を待って入力するのではなく、現在のビルドで検証できる範囲から回答根拠を作ります。

ラベルへ記載できる機能を確認する

アクセシビリティラベルの公式概要では、次の9機能が示されています。

• VoiceOver
• 音声コントロール
• テキストを大きな文字で表示
• ダークインターフェイス
• カラー以外で区別
• 十分なコントラスト
• 視差効果を減らす
• キャプション
• バリアフリー音声ガイド

すべてのラベルが全デバイスにあるわけではありません。たとえば音声コントロールはApple TVとApple Watch、テキストを大きな文字で表示するラベルはMacで対象外です。iPhoneの結果をそのままMacやApple Watchへコピーせず、App Store Connectで選択できるデバイスと機能の組み合わせを基準にします。

アクセシビリティラベルは、iOS 26、iPadOS 26、macOS 26、tvOS 26、visionOS 26、watchOS 26以降のApp Storeで表示されます。プロダクトページでは、ユーザーが見ているデバイスに対応したラベルが表示されます。

「一般的なタスク」を先に列挙する

対応機能を選ぶ前に、ユーザーが普段完了する一連の操作を洗い出します。Appleが示す一般的なタスクは、アプリ固有の主要機能だけではありません。

通知やwidgetから主要な操作を完了できるなら、アプリ外の入口も候補に含めます。一方、利用目的と関係の薄いマーケティングリンクのように、ユーザーが使えなくても緊急修正を出さない操作まですべて含める必要はありません。

操作名を「設定画面」のような画面単位だけで終わらせず、開始条件と完了条件が分かる粒度にします。たとえば「通知を無効にして前の画面へ戻る」「無料トライアルの条件を確認し、購入せず閉じる」のように書くと、途中まで使える状態を合格にしにくくなります。

デバイスごとにテスト表を作る

Appleは、評価対象となるデバイスごとに、一般的なタスクを行、アクセシビリティ機能を列とするテスト用マトリックスを推奨しています。次のような表をiPhone、iPad、Macなどで分けて作ります。

各セルは合格・不合格だけでなく、確認したbuild、OS、操作結果、不合格になった画面を残します。iPadにだけあるサイドバー操作や、Macにだけあるメニュー操作は、そのデバイスの行へ追加します。

機能を一部の画面で利用できても、一般的なタスクのどこかで完了できない場合は、そのデバイスについて対応済みとは記載しません。まず不合格箇所を修正し、同じ表を最初から通してから回答を変えます。

VoiceOverは表示を読み上げるだけで判断しない

VoiceOverは評価の入口にしやすい機能ですが、画面上の文字が読み上げられるだけでは一般的なタスクを完了できません。AppleのVoiceOver評価基準に沿って、対象デバイス上でVoiceOverだけを使い、視覚による補助なしで操作します。

少なくとも次を確認します。

• ボタン、入力欄、画像などに簡潔で正確なlabelがある
• 選択中、無効、進捗などの状態と値が伝わる
• フォーカスが論理的な順序で移動する
• モーダルを開いたとき、背後の操作へ移動せず閉じられる
• 長押し、ドラッグ、複数指gestureに発見可能な代替操作がある
• エラー、完了、読み込み結果などの変化を把握できる

自分で画面を見ながらVoiceOverの読み上げを補完すると、label不足や不自然なフォーカス移動を見落とします。確認担当は操作手順だけを持ち、画面を見ずに完了条件へ到達できるかを試します。

VoiceOverで見つかった問題を直したあとも、音声コントロールや大きな文字などは各評価基準で別に確認します。VoiceOverへの対応だけで、ほかのラベルをまとめて選択できるわけではありません。

App Store Connectでデバイス単位に公開する

テスト表とAppleの評価基準が一致したら、アクセシビリティラベルの管理手順に沿って入力します。操作できるroleはAccount Holder、Admin、Finance、App Manager、Marketingです。

1. App Store Connectの「アプリ」で対象アプリを選ぶ
2. サイドバーの「アプリのアクセシビリティ」を開く
3. 「はじめに」を選ぶ
4. 評価したデバイスを選択する
5. デバイスごとに、いずれかの機能へ対応するかを回答する
6. 対応を確認できた機能だけを選択する
7. 下書きとして保存された回答を見直す
8. 公開するデバイスを選択して「公開」を実行する

対応情報を公開できるのは、App Storeでアプリversionの配信対象になっているデバイスだけです。回答は公開後も更新できます。変更は即時に反映されますが、すべてのユーザー環境へ表示されるまで最大24時間かかる場合があります。

どの対象機能も基準を満たさない場合は、無理に一つ選ばず「いいえ」と回答できます。デバイスの情報を提供しない場合、プロダクトページには対応がまだ記載されていないことが表示されます。「未記載」と「対応なし」は異なるため、現在の評価結果に合う方を選びます。

アクセシビリティURLには説明を置く

アクセシビリティURLは任意です。ほかの機能への対応、アプリ内設定の使い方、キャプションの対応言語、対応していない領域など、ラベルだけでは伝わらないアプリ固有の情報を掲載できます。

このURLは問い合わせフォームの入口とは役割が違います。フォームだけを開いても、ダウンロード前のユーザーは対応内容を判断できません。アクセシビリティURLには説明ページを登録し、そのページから必要に応じて問い合わせ窓口へ移動できる構成にします。

Support URLも別項目です。連絡手段を含むサポートページの条件は、App StoreのサポートURLに必要な内容で確認してください。同じWebサイト内へ置くことはできますが、App Store Connectで何を説明するURLなのかを混同しないようにします。

公開後の報告を回答更新へつなげる

テスト時に合格しても、特定のOSや端末、文字サイズ、言語で操作できない問題が見つかる場合があります。一般的なタスクを妨げる不具合なら、修正予定を記録するだけでなく、公開中のラベルが現在の実態と一致するかを確認します。

IndieFormはアクセシビリティラベルを評価したり、App Store Connectへ公開したりするサービスではありません。ユーザーから利用できない操作の連絡を受けたとき、問い合わせ本文とアプリversion、OS、端末、言語などを対応付けて確認する補助窓口として使えます。

報告内容だけでラベルを外すか判断せず、同じデバイス条件で一般的なタスクを再テストします。不具合報告で集める情報と聞き方は、アプリの不具合問い合わせで集める情報を参照してください。

AIにプロジェクトの対応候補を調べさせる

コードを読めるAIエージェントへ次のプロンプトを渡すと、現在のプロジェクトから一般的なタスク、対応を示す実装、実機で確認すべき箇所をまとめられます。プロジェクトのルートを開いた状態で、そのまま貼り付けてください。

コードの静的な確認だけでは、一般的なタスクを最後まで完了できる証明にはなりません。出力はApp Store Connectへ転記する回答ではなく、実機テスト表を作るための下書きとして使います。

現在開いているアプリプロジェクトについて、App Storeのアクセシビリティラベルを検討するための事前調査をしてください。質問で止まらず、リポジトリ内から確認できる範囲を自律的に調べ、最後までレポートしてください。ファイルは変更しないでください。

目的は、対応済みと自動判定することではありません。コード上の根拠と懸念を整理し、Appleの評価基準に沿って実機確認するためのテスト計画を作ることです。

調査ルール:
- ソースコード、設定、依存関係、画面遷移、テスト、ドキュメントを実際に確認する
- 根拠にはファイルパスと行番号、または該当する型・関数・画面名を付ける
- コードから確認できない動作を推測しない
- 一部の画面に実装があるだけで、アプリ全体が対応済みとは判定しない
- iPhone、iPad、Mac、Apple Watch、Apple TV、Apple Vision Proなど、実際の配信対象デバイスを分ける
- プラットフォームやフレームワークを問わず、同等の仕組みを探す。特定APIの有無だけで判定しない
- 外部SDKやOS標準コンポーネントも、アプリ内の利用箇所と設定まで確認する
- 最終ステータスに「対応済み」は使わず、「申告候補」「要修正」「根拠なし」「対象外」「実機確認待ち」のいずれかを使う

次の順で調査してください。

1. プロジェクト構成
   - 使用フレームワークとUI技術
   - 対応OS、配信対象デバイス、最低OSバージョン
   - アプリ本体、拡張機能、widgetなどのターゲット

2. 一般的なタスク
   - 主要機能、初回起動、オンボーディング、権限選択、ログイン、アカウント作成、購入、設定を調べる
   - ストア説明や仕様書があれば照合する
   - 各タスクを「開始条件」「操作」「完了条件」「対象デバイス」「根拠」に分ける
   - アプリに存在しないタスクは、存在しないと明記する

3. 9種類のアクセシビリティ機能
   - VoiceOver: label、role、value、状態、フォーカス順、モーダル、画像、カスタム操作、gestureの代替を確認する
   - 音声コントロール: 操作要素の名前、タップ領域、独自gestureの代替、重複する名前を確認する
   - テキストを大きな文字で表示: Dynamic Type相当の仕組み、固定文字サイズ、折り返し、切り詰め、スクロール、最大サイズ時のレイアウトを確認する
   - ダークインターフェイス: OSテーマへの追従、固定色、画像、WebView、独自描画を確認する
   - カラー以外で区別: エラー、選択状態、グラフ、ステータスを色だけで伝えていないか確認する
   - 十分なコントラスト: カラートークン、文字、アイコン、無効状態、画像上の文字を確認し、コードだけで比率を確定できない箇所を分ける
   - 視差効果を減らす: Reduce Motion相当の設定参照、アニメーション、遷移、点滅、自動再生を確認する
   - キャプション: 動画や音声コンテンツの有無、字幕データ、同期、字幕の表示操作を確認する
   - バリアフリー音声ガイド: 映像コンテンツの有無、音声ガイドトラックと選択方法を確認する

4. 出力形式
   - 調査対象と確認できなかった範囲
   - デバイス別の一般的なタスク一覧
   - 「機能 × デバイス」の候補判定表
   - 各セルの根拠と、一般的なタスク全体を妨げる懸念
   - 優先度を付けた修正候補。コード変更は行わない
   - 実機テスト表。各項目に前提条件、開始位置、操作手順、期待結果、記録するbuildとOSを含める
   - App Store Connectへの申告候補と、申告前に残る確認事項

最後に、コード調査だけでは判定できなかった項目と、実機確認が完了するまで申告すべきでない項目を明確に分けてください。

出力された根拠に誤りがないかコードを開いて確かめたあと、前段で作ったデバイス別のテスト表へ実機確認の結果を記録します。「申告候補」であっても、一つの一般的なタスクが完了できなければ、その機能は対応済みとして公開しません。

公開前チェックリスト

• ストアで訴求している主要機能を一般的なタスクへ分解した
• 初回起動、ログイン、購入、設定を確認対象へ含めた
• デバイスごとにタスクと対象機能のテスト表を作った
• 各機能のApple公式評価基準を読んだ
• 実機で一般的なタスクを最初から最後まで完了した
• 部分的に使える機能を対応済みとして選んでいない
• 下書きと公開対象のデバイスを見直した
• アクセシビリティURLとSupport URLの役割を分けた
• 機能変更や不具合時に回答を更新する手順を決めた

ラベルの入力作業より時間がかかるのは、一般的なタスクを漏れなく定義して実機で通す工程です。テスト表をリリース確認へ残しておけば、次のアップデートでは変更した操作と影響する機能から再評価できます。