ログイン

モバイルアプリのアクセシビリティ：iOSおよびAndroid向けWCAG 2.2要件

4 min read
モバイルIosAndroid

WCAG 2.2はウェブサイトの枠をはるかに超えており、その達成基準はタッチターゲット、認証、ジェスチャー、フォーカスの可視性を含むネイティブのiOSおよびAndroidアプリにも直接適用されます。このガイドでは、関連するすべての要件、それぞれが各プラットフォームでどのように実装されているか、そしてコンプライアンスとインクルーシブ性を維持するためにチームが何をしなければならないかを分解して解説します。

障害のある成人の72%以上がスマートフォンを所有しており、ある調査によると、スクリーンリーダー利用者のおよそ86%がモバイルデバイスに依存しています — デスクトップやラップトップ利用者よりも高い割合です。それにもかかわらず、自社のウェブサイトは徹底的に監査している組織でさえ、モバイルアプリについては、アクセシビリティの基準に一度も照らしてテストしたことがない、というケースがよくあります。このギャップは急速に縮まりつつあります。その背景には、規制の進化、訴訟の増加、そして何よりも、W3C自身が WCAG 2.2 をネイティブの iOS および Android アプリケーションに明示的にマッピングしたガイダンスを出したことがあります。

なぜ WCAG 2.2 があなたのモバイルアプリに適用されるのか

WCAG はウェブ専用の標準だという根強い誤解があります。そうではありません。W3C はモバイルアクセシビリティ専用の別ガイドラインを持っていません。モバイルアクセシビリティは既存の WCAG フレームワークの中で扱われており、W3C の Mobile Accessibility Task Force (MATF) は、Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) という専用ガイダンスを作成しています。これは、すべてのレベル A および AA の達成基準を、ネイティブモバイルアプリ、モバイルウェブアプリ、ハイブリッドアプリにマッピングしたものです。

実務的な意味合いは大きいものです。WCAG の達成基準に「ウェブページ」という文言が出てきた場合、WCAG2Mobile 文書ではその言葉を「画面」や「ビュー」に置き換えています。「ユーザーエージェント」に言及している基準では、それはモバイル OS を意味します。POUR の4原則 — Perceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、Robust（堅牢） — は、iOS の SwiftUI のビューや Android の Jetpack Compose レイアウトにおけるユーザーの操作にそのまま対応します。

法的な観点から見ると、プレッシャーはもはや理論上のものではありません。ADA の Title II の下で、2024年4月に公表された改正 DOJ 規則は、州および地方自治体に対し、モバイルアプリケーションを WCAG 2.1 AA に準拠させることを明示的に求めています。Medicare や Medicaid を受け入れている医療機関も、2024年5月に最終化された HHS 規則の下で同様の要件に直面しています。民間セクターのモバイルアプリに対する訴訟は、ウェブサイトに対する訴訟ほど頻繁ではないものの、少なくとも1人の大量提訴を行う原告が、ADA に基づく公平なアクセスの欠如を理由にモバイルアプリケーションを特に標的にしており、Title II のコンプライアンス期限が 2026年に到来するにつれて、この傾向は加速すると見込まれます。

2025年6月28日に発効し、EN 301 549 を推定技術標準として採用している European Accessibility Act (EAA) も、EU 市場で販売または提供されるモバイルアプリを含むデジタル製品およびサービスに対し、WCAG 2.2 への適合を求めています。グローバルなユーザーベースを持つ組織にとって、モバイルにおける WCAG 2.2 は将来の目標ではなく、現在の義務です。

モバイルにとって重要な WCAG 2.2 の変更点

2023年10月に W3C 勧告として公開された WCAG 2.2 は、新たに9つの達成基準を追加し、現在では不要となった 4.1.1 Parsing を削除しました。完全な後方互換性があり、2.2 に準拠していれば 2.1 および 2.0 にも準拠していることになります。新しい基準のいくつかは、モバイルのインタラクションパターンを明示的に念頭に置いて書かれており、キーボード利用を前提としているように見えるものでも、iOS や Android の支援技術に直接対応するアナロジーがあります。

