モバイルWebアクセシビリティ実践ガイド：タッチ操作、拡大、リフロー、OS設定

モバイルのアクセシビリティは、PC向けページを狭い画面に収めるだけでは実現できません。

指での操作、画面拡大、縦横の切り替え、スクリーンリーダー、外付けキーボード、OSの表示設定まで含めて、情報を読み取り、操作を完了できるかを確かめる必要があります。

最初に確認したいのは、次の6点です。

• ボタンやリンクを狙って押せるか
• 拡大しても文字や操作部品が欠けないか
• ピンチやドラッグ以外の操作方法があるか
• フォームの入力、エラー修正、送信まで迷わず進めるか
• VoiceOverやTalkBack、キーボードで論理的な順序に移動できるか
• 文字サイズや動きの軽減など、利用者の設定を妨げていないか

WCAG 2.2を基準にする理由

Webアクセシビリティとは、心身の特性や利用環境にかかわらず、Web上の情報と機能を利用できるように設計し、実装し、検証することです。

WCAGは、そのための国際的なガイドラインです。

W3CのWCAG 2.2勧告は、2.1を土台にモバイル操作にも関係する達成基準を追加しています。

適合目標を定める際は、組織に適用される規格や契約を確認したうえで、WCAG 2.2のレベルAAを実務上の基準にすると整理しやすくなります。

追加基準の背景は、サイト内のWCAG 2.2で追加された達成基準の解説でも確認できます。

なお、2.4.13 Focus AppearanceはレベルAAAです。

レベルAAの2.4.11 Focus Not Obscured (Minimum)と混同しないようにします。

タッチターゲットの大きさと間隔

タッチターゲットとは、ボタンやリンクなど、指で反応させられる領域です。

アイコンが見える範囲だけでなく、その周囲の余白を含む実際の反応領域を確認します。

CSSピクセル、ポイント、dpは別の単位であり、同じ数値へ機械的に換算するものではありません。

WebではWCAGの適合条件を確認しつつ、主要な操作には余裕のあるコンポーネント基準を設け、実機で押しやすさを確かめます。

• アイコンだけを小さく置かず、余白を含む反応領域を確保する
• 隣接する操作を離し、誤って別の操作を選びにくくする
• 押下、選択、キーボードフォーカスの状態を見た目で区別する
• 状態の違いを色だけに頼らず、形、枠、文言なども使って示す
• 削除や送信など影響の大きい操作には、確認または取り消し方法を用意する

次の例では、見た目が小さいアイコンでも、ボタン自体の領域を広げています。

<button class="icon-button" type="button" aria-label="検索">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

.icon-button {
  min-inline-size: 3rem;
  min-block-size: 3rem;
  padding: .5rem;
}

.icon-button:focus-visible {
  outline: .1875rem solid #f0a000;
  outline-offset: .125rem;
}

拡大とリフローに耐えるレイアウト

リフローとは、表示領域や文字の大きさに応じて内容が折り返され、読み進める方向と直角のスクロールを原則として増やさないことです。

WCAG 2.2の1.4.10では、縦に読むコンテンツを幅320 CSSピクセル相当で表示したとき、情報や機能を失わず、原則として二方向のスクロールを不要にすることが求められます。

地図やデータ表など、意味を保つために二次元配置が必要な部分には例外があります。

viewportには幅と初期倍率を指定し、user-scalable=noや過度なmaximum-scaleで利用者の拡大を妨げないようにします。

<meta name="viewport" content="width=device-width, initial-scale=1">

img, video {
  max-inline-size: 100%;
  block-size: auto;
}

.layout {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
  gap: 1rem;
}

.table-wrap {
  max-inline-size: 100%;
  overflow-x: auto;
}

固定幅だけでなく、固定した高さとoverflow: hiddenの組み合わせにも注意が必要です。

文字が大きくなると、ボタンのラベルやエラーメッセージが二行になり、固定高さから欠けることがあります。

テキスト間隔の数値は耐性試験に使う

WCAG 2.2の1.4.12は、行の高さをフォントサイズの1.5倍、段落後の間隔を2倍、文字間を0.12倍、単語間を0.16倍に変更しても、内容や機能を失わないことを求めます。

これらは、すべてのサイトに初期値として設定する数値ではありません。

利用者の上書き設定にレイアウトが耐えられるかを試す条件として使います。

ジェスチャと画面の向きに代替を用意する

ピンチ、スワイプ、ドラッグは便利ですが、それだけで機能を提供すると、細かな指の動きが難しい利用者や補助機器の利用者が操作を完了できません。

機能が特定の操作方法だけに閉じないよう、画面上のボタンやメニューからも同じ結果へ進めるようにします。

タップは、指を触れた瞬間ではなく、離した時点で確定できる実装を基本にします。

途中で指を対象外へ動かして中止できるか、実行後に元へ戻せるかも確認します。

また、用途上どうしても必要な場合を除き、画面を縦向きまたは横向きの一方へ固定しません。

操作説明も「左上を押す」だけで済ませず、ボタン名を使って向きに依存しない形にします。

モバイルフォームの入力とエラー修正

フォームでは、入力欄を大きくするだけでは不十分です。

何を入力するか、どの形式が必要か、どこを直せば送信できるかを、視覚表示と読み上げの双方で理解できるようにします。

• labelを入力欄と関連付け、プレースホルダーだけをラベルにしない
• type、inputmode、autocompleteを入力内容に合わせる
• 入力例や条件を入力欄の近くに置き、aria-describedbyで関連付ける
• エラー箇所の近くに、原因と直し方を具体的に示す
• 複数のエラーがある場合は、フォームの先頭にも一覧を置く
• 同じ手続きで一度入力した情報を、必要な理由なく再入力させない

