企業サイトのアクセシビリティを確認しようとして、チェックツールの結果だけを見て終えていないでしょうか。機械は画像に説明が付いているかを見つけられても、その説明が画像の役割に合うかまでは十分に判断できません。フォームのエラーを読んで入力し直せるかも、実際の操作で確かめる必要があります。
この記事では、専門的な適合試験に入る前の初期点検を「自動検査」「キーボード操作」「目視と文章確認」の3段階に分けます。一般的な見やすさや操作性を整理するWebサイトのUI改善チェックリストとは、支援技術を含む利用のしやすさを確かめる目的で分けて扱います。
何のために確認するかを決める
ウェブアクセシビリティは、情報や操作をさまざまな利用者が利用できるようにする考え方です。W3CのWCAGは、知覚可能、操作可能、理解可能、堅牢という4つの原則で整理しています。初期点検では全基準の適合を宣言するのではなく、利用者が「情報を読み、目的の操作を終えられるか」を確認します。
対象ページはトップページだけにしません。会社概要、サービス、問い合わせ、採用、記事など、利用者の目的に関わるページを選びます。テンプレートが同じでも、画像やフォームの内容はページごとに違います。
第1段階：自動検査で機械が見つけやすい問題を拾う
検査ツールは、見出し構造、入力欄のラベル、画像の代替テキストの欠落など、プログラムで確認できる項目を探す補助として使います。結果には「どのページのどの要素か」を残します。警告がゼロでも点検は終わりません。
自動検査を始めるときの手段
| 確認手段 | 最初にすること | 結果の扱い |
|---|---|---|
| Chrome DevToolsのLighthouse | 対象ページを開き、Lighthouseパネルで「ユーザー補助」を選んでレポートを作成 | 検出されたマークアップや文字のコントラストなどを、修正候補として記録 |
| キーボード・画面読み上げでの操作 | 問い合わせなどの主要な導線を実際にたどる | 自動検査では分からない完了可否を、再現手順とともに記録 |
操作手順と自動検査の限界はChrome DevTools公式リファレンスを参照してください。自動検査の指摘がなくても、キーボードや画面読み上げによる操作は別に確かめます。
デジタル庁の導入ガイドブックも、機械的なチェックだけでは判断できない点があると説明しています。たとえば画像に代替テキストが存在していても、その文章が写真の意味を伝えているかは人が判断します。ツールの結果は修正候補の一覧として扱い、次の2段階で利用者の操作を確認します。
第2段階：キーボードだけで主要な行動を試す
マウスを使わず、ページ上部からTabキーで移動します。現在どこを操作しているか見えるか、メニューを開閉できるか、意図しない場所で操作が止まらないかを見ます。EnterキーやSpaceキーでボタンを実行し、Shift+Tabで戻れることも確認します。
問い合わせや応募フォームでは、入力欄から送信まで一連の操作を試します。エラーが出たときに、どの項目をどう直すか文章で分かり、入力済みの内容が不用意に失われないかが重要です。W3Cのフォーム解説は、ラベル、説明、エラー通知、完了時の案内を分けて説明しています。
スマートフォンでも画面が使えるかは別途確認します。スマホ対応の点検項目と併せ、狭い画面で拡大しても操作が隠れないか見てください。
第3段階：目視と文章で情報の意味を確かめる
次に画面を読み、機械だけでは決められない点を確認します。
- 画像の代替テキストは、装飾を説明しすぎず、必要な情報を伝えているか。
- 見出しだけを順に読んでも、ページの内容と順番が分かるか。
- 「詳しくはこちら」だけのリンクが並ばず、行き先を判断できるか。
- 色だけで必須・エラー・状態の違いを伝えていないか。
- 動画に重要な音声がある場合、必要な字幕や代替情報が用意されているか。
- フォームの必須項目、入力形式、送信後の流れが分かるか。
すべてを一度に直す必要はありません。まず問い合わせや応募など、利用者が目的を完了する経路で困る点を優先します。ただし、見た目の好みと基準への適合を混同しないよう、何を根拠に問題と判断したか記録します。
点検結果を改善につなぐ記録表
本記事では初期点検用に、次の5項目を一行で残す方法を提案します。
| 項目 | 記録例 |
|---|---|
| ページと操作 | 採用ページから応募フォームを開き送信する |
| 見つかったこと | キーボード移動中に現在位置が見えない |
| 利用者への影響 | 次にどの操作を実行するか判断しにくい |
| 根拠と確認方法 | キーボード操作で再現、該当画面を記録 |
| 担当・修正・再確認 | 担当者、修正日、同じ操作の再試験結果 |
「問題あり」だけでは実装者が直しづらいため、再現手順と利用者への影響を残します。修正後は同じ条件で確認し、解消したか記録します。正式なWCAGやJISの適合表明には、対象範囲と試験方法を定めた別の評価が必要です。この初期点検表だけで適合を宣言しません。
よくある質問
自動ツールでエラーが出なければ十分ですか？
十分とは言えません。ラベルの意味、画像説明の適切さ、エラーからの復帰、キーボード操作などを人が確認します。
全ページを同じ深さで調べるべきですか？
最初は重要なページと代表的なテンプレートを選び、目的の操作を通して点検します。同じテンプレートでも固有の画像・文章・フォームは別に確認します。
チェックリストを終えればWCAG 2.2に準拠したと言えますか？
言えません。本記事は改善箇所を探す初期点検です。適合表明には対象ページ、基準、試験方法を定めて評価します。
まとめ
企業サイトのアクセシビリティは、ツールの結果だけで判断せず、キーボード操作と人による内容確認を重ねます。利用者が目的の情報に到達し、必要な操作を終えられるかを中心に、問題の再現手順と修正後の結果を残してください。公開後の定期点検はホームページ公開後の運用・改善ガイドに組み込めます。
