Webアクセシビリティ対応はどこから始めればいいですか？

まずLighthouseやWAVEで現状のスコアと問題を把握するところから始めよう。次に重大度の高い問題（画像のalt属性欠如、コントラスト不足、フォームラベルなし）から順に修正する。完璧を目指すより「今よりも良くする」という継続的な改善アプローチが現実的だ。

WCAGのどのレベルまで対応すれば十分ですか？

一般的なビジネスサイトやフリーランスのポートフォリオサイトでは、WCAG 2.2のレベルAA準拠を目標にするのが標準的だ。行政・公共機関のサイトはJIS X 8341-3（WCAG相当）のAA適合が義務化されている。

フリーランスがクライアント案件でアクセシビリティに対応する場合の注意点は？

契約書や要件定義に「WCAG 2.2 AA準拠」を明示しておくのが重要だ。アクセシビリティ対応には工数がかかるため、スコープと費用は事前に合意しておく。納品後に追加コンテンツが増える場合は、クライアント側でもalt属性設定などの運用ルールを設けるよう提案しておくとトラブルを防げる。

自動チェックツールだけで十分ですか？

十分ではない。自動ツールが検出できるのはアクセシビリティ問題全体の約30〜40%と言われている。残りはキーボードだけでの全操作確認、スクリーンリーダー（NVDA, VoiceOverなど）を使った実機テスト、実際の障害当事者によるユーザーテストでしか発見できない。

CSSでoutline: noneを使ってはいけないのですか？

デフォルトのフォーカスリングを消すこと自体が問題なのではなく、代替のフォーカス表示を提供せずに消すことが問題だ。outline: none と同時にカスタムの:focus-visibleスタイルを設定すれば問題ない。

既存サイトの全ページを一度に対応するのは大変です。どう進めれば良いですか？

優先度を付けて段階的に進めるのが賢い。まずコンバージョンに直結するページ（トップページ、問い合わせフォーム、購入フロー）から対応する。次に流入の多いページ、そして残りのページと進む。テンプレートやコンポーネント単位で修正すれば同一の問題を一括で解消できる。

2026年版 ToolShare Lab / Guide

Webアクセシビリティ入門
WCAG基準とチェック方法

「障害のある人が使えるかどうか、考えたことがない」——多くのWeb制作者が直面するアクセシビリティの課題。2024年の障害者差別解消法改正で民間事業者にも合理的配慮が義務化された今、Webアクセシビリティへの対応は避けて通れない。WCAG 2.2の4原則から具体的なチェック方法、NG例と修正コードまで、実践的にまとめた。

読了時間: 約12分更新日: 2026年3月10日

Webアクセシビリティとは

Webアクセシビリティとは、障害のある人や高齢者を含むすべての人が、Webコンテンツやサービスを問題なく利用できる状態を指す。W3C（World Wide Web Consortium）は「Webアクセシビリティとは、障害のある人々がWebを使用できることを意味する」と定義している。

ここで言う「障害」は固定的なものではなく、状況によって誰にでも起こりえる。スマートフォンを片手で操作しているとき、眩しい屋外でスマホを見ているとき、マウスが壊れてキーボードだけで操作しているとき——これらはすべてアクセシビリティの恩恵を受ける状況だ。「自分には関係ない」と思っているなら、それは間違いだ。

なぜWebアクセシビリティが重要か

アクセシビリティ対応が重要な理由は、倫理的な観点だけではない。ビジネス上のメリットも無視できない。

日本の障害者人口は約1,160万人（人口の約9%）にのぼり、潜在的なユーザー層として無視できない
アクセシビリティ対応はSEOにも直結する（適切な見出し構造、alt属性、意味的なHTMLはGoogleの評価にも影響）
モバイルユーザーや低速回線環境のユーザー体験も向上する
スクリーンリーダー対応はAIエージェントやボットの理解精度も高める
法的リスクを回避できる（後述の障害者差別解消法）

2024年障害者差別解消法改正の影響