ここで系譜を理解しておく価値があります。2018年以降、Mobile Accessibility Task Force は、モバイルの観点が WCAG 2.1 と 2.2 の両方に反映されるようにしました。1.3.4 Orientation (AA)、1.4.10 Reflow (AA)、2.5.1 Pointer Gestures (A)、2.5.4 Motion Actuation (A)、そして新たな 2.5.7 Dragging Movements (AA)、2.5.8 Target Size Minimum (AA)、3.3.7 Redundant Entry (A) といった基準はすべて、スマートフォンやタブレットを使う障害のあるユーザーとの実地テストを通じて特定された、具体的なモバイルのユーザビリティパターンを反映しています。

WCAG 2.2 で導入された9つの新しい達成基準は、実際のユーザーが直面する特定の障壁を対象としています。記憶に問題がある人を罰するようなログインフロー、正確なタップのために安定した手を要求するインターフェース、画面ごとに異なる場所に埋もれているヘルプ機能、固定ナビゲーションバーの裏に隠れてしまうフォーカスインジケーターなどです。各基準は具体的な穴を塞ぐものであり、そのほとんどがモバイルに直接適用されます。

新しい WCAG 2.2 の基準と iOS / Android への適用方法

2.5.8 Target Size Minimum (レベル AA)

これはモバイルチームにとって、最も影響の大きい新基準と言ってよいでしょう。ボタン、リンク、フォームフィールド、チェックボックス、トグルなどのインタラクティブなターゲットについて、最小サイズを24 × 24 CSS ピクセルとするか、ターゲット自体がそれより小さい場合は、隣接するターゲットとの間に 24 ピクセルの間隔オフセットを設けることを求めています。理由は明快です。手の震え、パーキンソン病、巧緻性の制限があるユーザーにとって、16ピクセルのアイコンボタンを確実にタップすることは事実上不可能であり、障害のないユーザーであっても、小さなターゲットではエラーが大幅に増えるからです。

ネイティブモバイル開発において、WCAG 2.2 の 24 × 24 の最小値は、実際には上限ではなく下限です。Apple の Human Interface Guidelines は、iOS および iPadOS におけるタッチターゲットの最小サイズとして44 × 44 ポイントを推奨しています。Google の Material Design は、Android において48 × 48 density-independent pixels (dp) を推奨しています。アプリが Apple や Google のプラットフォームガイダンスを満たしていれば、すでに WCAG 2.2 の最小値を上回っています — しかし、多くのアプリはそうなっていません。モーダルシートの小さな閉じるボタン、設定画面の細いチェックボックス、20 × 20 dp しかないアイコンのみのツールバーアクションなどは、監査で表面化するのを待っているコンプライアンス違反です。

実務的な注意点として、WCAG の要件はインタラクティブなヒットエリアに関するものであり、アイコンの見た目のサイズに関するものではありません。16ポイントのアイコンの周囲に各辺 14ポイントのパディングを付ければ、実効的なタップターゲットは 44 × 44 ポイントになります。つまり、開発者は要素を視覚的に大きくすることなく、この基準を満たすことができます — ただし、そのパディングを意図的に設定する必要があり、システムが自動的にやってくれると当てにしてはいけません。

2.5.7 Dragging Movements (レベル AA)

この基準は、ドラッグジェスチャーで実装されているあらゆる機能 — スライダー、ドラッグ＆ドロップによる並べ替え、プル・トゥ・リフレッシュ、カルーセルのスクラブなど — について、ドラッグを必要としない単一ポインタ操作でも実行できるようにすることを求めています。iOS と Android では、プラットフォームの支援技術が特定のジェスチャーを異なる方法で処理しますが、アプリが独自のドラッグ動作を実装する場合、その代替となる非ドラッグ操作をアプリ側で提供しなければなりません。

