Webサイトのアクセシビリティを改善する方法:実践ガイド

アクセシブルなWebサイトとは、障害の有無やWebの利用方法にかかわらず、誰もが使えるサイトのことです。スクリーンリーダーを使う人、キーボードだけで操作する人、文字を拡大して読む人、色の見え方に制約がある人、手に震えがある人。同じ改善は、腕を骨折している人、強い日差しの下で小さなスマートフォンの画面を見ている人、回線が遅い人にも役立ちます。

広く使われている基準はWeb Content Accessibility Guidelines (WCAG)で、現在のバージョンは2.2です。アクセシビリティに関する法律や調達基準の多くがWCAGを参照しており、最もよく求められるのはレベルAAです。このガイドでは、よくある障壁の大半を取り除ける修正に絞って説明し、そのあとでテストの方法を紹介します。

まず自動チェック、次に手動でテスト

明らかな問題を見つけるには、自動スキャンが最も手早い方法です。Rudraの無料アクセシビリティチェッカーは、実際のブラウザでページを読み込み、広く使われているオープンソースのテストエンジンaxe-coreを実行します。不合格になったルールごとに、影響を受ける要素の数と影響の深刻度を一覧表示します。対象は、altテキストの欠落、ラベルのないフォーム項目、コントラスト不足、ページ言語の未指定、中身のないボタンやリンクなどです。

最も効果の大きい修正

1. 画像に意味のある代替テキストを付ける

すべての <img> に alt 属性が必要です。情報を伝える画像では、何が写っているかだけでなく、その文脈で画像が伝えている内容を説明します。alt="Line chart: sign-ups doubled after the March redesign"(折れ線グラフ:3月のリニューアル後に登録数が倍増)のほうが、alt="chart"(グラフ)よりも役に立ちます。純粋に装飾目的の画像には、空の alt="" を指定して、スクリーンリーダーが読み飛ばせるようにします。リンクやボタンになっている画像では、その動作を説明します(「検索」「レポートをダウンロード」など)。複雑なグラフの場合は、主要なデータを近くの本文や表でも示す必要があります。

2. すべてのフォーム項目にラベルを付ける

各入力欄には、コード上で関連付けられた、目に見えるラベルが必要です。<label for="email">Email address</label> のあとに <input id="email" type="email" autocomplete="email"> を続ける形です。プレースホルダーのテキストはラベルの代わりになりません。入力を始めたとたんに消えてしまい、コントラストが低いことも多いからです。エラーは(赤い枠線だけでなく)項目の横にテキストで表示し、直し方を説明したうえで、aria-describedby で項目と関連付けます。

3. 色のコントラストを適切にする

• 通常のテキスト: 背景に対して 4.5:1 以上のコントラスト比(WCAG 1.4.3、レベルAA)。
• 大きなテキスト(24 px以上、太字の場合は約18.7 px以上): 3:1 以上。
• UIコンポーネントと意味を持つグラフィック(入力欄の枠線、フォーカスインジケーター、意味を伝えるアイコンなど): 隣接する色に対して 3:1 以上(WCAG 1.4.11)。
• 色だけに頼らない(WCAG 1.4.1)。段落内のリンクは、色以外の手がかり(通常は下線)でも見分けられるようにし、エラーを赤色だけで示すことも避けます。

ブラウザの開発者ツールでテキスト要素を検証するとコントラスト比が表示されるので、作業しながら色を確認して調整できます。薄いグレーの文字、写真に重ねた文字、プレースホルダーのテキストには特に注意してください。

4. すべてをキーボードで操作できるようにする

マウスでできることはすべて、Tab、Shift+Tab、Enter、Space、矢印キー、Escapeでもできなければなりません。クリックできるようにした <div> ではなく、本物の <button> 要素と <a href> 要素を使ってください。前者は追加の実装をしないかぎり、キーボードでフォーカスすることも実行することもできません。はっきり見える代わりの表示を用意せずに、フォーカスのアウトラインを消してはいけません。:focus-visible を使えば、キーボードユーザーに対してだけスタイルを適用できます。固定ヘッダーやCookieバナーがフォーカス中の要素を隠さないこと(WCAG 2.2で新設された達成基準2.4.11)、ダイアログが開いている間はフォーカスを内部に閉じ込め、閉じたら元の位置に戻すことを確認し、ページの先頭には「メインコンテンツへスキップ」リンクを追加します。

5. 見出しとランドマークでページを構造化する

スクリーンリーダーのユーザーは、見出しから見出しへ移動しながらページを読み進めることがよくあります。ページの内容を表す <h1> を1つ置き、そのあとに <h2>、<h3> を論理的な順序で使います。見出しレベルは文字の大きさではなく、構造に基づいて選んでください。各領域を <header>、<nav>、<main>、<footer> で囲んでおけば、利用者はコンテンツへ直接移動できます。

