WCAG（Web Content Accessibility Guidelines）とは、ウェブコンテンツをより多くの人が利用できるようにするため、W3Cが策定しているアクセシビリティのガイドラインです。
ウェブアクセシビリティは、障害の有無、年齢、利用する端末や操作方法などにかかわらず、情報や機能を利用しやすくする考え方を指します。
WCAGは、見た目を統一するデザイン規則ではありません。
情報を認識できるか、必要な操作を完了できるか、内容や手順を理解できるか、ブラウザや支援技術が内容を解釈できるかを確認するための枠組みです。
この記事ではWCAG 2.2を基準に、4原則と適合レベル、既存サイトで最初に確認したい実践項目を整理します。
WCAGの4原則
WCAGの達成基準は、「知覚可能」「操作可能」「理解可能」「堅牢」という4原則に分けて整理されています。
それぞれが、利用者の異なる困りごとに対応します。
| 原則 | 確認すること | 代表的な対応 |
|---|---|---|
| 知覚可能（Perceivable） | 情報を視覚、聴覚など利用可能な方法で受け取れるか | 画像の代替テキスト、読みやすい文字と背景のコントラスト |
| 操作可能（Operable） | 必要な機能へ移動し、操作を完了できるか | キーボード操作、現在位置がわかるフォーカス表示 |
| 理解可能（Understandable） | 情報の意味や操作方法を理解できるか | 明確な見出し、入力項目の説明、具体的なエラーメッセージ |
| 堅牢（Robust） | ブラウザや支援技術が内容と機能を解釈できるか | 要素の役割や関係が伝わる一貫した実装 |
たとえば、画像に必要な説明がなく、マウスでしかメニューを開けず、入力エラーの理由も表示されないページには、複数の原則にまたがる問題があります。
4原則で分類すると、どの利用場面が妨げられているのかを切り分けやすくなります。
適合レベルA、AA、AAAの違い
WCAGの適合レベルは、達成すべき基準の範囲をA、AA、AAAの3段階で示します。
これは点数や利用者の重要度を表す区分ではありません。
| レベル | 満たす達成基準の範囲 | 誤解しやすい点 |
|---|---|---|
| A | レベルAの達成基準をすべて満たす | 最低適合レベルですが、すべての利用者に問題が起きないことを保証するものではありません。 |
| AA | レベルAとAAの達成基準をすべて満たす | Aより広い要件を扱いますが、AAだけであらゆる利用上の障壁を取り除けるわけではありません。 |
| AAA | レベルA、AA、AAAの達成基準をすべて満たす | 最も広い適合レベルですが、あらゆるサイトで一律に目標とすべき「理想点」を意味しません。 |
レベルが上がるほど、満たす必要のある達成基準が追加されます。
一方で、AAAの達成基準にはコンテンツの性質によって満たせないものもあるため、サイト全体へ一律にAAA適合を求める考え方は現実的とは限りません。
サイトの役割、利用者のニーズ、組織の方針を踏まえて目標を定め、目標レベルを超える基準にも必要に応じて取り組みます。
最初に確認したい4つの実践項目
画像の役割に合う代替テキストを書く
代替テキスト（altテキスト）は、画像が伝える情報や機能を文字で表すものです。
画像を見られない状況でも内容を把握しやすくなり、スクリーンリーダーを利用する人にも情報を伝えられます。
代替テキストは、長く詳しく書けばよいわけではありません。
商品画像なら「赤いバッグ」だけで足りるのか、「赤いレザーのトートバッグ」まで必要なのかを、ページ内で画像が担う役割に沿って判断します。
画像の見た目を列挙するのではなく、その画像から利用者が受け取るべき情報を簡潔に書きます。
文字と背景のコントラストを確認する
コントラスト比は、文字色と背景色の明るさの差を数値で表したものです。
差が小さいと、視力や色の見え方、閲覧環境によって文字を読み取りにくくなります。
WCAG 2.2のレベルAAでは、一般的な大きさの文字に4.5対1という基準があります。
ただし、必要な比率は文字の大きさや対象となる要素によって異なるため、4.5対1だけでページ全体を判定することはできません。
見やすい配色とコントラストの確認方法を参照し、実際の文字サイズと表示状態に合わせてチェックします。
キーボードだけでも操作を完了できるようにする
マウスを使えない場合でも、メニュー、リンク、ボタン、フォームなどの機能へ移動し、操作を完了できる必要があります。
Tabキーで移動したときは、現在どこを操作しているのかが見た目でわかり、移動順も画面の内容に沿っていることを確認します。
実装後は、マウスを使わずに主要な操作を最初から最後まで試します。
フォーカスが見えなくなる箇所や、途中から先へ進めない箇所があれば、キーボード操作とフォーカス表示の実装ポイントを確認します。
エラーの場所と直し方を具体的に伝える
フォームで入力に問題があったとき、「エラーが発生しました」だけでは利用者が修正方法を判断できません。
「名前の入力が必要です」のように、問題のある項目と必要な対応を具体的に示します。
エラーメッセージは、対象の入力欄を見つけやすい位置に表示し、色だけに頼らず文章でも伝えます。
送信をやり直す前に、どこを直せばよいかを理解できる状態が目標です。
WCAG対応を進める手順
- 対象と主要な操作を決める
サイト全体を一度に見直すのが難しい場合は、問い合わせ、申し込み、購入、情報検索など、利用者が完了したい操作から対象を定めます。 - 利用を妨げる箇所を洗い出す
代替テキスト、コントラスト、キーボード操作、フォームのエラー表示を確認し、操作を完了できない問題から優先します。 - 担当と修正内容を対応づける
文章や画像はコンテンツ担当、配色やフォーカス表示はデザイナー、操作や要素の関係は開発者というように、問題ごとの担当を明確にします。 - 実際の操作で確かめる
数値やチェック結果だけで終えず、キーボード操作や読み上げを含む利用場面に沿って、修正後のページを確認します。 - 更新後も見直す
記事、画像、フォーム、ナビゲーションの変更によって新しい問題が生じることがあるため、公開後の運用にも確認項目を組み込みます。
担当者ごとの役割
ウェブアクセシビリティは、開発者だけに任せる作業ではありません。
企画、制作、公開後の運用まで、各担当者が自分の成果物を確認できる体制にすると進めやすくなります。
| 担当 | 主な役割 |
|---|---|
| サイト運営者とウェブ担当者 | 対象範囲、目標、優先順位を決め、継続して改善できる運用を整える |
| コンテンツ制作者 | 見出し、リンク文、画像の代替テキスト、説明文をわかりやすくする |
| デザイナー | 文字と背景のコントラスト、操作位置の見え方、情報の区別しやすさを設計する |
| 開発者 | キーボード操作や支援技術で利用できるように、要素の役割と関係を実装する |
| テスト担当とサポート担当 | 主要な操作を通して確認し、利用者から届いた問題を改善につなげる |
公共機関や教育機関のように、多様な利用者へ情報を届ける組織でも同じ考え方が必要です。
対象者を限定せず、情報取得や手続きの途中で誰が困るのかを具体的に確認します。
期待できる効果と注意点
WCAGに沿って改善すると、障害のある人や高齢者を含む、より多くの利用者が情報を受け取り、必要な操作を完了しやすくなります。
達成基準を共通の確認項目として使えば、運営者、デザイナー、開発者の間で問題の場所と修正方針も共有しやすくなります。
日本では、障害者差別解消法に基づく合理的配慮の提供が事業者にも求められています。
ただし、WCAGへの適合だけで個別の法的要件をすべて満たしたと判断することはできません。
実際の対応では、組織の事業分野に関する最新の公的情報や対応指針も確認します。
アクセシビリティに配慮した見出しや代替テキストは、利用者にも検索システムにも内容を理解しやすくする助けになります。
一方で、WCAGへの適合が検索順位の上昇を保証するわけではありません。
検索対策の効果とは切り分け、まず利用者が情報と機能へ到達できる状態を整えます。
公開前の簡易チェックリスト
- ページの目的と主要な内容が、画像や色だけに頼らず伝わる
- 情報を伝える画像に、役割に合った代替テキストがある
- 文字と背景に十分なコントラストがある
- 主要な機能をキーボードだけで操作でき、フォーカス位置が見える
- 見出しの順序が自然で、各節の内容を特定できる
- フォームのエラー箇所と修正方法が文章でわかる
- 変更後のページを、実際の利用手順に沿って再確認している
小さな改善を運用に組み込む
WCAG対応は、公開前に一度だけ確認して終える作業ではありません。
まず主要な操作を妨げる問題を直し、記事や機能を更新するたびに確認を重ねることで、利用しやすい状態を保てます。
当社では、ウェブアクセシビリティへの対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
既存サイトでのアクセシビリティ向上を検討している方は、サービスの詳細をご覧ください。