ウェブアクセシビリティチェックとは、ウェブサイトの情報や機能を、異なる状況にある利用者が認識し、理解し、操作できるか確かめる作業です。
自動ツールの点数を見るだけで終わらせず、キーボード操作やスクリーンリーダーによる確認を組み合わせることで、実際の使いにくさを見つけやすくなります。
この記事では、初めてチェックを担当する制作者やサイト運営者に向けて、参照する基準、確認項目、改善の進め方を順番に整理します。
ウェブアクセシビリティチェックで確かめること
チェックの対象は、障害のある人だけを想定した特別な機能ではありません。
視覚や聴覚、身体の動かし方に制約がある人、高齢者、利用できる端末や入力方法が限られている人などが、情報や機能を利用できるかを確かめます。
たとえば、マウスを使えない利用者にはキーボードだけで操作できることが必要です。
画面の文字を読むことが難しい利用者には、スクリーンリーダーが見出し、リンク、フォームの意味を適切に読み取れることが助けになります。
チェックを行う主な理由
- 利用できない場面を減らす：情報が画像だけで示される、キーボードでボタンに到達できないなどの障壁を見つけ、改善につなげます。
- 操作や理解のしやすさを整える：見出しの順序、フォームの説明、エラー表示などを確認し、迷いにくい画面を目指します。
- 基準や制度への対応状況を把握する：WCAGやJIS X 8341-3を参照し、サイトが採用する目標に照らして不足を確認します。法令上の対応範囲は組織やサービスによって異なるため、チェック結果だけで法的適合を断定することはできません。
アクセシビリティとSEOには、見出しや代替テキストなど共通して整備する要素があります。
ただし、アクセシビリティチェックは検索順位の上昇を保証する作業ではなく、利用者が情報と機能に到達できるかを確かめる作業です。
チェックで参照する基準と仕様
基準と実装仕様は役割が異なります。
次の三つを同じ種類の資料として扱わず、目的に応じて参照します。
| 名称 | 位置づけ | チェックでの使い方 |
|---|---|---|
| WCAGの基本と実務での読み方 | 国際的なアクセシビリティガイドライン | 「認知可能」「操作可能」「理解可能」「堅牢性」という四つの原則をもとに、確認項目を整理します。 |
| JIS X 8341-3 | 日本のウェブコンテンツ向け規格 | 国内で目標や試験方法を検討するときの基準として参照します。 |
| WAI-ARIA | 動的な画面要素などの意味や状態を支援技術へ伝えるための仕様 | 標準のHTMLだけでは意味や状態を伝えにくい部分の実装を確認します。 |
WAI-ARIAは、サイト全体の適合状況を判定するチェック基準ではありません。
ボタンや開閉要素などの名前、役割、状態が支援技術へ伝わるようにするための実装仕様として扱います。
チェックを始める前に対象を決める
最初に、どのページと機能を確認するか決めます。
対象が曖昧なままでは、トップページだけを詳しく調べても、問い合わせや購入など利用者の目的に直結する問題を見落とす可能性があります。
- トップページ、記事、一覧など構造の異なるページ
- 問い合わせ、申し込み、ログインなど入力を伴う機能
- メニュー、検索、開閉パネルなど操作を伴う部分
- 画像、動画、エラーメッセージなど、文字以外の情報や状態変化を含む部分
対象を決めたら、確認する端末、ブラウザ、入力方法、支援技術も記録します。
同じページでも利用環境によって操作方法が変わるため、再確認できる条件を残しておくと改善前後を比較しやすくなります。
自動ツールと手動確認を使い分ける
自動ツールは、機械的に判定できる問題を短時間で探す用途に向いています。
元の記事で紹介していたWAVE、axe、Lighthouseなどを使えば、代替テキストやフォーム、コントラストに関する問題の手がかりを得られます。
ただし、自動ツールが警告を出さなかったことは、利用者が問題なく使えることの保証にはなりません。
代替テキストが画像の目的を伝えているか、フォーカスの移動順が自然か、エラー説明を理解して修正できるかといった内容は、人が実際に操作して確かめます。
| 方法 | 見つけやすい問題 | 確認時の注意 |
|---|---|---|
| 自動チェック | 属性の不足、判定可能なコントラストや構造上の問題 | 警告の意味を確認し、画面の文脈に沿って修正の要否を判断します。 |
| 手動チェック | 操作順、説明の分かりやすさ、代替テキストの適切さ | 一つの操作方法だけで判断せず、対象として決めた利用環境で確かめます。 |
手動で確認する五つの項目
1．キーボードだけで操作できるか
マウスを使わず、Tabキーでリンク、ボタン、入力欄へ順番に移動し、Enterキーで操作します。
現在選ばれている場所が画面上で分かるか、途中で移動できなくならないか、目的の機能を完了できるかを確認します。
2．スクリーンリーダーで内容が伝わるか
NVDAやVoiceOverを使い、ページの見出し、リンク、フォームのラベルが意味の分かる順序で読み上げられるかを確認します。
初めて試す場合は、スクリーンリーダーの仕組みと実装上の確認点も参考になります。
3．画像の内容や目的が伝わるか
情報を伝える画像には、画像が見えない場合にも役割が伝わる代替テキストが必要です。
ファイル名や見た目を並べるのではなく、その画像がページ内で何を伝えているかを確認します。
画像ごとの判断方法は、代替テキストの役割と書き方で詳しく整理しています。
4．文字と背景を区別しやすいか
本文、リンク、ボタン、入力欄などについて、文字と背景のコントラストを採用する基準に照らして測定します。
文字サイズや対象要素によって確認条件が異なるため、一つの数値をすべての文字へ機械的に当てはめず、該当する基準を確認します。
5．フォームの入力と修正が分かりやすいか
各入力欄に内容を示すラベルがあるか、必須項目や入力条件が操作前に分かるか、入力エラーの場所と直し方が伝わるかを確認します。
実装を見直す際は、フォームのラベルと説明の使い分けも確認してください。
指摘を改善につなげる手順
- 結果をまとめる：対象ページ、確認環境、操作手順、起きた問題を記録します。
- 優先順位を決める：情報を読めない、操作を完了できないなど、利用を妨げる問題から扱います。
- 担当を分ける：文章、デザイン、HTML、動作のどこを直すか整理し、ライター、デザイナー、開発者へ割り当てます。
- 修正後に同じ手順で確かめる：指摘箇所だけでなく、修正によって周辺の操作へ影響が出ていないかも確認します。
- 次回の確認条件を残す：更新時に再発しやすい項目をチェックリストへ加えます。
アクセシビリティは、一度の点検で完了する作業ではありません。
記事の追加、画面の改修、外部サービスの変更などに合わせて確認し、問題の発見と修正をサイト運営の流れに組み込みます。
最初のチェックで押さえる項目
- ページタイトルと見出しが内容を表し、順序が分かりやすい
- リンクの文言だけで移動先や目的を判断できる
- 情報を伝える画像に適切な代替テキストがある
- 文字と背景を区別しやすい
- キーボードだけで主要な機能を利用できる
- フォームのラベル、入力条件、エラーの直し方が伝わる
- スクリーンリーダーで見出し、リンク、フォームの意味を確認できる
初回は、問い合わせや申し込みなど利用者の目的に直結するページから始めると、対応範囲を定めやすくなります。
自動ツールで候補を探し、手動操作で影響を確かめ、修正後に同じ条件で再確認してください。
当社では、ウェブアクセシビリティの導入を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
アクセシビリティ改善を検討している場合は、サービスの詳細をご覧ください。