6. ページの言語と固有のタイトルを設定する

<html lang="en">(またはサイトの言語)を指定すると、スクリーンリーダーがテキストをどう発音すべきかを判断できます。固有で内容のわかる <title> は、ページを開いたときに最初に読み上げられるものであり、ブラウザのタブの中からそのページを見分ける手がかりにもなります。

7. 単独でも意味が通じるリンクとボタンにする

スクリーンリーダーのユーザーは、ページ内のリンクをすべて一覧表示できます。そこに「こちらをクリック」や「続きを読む」が10回並んでいても、何の手がかりにもなりません。「料金ガイドを読む」のような文言にしましょう。虫眼鏡や閉じる「×」のようなアイコンだけのボタンには、アクセシブルな名前が必要です。例: <button aria-label="Close">。

8. ターゲットを押しやすい大きさにする

WCAG 2.2では、ポインターのターゲットを 24 × 24 CSSピクセル以上にする、または各ターゲットを囲む直径24ピクセルの円がほかと重ならない間隔を空ける、というレベルAAの要件(2.5.8)が追加されました。タッチスクリーンでは、44 × 44ピクセル程度(レベルAAAの基準)のより大きなターゲットのほうがさらに望ましいと言えます。

9. 拡大表示とリフローに対応する

user-scalable=no や maximum-scale=1 で拡大を無効にしてはいけません。コンテンツは、幅320 CSSピクセルでも横スクロールなしで1カラムに収まるようリフローする必要があります。これは、一般的なデスクトップ画面で400%に拡大したときの幅にあたります(WCAG 1.4.10)。レスポンシブなレイアウトにしておけば、大部分は達成できます。Webサイトをモバイルフレンドリーにする方法もご覧ください。

10. メディアと動きを慎重に扱う

動画にはキャプション(字幕)を、音声には書き起こしを用意します。音声を自動再生してはいけません。カルーセルやアニメーションには一時停止ボタンを付け、prefers-reduced-motion メディアクエリを尊重して、動きを減らすよう設定している人には、必須でないアニメーションを控えめにするか取り除きます。

11. ARIAよりもネイティブのHTMLを優先する

ARIA属性は支援技術が読み上げる内容を変えますが、要素の動作は変えません。<div role="button"> には、キーボード操作の処理を自分で書く必要があります。<button> なら最初から備わっています。可能なかぎりネイティブの要素を使い、ARIAを追加するのはHTMLに相当するものがない場合だけにして、W3CのARIA Authoring Practices Guideにあるパターンに従ってください。

15分でできる手動テスト

1. マウスを抜く。 ページの先頭からTabキーで移動していきます。どの時点でもフォーカスの位置が見えますか。すべてのリンク、ボタン、メニュー、フォーム項目にたどり着いて操作できますか。ポップアップはEscapeで閉じられますか。
2. 200%、続いて400%に拡大する。 テキストはリフローしますか、それとも横にスクロールしなければなりませんか。重なったり消えたりするものはありませんか。
3. スクリーンリーダーを数分間試す。 NVDA(無料、Windows)、VoiceOver(macOSとiOSに標準搭載)、TalkBack(Android)のいずれかを使います。見出しとリンクを一覧表示し、フォームに入力してみてください。すべてがはっきり読み上げられますか。
4. 画像を確認する。 altテキストを読みます(スクリーンリーダーか、ブラウザのアクセシビリティインスペクターで確認できます)。大事なことが説明されていますか。
5. ページをグレースケールで見る(ほとんどのOSにカラーフィルターの設定があります)。色だけで伝えている情報はありませんか。

アクセシビリティをプロセスに組み込む

• 共通のコンポーネントとテンプレートの問題から先に直します。ヘッダーやフォームのコンポーネントを1つ直せば、それを使っているすべてのページが直ります。
• 開発パイプラインに自動チェックを追加します。たとえばエンドツーエンドテストにaxe-coreを組み合わせれば、リリース前にデグレードを検出できます。
• 新機能の完了条件(Definition of Done)に、キーボードとコントラストのチェックを含めます。
• 障壁を報告できる窓口を添えたアクセシビリティ方針を公開し、寄せられた声に対応します。

よくある間違い

• オーバーレイ型のウィジェットでアクセシビリティを解決しようとする。ページの上に追加したスクリプトでは、土台となるマークアップを直せません。また、多くの障害当事者が、オーバーレイはかえって邪魔になると報告しています。
• altテキストにキーワードを詰め込む、あるいは「〜の画像」で書き始める(画像であることはスクリーンリーダーがすでに読み上げています)。
• ラベルの代わりにプレースホルダーのテキストを使う。
• 見た目を理由にフォーカスのアウトラインを消す。
• あらゆるものに aria-label を付け、ときには何の問題もない表示テキストまで上書きしてしまう。
• 自動レポートで問題が出なかったことを、サイトがアクセシブルである証拠と見なす。