「アクセシビリティ対応はやったほうがいいらしい」——そこで止まっている制作者は多いはずです。ところが2024年4月、事業者にとってアクセシビリティは「やったほうがいい」から一段進んだ位置づけに変わりました。この記事では、日本の制作現場でいま何が求められているのかを法制度から整理したうえで、今日から手を動かせる改善手順とその検証方法までをまとめます。
Webアクセシビリティとは、障害の有無・年齢・利用環境にかかわらず、すべての人がWebコンテンツを認識し、操作し、理解できる状態にすることです。国際的にはW3Cが策定するWCAG（Web Content Accessibility Guidelines）、日本国内ではJIS X 8341-3:2016が判断の基準になります。
Webアクセシビリティが「努力目標」で終わらなくなった理由
2024年4月1日に改正障害者差別解消法が施行され、事業者による「合理的配慮の提供」が努力義務から法的義務に変わりました。国や自治体だけでなく、個人事業主やNPOを含むすべての民間事業者が対象です。
2024年4月、合理的配慮の提供が事業者にも義務化された
根拠は「障害を理由とする差別の解消の推進に関する法律の一部を改正する法律（令和3年法律第56号）」です。内閣府は同法について、令和3年5月に改正され令和6年4月1日に施行されたと公表しています。改正前は行政機関等が義務・事業者は努力義務という二段構えでしたが、改正によってこの区別がなくなりました。
ここで制作者が押さえるべきなのは、「Webサイトを WCAG 準拠にせよ」と条文が命じているわけではないという点です。義務化されたのはあくまで「合理的配慮の提供」であり、Webサイトの作り込みはその前提となる「環境の整備」に位置づけられます。この2つを混同すると、要件定義でクライアントに誤った説明をしてしまいます。
混同しやすい「合理的配慮」と「環境の整備」
両者は目的が地続きですが、法的な強制力と対応のタイミングが異なります。
| 観点 | 合理的配慮の提供 | 環境の整備 |
|---|---|---|
| 法的な位置づけ | 義務（2024年4月〜） | 努力義務 |
| 対応のきっかけ | 本人からの意思表明があったとき | 不特定多数に向けて事前に |
| 対応の性質 | 個別・その場の調整 | あらかじめの仕組みづくり |
| Webでの具体例 | 問い合わせを受けて情報を電話や別形式で提供する | サイト自体をWCAG準拠で構築しておく |
つまりアクセシブルなサイトを最初から作っておくことは、個別対応というコストが発生する場面そのものを減らす投資です。環境の整備が進んでいるほど、合理的配慮として求められる対応は軽くなります。
では、対応しないと罰則があるのか
民間事業者のWebサイトについて、アクセシビリティ基準を満たさないこと自体を直接罰する規定はありません。ただし「罰則がない＝リスクがない」ではない点に注意してください。事業者が合理的配慮の提供を怠っている場合、主務大臣による報告徴収・助言・指導・勧告の対象になり得ます。加えて、行政機関や大企業の調達要件ではJIS X 8341-3:2016 のレベルAA準拠が発注条件として明記されるケースが一般化しており、非対応は受注機会の損失に直結します。
行政官や事業者向けの入門資料としては、デジタル庁のウェブアクセシビリティ導入ガイドブックが公開されています。クライアントに社内説明してもらう際の資料としても使いやすい内容です。
基準はWCAG 2.2とJIS X 8341-3:2016の2本立て
実務で参照する基準は2つです。国際標準がWCAG、日本国内の規格がJIS X 8341-3:2016で、後者は前者の古いバージョンと内容が一致しています。どちらか一方を選ぶのではなく、両者の関係を理解して使い分けます。
WCAG 2.2 — 最新の国際標準
WCAG 2.2 は2023年10月5日にW3C勧告となり、その後2024年12月12日付の改訂版が現行の勧告として公開されています。WCAG 2.1に9つの達成基準が追加され、特にロービジョン・認知障害・タッチ操作に関する項目が強化されました。日本語訳はWAIC（ウェブアクセシビリティ基盤委員会）がWCAG 2.2 日本語訳として公開しています。
WCAGは4つの原則（知覚可能・操作可能・理解可能・堅牢）の下に達成基準が並ぶ構造です。この4原則は頭文字を取ってPOURと呼ばれ、個別のチェック項目を暗記するより、この4つのどれに関わる問題なのかで切り分けたほうが実務では速く判断できます。
JIS X 8341-3:2016 — WCAG 2.0の一致規格
正式名称は「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第3部：ウェブコンテンツ」です。WAICの解説によれば、JIS X 8341-3:2016 は ISO/IEC 40500:2012（＝WCAG 2.0）の一致規格であり、規格本文はWCAG 2.0と同じ内容になっています。2010年版に存在した日本独自の要求事項は、2016年改正で参考附属書へ移されました。
ここから導かれる実務上の結論はシンプルです。WCAG 2.2に沿って作れば、JIS X 8341-3:2016（＝WCAG 2.0）の要求は自動的に満たされます。WCAG 2.2はWCAG 2.0の上位互換だからです。公共系案件で「JIS準拠」を求められた場合も、実装の指針としてはWCAG 2.2を見ておけば足ります。
レベルA・AA・AAAの違いと、目指すべき水準
WCAGの達成基準には3段階の適合レベルがあります。実務で目標にするのはレベルAAです。
| レベル | 位置づけ | 実務での扱い |
|---|---|---|
| A | 満たさないと利用自体が不可能になる最低ライン | 必須。ここを落とすと使えない人が出る |
| AA | 多くの利用者にとって大きな障壁を取り除く水準 | 事実上の標準目標。調達要件もここが基準 |
| AAA | 特定の利用者に対する最大限の配慮 | サイト全体での達成は現実的でなく、W3Cも全体適合を要求していない |
目標を「AAA準拠」に置くと、コントラスト比7:1などの厳しい要求でデザインの自由度が大きく削られます。まずはAAを全ページで確実に満たし、余力のある箇所だけAAAの項目を取り込むという進め方が現実的です。
いま実装できるアクセシビリティ改善6ステップ
ここからは実装です。費用対効果が高い順に6ステップで並べました。この6つを潰すだけで、レベルAAで問題になりやすい箇所の大半をカバーできます。
ステップ1. 画像に「文脈に合った」代替テキストを付ける
alt属性はスクリーンリーダーが画像の内容を読み上げるための情報です。重要なのは「画像に何が写っているか」ではなく「その画像がその文脈で果たしている役割」を書くことです。同じ画像でも、置かれる場所によって適切なaltは変わります。
<!-- 悪い例：ファイル名や冗長な接頭辞 -->
<img src="chart.png" alt="chart.png">
<img src="chart.png" alt="画像：グラフの写真">
<!-- 良い例：その画像が伝えている情報を書く -->
<img src="chart.png" alt="2024年度の問い合わせ件数は前年比で約1.5倍に増加">
<!-- 装飾目的の画像は空のaltで読み上げ対象から外す -->
<img src="divider.svg" alt="">
<!-- リンクを画像だけで構成する場合、altがリンクテキストの代わりになる -->
<a href="/contact/"><img src="btn-contact.png" alt="お問い合わせフォームへ"></a>装飾画像に alt="" を指定するのは「手抜き」ではなく正しい対応です。意味を持たない画像を読み上げさせると、かえって情報がノイズで埋もれます。逆にalt属性そのものを書き忘れると、スクリーンリーダーはファイル名を読み上げてしまうため、「空のalt」と「altなし」はまったく別物として扱ってください。
ステップ2. コントラスト比を確保する（4.5:1と3:1の使い分け）
コントラスト比は主にロービジョン（弱視）の利用者への配慮です。色覚特性への配慮とは別の達成基準なので、混同しないでください。WCAG 2.2の達成基準1.4.3「Contrast (Minimum)」はレベルAAで、通常のテキストに4.5:1以上、大きなテキストには3:1以上を求めています。
| 対象 | 必要な比率 | 達成基準 |
|---|---|---|
| 通常のテキスト | 4.5:1 以上 | 1.4.3（AA） |
| 大きなテキスト（18pt以上、または14pt以上の太字） | 3:1 以上 | 1.4.3（AA） |
| UIコンポーネントの境界・アイコンなど文字以外 | 3:1 以上 | 1.4.11（AA） |
| より高い水準を目指す場合の通常テキスト | 7:1 以上 | 1.4.6（AAA） |
見落とされがちなのが表の3行目、1.4.11「Non-text Contrast」です。入力フォームの枠線、トグルスイッチ、グラフの区切り線といった「文字ではないが意味を持つ要素」も3:1以上が必要になります。薄いグレーの1px枠線は、この基準でほぼ確実に落ちます。
配色を検討する段階でコントラストを確認しておくと手戻りが減ります。写真からパレットを起こす場合は画像・写真からWEBデザイン用カラーパレットを自動生成できるツール、色名や由来から色を選びたい場合は日本の伝統色とCSS名前付き色を引ける色の辞書が使えます。
ステップ3. 色だけで情報を伝えない
こちらが色覚特性への配慮にあたる項目で、達成基準1.4.1「Use of Color」（レベルA）です。レベルAなので、コントラスト比より優先度が高いと考えてください。
- フォームのエラーを赤字だけで示す → アイコンとエラー文言を併記する
- 必須項目を赤い色だけで示す → 「必須」というラベルを添える
- グラフの系列を色だけで区別する → 線種・パターン・直接ラベルを併用する
- 本文中のリンクを色の違いだけで示す → 下線を残す、または3:1以上の輝度差を確保する
判定方法は簡単で、グレースケールにしても情報が伝わるかを確認するだけです。デザインカンプの段階で一度モノクロにしてみると、色に依存した表現が一目で洗い出せます。
ステップ4. キーボードだけで最後まで操作できるようにする
マウスが使えない利用者、スクリーンリーダー利用者、そして単に効率を求める人がキーボード操作に依存します。達成基準2.1.1「Keyboard」はレベルAです。
最も効果が大きい対策はネイティブのHTML要素を使うことです。<button> や <a href> は最初からキーボードで到達・実行できますが、<div> にクリックイベントを付けただけの疑似ボタンはフォーカスも受け取れず、Enterでも動きません。
<!-- 悪い例：キーボードで到達も実行もできない -->
<div class="btn" onclick="submitForm()">送信</div>
<!-- 良い例：ネイティブ要素なら何もしなくてもキーボードで動く -->
<button type="submit" class="btn">送信</button>
<!-- ページ先頭にスキップリンクを置き、繰り返しナビを飛ばせるようにする -->
<a href="#main" class="skip-link">本文へスキップ</a>あわせて注意したいのがタブ順序です。CSSで見た目の並びを入れ替えると、DOM順とフォーカス移動の順序がずれて「画面を行ったり来たりする」挙動になります。tabindex に正の値を指定して順序を無理やり制御するのも避けてください。管理が破綻します。DOMの並び自体を論理順にするのが正解です。
ステップ5. フォーカスインジケーターを消さない
キーボード操作中に「いまどこにいるか」を示す枠線がフォーカスインジケーターです。達成基準2.4.7「Focus Visible」（レベルAA）で可視化が求められています。
ところが実装現場では、デザイン上の理由で outline: none; が書かれてしまうことが非常に多い。これはキーボード利用者から現在位置を奪う操作なので、代替のスタイルなしに消してはいけません。
/* 悪い例：フォーカス位置がまったく見えなくなる */
:focus {
outline: none;
}
/* 良い例：マウス操作では出さず、キーボード操作時だけ明示する */
:focus-visible {
outline: 3px solid #1a73e8;
outline-offset: 2px;
border-radius: 2px;
}:focus-visible を使えば、マウスクリック時には枠線が出ず、キーボード操作時だけ表示されます。「デザインが崩れるから消したい」という要望と基準の両立は、この擬似クラスでほぼ解決できます。なおアウトラインの色も背景に対して3:1以上を確保してください（1.4.11の対象です）。
ステップ6. 動画・音声に代替手段を用意する
ここは「字幕を付ける」で片付けられがちですが、コンテンツの種類によって必要な代替手段が違います。音声だけのコンテンツに字幕という概念はありません。
| コンテンツ | 必要な代替手段 | 達成基準 |
|---|---|---|
| 音声のみ（ポッドキャストなど） | 書き起こしテキスト | 1.2.1（A） |
| 映像のみ（BGMなしの操作デモなど） | 内容を説明したテキスト、または音声解説 | 1.2.1（A） |
| 音声付き動画 | 同期した字幕（キャプション） | 1.2.2（A） |
| 音声付き動画（映像内の情報が音声にない場合） | 音声解説、または書き起こし | 1.2.3 / 1.2.5（A / AA） |
自動生成字幕をそのまま使うのは避けてください。固有名詞や専門用語の誤変換が残った字幕は、正確な情報伝達という目的を果たしません。生成後に人の目で修正するところまでが対応です。
検証は「自動チェックだけでは終わらない」前提で組む
アクセシビリティ検証で最も多い誤解が、「自動チェックツールでエラーゼロ＝準拠」だと考えてしまうことです。自動ツールが機械的に判定できるのは達成基準のごく一部にすぎません。ツールは出発点であって、ゴールではありません。
まず動かす自動チェックツール
導入コストが低い順に3つ挙げます。最初の1つはブラウザに最初から入っています。
| ツール | 形態 | 向いている用途 |
|---|---|---|
| Lighthouse | Chrome DevTools内蔵 | 導入不要。まず現状のスコアと主要な問題を把握する |
| axe DevTools | ブラウザ拡張 | 誤検知が少なく、違反箇所とWCAG基準の対応が明確 |
| WAVE | ブラウザ拡張／Web版 | 問題箇所をページ上に視覚的に重ねて表示する |
LighthouseはChromeの開発者ツールから追加インストールなしで実行できます。DevTools自体の使い方から固めたい場合はChrome DevToolsで仮説と検証を回す手順を参照してください。
自動では検出できず、手動確認が必要な項目
以下はいずれも「機械的にはエラーにならないが、実際には使えない」典型例です。リリース前に人の手で確認してください。
- altの内容が適切か：altが存在することは自動判定できても、その文言が文脈に合っているかは判定できない
- キーボードだけで全機能を使えるか：Tabキーだけでフォーム送信からモーダルの開閉まで一周できるか実際に触る
- フォーカスの移動順が論理的か：視覚的な並びとフォーカス順が一致しているか目で追う
- モーダル内にフォーカスが閉じ込められているか：開いたまま背後の要素にフォーカスが抜けないか
- 200%まで拡大しても内容が失われないか：ブラウザのズームで横スクロールや文字の重なりが発生しないか
- 見出し構造が文書の論理と一致しているか：見た目の大きさでh要素を選んでいないか
6番目の見出し構造は、スクリーンリーダー利用者がページ内を移動する主要な手段であると同時に、検索エンジンが文書構造を理解する手がかりでもあります。階層の飛び（h2の次にh4が来るなど）はHTMLアウトライン設計ツールで機械的に洗い出せます。
制作現場でよく起きる失敗パターン
基準を知っていても、進め方を誤ると工数だけがかさみます。実装で踏みやすい落とし穴を挙げます。
公開直前にまとめて対応しようとする
最も高くつくパターンです。コントラスト不足はデザイン工程まで、見出し構造とマークアップは実装工程まで戻らないと直せません。アクセシビリティはテスト工程で追加するものではなく、デザイン段階から織り込む制約として扱ってください。カンプ作成前に決めておくべきルールについてはデザインカンプ前に決めるWebデザインのルールも参考になります。
ARIAを付ければ解決すると考える
WAI-ARIAは、ネイティブHTMLで表現できない場合の補助手段です。<div role="button"> と書いても、キーボードのフォーカスもEnterキーの実行も自動では付いてきません。W3Cも「ARIAを使わないで済むならその方がよい」という趣旨の原則を示しています。まずネイティブ要素、それで表現できない場合にだけARIAという順序を守ってください。
オーバーレイ型の「ワンタグ導入」ツールに頼る
JavaScriptを1行入れるだけでアクセシビリティ対応が完了する、と謳うオーバーレイ型ツールがあります。しかしこれらはHTMLの構造そのものを直すわけではないため、altの適切さや見出し構造といった根本的な問題は解決しません。海外では、オーバーレイを導入したサイトが訴訟対象になった事例も報告されています。導入するとしても、あくまで補助として位置づけ、本体の実装を直すことから逃げないでください。
アクセシビリティ対応を「SEO施策」として売り込む
両者に重なりがあるのは事実です。適切なalt属性はGoogleの画像SEOドキュメントでも画像の内容理解に役立つと説明されていますし、正しい見出し構造やセマンティックなHTMLはクローラーの理解を助けます。
ただしGoogleは「アクセシビリティ対応をすれば検索順位が上がる」とは明言していません。順位向上を約束する形で提案すると、成果が出なかったときに信頼を損ないます。アクセシビリティは「利用できる人を増やす」ことが本来の目的であり、SEOへの好影響は副次的なものと整理して説明するのが誠実です。検索面の施策はSEO対策ガイドのように別軸で組み立ててください。
見出し構造とメタタグの状態はDirebase（ディレベース）で診断できます
まとめ
2024年4月の法改正で、事業者にとってアクセシビリティは無視できない前提になりました。とはいえ条文がWCAG準拠を直接命じているわけではなく、制作者がやるべきことは「環境の整備」としてサイトを最初からアクセシブルに作っておくことに尽きます。
- 基準はWCAG 2.2に合わせれば、JIS X 8341-3:2016の要求も満たせる
- 目標水準はレベルAA。AAAの全体適合は目指さない
- コントラスト比はロービジョン向け、色以外の手がかりは色覚特性向けで、別々の基準
- ネイティブHTML要素を使うことが、キーボード操作対応の最短ルート
- 自動チェックはあくまで出発点。キーボード操作と拡大表示は手で確認する
すべてを一度に完璧にする必要はありません。まずLighthouseを1回動かし、altとコントラスト、そしてキーボード操作の3点から着手してください。この3つだけでも、届く利用者の範囲は確実に広がります。
よくある質問（FAQ）
Q. Webアクセシビリティとは何ですか？
Webアクセシビリティとは、障害の有無・年齢・利用環境にかかわらず、すべての人がWebコンテンツを認識し、操作し、理解できる状態にすることです。国際的にはW3Cが策定するWCAG（Web Content Accessibility Guidelines）が標準として使われ、日本国内ではWCAG 2.0の一致規格であるJIS X 8341-3:2016が規格として定められています。
Q. 法改正で企業のWebサイトは何が義務になったのですか？
2024年4月1日施行の改正障害者差別解消法で義務化されたのは「合理的配慮の提供」であり、Webサイトを特定の基準に準拠させること自体を直接義務づける規定ではありません。サイトをアクセシブルに作っておくことは「環境の整備」にあたり努力義務ですが、環境の整備が進んでいるほど個別対応の負担は軽くなるため、実務上は事前対応が有利です。
Q. WCAGとJIS X 8341-3のどちらに従えばよいですか？
実装の指針としてはWCAG 2.2を見れば足ります。JIS X 8341-3:2016はISO/IEC 40500:2012（WCAG 2.0）の一致規格で、WCAG 2.2はWCAG 2.0の上位互換にあたるためです。公共系案件で「JIS準拠」を求められた場合も、WCAG 2.2のレベルAAを満たす作りにしておけばJISの要求を満たせます。
Q. レベルA・AA・AAAのどれを目指すべきですか？
レベルAAを目標にしてください。行政機関や大企業の調達要件でもAA準拠が基準とされることが一般的です。AAAはコントラスト比7:1などの厳しい要求を含み、W3C自身もサイト全体でのAAA適合は要求していないため、余力のある箇所で個別に取り込む程度が現実的です。
Q. アクセシビリティ対応をすると検索順位は上がりますか？
Googleはアクセシビリティ対応が検索順位を上げるとは明言していません。ただし適切なalt属性は画像の内容理解に役立つとGoogleの画像SEOドキュメントで説明されており、正しい見出し構造やセマンティックなHTMLはクローラーの文書理解を助けます。順位向上を目的にするのではなく、利用できる人を増やす取り組みとして進め、SEOへの好影響は副次的なものと捉えるのが適切です。