2024年4月施行の改正障害者差別解消法により、それまで国・地方公共団体のみに義務付けられていた「合理的配慮の提供」が、民間事業者にも義務化された。Webサービスや商品ページ、問い合わせフォームなどのデジタルコンテンツも、この「合理的配慮」の範囲に含まれると解釈されている。

Point

「うちは中小企業だから関係ない」は通用しない。事業規模を問わず、すべての民間事業者が対象だ。Webサイトでアクセシビリティを無視した場合、障害者からの申し出に応じる義務（合理的配慮）が生じる。フリーランスが受注するWeb制作案件でも、クライアントへの説明責任が発生する点を覚えておきたい。

WCAG 2.2の4原則

WCAG（Web Content Accessibility Guidelines）は、W3Cが策定したWebコンテンツのアクセシビリティに関する国際基準だ。2023年10月に最新版の2.2がリリースされ、現在は2.2への準拠が推奨されている。

WCAGは「POUR」と呼ばれる4つの原則を柱としている。

知覚可能（Perceivable）
情報とUIコンポーネントは、ユーザーが知覚できる方法で提示しなければならない。テキスト代替（alt属性）、字幕・音声解説、コンテンツの表示方法、前景と背景のコントラスト確保などが含まれる。要するに「見える人しか分からない」情報の提供方法は不適切だ。
操作可能（Operable）
UIコンポーネントとナビゲーションは操作可能でなければならない。キーボードのみによる全機能操作、十分な操作時間の確保、発作を引き起こさないコンテンツ設計、ナビゲーション補助（スキップリンク、ページタイトル、フォーカス表示）などが求められる。
理解可能（Understandable）
情報とUIの操作方法は理解可能でなければならない。テキストの読みやすさ（lang属性の指定）、コンテンツの予測可能な動作、入力支援（フォームのラベル、エラーメッセージ）などが含まれる。ユーザーが「何が起きているか」を常に把握できる設計が必要だ。
堅牢（Robust）
コンテンツは、支援技術を含む多様なユーザーエージェントが確実に解釈できるよう堅牢でなければならない。正しいHTML構文、ARIA属性の適切な使用、ステータスメッセージのプログラム的な提供などが求められる。将来の技術変化にも耐えられる設計という観点でもある。

適合レベルA/AA/AAAの違い

WCAGの各達成基準は、重要度に応じて3つの適合レベルに分類されている。

レベル	意味	基準数（WCAG 2.2）	推奨対象
A	最低限のアクセシビリティ。対応しないと一部ユーザーが完全に利用不能になる	25項目	すべてのWebサイト
AA	一般的な推奨レベル。多くの法規制・ガイドラインが準拠を求める	13項目（A含め38項目）	企業サイト・行政・商用サービス
AAA	最高水準。すべての達成は困難だが、可能な範囲で対応することを推奨	26項目（A+AA含め64項目）	高度なアクセシビリティが求められる専門サービス

一般的なWebサイトではレベルAAへの準拠が目標とされている。日本のJIS X 8341-3（高齢者・障害者等配慮設計指針）もWCAG 2.1/2.2のAAに相当する内容だ。行政機関のWebサイトはJIS X 8341-3の適合レベルAA以上への準拠が義務化されており、民間でも同水準を目指すのが現実的なラインとなっている。

注意

「AAA対応は難しすぎる」からといってAAへの対応を諦める必要はない。WCAGは「可能な範囲で最大限対応する」というアプローチを推奨している。まずレベルAを完全に満たし、次にAAの主要項目から着手するのが現実的な進め方だ。

具体的なチェック項目

以下は、Web制作で特に頻繁に問題が発生するチェック項目だ。優先度の高いものから順に見ていこう。

1. 代替テキスト（alt属性）

画像に意味がある場合は、内容を説明するalt属性を設定する。装飾目的の画像はalt=""（空文字）を指定してスクリーンリーダーが読み飛ばすようにする。「画像」と書くだけのaltは無意味なので注意。