<label for="phone">電話番号</label>
<input id="phone" name="phone" type="tel"
       inputmode="tel" autocomplete="tel"
       aria-describedby="phone-hint">
<p id="phone-hint">例：09012345678</p>

ラベル、エラー通知、入力支援の設計は、サイト内のフォームと入力UIのアクセシビリティガイドで詳しく扱っています。

文字、色、動きの設定を尊重する

利用者はOSやブラウザーで、文字サイズ、コントラスト、配色、動きの軽減などを調整することがあります。

サイト側の指定で設定を打ち消さず、変更後にも情報と操作を保てるようにします。

• 本文の文字を固定値だけで設計せず、文字拡大時の折り返しを確認する
• 通常の文字は背景とのコントラスト比4.5対1以上を基準にする
• 色だけでエラー、選択、成功などの状態を区別しない
• prefers-reduced-motionに応じて、大きな移動や反復する動きを止めるか弱める
• prefers-color-schemeに対応する場合は、ライトとダークの両方で文字、アイコン、フォーカス表示のコントラストを確認する

ダークモードを用意すること自体は、WCAG適合の条件ではありません。

選べる配色を増やす場合も、それぞれの配色で読み取りと操作が成立することが条件です。

@media (prefers-reduced-motion: reduce) {
  .drawer, .toast, .carousel {
    animation: none;
    transition: none;
    scroll-behavior: auto;
  }
}

ドロワー、通知、フォーカスの扱い

モバイル特有の部品は、開閉や状態変化が画面上で分かっても、読み上げやキーボードでは伝わらないことがあります。

ドロワーとダイアログ

モーダルとして開くドロワーやダイアログでは、開いた後のフォーカス位置を決め、操作中のフォーカスを内部に保ち、閉じた後は起点のボタンへ戻します。

非モーダルの部品まで機械的にフォーカストラップする必要はありません。

外付けキーボードを想定し、閉じるボタンとEscキーの動作も確認します。

通知とライブリージョン

保存完了などの控えめな状態通知にはrole=status、すぐ対応が必要なエラーにはrole=alertを使い分けます。

通知を短時間で消す場合は、内容を理解して操作する時間を確保します。

同じ領域を頻繁に更新すると読み上げが続くため、必要な変化だけを伝えます。

見えるラベルとフォーカス

「検索」「送信」などの可視ラベルは、aria-labelなどで設定するアクセシブルネームにも含めます。

固定ヘッダー、Cookie通知、画面下部の操作バーが、フォーカスを完全に隠していないかも確認します。

フォーカス設計の確認方法は、サイト内のキーボード操作とフォーカス表示の実務ガイドも参考になります。

実機テストの手順

開発者ツールの画面幅切り替えだけでは、指での押しやすさ、ソフトウェアキーボード、VoiceOverやTalkBackの挙動までは確認できません。

自動検査と実機での手動検査を組み合わせます。

1. 拡大を確認する：ピンチズームと文字サイズ変更を行い、欠落、重なり、操作不能がないかを見る。
2. 狭い表示を確認する：幅320 CSSピクセル相当で、例外部分を除いて二方向のスクロールが生じないかを見る。
3. 文字間隔を変更する：WCAG 1.4.12の試験値を適用し、文字やボタンが切れないかを見る。
4. 縦横を切り替える：どちらの向きでも内容を読み、操作を完了できるかを見る。
5. 指で操作する：主要な操作を片手でも選びやすいか、隣のボタンを誤って押さないかを見る。
6. ジェスチャの代替を使う：ピンチ、スワイプ、ドラッグを使わずに同じ機能へ到達する。
7. VoiceOverとTalkBackで移動する：見出し、リンク、フォーム、通知の名前と順序を確認する。
8. 外付けキーボードで移動する：フォーカスの順序、見た目、隠れ、Escキー、開閉後の戻り先を確認する。
9. フォームで失敗する：未入力や形式違いを意図的に作り、エラーを見つけて修正できるか確かめる。
10. OS設定を変える：文字拡大、動きの軽減、ライトとダークの各配色で表示を確認する。

画面の読み込み中や更新直後に部品が大きく移動すると、狙っていた場所とは別の操作を押す原因になります。

画像の寸法を確保し、遅れて表示される要素の領域を予約して、操作中のレイアウト変化も抑えます。

改善を継続するための受け入れ基準

確認項目を「配慮する」のような抽象語で終わらせると、担当者によって判定が変わります。

次のように、対象、操作、期待結果を組み合わせて書きます。

• 主要なボタンは、実機で隣の操作を誤って選ばずに押せる
• 本文を200％まで拡大しても、文章と操作部品が欠けない
• カルーセルは、スワイプを使わず「前へ」と「次へ」で操作できる
• フォーム送信に失敗したとき、エラー箇所と修正方法を視覚表示と読み上げで把握できる
• モーダルを閉じると、フォーカスが開いたボタンへ戻る

共通ボタン、フォーム部品、ドロワーなどをコンポーネント単位で直し、代表画面で実機検証した後、回帰テストへ組み込みます。

モバイル最適化の結論

モバイルWebアクセシビリティは、レスポンシブ対応、タッチ領域、代替操作、入力支援、支援技術への通知を別々に確認して初めて、利用者が目的を達成できる設計になります。

まず、拡大を妨げないこと、主要操作を押しやすくすること、複雑なジェスチャへボタン操作を用意することから着手します。

そのうえで、実機と支援技術を使った検証を公開前と更新後に繰り返せば、見た目の調整だけでは見つからない障壁を減らせます。