ウェブサイトのアクセシビリティ：実践WCAG 2.2ガイド
ホーム 自分のサイト向けにWCAG 2.2を読み解く方法、実際の失敗の大半をカバーする修正、誰でもできる30分の手動テスト、そしてアクセシビリティとユーザビリティがどう重なるかを解説します。
よくある質問
ウェブサイトがWCAG準拠であるとはどういう意味ですか？
選んだレベル、通常はWCAG 2.1または2.2のレベルAAで、Web Content Accessibility Guidelinesの達成基準を満たしていることを意味します。レベルAAには、レベルAとAAのすべての基準が含まれます。WCAGを参照するほとんどの法律や調達方針はレベルAAを求めています。
自分のサイト向けにWCAGガイドラインをどう解釈すればよいですか？
W3Cの「How to Meet WCAG」クイックリファレンスから始め、レベルAとAAに絞り込み、各基準について、意図を平易な言葉で説明する「Understanding」ページを読みましょう。そのうえで、すべてのページを個別にではなく、主要なテンプレート（ホーム、コンテンツページ、フォーム、チェックアウト）をテストしましょう。
アクセシビリティのオーバーレイやプラグインでサイトを準拠させられますか？
どんなツールも単独でサイトを準拠させることはできません。ツールバーを追加するオーバーレイは基盤となるコードを修正せず、多くの障害を持つユーザーやアクセシビリティ専門家が、それがかえって邪魔になると報告しています。HTML、コントラスト、ラベル、キーボード対応を直接修正しましょう。
ユーザビリティとアクセシビリティの違いは何ですか？
アクセシビリティとは、障害を持つ人がサイトを知覚し、理解し、操作し、利用できることを意味します。ユーザビリティとは、サイトが誰にとっても簡単で効率的であることを意味します。両者は大きく重なり合っています。明確なラベル、良いコントラスト、予測可能なナビゲーションは、障害の有無にかかわらずすべての訪問者に役立ちます。
自動チェックツールはすべてのアクセシビリティの問題を見つけられますか？
いいえ。WAVE、axe、Lighthouseのようなツールは、alt属性の欠落、低いコントラスト、ラベルの欠落といった問題を捉えますが、alt属性が意味のある内容かどうか、フォーカス順序が理にかなっているかどうかといった多くの基準は、人間の確認が必要です。
WCAG準拠のウェブサイトとは、選んだレベルでWeb Content Accessibility Guidelinesを満たすサイトのことで、ほとんどの事業にとってそれはWCAG 2.2 レベルAA を意味します。実際には、ほとんどのサイトは同じ一握りの問題でつまずきます。低いカラーコントラスト、画像のalt属性の欠落、ラベルのないフォーム項目、空のリンクやボタン、そしてキーボードで到達できない要素です。これらを修正し、キーボードとスクリーンリーダーでテストすれば、実際のユーザーが遭遇する問題の大部分をカバーしたことになります。
このガイドでは、迷わずにWCAGを読む方法、最も重要な修正、そして自分でできる30分のテストを解説します。
WCAGの構造
WCAGはW3Cが公開しています。階層構造になっています。
4つの原則。 POURとして知られ、コンテンツはP erceivable（知覚可能）、O perable（操作可能）、U nderstandable（理解可能）、R obust（堅牢）でなければなりません。各原則の下にあるガイドライン （たとえば「Text Alternatives」や「Keyboard Accessible」）。 各ガイドラインの下にある達成基準。 これらはテスト可能なルールで、それぞれ番号が付けられ（1.4.3 Contrastなど）、レベル（A、AA、AAA）が与えられています。 レベルAが最低限です。レベルAAは、法律や調達要件で一般的に求められる目標です。レベルAAAはより厳しく、サイト全体には通常求められません。
WCAG 2.2は2023年10月にW3C Recommendationになりました。最小ターゲットサイズ、フォーカスが隠されないこと、アクセシブルな認証といった基準が追加され、4.1.1 Parsingは廃止として削除されました。
自分のサイト向けにWCAGを解釈する方法
仕様書は規格のように読めます。実際、規格だからです。実践的な進め方は次のとおりです。
W3Cの「How to Meet WCAG (Quick Reference)」 を開く。 レベルAとAAのみ に絞り込む。各基準について、リンクされた「Understanding」 ページを読む。意図を平易な言葉で、合格・不合格の例とともに説明しています。 すべてのページをテストする代わりに、テンプレート をテストする。ホームページ、標準的なコンテンツページ、ブログ記事、フォーム、商品ページやチェックアウトページです。テンプレートを直せば、それを基に作られたすべてのページが直ります。 基準番号、ページ、修正内容とともに各問題を記録する。 実際の失敗の大半をカバーする修正
1. カラーコントラスト（1.4.3、1.4.11）
通常のテキスト：背景に対して少なくとも4.5:1。 大きいテキスト（通常でおよそ24px、太字なら18.66px以上）：少なくとも3:1。 インターフェース部品と意味を持つグラフィック（ボタンの枠線、入力欄の輪郭、情報を伝えるアイコン）：少なくとも3:1。 薄いグレーのプレースホルダーテキストや、淡いブランドカラー上の白いテキストがよくある原因です。WebAIMのコントラストチェッカーやブラウザの開発者ツールで確認しましょう。
2. 画像の代替テキスト（1.1.1）
情報を伝える画像には、重要な内容を説明するalt属性を付けます：alt="暖房フィルターを交換する技術者"。 装飾的な画像には空のaltを付けます：alt=""。これによりスクリーンリーダーは読み飛ばします。 テキストの画像（チラシのスクリーンショット、JPGのメニューなど）には、同じテキストを実際のテキストとしても用意する必要があります。 ホームへのリンクとなるロゴなど、リンク付きの画像には遷移先を説明します：alt="Acme Plumbing ホームへ"。 3. フォームのラベルとエラー（1.3.1, 3.3.1, 3.3.2）
すべての入力項目には、それに紐づく目に見える<label>が必要です。プレースホルダーテキストはラベルではありません。入力すると消えてしまいます。 エラーメッセージは、何が問題で、どう直せばよいかをテキストで伝えます（「市外局番付きの電話番号を入力してください」など）。赤い枠線だけでは不十分です。 必須項目は、色だけでなくテキストやアクセシブルな指標でマークします。 4. キーボードアクセス（2.1.1, 2.4.3, 2.4.7）
すべてのリンク、ボタン、メニュー、フォームコントロールは、Tab、Shift+Tab、Enter、Spaceで操作できる必要があります。 フォーカス順序は視覚的な順序に従います。 目に見えるフォーカスインジケーターが、今どこにいるかを示します。outline: noneでブラウザのアウトラインを削除し、代替を用意しないのはよくある失敗です。 ドロップダウンメニューとモーダルは、キーボードから開き、操作でき、閉じられる必要があり、モーダルは閉じるまでフォーカスを内部に保つべきです。 5. 名前を持つリンクとボタン（2.4.4, 4.1.2）
アイコンのみのボタン（ハンバーガーメニュー、検索の虫眼鏡、SNSアイコン）には、目に見えるテキスト、aria-label、または隠しテキストによる、アクセシブルな名前が必要です。 「Click here」や「Read more」だらけのページは避けましょう。リンクのテキストが遷移先を説明するようにするか、それぞれに固有のアクセシブルな名前を付けましょう。 6. 構造と見出し（1.3.1, 2.4.6）
ページごとに、そのページを説明する<h1>を1つ。 見出しは論理的な順序で（セクションにはh2、その中にはh3）、フォントサイズのために選ばない。 実際のリスト、見出しセルを持つ表、ランドマーク（<header>、<nav>、<main>、<footer>）を使う。 ページの言語を設定する：<html lang="ja">。 7. WCAG 2.2の新項目で知っておく価値のあるもの
2.5.8 Target Size (Minimum) 、AA：クリック可能なターゲットは少なくともCSSピクセルで24×24、それより小さい場合は十分な余白を確保する。2.4.11 Focus Not Obscured (Minimum) 、AA：固定ヘッダー、クッキーバナー、チャットウィジェットが、フォーカスされた要素を完全に隠してはならない。3.3.8 Accessible Authentication (Minimum) 、AA：代替手段なしにパズルを解いたり情報を記憶したりすることをログインに要求しない。パスワードマネージャーと貼り付けを許可する。3.3.7 Redundant Entry 、A：同じ手続き内ですでに提供した情報を、再入力させない。8. メディアと動き
動画にはキャプションが必要です（1.2.2）。収録済み動画には、重要な視覚情報について音声解説かテキストによる代替が必要です。 5秒を超えて自動的に動くものには、一時停止する方法が必要です（2.2.2）。 大きなアニメーションではprefers-reduced-motion設定を尊重しましょう。 30分の手動テスト
自動ツールは全体像の一部しか捉えません。主要なテンプレートごとに、この手順を加えましょう。
0〜5分：自動スキャン。 WAVE（ブラウザ拡張機能）かaxe DevTools、またはLighthouseのアクセシビリティセクションを実行します。alt属性の欠落、ラベルの欠落、コントラストの失敗といった明確なエラーを修正します。
5〜15分：キーボードのみ。 マウスをしまいましょう。ページの先頭からTabキーで進みます。
常にフォーカスがどこにあるか見えますか？ メニューを開閉でき、すべてのフォーム項目を使い、送信できますか？ 「Skip to content」リンクはありますか、機能しますか？ フォーカスが固定ヘッダーやバナーの裏に消えることはありませんか？ 15〜25分：スクリーンリーダー。 VoiceOver（macOSとiOSに標準搭載）かNVDA（Windowsで無料）を使います。
見出しの一覧を聞きましょう。ページを説明していますか？ 画像やボタンにTabで移動しましょう。文脈なしでも意味が通じますか？ フォームに入力しましょう。すべての項目がラベルとともに読み上げられますか？エラーは読み上げられますか？ 25〜30分：ズームとリフロー。 ブラウザを200%、次に400%にズームします。400%では、横スクロールなしで1カラムにリフローすべきで（1.4.10 Reflow）、何も切れて見えなくなってはいけません。
ユーザビリティとアクセシビリティの重なり
「ウェブユーザビリティ アクセシビリティ」を検索する人がこの2つをまとめて考えるのは正しいことです。ほぼすべてのアクセシビリティの修正はユーザビリティの修正でもあります。
アクセシビリティの修正 他に誰が助かるか 強いコントラスト 日差しの下でスマートフォンを見る人全員 目に見えるラベル 急いでフォームに入力する人全員 キャプション 音を消して視聴する人 キーボード対応 パワーユーザー、トラックパッドが壊れている人 大きいタップ領域 モバイルの全ユーザー 明確なエラーメッセージ 誤入力をした人全員
オーバーレイ、声明、法律
オーバーレイ： 一行で準拠を約束するウィジェットは、基盤となるコードを変えません。サイト自体を直しましょう。アクセシビリティ声明： どの基準を目指しているか、既知の問題、そしてヘルプや代替フォーマットのための連絡方法を記した短いページを公開しましょう。法的背景： 要件は国によって異なります。European Accessibility Actは、2025年6月からEU内の多くの製品・サービスに適用されます。米国ではADAがウェブサイトにしばしば適用され、公共機関には特定のルールがあることが多いです。自分の状況について法的助言を得てください。チェックリスト
[ ] コントラスト：テキスト4.5:1、大きいテキストとUI部品は3:1 [ ] 情報を伝える画像にはalt属性、装飾的な画像には空のalt [ ] すべての入力項目に目に見える、紐づいたラベルがある [ ] サイト全体が目に見えるフォーカス付きでキーボード操作できる [ ] アイコンボタンにアクセシブルな名前がある [ ] 論理的な見出しとランドマーク、ページ言語の設定 [ ] タップ領域が少なくともCSSピクセルで24×24 [ ] 動画にキャプション、動きに一時停止コントロール [ ] 400%ズームでリフローする [ ] アクセシビリティ声明を公開済み アクセシビリティは検索も後押しします。見出し、alt属性、説明的なリンクはオンページSEOの基本でもあり、オンページSEOチェックリスト で解説しています。
We.Incは、直接編集できる標準的なHTML、CSS、Reactのコードとしてサイトを生成するため、ラベル、alt属性、コントラストを自分で修正するか、チャットで変更を依頼できます。公開するものには必ず上記の手動チェックを実行してください。
無料で始める
無料で始める · クレジットカード不要
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る