すべての<img>タグにalt属性が存在するか
altの内容は画像の機能・内容を適切に説明しているか
「画像」「写真」などの冗長な説明になっていないか
グラフ・図表の場合、数値や概要が文章で説明されているか

2. キーボード操作

マウスを使わずキーボードのみで、すべての機能を操作できるか確認する。タブキーで順番にフォーカスが移動し、Enterキー・スペースキーで操作できる状態が基本だ。実際にキーボードだけで自分のサイトを操作してみると、問題がすぐ見つかる。

すべてのリンク・ボタン・フォームにキーボードでアクセスできるか
モーダルやドロップダウンをキーボードで開閉できるか
キーボードフォーカスがページのどこかに「罠」として閉じ込められていないか
スキップナビゲーション（コンテンツへスキップするリンク）が実装されているか

3. コントラスト比

テキストと背景のコントラスト比は、視覚障害や色覚特性を持つユーザーの可読性に直結する。「おしゃれに見えるから」と薄いグレーのテキストを使いがちだが、WCAG AAでは以下の基準が定められている。

テキストの種類	レベルAA基準	レベルAAA基準
通常テキスト（18pt未満、太字14pt未満）	4.5:1以上	7:1以上
大きいテキスト（18pt以上、太字14pt以上）	3:1以上	4.5:1以上
UIコンポーネント・グラフィック	3:1以上	—

4. フォーカス表示

キーボード操作時に、現在フォーカスされている要素が視覚的に判別できる必要がある。WCAG 2.2で新たに追加された達成基準2.4.11では、フォーカスの表示面積や色彩コントラストの具体的な基準が規定された。デザインのためにoutline: none を全体に設定するのは厳禁だ。

フォーカスリングが完全に非表示になっていないか（outline: none の使用は要注意）
カスタムフォーカススタイルのコントラスト比が3:1以上あるか
フォーカス時の視覚的変化が周囲と区別できるか

5. 見出し構造

見出しタグ（h1〜h6）は視覚的な装飾ではなく、コンテンツの論理的な階層構造を表す。スクリーンリーダーユーザーは見出しを使ってページを高速にナビゲートするため、「大きく見せたいから h2」という使い方は NG だ。

h1はページに1つだけ使用されているか
見出しレベルが飛んでいないか（h2の次にh4は不可）
見出しは見た目ではなく意味的な階層で付けられているか
「もっと見る」「詳しくはこちら」など、文脈なしに意味が分からないリンクテキストになっていないか

6. フォームラベル

すべてのフォームコントロールには、プログラム的に関連付けられたラベルが必要だ。placeholder属性だけでは不十分で、フォーカス時にラベルが消えてしまう。placeholderはあくまで補助であって、labelの代替にはならない。

すべての入力フィールドに<label>タグが関連付けられているか
必須入力項目は視覚的・プログラム的に示されているか
エラーメッセージは具体的で修正方法が分かるか
送信ボタンに意味のある名前が付いているか（「送信」「確認する」など）

7. ARIA属性

WAI-ARIA（Accessible Rich Internet Applications）は、HTMLだけでは表現できないUIの意味をスクリーンリーダーに伝えるための仕様だ。ただし、ARIAの誤用はアクセシビリティをむしろ悪化させる。「ARIAをたくさん書けばアクセシブルになる」は誤解なので注意。

ARIAのルール第一条

「ネイティブHTMLで表現できるなら、ARIAは使わない」——ボタンには<button>、リンクには<a href>を使い、role="button"をdivに付けるのは最終手段だ。適切なHTMLセマンティクスがARIA対応の基本で、それだけで解決できることの方が多い。

よくあるNG例と修正方法

NG例1: alt属性の欠如・不適切な内容

<img src="chart.png">  <img src="chart.png" alt="画像">  <img src="chart.png" alt="2026年1月〜3月の月別売上グラフ。3月が最高値の120万円">  <img src="decoration.svg" alt="">

NG例2: フォーカスリングの非表示

