Webアクセシビリティと聞くと、規格を読み込んで専門的な検査をしなければならないように感じるかもしれません。実際には、ブラウザとキーボードだけでも、利用者を困らせている箇所の手がかりは見つけられます。
まずは問い合わせや予約に近いページを一つ選び、30分で7項目を確認します。これは正式な適合評価ではなく、改修の優先順位を決めるための初期点検です。
3分で分かる結論｜問い合わせに近い1ページを実際に操作する
今回の点検時間は、次のように配分します。
COLUMN
Webアクセシビリティを30分で点検する7項目
| 項目 | 時間 | 確認すること |
|---|---|---|
| 1. ページタイトル | 2分 | タブの名前だけで内容を判断できるか |
| 2. 画像と代替テキスト | 4分 | 画像が見えなくても意味が伝わるか |
| 3. 見出しと読む順番 | 4分 | 見出しだけで内容の流れを追えるか |
| 4. 200％表示と色 | 5分 | 拡大しても文字や操作部分が欠けないか |
| 5. キーボード操作 | 5分 | マウスなしで移動・選択・実行できるか |
| 6. フォーム | 7分 | 入力項目、必須条件、エラーが分かるか |
| 7. 動きと動画 | 3分 | 停止操作や字幕などが用意されているか |
対象ページは、サービス紹介、予約、問い合わせなど、事業の成果に近いページを一つ選びます。最初から全ページを調べるより、利用者が途中で進めなくなると影響が大きい導線から確認するほうが、改修の優先順位を決めやすいためです。これは規格上の指定ではなく、実務で点検を始めるための順番です。
点検前に用意するもの
特別な検査ツールは使いません。PCのブラウザで対象ページを開き、マウス、キーボード、メモを用意します。スマートフォンでも同じページを開けるようにしておくと、表示の違いも確かめられます。
記録は次の4列で十分です。
| 場所 | 試した操作 | 起きたこと | 優先度 |
|---|---|---|---|
| 問い合わせフォーム | Tabキーで送信まで移動 | 同意欄で現在位置が見えない | 高 |
「使いにくい」だけでは、担当者へ改修内容を伝えにくくなります。URL、画面上の場所、押したキー、期待した動き、実際の動きを一緒に残してください。
W3CのEasy Checksも、初期確認は包括的な評価の代わりにならないと説明しています。今回の7項目に問題がなくても、WCAG 2.2への適合を示すものではありません。正式な評価や適合表明が必要な場合は、対象範囲と試験方法を別途定めます。
1. ページタイトルを確認する（2分）
ブラウザのタブに表示される名前を確認します。「トップ」「サービス」「無題」のような短い名前だけでは、複数のページを開いたときに区別しにくくなります。
次の3点を見ます。
- ページの内容が具体的に分かる
- 同じサイト内の別ページと見分けられる
- サイト名だけで終わっていない
たとえば問い合わせページなら、「お問い合わせ｜会社名」のように目的が先に分かる形が一案です。検索結果に表示されるタイトルの確認にもつながりますが、ここではブラウザ上でページを識別できるかを先に見ます。
2. 画像と代替テキストを確認する（4分）
画像が表示されない状況や、画面読み上げソフトを使う状況を想定します。商品の外観、図表、ボタン、写真内の文字など、画像が情報や操作を担っている場合は、その役割が代替テキストから分かるか確認します。
代替テキストは、画像の見た目をすべて説明する欄ではありません。同じ画像でも、ページ内での役割によって必要な説明は変わります。
- 商品写真なら、判断に必要な形状や状態を伝える
- グラフなら、結論や重要な数値を本文でも説明する
- 画像だけのリンクなら、移動先や操作を伝える
- 意味を持たない装飾画像なら、空の代替テキスト
alt=""を使う
近くの本文と同じ説明を繰り返していないかも確認します。画像内に重要な文章を入れている場合は、本文にも同じ情報があるかを見てください。
3. 見出しと読む順番を確認する（4分）
ページを上から見て、見出しだけを順に読みます。見出しが「特徴」「詳細」「その他」のような曖昧な言葉ばかりなら、目的の情報を探すのに時間がかかります。「料金に含まれるもの」「予約から当日までの流れ」のように、その節で分かることを具体的にします。
あわせて、次の状態がないか確認します。
- 大きく太い文字なのに、HTML上は見出しではない
- 見出しの段階が不自然に飛んでいる
- 見出しの直後に、関係のない内容が続く
- PCとスマートフォンで、読む順番が大きく変わる
見た目だけで見出しを作ると、支援技術から構造を把握しにくくなります。デザインとHTMLの両方で、同じ情報の階層を示します。
4. 200％表示と色を確認する（5分）
ブラウザのズームを200％にします。文字が大きくなること自体ではなく、拡大後も内容と機能を利用できるかを確認してください。
- 文章やボタンが枠からはみ出して隠れない
- 横に長い文章を読むための不要な横スクロールが生じない
- メニューや閉じるボタンが画面外へ消えない
- 問い合わせフォームの項目名と入力欄を対応づけられる
- 文字と背景を見分けられる
WCAG 2.2には、支援技術を使わずに文字を200％まで拡大しても、内容や機能が失われないことを求める達成基準があります。Webページ全体の適合判断にはほかの条件も必要ですが、200％表示は初期点検として試しやすい操作です。
色については、薄い灰色の文字、写真の上の文字、ボタン内の文字を重点的に見ます。「赤字が必須」「緑が正常」のように、色だけで意味を分けていないかも確認します。文字や記号を併用すれば、色を判別しにくい状況でも内容を受け取りやすくなります。
5. キーボードだけで操作する（5分）
ページを再読み込みし、マウスを使わずに操作します。Tabキーで次へ、Shift＋Tabキーで前へ移動し、EnterキーやSpaceキーでリンク、ボタン、チェック項目を操作します。
見るべき点は、移動できるかだけではありません。
- 今どこを選んでいるか、枠や色の変化で分かる
- 見た目の順番と、Tabキーで移動する順番が大きくずれない
- メニュー、モーダル、カルーセルから抜けられなくならない
- リンクやボタンへ移動でき、実行できる
- マウスを重ねたときだけ表示される情報を、キーボードでも確認できる
フォーカスの印が消えていると、操作自体はできても現在地が分かりません。ブラウザ標準の枠をデザイン上の理由だけで消していないか、CSSも含めて確認します。
6. フォームを入力して送信直前まで進む（7分）
問い合わせフォームは、閲覧から行動へ移る場所です。送信テストが業務へ影響する場合は、実際には送信せず、確認画面または送信ボタンの直前まで操作します。
次の順で試します。
- 項目名と入力欄の対応が見ただけで分かるか
- 必須・任意を色以外でも判別できるか
- 電話番号や日付など、入力形式の説明があるか
- キーボードだけで選択肢や同意欄を操作できるか
- 未入力や誤った形式で進み、エラーの場所と直し方が分かるか
- エラー後も、正しく入力した内容が不必要に消えないか
入力欄の中にだけ薄く表示される例文は、入力を始めると消えます。項目名や重要な条件の代わりにせず、欄の外にも必要な説明を残します。
エラー表示は「入力に誤りがあります」だけで終えず、「メールアドレスを半角で入力してください」のように、場所と修正方法を示します。画面上部にエラー一覧を出す場合も、各入力欄の近くに案内があると直しやすくなります。
7. 動きと動画を確認する（3分）
自動再生するスライダー、背景動画、点滅、スクロール連動アニメーションを確認します。動きが読み取りや操作を妨げる場合に、停止・一時停止・非表示を選べるかを見ます。表示が切り替わったとき、キーボードのフォーカスが突然移動しないかも試します。
音声を含む動画には、会話や重要な音を確認できる字幕があるかを見ます。音声だけで伝える案内には、同じ内容を読める文章があるか確認してください。自動再生を採用する場合は、音の扱いと停止方法を実際の端末で確かめます。
30分後に改修の優先順位を決める
点検結果を、次の3段階に分けます。
| 優先度 | 判断の目安 | 例 |
|---|---|---|
| 高 | 問い合わせや予約を完了できない | キーボードで送信ボタンへ移動できない、エラーを直せない |
| 中 | 内容の理解や比較が難しい | 見出しが曖昧、画像内の重要情報を本文で読めない |
| 低 | 操作はできるが、見やすさを改善できる | 余白や装飾の調整、説明の重複 |
影響が大きい問題から、再現手順と対象URLを添えて修正します。デザインだけ、文章だけ、システムだけで解決できない場合もあります。たとえばフォームのエラーなら、表示設計、説明文、入力判定を一緒に見直します。
Webサイト制作を依頼する前の7項目も確認すると、改修範囲、管理権限、公開後の運用まで整理できます。
よくある質問（FAQ）
Q. 7項目に問題がなければ、アクセシビリティ対応済みと言えますか？
A. 言えません。今回の手順は、問題の手がかりを見つける初期点検です。WCAGやJISへの適合を示すには、対象ページ、達成基準、試験方法を定めた評価が必要です。
Q. すべてのページを30分ずつ確認する必要がありますか？
A. 最初は、問い合わせ、予約、購入、サービス説明など重要な導線から始めます。共通のヘッダーやフォームで問題が見つかった場合は、同じ部品を使うページへ確認範囲を広げてください。
Q. 自動チェックツールだけでは足りませんか？
A. 自動ツールはHTML上の問題を効率よく探せますが、見出しが内容を正しく表しているか、キーボード操作の順番が自然か、エラーの直し方を理解できるかなど、人が操作して確かめる項目も残ります。自動検査と手動確認を組み合わせます。
Q. まず何から直せばよいですか？
A. 利用者が先へ進めない問題を優先します。キーボードで操作できない、文字を拡大するとボタンが消える、フォームのエラーを修正できないといった箇所から着手してください。
まとめ｜合否を急がず、止まる場所を一つずつ減らす
Webアクセシビリティの改善は、基準名を掲げることではなく、ページの内容を受け取り、操作を完了できる人を増やすことです。タイトルからフォームまで順に試すと、見た目を眺めるだけでは気づきにくい問題も見えてきます。
デジタル庁のウェブアクセシビリティ導入ガイドブックは、これから取り組む担当者や事業者向けに基本を整理しています。30分の点検で見つけた課題を入口に、必要に応じて公式資料や専門的な評価へ確認範囲を広げてください。
Webサイト制作・改善支援では、表示、導線、フォームをまとめて確認し、改修の優先順位を整理します。自社サイトの点検結果をどのように修正へつなげるか迷っている場合は、ご相談ください。
