LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

モバイルアプリのアクセシビリティとは — VoiceOver/TalkBackが担う役割

モバイルアプリのアクセシビリティとは、視覚・聴覚・運動・認知などに障害のあるユーザーを含む、あらゆる利用者がアプリを支障なく操作できるよう設計・実装することを指します。W3C（World Wide Web Consortium）が策定するWCAG（Web Content Accessibility Guidelines）では「知覚可能・操作可能・理解可能・堅牢」の4原則を定め、モバイルアプリでもこの考え方が適用されます。

アクセシビリティ対応の中心にあるのがスクリーンリーダーへの対応です。iOSではAppleが開発したVoiceOver、AndroidではGoogleが提供するTalkBackが標準のスクリーンリーダーとして搭載されています。これらは画面上のUIを音声で読み上げ、視覚に依存せずアプリを操作できるようにする機能です。Appleの公式アクセシビリティドキュメントによれば、VoiceOverはiPhone・iPad・Macを含むAppleデバイス全般に対応しており、アプリがアクセシビリティラベルを適切に実装しているかどうかで読み上げの精度が大きく変わります。

アクセシビリティ対応が求められる背景には、障害のあるユーザーへの使いやすさ向上だけでなく、高齢者・一時的な怪我による操作制限・騒音環境での画面参照困難など、あらゆる利用状況に対する配慮があります。また国内では障害者差別解消法の改正（2024年4月施行）により、民間事業者にも合理的配慮の提供が義務化されており、アプリのアクセシビリティ対応はリスク管理の観点からも重要度が増しています。

準拠の指針 — WCAG 2.1 AA・WCAG2Mobile・デジタル庁ガイドブック

モバイルアプリのアクセシビリティ対応にあたって参照すべき主要な指針は3つあります。W3Cが策定するWCAG 2.1、モバイル向けに拡張されたWCAG2Mobile、そして国内実務で参照されるデジタル庁のガイドブックです。

WCAG 2.1 AA — モバイルでも共通の物差し

W3CのWCAG（Web Content Accessibility Guidelines）2.1は2018年に勧告され、モバイルデバイスの利用を前提とした達成基準が加わりました^*1。AAレベル（3段階中の中間）はウェブ・モバイルアプリいずれにおいても実務上の準拠目安として広く参照されています。WCAG 2.1では「知覚可能・操作可能・理解可能・堅牢」の4原則に基づいた達成基準が定義されており、モバイルアプリでも指針として適用できます。

2023年にはWCAG 2.2が勧告され、フォーカス外観・ドラッグ操作の代替手段など新たな達成基準が追加されています^*1。改修の優先度としてはまずWCAG 2.1 AAへの対応を足がかりにしつつ、WCAG 2.2の追加基準も参照することが望ましいです。

WCAG2Mobile — モバイル固有の適用ガイドライン（策定中）

W3CのMobile Accessibility Task Forceは、WCAGをモバイルに適用するための「WCAG2Mobile」を策定中です。2025年時点ではドラフト段階であり、最終勧告には至っていません。詳細な策定状況はW3Cの公式サイトで確認することをお勧めします。このドラフトではタッチターゲットのサイズ、ポインタジェスチャの代替手段、動的フォントサイズへの対応など、スマートフォン固有の操作環境に対する考え方が整理されています。

デジタル庁ウェブアクセシビリティ導入ガイドブック — 国内実務の参照先

デジタル庁が公開している「ウェブアクセシビリティ導入ガイドブック」は、WCAG 2.1に基づく原則の整理と実践的なチェックリストを提供しています^*2。主にウェブサービスを対象としていますが、アクセシビリティ対応の進め方や組織内の合意形成プロセスはモバイルアプリ対応にも参考になります。国内のシステム調達・改修の場で参照されることが増えており、外注先との共通言語としても活用できます。

対応を外注で進める流れ — 現状診断から継続運用まで

アクセシビリティ対応を外注で進める場合、フェーズを5つに分けて取り組むことが実務上の一般的なアプローチです。各フェーズで何を委託し、何を社内で判断するかを整理しておくと、委託先とのコミュニケーションが円滑になります。

フェーズ1：現状診断（アクセシビリティ監査）