実際には、ドラッグで並べ替えるリストには、「上へ／下へ」のステッパーボタンなどの代替手段を用意する必要があります。ドラッグジェスチャーにしか反応しないカスタムレンジスライダーは、特定の位置をタップしたときにも反応するか、増減ボタンを提供しなければなりません。基準は、基盤となる OS や支援技術が自動的に代替手段を提供している場合には適用されませんが、開発者はそれに頼るのではなく、必ず自分でテストして確認すべきです。

2.4.11 Focus Not Obscured — Minimum (レベル AA) と 2.4.12 (強化版、レベル AAA)

これらの基準は、ウェブとネイティブモバイルアプリの両方で非常に一般的なパターンに対処するものです。つまり、フォーカスされた要素が、固定 UI — 永続的なボトムナビゲーションバー、フローティングアクションボタン、スクロール領域に重なるトップツールバー — によって部分的または完全に隠れてしまうという問題です。最小基準（レベル AA）は、コンポーネントがフォーカスを受けたとき、その一部が少なくとも可視のままであることを求めます。強化版（レベル AAA）は、フォーカスされたコンポーネント全体が可視であることを求めます。

ネイティブモバイルにおいては、「キーボードフォーカス」は広義に解釈され、Switch Control や Switch Access、Full Keyboard Access（iOS 15+）、Voice Control/Access で使われるフォーカスリングも含まれます。Switch Control のスイープ中にフォーカスされた要素がボトムナビゲーションバーの下に滑り込んでしまうアプリは、物理キーボードが関与していなくても、この基準に違反します。アプリの UI は、開発者が作成したオーバーレイ、固定バー、一時的なサーフェスによってフォーカスされたコントロールを隠さないようにすべきです。

2.4.13 Focus Appearance (レベル AA)

この基準は、フォーカスインジケーターの視覚的特性に関する最小要件を定めています。コンポーネントの周囲長 × 2 CSS ピクセルに相当する最小面積を持ち、隣接する色とのコントラスト比が少なくとも 3:1 でなければなりません。ネイティブモバイルプラットフォームでは、VoiceOver や TalkBack のフォーカスリングは OS によって制御されており、開発者はその見た目を変更できません — つまり、開発者は一般的にこの特定の基準については例外扱いとなります。ただし、アプリのスタイリングによって、たとえばフォーカスされたコントロールの上に半透明のスクラムを重ねるなどして、フォーカスの視認性を低下させてはなりません。

3.3.8 Accessible Authentication — Minimum (レベル A)

この基準は、認知アクセシビリティにとって大きな前進です。認証プロセスが、認知機能テストのみに依存してはならないと定めています。つまり、ユーザーにパスワードを記憶させたり、パズルを解かせたり、CAPTCHA を書き写させたりすることを唯一の手段としてはならず、アプリはアクセシブルな代替手段を提供しなければなりません。iOS では、ユーザーが資格情報を記憶しなくても認証できるように、Apple の Keychain や Sign in with Apple をサポートすることを意味します。Android では、Google の Autofill フレームワークや生体認証をサポートし、サードパーティのパスワードマネージャーの利用を妨げないことを意味します。

より具体的に言えば、パスワードフィールドでペースト操作をブロックしているアプリは、3.3.8 に非準拠である可能性が高いということです。二要素認証フローで、通知に表示された OTP コードをユーザーに手入力させるだけで、コピー＆ペーストの仕組みを提供していない場合、それは不要な認知的負荷を生み出しています。Android の Messages アプリが OTP 通知に「コードをコピー」ボタンを用意しているのは、まさにこの理由であり、プラットフォームの挙動をこの基準の意図に合わせているのです。

重要なポイント: 生体認証（Face ID、Touch ID、Android Biometric API）のサポートは、単なる UX 向上ではなく、パスワードを安定して想起できない認知障害のあるユーザーにとっての WCAG 2.2 準拠の手段でもあります。

3.3.7 Redundant Entry (レベル A)

