Webサイトに必要な情報が書かれていても、読者がその情報へたどり着けるとは限りません。
リンクが本文と区別できない。キーボードではメニューを開けない。入力エラーの理由が色だけで示される。見出しだけを追っても、ページの構造が分からない。このような問題があれば、情報は存在していても利用できない人が出てきます。
Webアクセシビリティへの対応で陥りがちな事は、サイト公開前の一回きりの品質検査項目ですましてしまうこと。分かります、正直これをしっかりやりながら更新するのは工数は大きく増えますし、チェックする担当が必要です。
しかし、アクセシビリティは維持しなければ意味がありません。そして、Webサイトは公開後も更新されます。担当者が記事を追加し、画像を差し替え、新しいフォームや外部サービスを組みこんだり…どんどん変わるものです。であれば、公開時にはなかった問題が生じます。
この記事では、その前提でWCAG 2.2の運用面での位置付け、自動検査と人による評価の違い、企画から運用までの役割分担についてまとめます。
まず、アクセシビリティの問題とは？
Webアクセシビリティは「障害のある人を含むさまざまな利用者が、Web上の情報や機能へ到達し、目的を達成できる状態を考える」取り組みです。
例えば、次のような利用場面があります。
- 画像を見られない人が、代替テキストから内容を把握する
- マウスを使えない人が、キーボードでメニューやフォームを操作する
- 音声を聞けない人が、字幕や書き起こしから内容を理解する
- 小さな文字を読みにくい人が、画面を拡大して閲覧する
- 複雑な文章を理解しにくい人が、見出しや一貫した表現から内容を追う
対応する対象を「全盲の人」「聴覚障害のある人」のように狭く捉えるのは良くないとされています。例えば、けがで一時的に片手を使えない人、騒がしい場所で動画を見る人、加齢によって細かな操作が難しくなった人にも、同じ設計が役立ちます。
WCAG 2.2も、視覚、聴覚、身体、発話、認知、言語、学習、神経に関する幅広い障害を対象としています。また、高齢者の使いやすさや、利用者全般のユーザビリティ向上につながる場合があると説明しています。
使えるだけでなく、伝わることも必要になる
アクセシビリティの問題は、ボタンや配色だけに表れるものではありません。
サービス提供者だけが使う専門用語で説明されていれば、読者は自分に関係する内容か判断できません。リンク文が全て「詳しくはこちら」では、リンクだけを読み上げた時に移動先を把握しにくくなります。フォームのエラー表示に原因と修正方法が書かれていなければ、入力を完了できない人も出てきます。
良い情報でも、相手に伝わる形で提示されなければ価値を発揮しません。文章を書く人、画像を登録する人、ページを更新する人も、アクセシビリティ運用の当事者です。
WCAG 2.2は何を示しているのか
WCAGは、Web Content Accessibility Guidelinesの略称です。
W3Cが策定するWebコンテンツのアクセシビリティに関するガイドラインです。日本語で達成基準や用語を確かめる場合は、WAICが公開しているWCAG 2.2日本語訳を参照できます。
WCAG 2.2には、次の四つの原則があります。
| 原則 | 考え方 | Webサイトでの例 |
|---|---|---|
| 知覚可能 | 情報を利用者が認識できる | 画像の代替テキスト、動画の字幕、十分なコントラスト |
| 操作可能 | インターフェースを操作できる | キーボード操作、十分な操作対象の大きさ、フォーカスの表示 |
| 理解可能 | 情報と操作方法を理解できる | 一貫したナビゲーション、ラベル、エラーの修正提案 |
| 堅牢 | 支援技術を含むさまざまな環境で解釈できる | 適切なHTML要素、名前・役割・値の提供 |
四原則の下にガイドラインがあり、その下に検証可能な達成基準が置かれています。適合レベルはA、AA、AAAの三段階。
WCAG、ISO/IEC、JISの状況を分けて読む
海外規格と国内規格の関係は、確定した内容と検討中の内容を分ける必要があります。
※追記：WAICは2026年6月8日にWCAG 2.2日本語訳を更新しました。
同ページによると、国際規格ISO/IEC 40500は2025年9月にWCAG 2.2と同内容へ改正されています。
一方、対応するJIS X 8341-3について、WAICは改正を検討している段階だと説明しています。公開された日本語訳が、そのままJIS規格になるわけではありません。Webサイトで規格への対応状況を説明する場合は、「WCAG 2.2を参照した」「JIS X 8341-3:2016に基づいて試験した」など、参照した規格と版を明記しましょう。
デジタル庁のウェブアクセシビリティ導入ガイドブックは、技術者だけでなく、デザイナーや行政職員など、初めて取り組む人も対象にしています。規格の原文だけでは実務へ置き換えにくい場合に、具体例を把握する資料として利用できます。
自動検査で見つかる問題と、見つからない問題
アクセシビリティ検査ツールを使うと、多数のページを短時間で調べられます。ただし、自動検査だけで適合性を判断することはできません。どうしても人間のチェックは必要になります。実際、WCAG 2.2は、自動テストと人による評価を組み合わせて検証するよう設計されています。
自動検査で見つけやすい問題
alt属性がない画像- フォーム部品とラベルの関連付け不足
- ページ言語の指定漏れ
- 見出し構造の明確な不整合
- コントラスト不足の候補
- 同じIDの重複など、HTML上の明確な問題
人が判断しなければ分からない問題
- 代替テキストが画像の役割を適切に伝えているか
- 見出しと本文の関係が自然か
- リンク文だけで移動先を理解できるか
- キーボードで操作する順序が自然か
- エラー表示から修正方法を理解できるか
- 文章が対象読者に伝わるか
- 動画の字幕が発話内容と一致しているか
例えば、全ての画像にalt属性があっても、「画像」「写真」「バナー」としか書かれていなければ、内容を把握できません。反対に、装飾目的の画像へ長い説明を付けると、読み上げる情報が増え、かえって利用しにくくなる場合があります。
検出件数は、適合性の判定ではない
WebAIM Million 2025は、上位100万ホームページをWAVEで分析し、1ページ当たり平均51件の検出エラーを報告しました。
同報告は、自動ツールでは全ての適合失敗を検出できず、エラーが検出されないことも、ページがアクセシブルまたは適合していることを意味しないと明記しています。
自動検査の件数は、修正候補を見つけたり、定期的な変化を把握したりする材料です。件数がゼロだから問題がない、件数が多いから利用できないと、数字だけで結論を出さないように。
制作工程ごとに担当を決める
アクセシビリティを制作会社や開発者だけに丸投げにしてしまうと、自社で文章や画像を更新する際に品質を保てないケースがあります。なので、企画、設計、制作、実装、運用の各工程で、誰が何を担うかを決めておかないと、せっかく考えて作ったWebサイトのアクセシビリティがどんどん悪化してしまいます。
| 工程 | 主な担当 | 行うこと |
|---|---|---|
| 企画 | 責任者、Web担当者 | 対象利用者、優先範囲、参照規格、目標を決める |
| 情報設計 | Web担当者、デザイナー | 読み順、操作順、見出し、ナビゲーションを設計する |
| デザイン | デザイナー | コントラスト、文字サイズ、状態変化、操作対象を設計する |
| コンテンツ制作 | 編集者、ライター、更新担当者 | 見出し、リンク文、画像説明、平易な表現を整える |
| 実装 | 開発者 | 適切なHTML要素、キーボード操作、フォーカス、エラー通知を実装する |
| 公開前検査 | 担当者横断 | 自動検査、目視、キーボード、支援技術で検査する |
| 運用 | 更新担当者、責任者 | 更新時の再検査、問題受付、修正記録を続ける |
発注者も判断を委ねきらない
外部の制作会社へ依頼する場合も、「アクセシビリティに配慮してください」だけでは、対応範囲が決まりません。
次の項目を発注時に決めます。そうしなければ、特に経験がない会社では対応できないと考えた方が良いです。なぜなら、一般的に行われていることではないからです。あるいは慣れている会社に頼むべきです。
- 参照する規格と適合レベル
- 対象とするページや機能
- 制作中と公開前に行う検査
- 検査結果の提出方法
- 第三者サービスや外部コンテンツの扱い
- 公開後の修正範囲
- コンテンツ更新者向けのルールと教育
どこまでを今回の制作範囲とし、残った問題を誰がいつ直すかまで決めておくと、公開後の運用へ引き継ぎやすくなります。
小さく始める利用者確認
専門的な試験は重要ですが、日常的な運用では小さな確認から始められます。
キーボードだけで主要な操作を試す
マウスを使わず、Tabキー、Shift＋Tabキー、Enterキー、矢印キーなどで移動します。現在の位置が見えるか、メニューやダイアログを開閉できるか、フォームを送信できるかを確かめましょう。
画面を拡大して読む
文字や画面を拡大した時に、本文が横へはみ出して読めなくならないか、ボタンやメニューが重ならないかを見ます。PCの画面幅を狭めた場合も確認すると、表示の崩れを見つけやすくなります。
見出しとリンク文だけを読む
見出しだけを順番に読んで、ページの内容を把握できるか確かめます。リンク文についても、「こちら」や「詳しく見る」だけが並んでいないかを見ましょう。
簡易ユーザーテストでチェック
解析ツールは、どのページで離脱したかを示せますが、なぜ迷ったのかまでは説明しません。対象者に近い人へ目的を伝え、操作しながら考えたことを話してもらうと、数字だけでは見えない問題を把握できます。
記録するのは、次の三つです。
- 利用者の発言
- 実際に行った操作
- 問題が起きたページや部品
利用者が正しい操作をしたか評価するのではありません。なぜその受け取り方になったのか、サイト側で改善できる原因を探します。
公開後の運用を固めておく
公開時に検査へ合格しても、翌月に追加した記事やフォームが同じ品質とは限りません。アクセシビリティを制作案件ではなく、更新業務として扱う必要があります。
入稿ルールを用意する
更新担当者が毎回規格を読み直さなくても対応できるよう、日常作業をルールにします。
- 見出しは順序と内容のまとまりに合わせる
- リンク文には移動先が分かる言葉を使う
- 画像の目的に応じて代替テキストを設定する
- 色だけで状態や重要度を伝えない
- 表には見出しセルを設定する
- 動画には字幕または書き起こしを用意する
変更の種類に応じて再検査する
誤字を直した場合と、ナビゲーションを作り直した場合では、必要な検査が異なります。
| 変更 | 主な再検査 |
|---|---|
| 記事や画像の追加 | 見出し、リンク文、代替テキスト、文章 |
| フォームの変更 | ラベル、エラー、キーボード操作、完了通知 |
| 共通部品の変更 | 複数ページの自動検査、目視、支援技術 |
| 外部ツールの導入 | 埋め込み部分の操作、読み上げ、代替手段 |
| 大規模な改修 | 対象範囲を決めた総合試験 |
問題を受け付け、修正の経過を残す
全ての問題を一度に解消できない場合もあります。利用者が問題を連絡できる窓口を示し、影響の大きさと利用頻度から修正の優先順位を決めます。
検査日、対象範囲、見つかった問題、修正状況、未対応の理由を記録すれば、次の改修時に判断材料として使えます。
まとめ
Webアクセシビリティは、公開前に一度検査すれば終わる品質項目ではありません。Webサイトは、記事、画像、フォーム、外部サービスの追加によって変わり続けるからです。
WCAG 2.2は、知覚可能、操作可能、理解可能、堅牢という四原則を示し、自動テストと人による評価を組み合わせる前提で設計されています。自動検査は有力な手段ですが、文章の意味、操作の自然さ、利用者の迷いまで全て判定できるわけではありません。
企画、設計、文章、実装、検査、運用の担当者が、それぞれの役割を持つ。公開後も変更に応じて再検査する。この仕組みがあって初めて、Webサイトのアクセシビリティを保ち続けられます。大変ではありますが、サイトによっては非常に重要な項目もで有ります。
参考文献
- W3C “Web Content Accessibility Guidelines (WCAG) 2.2”
https://www.w3.org/TR/WCAG22/ - ウェブアクセシビリティ基盤委員会「Web Content Accessibility Guidelines (WCAG) 2.2 日本語訳」
https://waic.jp/translations/WCAG22/ - ウェブアクセシビリティ基盤委員会「WCAG 2.2 日本語訳 更新のお知らせ」
https://waic.jp/news/20260608/ - デジタル庁「ウェブアクセシビリティ導入ガイドブック」
https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook - WebAIM “The WebAIM Million 2025”
https://webaim.org/projects/million/2025
