この記事の対象: Webアクセシビリティ対応を始めたいWeb担当者・デザイナー・エンジニア
読了時間: 約9分
「アクセシビリティは大事だとわかっているが、何から着手すればいいのかわからない」という相談は、2026年になった今も変わらず多く聞かれます。
2024年4月の障害者差別解消法改正で、民間企業にも合理的配慮の提供義務が課されてから2年半が経過しました。義務化は「対応するかどうか」の議論ではなく、「どこまで、どの順番で対応するか」という実務の話に移っています。
この記事では、WCAG（Web Content Accessibility Guidelines）の基本を踏まえつつ、まず着手すべき5つのポイントを具体的な実装コードとあわせて整理します。制作会社に発注する際の確認リストとしても使えます。
Webアクセシビリティとは
Webアクセシビリティとは、障害の有無や年齢、利用環境に関係なく、誰もがWebサイトの情報にアクセスできる状態を指します。
対象は視覚障害のある方だけではありません。
| ユーザー | 困りごとの例 |
|---|---|
| 視覚障害（全盲） | スクリーンリーダーで読めない画像・動画 |
| 視覚障害（弱視） | 小さい文字、低コントラストのテキスト |
| 色覚特性 | 赤と緑で区別された情報が判別できない |
| 聴覚障害 | 字幕のない動画、音声のみの情報 |
| 運動障害 | マウスが使えず、キーボードのみで操作 |
| 高齢者 | 小さいリンク、複雑なナビゲーション |
| 一時的な障害 | 骨折した手、まぶしい屋外でのスマホ利用 |
日本は高齢化が進んでおり、高齢者への配慮だけでも対応の効果は広い範囲に及びます。「少数のための特別対応」ではなく、「大半のユーザーの体験を底上げする施策」として捉えるほうが実態に近いです。
準拠すべき基準: WCAG 2.1
Webアクセシビリティの国際基準がWCAG（Web Content Accessibility Guidelines）です。W3C（World Wide Web Consortium）が策定し、日本のJIS X 8341-3もWCAGに準拠しています。
| 適合レベル | 概要 | 目安 |
|---|---|---|
| レベルA | 最低限の基準 | すべてのサイトが満たすべき |
| レベルAA | 推奨基準 | 公的機関・大手企業の目標 |
| レベルAAA | 最高基準 | すべてのコンテンツで達成は困難 |
多くの企業サイトで目指すべきはレベルAAです。この記事で紹介する5つのポイントは、レベルAAの主要項目をカバーしています。
レベルAA（目標）
- コントラスト比4.5:1以上
- キーボード操作完結
- 見出し階層が正しい
レベルA（最低限）
- alt属性の設定
- フォーム要素のラベル付け
- 色だけに依存しない表示
レベルAをクリアしないままAAを目指すのは無理があります。まずA相当の項目から埋めていくのが現実的な進め方です。
2026年の義務化動向と押さえておきたい前提
障害者差別解消法の改正と合理的配慮の義務化
2024年4月に改正障害者差別解消法が施行され、民間企業にも合理的配慮の提供が義務化されました（それまでは努力義務）。
Webサイトに関しては、「合理的配慮」の具体的な内容として、JIS X 8341-3（≒WCAG 2.1）への準拠が一つの目安として扱われています。施行から2年半が経ち、公共性の高い業種（金融・医療・自治体関連）ほど対応状況が注目されやすくなっている段階です。
法的リスクは「訴訟」よりも「見えない離脱」が先に来る
罰則規定は現時点でも設けられていませんが、問い合わせ窓口にクレームが入る、採用応募がスクリーンリーダー利用者から来ない、といった目に見えにくい機会損失のほうが、実務上は先に表面化します。
「義務だから対応する」のではなく、「すべてのユーザーにリーチするためのビジネス投資」として捉えるのが、2026年時点でも変わらず正しいアプローチです。
最低限対応すべき5つのポイント
1. 色だけで情報を伝えない
問題: フォームのエラーを赤色だけで表示している → 色覚特性のあるユーザーが気づけない
対応方法:
– エラー箇所に赤色 + アイコン（⚠）+ テキスト（「この項目は必須です」）を併記
– リンクテキストに下線を追加（色だけでリンクと判別させない）
– グラフの凡例に色 + パターン（斜線、ドットなど）を使用
<!-- 悪い例 -->
<span style="color: red;">必須</span>
<!-- 良い例 -->
<span class="error-text" role="alert">
<span aria-hidden="true">⚠</span> この項目は必須です
</span>
2. キーボード操作に対応する
問題: マウスでしか操作できないUI → 運動障害のあるユーザーが利用できない
対応方法:
– すべてのインタラクティブ要素（リンク、ボタン、フォーム）にTabキーでフォーカスが当たることを確認
– フォーカス時のスタイル（アウトライン）を消さない
– ドロップダウンメニューやモーダルがキーボードで操作できることを確認
/* 悪い例: フォーカスリングを消している */
*:focus {
outline: none;
}
/* 良い例: マウスユーザーにはリングを消し、キーボードユーザーには表示 */
:focus:not(:focus-visible) {
outline: none;
}
:focus-visible {
outline: 2px solid #0066ff;
outline-offset: 2px;
}
チェック方法: Tabキーだけでサイト内のすべての機能を操作してみます。ハンバーガーメニューの開閉、フォーム入力、送信ボタンまでキーボードだけで完了できるかを確認します。
3. alt属性を適切に設定する
問題: 画像にalt属性がない、または「image1.jpg」のような無意味な値 → スクリーンリーダーで画像の内容が伝わらない
| 画像の種類 | alt属性の書き方 |
|---|---|
| 情報を伝える画像 | 画像の内容を簡潔に記述 |
| 装飾目的の画像 | alt="" （空文字）で読み上げスキップ |
| テキスト入りの画像 | 画像内のテキストをそのまま記述 |
| リンク画像 | リンク先の内容を記述 |
| 複雑な図表 | 本文で説明し、altは概要のみ |
<!-- 悪い例 -->
<img src="team.jpg">
<img src="team.jpg" alt="image">
<!-- 良い例 -->
<img src="team.jpg" alt="ミーティング中の開発チーム4名">
<!-- 装飾画像 -->
<img src="divider.png" alt="">
ポイント: 「〇〇の画像」「〇〇の写真」という書き方は冗長です。スクリーンリーダーは<img>要素であることを自動的に伝えるため、「写真」等の記述は不要です。
4. コントラスト比を確保する
問題: 薄いグレーのテキスト（#999999）が白背景で読みにくい → 弱視のユーザーや屋外利用者が読めない
WCAG 2.1 レベルAAの基準:
| テキスト種類 | 必要なコントラスト比 |
|---|---|
| 通常テキスト（18px未満） | 4.5:1 以上 |
| 大きいテキスト（18px以上 or 14px太字以上） | 3:1 以上 |
| ロゴ・装飾テキスト | 基準なし |
実例での確認:
| テキスト色 | 背景色 | コントラスト比 | 判定 |
|---|---|---|---|
| #333333 | #FFFFFF | 12.6:1 | ✅ 合格 |
| #666666 | #FFFFFF | 5.7:1 | ✅ 合格 |
| #999999 | #FFFFFF | 2.8:1 | ❌ 不合格 |
| #FFFFFF | #0066FF | 4.7:1 | ✅ 合格 |
チェックツール: WebAIMのContrast Checkerに2色を入力するだけで判定できます。Figmaユーザーは「Contrast」プラグインが便利です。
5. 見出しの階層を正しくする
問題: デザインの都合でh1→h3→h2のように見出しレベルが飛んでいる → スクリーンリーダーの見出しジャンプ機能が正しく動作しない
対応方法:
– h1 → h2 → h3 の順番を守る（h2の次にh4が来てはいけない）
– 各ページにh1は1つだけ
– 見出しのデザイン（サイズ・太さ）は見出しレベルとは別にCSSで制御
<!-- 悪い例 -->
<h1>会社概要</h1>
<h3>代表メッセージ</h3> <!-- h2を飛ばしている -->
<h2>事業内容</h2>
<!-- 良い例 -->
<h1>会社概要</h1>
<h2>代表メッセージ</h2>
<h2>事業内容</h2>
<h3>Web制作事業</h3>
<h3>コンサルティング事業</h3>
難易度が低いものから着手すると、短期間でLighthouseのスコアが上がり、対応の効果を社内に示しやすくなります。
アクセシビリティチェックツールとAIの使い方
自分のサイトがどの程度対応できているか、以下のツールで確認できます。
| ツール | 種類 | 特徴 |
|---|---|---|
| WAVE | ブラウザ拡張 | 視覚的にエラー箇所を表示。初心者向け |
| axe DevTools | ブラウザ拡張 | 詳細な技術レポート。開発者向け |
| Lighthouse | Chrome DevTools内蔵 | パフォーマンス+アクセシビリティを一括チェック |
| Nu Html Checker | Webサービス | HTMLの文法チェック（W3C公式） |
| カラーコントラストアナライザー | デスクトップアプリ | 任意のUI要素のコントラスト比を測定 |
おすすめの使い方: まずLighthouseで全体のスコアを確認 → スコアが低い項目をaxe DevToolsで詳細分析 → 修正、という流れが効率的です。
検出された問題を直す段階でAIコーディング支援を使う制作者も増えています。alt属性の文案作成や、見出し階層のずれを検出してもらう程度の用途であれば実務に乗りますが、コントラスト比の最終判断や複雑なUIのキーボード操作検証は人の目で確認するのが前提です。使いどころの線引きはAIコーディングはWeb制作の現場で使えるか｜実案件での使いどころで詳しく整理しています。チェックツールとAIの組み合わせ方を用途別に比較したい場合はAIツール比較｜Webディレクターの用途別使い分け完全ガイドも参考になります。
発注者が制作会社に伝えるべきこと
Web制作を外注する場合、以下の項目を制作会社に確認・依頼しましょう。
見積もり・契約段階で確認すること
- 「WCAG 2.1 レベルAAに準拠してほしい」と明確に伝える
- アクセシビリティ対応が見積もりに含まれているか確認
- 対応範囲（全ページか、主要ページのみか）を合意する
費用感は制作会社の規模・対応範囲・既存サイトの改修かリニューアルかによって大きく変わるため、個別の金額を鵜呑みにせず、必ず「どこまでの対応を含むか」を明記した見積もりを取りましょう。
制作中に確認すること
- デザインカンプの段階でコントラスト比をチェック
- テスト環境でキーボード操作を試す
- alt属性のテキスト案を確認・指示
納品時に確認すること
- LighthouseのAccessibilityスコアを納品物に含めてもらう
- 「アクセシビリティ対応箇所一覧」のドキュメントを依頼
既存のテーマ改修や記事生成をAIに任せる案件が増えていますが、アクセシビリティの最終チェックは人が担当すべき工程です。生成作業と確認作業の線引きについてはClaude Code Web制作 使い方｜テーマ改修と記事生成を任せる線引きにまとめています。
よくある質問
アクセシビリティ対応をしないとどんな罰則がありますか？
2026年時点で、Webアクセシビリティ未対応そのものに直接の罰則規定はありません。ただし2024年4月の障害者差別解消法改正で合理的配慮の提供は民間企業にも義務化されており、対応の遅れは問い合わせ対応や企業イメージの面でリスクになります。
WCAG 2.1とWCAG 2.2は何が違いますか？
WCAG 2.2はWCAG 2.1に新しい達成基準を追加したバージョンです。日本のJIS X 8341-3はWCAG 2.1に準拠した内容が基準として広く使われており、まずはこの記事で紹介した2.1レベルAAの項目を満たすことが優先です。
コントラスト比の基準を満たすとデザインが制約されませんか？
薄いグレーやパステルカラーを多用したデザインでは制約を感じやすいですが、濃淡の階調を1段階調整するだけで基準を満たせるケースが大半です。ブランドカラーが基準を満たさない場合は、テキストに使う色とロゴ・装飾に使う色を分けて管理すると解決しやすくなります。
既存サイトのアクセシビリティ対応はどこから始めればいいですか？
この記事の5項目のうち、alt属性と見出し階層の修正はHTMLの記述変更だけで対応できるため、着手コストが最も低いです。次にコントラスト比、最後にキーボード操作の確認という順番で進めると、作業量と効果のバランスが取れます。
スマートフォン表示でも同じ基準を満たす必要がありますか？
はい。WCAG 2.1はデバイスを問わず適用される基準です。特にタップ操作が中心のスマートフォンでは、キーボード操作の代わりにフォーカス移動や音声操作との互換性を確認する必要があります。
まとめ
Webアクセシビリティ対応は、特別なことではありません。この記事で紹介した5つのポイントは、いずれも基本的なHTML/CSSの知識で対応できるものです。
| # | ポイント | 対応の難易度 |
|---|---|---|
| 1 | 色だけで情報を伝えない | 低 |
| 2 | キーボード操作に対応する | 中 |
| 3 | alt属性を適切に設定する | 低 |
| 4 | コントラスト比を確保する | 低 |
| 5 | 見出しの階層を正しくする | 低 |
まずはこの5項目をクリアし、その上で段階的にWCAG 2.1レベルAAの完全準拠を目指すのが現実的なアプローチです。
「対応しなければならないから」ではなく、「すべてのユーザーにとって使いやすいサイトを作る」という意識で取り組むことが、結果としてビジネス成果にもつながります。