アプリ内の複数画面にまたがるフロー — チェックアウト、オンボーディング、医療の問診フォームなど — で、同じ情報をユーザーに複数回入力させる場合、以前に入力した値を自動入力するか、過去の入力から選択できるようにしなければなりません。この基準はネイティブモバイルアプリに直接適用されます。典型的な失敗例は、配送先住所フォームの後に、配送先と同じ住所を選べる「配送先と同じ」オプションを用意せずに請求先住所を再度入力させ、運動障害や認知障害のあるユーザーに同じテキストを何度も入力させるケースです。

3.2.6 Consistent Help (レベル A)

アプリがヘルプ機能 — サポートチャットボタン、ヘルプアイコン、「お問い合わせ」リンクなど — を提供している場合、それはアプリ内のすべての画面で一貫した位置に表示されなければなりません。認知障害のあるユーザーは、ナビゲーションやサポート機能の予測可能な配置に依存しています。ある画面ではヘッダーにヘルプボタンを置き、別の画面ではタブバーに置いたり、特定のフローでは設定メニューの中に埋め込んだりするのは、この基準に反します。

モバイルにとって依然として重要な WCAG 2.1 の基準

新しい WCAG 2.2 の基準に注目が集まりがちですが、モバイルを念頭に置いて導入された WCAG 2.1 の要件のうち、ネイティブアプリで依然として頻繁に守られていないものがいくつかあり、コンプライアンス担当者は監査の際にそれらを見落としてはなりません。

1.3.4 Orientation (AA) は、コンテンツの機能上不可欠でない限り、アプリを縦向きまたは横向きに固定することを禁じています。多くのアプリが、オンボーディングフローやアプリ内の動画プレーヤーで、正当な理由なく縦向きに固定しています。これは、端末を回転できない車椅子マウントのデバイスを使うユーザーに不利益を与えます。1.4.10 Reflow (AA) は、コンテンツが幅 320 CSS ピクセル（400% ズームに相当）で表示されたときに水平スクロールなしで提示できることを求めており、モバイルの観点では、Dynamic Type やシステムの文字サイズ拡大をサポートしてもレイアウトが崩れたりコンテンツが切れたりしないことを意味します。

2.5.1 Pointer Gestures (A) は、マルチポイントや軌跡ベースのジェスチャー — ピンチズーム、2本指スワイプなど — を使う機能には、単一ポインタの代替手段も用意することを求めています。2.5.4 Motion Actuation (A) は、端末のシェイクや傾きでトリガーされる機能について、標準的な UI コントロールでも操作できるようにし、誤作動を避けるためにモーションベースのトリガーを無効化できるようにすることを求めています。

視覚的な提示に関しては、1.4.3 Contrast Minimum (AA) が、通常のテキストで少なくとも 4.5:1、大きなテキストで 3:1 のコントラスト比を求めています。多くのアプリが、入力フィールドのプレースホルダーテキスト、無効化されたボタンラベル、写真背景上のテキストなどで、この最小値を下回っているためにここで失敗しています。開発者は、すべてのコピー、コントロール、コンテンツが、iOS と Android の両方で Dynamic Type、太字テキスト、ダークモード、システムレベルのコントラストオプションと連携して機能することを確認すべきです。

プラットフォーム別の実装ガイダンス

iOS と SwiftUI / UIKit

Apple は、UIAccessibility API と SwiftUI のアクセシビリティモディファイアを通じて、豊富なネイティブアクセシビリティサポートを提供しています。VoiceOver をサポートするには、すべてのインタラクティブ要素に意味のあるアクセシビリティラベル、ヒント、値を設定する必要があります。標準の UIKit コンポーネントを継承していないカスタムコントロールは、VoiceOver が正しくアナウンスできるように、.isButton、.isHeader、.isLink など適切なアクセシビリティトレイトを明示的に採用しなければなりません。Xcode の Accessibility Inspector は、開発中にラベルの欠落やトレイトの不一致を洗い出すのに役立ちます。

