Webアクセシビリティとは、障害の有無や年齢、利用環境にかかわらず、必要な情報と機能を利用できるようにWebサイトを設計、実装、運用する考え方です。
スマートフォンやタブレットでは、小さな画面、指による操作、端末の支援機能との連携を同時に考える必要があります。
PC向け画面をそのまま縮小するだけでは、文字が読めてもボタンを押せない、見た目では操作できても読み上げでは状態が伝わらない、といった問題が残ります。
この記事では、Webアクセシビリティの基本を踏まえ、モバイル画面の設計、HTML実装、実機検証を一つの流れとして整理します。
モバイルで起こりやすい四つの問題
モバイルの使いにくさは、画面の狭さだけから生じるものではありません。
表示、操作、支援機能、入力の四つに分けると、確認すべき箇所を見落としにくくなります。
| 対象 | 起こりやすい問題 | 設計時の確認項目 |
|---|---|---|
| 表示 | 文字や操作部品が密集し、拡大や横スクロールの負担が増える | 狭い画面でも内容が自然に折り返され、文字を拡大して読めるか |
| タッチ操作 | ボタンやリンクを押し間違えやすい | 操作領域に十分な大きさと間隔があり、複雑なジェスチャー以外でも操作できるか |
| 支援機能 | 要素の名前、役割、開閉状態が読み上げで伝わらない | 意味に合うHTML要素と明確なラベルを使っているか |
| フォーム | 入力欄の目的や入力方法がわかりにくい | 画面に見えるラベルと入力欄が対応し、内容に合う入力形式が指定されているか |
WCAGをモバイル設計に当てはめる
WCAGは、Webコンテンツを知覚し、操作し、理解できるようにするための国際的なガイドラインです。
モバイル専用の別基準として扱うのではなく、狭い画面、タッチ操作、読み上げなどの利用場面に既存の考え方を当てはめます。
このとき確認したいのは、拡大や画面幅の変更に内容が追従すること、複雑なジェスチャーだけに操作を依存させないこと、画面に見えるラベルと支援機能に伝わる名前をわかりやすくすることです。
個別の達成基準を確認するときは、対象とするWCAGの版と適合レベルをそろえて判断します。
版ごとの違いを確認したい場合は、WCAG 2.2で追加された達成基準の解説も参照してください。
文字の読みやすさと画面の折り返し
本文の文字サイズと行間は、読みやすさを検討する出発点です。
たとえば、本文を16px、行間を1.6にした次の指定は初期設定として使えますが、この数値だけで読みやすさが決まるわけではありません。
body {
font-size: 16px;
line-height: 1.6;
}
フォント、文章量、画面幅が変わっても文字が重ならず、拡大したときに内容が画面から欠けないかを確認します。
横スクロールが避けられない表やコードは、本文全体ではなく、その要素だけをスクロールできる構成にします。
タッチ操作で押し間違いを減らす
リンクやボタンは、指で狙いやすい操作領域と、隣の要素との間隔を確保します。
一律の寸法だけで合否を決めず、文字を拡大した状態や片手で操作する場面でも、目的の要素を選べるかを実機で確かめます。
アイコンだけのボタンは、意味を推測しなければならないことがあります。
「送信」「メニューを開く」のように動作がわかる文字を表示するか、見た目を変えずに支援機能へ明確な名前を伝えます。
スワイプやピンチでしか実行できない操作には、タップできるボタンなどの代替手段を用意します。
同じ機能へ単純な操作でも到達できれば、細かな指の動きが難しい利用者にも使いやすくなります。
セマンティックHTMLとスクリーンリーダー
セマンティックHTMLとは、見た目ではなく役割に合うHTML要素を使うことです。
リンクにはa要素、実行する操作にはbutton要素を使うと、ブラウザーと支援機能へ役割を伝えやすくなります。
スクリーンリーダーは、画面上の文字や要素の情報を音声などで伝える支援機能です。
VoiceOverやTalkBackで確認するときは、表示文字だけでなく、ボタンの名前、役割、開閉状態、読み上げ順を確かめます。
スクリーンリーダーの仕組みと確認項目は、スクリーンリーダー対応の基本で詳しく解説しています。
開閉メニューの状態を伝える例
ハンバーガーメニューでは、ボタンが何をするのかに加えて、メニューが開いているかどうかを伝えます。
<button
type="button"
aria-expanded="false"
aria-controls="global-menu">
メニューを開く
</button>
<nav id="global-menu" aria-label="主なメニュー">
...
</nav>
実装時は、メニューの表示と非表示を切り替える処理に合わせて、aria-expandedの値も更新します。
見た目だけが変わり、支援機能に伝わる状態が古いまま残らないようにします。
フォームでは見えるラベルを入力欄と結び付ける
入力欄の目的は、プレースホルダーや読み上げ専用の説明だけに任せず、画面上のラベルでも示します。
labelのforと入力欄のidを一致させると、ラベルと入力欄の対応が明確になります。
<label for="email">メールアドレス</label>
<input id="email" name="email" type="email">
type="email"やtype="tel"のように入力内容に合う形式を指定すると、モバイル端末で内容に適した入力画面を提示しやすくなります。
フォーム全体の入力支援とエラー表示は、アクセシブルなフォーム設計の基本も確認してください。
レスポンシブ設計とズーム
レスポンシブ設計は、画面幅に応じてレイアウトを調整する設計方法です。
モバイルから情報の優先順位を整理すると、狭い画面でも内容と操作の順序を保ちやすくなります。
モバイルアクセシビリティとレスポンシブ設計では、レイアウトを組み立てる手順を詳しく紹介しています。
ビューポートは端末幅に合わせつつ、利用者のズームを妨げない設定にします。
<meta name="viewport" content="width=device-width, initial-scale=1">
ズームを無効にする指定は避け、拡大後も本文、メニュー、フォームを操作できるかを確認します。
自動検査と実機テストを組み合わせる
自動検査は、HTMLや色、ラベルなど、規則に照らして機械的に判定できる問題を見つける方法です。
Lighthouse、axe DevTools、WAVEなどを使うと、修正候補を効率よく洗い出せます。
ただし、自動検査の結果だけでは、実際の読み上げ順が理解しやすいか、指で狙ったボタンを押せるかまでは判断できません。
次の順序で実機テストを行い、利用場面に沿って確認します。
- 画面を拡大し、文字の重なりや内容の欠落がないか確認する
- リンクとボタンをタップし、押し間違いや操作しにくい箇所を探す
- 外部キーボードで移動し、フォーカスの順序と表示を確認する
- VoiceOverまたはTalkBackで、見出し、リンク、ボタン、開閉状態を読み上げる
- フォームを入力し、ラベルと入力欄の対応を確認する
公開前に確認したいチェックリスト
- 狭い画面や文字の拡大時にも、内容が重ならず読める
- リンクとボタンに、押しやすい大きさと間隔がある
- 複雑なジェスチャーを使わなくても同じ操作を完了できる
- ボタンの名前、役割、状態が支援機能に伝わる
- フォームのラベルと入力欄が対応している
- 利用者のズーム操作を妨げていない
- 自動検査と実機テストの両方を行っている
モバイルWebアクセシビリティは、特定の利用者だけのために後から追加する機能ではありません。
表示、操作、支援機能、入力を設計段階から確認し、実機で検証することで、多様な環境から情報と機能を利用しやすいWebサイトになります。