既存アプリを対象に、WCAG 2.1 AAの達成基準に対する現状のギャップを洗い出します。自動ツールによるスキャンと、専門者による手動確認を組み合わせることが一般的です。iOS・Androidそれぞれの実機でVoiceOver・TalkBackを操作し、読み上げが適切に機能しているかを確認します。診断の結果は「Critical・High・Medium・Low」などのリスクレベルで整理され、改修の優先度付けに使います。

この工程から外注に入ると、対応範囲と費用を見積もりやすくなる利点があります。診断なしに実装から着手すると、改修範囲が不明確なまま工数が膨らむリスクがあります。

フェーズ2：指針に基づく改修方針の策定

診断結果をもとに、WCAG 2.1 AA準拠に向けた改修方針と優先順位を決定します。対応すべき箇所が多い場合は、ユーザー影響度が高い画面（ログイン・主要フロー・エラー通知など）から優先して対応する方針が合理的です。外注先には診断レポートと改修対象画面リストを提示し、見積もりの根拠を具体化します。

フェーズ3：実装

アクセシビリティラベルの付与、フォーカス順序の設定、コントラスト比の調整、動的フォントサイズへの対応、タップ領域の拡大など、各プラットフォームの仕様に従って実装します。iOSではAppleの公式アクセシビリティドキュメントに記載されたaccessibilityLabel・accessibilityHintなどのAPIを用い、AndroidではGoogleの公式ドキュメントに基づきcontentDescriptionやimportantForAccessibilityを設定します。

実装は既存コードへの変更を伴うため、リグレッションテスト（既存機能への影響確認）と合わせて品質を担保します。フレームワーク（SwiftUI（Apple）、Jetpack Compose（Android）など）によっても設定方法が異なるため、外注先がそのフレームワークの経験を持つかどうかを事前に確認することが大切です。

フェーズ4：スクリーンリーダー実機検証

VoiceOver（iOS）およびTalkBack（Android）を使った実機テストで、想定通りに読み上げられるかを確認します。この工程では自動テストツールでは検出できないUX上の問題（読み上げ順序の不自然さ、ボタン名称の不明瞭さなど）が見つかることがあります。実機テストは専用の知識と端末環境が必要であり、外注に向いている工程の一つです。

フェーズ5：継続運用

アクセシビリティ対応は一度完了すれば終わりではなく、機能追加・OSアップデートのたびに再確認が必要です。アプリリリースサイクルに合わせた定期的な監査や、新機能追加時のチェックリストを整備しておくと、継続的な品質維持がしやすくなります。

実装の勘所 — ラベル・フォーカス・コントラスト・動的フォント・タップ領域

アクセシビリティ対応の実装では、5つの観点が中心的なチェック項目となります。それぞれOS固有の仕様があるため、Appleの公式アクセシビリティドキュメントおよびAndroidの公式ドキュメントを一次情報として参照しながら進めることが大切です。

アクセシビリティラベルと状態の読み上げ

UIコンポーネントにはスクリーンリーダーが読み上げるためのラベルを設定します。Appleの仕様ではaccessibilityLabel（要素の名称）・accessibilityHint（操作後の結果説明）・accessibilityValue（スライダー等の現在値）を適切に設定することが求められます。Androidの仕様ではcontentDescriptionが同様の役割を担います。ラベルが未設定のボタンやアイコンは、スクリーンリーダーが「ボタン」とのみ読み上げるため、操作できても意味が分からない状態になります。

また、チェックボックスやトグルスイッチの「オン/オフ」状態、プログレスバーの進捗、エラーメッセージの出現など、動的に変化する状態をスクリーンリーダーに伝えることも重要な実装ポイントです。

フォーカス順序

キーボードや外部スイッチコントロールを使う場合、フォーカスが画面上の論理的な順序（通常は左上から右下へ）で移動することが求められます。Appleの公式ドキュメントではaccessibilityElements配列でフォーカス順を明示的に制御できると説明されており、AndroidではaccessibilityTraversalBefore/Afterで隣接要素を指定できます。レイアウトが複雑なカードUIやモーダルダイアログでは、フォーカスが意図しない要素に飛びやすいため、実機テストで確認が必要です。

コントラスト比

WCAG 2.1 AA基準では、通常テキストのコントラスト比は4.5:1以上、大きなテキスト（18pt以上または太字14pt以上）は3:1以上が求められます^*1。背景色とテキスト色の組み合わせが基準を下回ると、弱視・色覚特性を持つユーザーが文字を読みにくくなります。デザインシステムの配色ガイドラインとコントラストチェックツールを組み合わせて、設計段階から基準をクリアする配色を選ぶことが手戻り防止になります。