Dynamic Type については、UIKit の UIFont.preferredFont(forTextStyle:) や SwiftUI の .font(.body) といったシステムフォントが、ユーザーの好みの文字サイズに合わせて自動的に拡大縮小します。scaledValue(for:) を使わないポイント指定のハードコードフォントサイズは、1.4.4 Resize Text に違反します。ターゲットサイズについては、UIKit では contentEdgeInsets、SwiftUI では .contentShape() モディファイアを使って、小さなアイコンのタップ領域を視覚的なサイズを変えずに拡張できます。

// SwiftUI: 見た目のサイズを変えずにタップ領域を拡大
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android と Jetpack Compose / Views

Android のアクセシビリティは AccessibilityNodeInfo API を通じて提供され、TalkBack や Switch Access がそれを利用します。Jetpack Compose では、Modifier.semantics ブロックを使って、コンテンツ記述、ロール、状態の説明、子孫セマンティクスのマージなどを設定できます。View ベースの UI では、ViewCompat.setAccessibilityDelegate() を使って、任意のビューのアクセシビリティプロパティをプログラム的に操作できます。

タッチターゲットのサイズについては、Material Design ガイダンスが 48 × 48 dp の最小値を推奨しています。コンポーザブルやビューが見た目上それより小さい場合、Compose では（Material3 で導入された）Modifier.minimumInteractiveComponentSize() を使って 48 dp の最小値を自動的に適用するか、従来の View システムでは小さなビューを TouchDelegate でラップしてヒットエリアを拡張できます。テキストの拡大縮小については、すべてのテキストサイズを dp ではなく sp（scale-independent pixels）で指定し、Android の「画面設定」でユーザーが設定したフォントサイズの好みに従うようにします。

// Jetpack Compose: 最小サイズを満たすアクセシブルなアイコンボタン
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // 48dp の最小値を適用
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // 親で説明
    )
}

WCAG 2.2 に対するアプリのテスト

モバイルアクセシビリティのテストには、自動化ツールと実際の支援技術を使った手動テストの組み合わせが必要です。Deque の axe DevTools Mobile、Google の Accessibility Scanner for Android、Apple の Xcode 内 Accessibility Inspector などの自動化ツールは、ラベルの欠落、不十分なコントラスト、プラットフォームの最小値を下回るタッチターゲットなどを検出できます。しかし、自動化ツールが検出できるのは、実際のアクセシビリティ問題の一部に過ぎません。iOS の VoiceOver と Android の TalkBack を使った手動テストは、複雑なフロー全体で読み上げ順序が正しいか、ラベルが意味を持っているか、フォーカス管理が論理的かを検証するために不可欠です。

WCAG 2.2 特有の基準については、特に手動テストが重要です。2.5.8（Target Size）をテストするには、iOS シミュレータのマウスカーソルではなく、実際の指を使って小さなコントロールの操作を試してください。3.3.8（Accessible Authentication）をテストするには、ログインフローでパスワードフィールドへのペーストが許可されているか、パスワードマネージャー（1Password、Bitwarden、システムキーチェーン）をサポートしているか、生体認証をサポートしているかを確認します。2.4.11（Focus Not Obscured）をテストするには、iOS では Switch Control、Android では Switch Access のみでアプリを操作し、フォーカスされた要素がナビゲーションバー、モーダルオーバーレイ、フローティングボタンの裏に消えてしまうことがないか確認します。

包括的なアクセシビリティテスト計画には、少なくとも2台の実機 — iPhone 1台と Android デバイス 1台 — でのテストを含めるべきです。ユーザーのデフォルトの文字サイズとシステム最大文字サイズの両方で、VoiceOver と TalkBack をそれぞれ有効にしてテストしてください。シミュレータのみのテストでは、実環境でのレンダリングの違いや支援技術の挙動を見落とします。