/* NG: フォーカスを完全に消す */ * { outline: none; } a:focus, button:focus { outline: 0; } /* OK: カスタムフォーカススタイルを設定する */ a:focus-visible, button:focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; border-radius: 2px; }

NG例3: コントラスト不足のテキスト

/* NG: 白背景に明るいグレーのテキスト（コントラスト比 2.3:1） */ .note { color: #aaaaaa; background-color: #ffffff; } /* OK: コントラスト比 4.5:1以上を確保 */ .note { color: #767676; /* 白背景との比率 4.54:1 */ background-color: #ffffff; }

NG例4: フォームラベルの未設定

<input type="email" placeholder="メールアドレス">  <label for="email">メールアドレス</label> <input type="email" id="email" placeholder="example@email.com">  <input type="search" aria-label="サイト内検索">

NG例5: キーボード操作不能なカスタムボタン

<div onclick="submitForm()">送信する</div>  <span class="btn" onclick="openModal()">開く</span>  <button type="button" onclick="submitForm()">送信する</button>  <div role="button" tabindex="0" onclick="openModal()" onkeydown="if(event.key==='Enter'||event.key===' ')openModal()"> 開く </div>

NG例6: 言語属性の未設定

<html>  <html lang="ja"> <p>Hello, this is an English paragraph.</p> </html>  <html lang="ja">  <p>Web Accessibility（<span lang="en">Accessibility</span>）とは...</p>

自動チェックツールの紹介

アクセシビリティの問題を100%自動検出するのは不可能だが、自動チェックツールで全体の約30〜40%の問題は発見できる。手動チェックと組み合わせて使うのが効果的だ。

Lighthouse（Google）

Chrome DevToolsに内蔵されているGoogleの計測ツール。アクセシビリティスコア（0〜100点）と具体的な改善提案を提供する。追加インストール不要で今すぐ使える。

使い方
Chrome DevToolsを開く（F12）→「Lighthouse」タブを選択→「アクセシビリティ」にチェック→「レポートを生成」をクリック。スコアと問題の一覧が表示される。
強み
パフォーマンス・SEO・ベストプラクティスと同時に確認できる。CI/CDに組み込める（Lighthouse CI）。無料・ブラウザ内で完結。
弱み
動的コンテンツや状態変化（モーダル開閉後など）のチェックは限定的。スコアの高さが完全な対応を意味しない。

axe DevTools（Deque Systems）

世界で最も広く使われているアクセシビリティチェックエンジン。Chrome/Firefox拡張機能として無料で使え、Playwright・Cypressなどのテストフレームワークとの統合も可能だ。CI/CDに組み込んでいるチームも多い。

誤検出（false positive）が非常に少ない設計で、報告された問題は必ず対応が必要
WCAG 2.1/2.2のA・AA基準を網羅的にカバー
axe-coreとしてnpmパッケージが公開されており、自動テストに組み込める
問題ごとに修正方法と参考リンクが提示される

WAVE（WebAIM）

WebAIMが提供するブラウザ拡張機能とオンラインツール。ページに直接アイコンを重ねて表示するビジュアルなUIが特徴で、どこに問題があるかが一目でわかる。

エラー（赤）・警告（黄）・構造（ページの見出し・ランドマーク構造）を色分けで表示
コントラスト比チェック機能が内蔵されている
スタイルなし表示に切り替えてHTMLの構造を確認できる
初学者にとって最もとっつきやすいUIで、学習目的にも最適

注意

自動ツールで「問題なし」と表示されても、アクセシビリティが完全に確保されているわけではない。キーボード操作の確認、スクリーンリーダー（NVDA, JAWS, VoiceOverなど）での実機テストが不可欠だ。特にフォームの操作性やモーダルの動作は手動テストでしか確認できない項目が多い。

アクセシビリティ監査ツールの使い方

当サイトのアクセシビリティ監査ツールを使えば、URLを入力するだけで主要なアクセシビリティ問題を一覧で確認できる。Lighthouseベースのスキャンに加え、コントラスト比・画像のalt属性・見出し構造・lang属性といった重要項目を個別にチェックできる。

ステップ1: URLを入力してスキャン
チェックしたいWebページのURLを入力し、「監査を開始」ボタンをクリックする。スキャンには数秒〜30秒程度かかる。
ステップ2: スコアと問題一覧を確認
WCAG基準ごとのスコアと、検出された問題の一覧が表示される。重大度（エラー/警告/情報）で分類されており、各問題には修正の手がかりも記載されている。
ステップ3: コントラストチェッカーで詳細確認
コントラスト比に問題がある場合は、コントラストチェッカーで具体的な色の組み合わせを検証する。目標のコントラスト比を満たす代替カラーの提案機能も活用できる。
ステップ4: 修正して再スキャン
問題を修正したら再度スキャンして改善を確認する。エラーがゼロになっても手動テスト（キーボード操作、スクリーンリーダー）は必ず実施したい。自動チェックと手動確認の両輪が大切だ。

ツールで効率化

監査ツールと並行して、コントラストチェッカーを使えばデザイン段階でカラー選定のミスを防げる。前景色と背景色を入力するだけでWCAG AA/AAAへの適合可否を即座に判定できる。

アクセシビリティを今すぐチェックする

記事で学んだアクセシビリティの知識を即実践できる無料ツールを用意している。URLを入力するだけでWCAG基準の問題を自動検出し、コントラスト比も瞬時に確認できる。登録不要。

アクセシビリティ監査ツールを開くコントラストチェッカー

よくある質問

Webアクセシビリティ対応はどこから始めればいいですか？: まずLighthouseやWAVEで現状のスコアと問題を把握するところから始めよう。次に重大度の高い問題（画像のalt属性欠如、コントラスト不足、フォームラベルなし）から順に修正する。完璧を目指すより「今よりも良くする」という継続的な改善アプローチが現実的だ。
WCAGのどのレベルまで対応すれば十分ですか？: 一般的なビジネスサイトやフリーランスのポートフォリオサイトでは、WCAG 2.2のレベルAA準拠を目標にするのが標準的だ。行政・公共機関のサイトはJIS X 8341-3（WCAG相当）のAA適合が義務化されている。AAAは全項目達成が困難なため、対応可能な項目から取り組むのが現実的な姿勢だ。
フリーランスがクライアント案件でアクセシビリティに対応する場合の注意点は？: 契約書や要件定義に「WCAG 2.2 AA準拠」を明示しておくのが重要だ。アクセシビリティ対応には工数がかかるため、スコープと費用は事前に合意しておく。納品後に追加コンテンツ（画像・動画）が増える場合は、クライアント側でもalt属性設定などの運用ルールを設けるよう提案しておくとトラブルを防げる。
自動チェックツールだけで十分ですか？: 十分ではない。自動ツールが検出できるのはアクセシビリティ問題全体の約30〜40%と言われている。残りはキーボードだけでの全操作確認、スクリーンリーダー（NVDA, VoiceOverなど）を使った実機テスト、実際の障害当事者によるユーザーテストでしか発見できない。自動ツールはあくまで「スタート地点の把握」と捉えるのが正確だ。
CSSでoutline: noneを使ってはいけないのですか？: デフォルトのフォーカスリングを消すこと自体が問題なのではなく、代替のフォーカス表示を提供せずに消すことが問題だ。outline: none と同時にカスタムの:focus-visibleスタイルを設定すれば問題ない。マウスユーザーには余分なリングが表示されず、キーボードユーザーには明確なフォーカス表示が提供される理想的な実装になる。
既存サイトの全ページを一度に対応するのは大変です。どう進めれば良いですか？: 優先度を付けて段階的に進めるのが賢い。まずコンバージョンに直結するページ（トップページ、問い合わせフォーム、購入フロー）から対応する。次に流入の多いページ、そして残りのページと進む。テンプレートやコンポーネント単位で修正すれば同一の問題を一括で解消できるので効率がいい。