動的フォントサイズ（Dynamic Type / フォントスケール）

iOSのDynamic Type（Apple公式の仕様）、AndroidのFont Scale設定を使うと、ユーザーがOSで設定した文字サイズが自動的にアプリのUIに反映されます。固定ピクセルでフォントサイズを指定している場合、ユーザーがアクセシビリティ設定で文字を大きくしてもアプリ内の文字が変わらないため、視覚サポートとしての機能が失われます。テキストサイズをsp（Androidではdp換算）やuiKit/SwiftUIの動的サイズクラスで指定し、レイアウトが崩れないことを複数のフォントスケール設定で検証することが求められます。

タップ領域

指や補助具でのタップ操作を考慮し、インタラクティブ要素のタップ可能領域は十分な大きさを確保します。WCAG 2.2では新たな達成基準（2.5.8 Target Size(Minimum)）でターゲットサイズの下限が規定されており、最新の仕様はW3Cの公式ページで確認できます^*1。アイコンボタンが視覚的に小さく見えても、タップ領域をコードで広げることで使いやすさを改善できます。iOSではhitTestメソッドのオーバーライド、Androidではpadding/clickable領域の調整で対応できます。

外注の使いどころ — 診断・実装・検証の委託判断軸

アクセシビリティ対応の工程を内製で担うには、iOS・AndroidそれぞれのアクセシビリティAPIに関する深い知識、スクリーンリーダーの操作経験、WCAG基準の解釈能力、そして実機環境（複数OSバージョン・端末）が必要です。これらを内製チームが保有していない場合、対応品質が不均一になるリスクがあります。

外注に向いている3工程

外注を検討しやすい工程として、現状診断・実装・実機検証の3つが挙げられます。現状診断は専門知識と診断ツールが必要なため外注でのスタートが現実的です。実装はフレームワーク経験と細かなOS仕様の理解が必要で、経験のある外部エンジニアに依頼することで品質を安定させられます。実機検証はVoiceOver・TalkBackの操作習熟度が結果の精度に直結し、専門チームへの委託メリットが大きい工程です。

内製が有効な工程

一方、改修方針の意思決定（どの画面を優先するか）と継続運用の体制整備（リリースチェックリストの運用）は社内で主体的に担う必要があります。外注先が診断・実装・検証を担ったとしても、優先順位の判断と運用プロセスへの組み込みは事業側の判断が不可欠です。

委託先選定で確認すべき観点

委託先を選定する際には、iOS/Androidそれぞれのアクセシビリティ実装経験の有無、WCAG 2.1準拠の対応実績、スクリーンリーダー実機テストの実施体制、修正後の再検証（リテスト）対応の可否を確認することが大切です。診断レポートの形式と改修指示書の粒度も事前に確認しておくと、社内への説明と発注後の品質管理が円滑になります。

まとめ — アクセシビリティ外注を成功に導く3つの判断軸

本稿ではモバイルアプリのアクセシビリティ対応を外注で進める方法を整理しました。要点を3つに集約すると次の通りです。

第一に、VoiceOver（iOS）・TalkBack（Android）への対応がアクセシビリティ実装の中心であり、WCAG 2.1 AAレベルが共通の準拠目安です。W3CのWCAG2Mobileドラフトやデジタル庁のガイドブックも合わせて参照すると、対応範囲の整理と社内合意形成がしやすくなります。

第二に、外注の進め方は「現状診断→改修方針→実装→実機検証→継続運用」の5フェーズが基本です。現状診断から外注に入ることで対応範囲と費用を見積もりやすくなり、内製チームの負担を抑えながら品質を確保できます。

第三に、ラベル・フォーカス順序・コントラスト比・動的フォントサイズ・タップ領域の5点が実装の主要チェック項目です。これらはApple・Androidそれぞれの公式ドキュメントに実装方法が記載されており、外注先との合意基準として活用できます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：W3C「Web Content Accessibility Guidelines (WCAG) 2.1」（2018年勧告）／「Web Content Accessibility Guidelines (WCAG) 2.2」（2023年勧告）
2. *2　出典：デジタル庁「ウェブアクセシビリティ導入ガイドブック」

Tweet