アクセシビリティチェックを CI/CD パイプラインに組み込むことも検討してください。Espresso（Android）と XCUITest（iOS）の両方で、コンテンツ記述、トレイト、有効状態などのアクセシビリティプロパティを検証する自動 UI テストを記述できるため、リグレッションを本番監査で発見するのではなく、コードがマージされる前に検出できます。

今すぐ行動すべき法的・ビジネス上の理由

インクルージョンという道徳的要請を超えて、モバイルアクセシビリティには具体的なビジネス上の根拠があります。障害者インクルージョンで先行する企業は、同業他社と比べて 1.6 倍の収益と 2.6 倍の純利益を生み出しています。米国の障害者は、ほぼ 5,000 億ドルに迫る可処分所得を持っています。そして、障害のあるオンライン消費者の 69% が、使いにくいと感じたアプリやウェブサイトを離脱していることを考えると、あらゆるアクセシビリティの障壁は、決して発生しないコンバージョンを意味します。

法的リスクは高まっています。デジタルアクセシビリティの不備を抱える企業を標的にした訴訟は、年々増加し続けています。DOJ による ADA 準拠の技術標準としての WCAG の採用、2026年の Title II 執行期限、そして 2025年6月の EAA 発効は、ネイティブモバイルアプリケーションを明示的に含む、多法域にまたがるコンプライアンス要件を形成しています。過去に行った WCAG 2.1 監査は、自動的に WCAG 2.2 準拠を示すものではありません。認証フロー、フォームフィールド、インタラクティブコンポーネント、フォーカス管理は、9つの新しい達成基準に照らして再評価する必要があります。

重要なのは、モバイルにおけるアクセシビリティは、ローンチ後に安価に後付けできる機能ではないということです。リリース済みアプリの WCAG 不適合を解消するには、アセットの更新、コンポーネントの再構築、レイアウトの修正、フローの再テスト、場合によっては認証システムのリファクタリングが必要になります。最初からデザインシステムやコンポーネントライブラリに WCAG 2.2 準拠を組み込み — 最小タッチターゲットサイズ、コントラストトークン、セマンティックロール、認証パターンをコンポーネントレベルで強制する — チームは、ローンチ後にアクセシビリティのないアプリを修正する場合と比べて、はるかに少ないコストで済みます。

主なポイント

  • WCAG 2.2 はネイティブの iOS および Android アプリに適用されます。 W3C の WCAG2Mobile ガイダンスは、すべてのレベル A および AA の達成基準をモバイルの画面やビューにマッピングしており、対象となるのはモバイルウェブサイトだけでなく、ネイティブアプリも含まれます。
  • タッチターゲットサイズは、モバイル監査で最も一般的な新たな不適合項目です。 WCAG 2.2 の 24 × 24 の最小値は下限であり、Apple は 44 × 44 pt、Google は 48 × 48 dp を推奨しています。アイコンを視覚的に大きくするのではなく、パディングやプラットフォームネイティブ API を使ってヒットエリアを拡張してください。
  • パスワードフィールドでペーストをブロックすることは、3.3.8 Accessible Authentication に違反している可能性が高いです。 両プラットフォームのログインフローで、システムキーチェーン、パスワードマネージャー、生体認証、OTP の自動入力をサポートし、認知アクセシビリティの要件を満たしてください。
  • VoiceOver と TalkBack を使った手動テストは不可欠です。 自動化ツールが検出できるアクセシビリティ問題は一部に過ぎません。実機で最大文字サイズに設定し、支援技術を有効にした状態で、すべての重要なユーザージャーニーをテストしてください。
  • アクセシビリティは、ローンチ後ではなくデザインシステムに最初から組み込んでください。 ローンチ後にアクセシビリティのないアプリを修正するコストは、最初からアクセシブルなコンポーネント標準を適用する場合と比べてはるかに高くつきます。DOJ、HHS、EAA の執行タイムラインが 2025〜2026年に迫る中、低コストでコンプライアンス対応できる時間的余裕は急速に失われつつあります。