Webアクセシビリティ対応ガイド｜企業担当者が知るべき法的背景・対応手順・費用を解説【2026年版】

自社のWebサイトがアクセシビリティ対応できているか不安を感じているWeb担当者の方は、ここ数年で急増しています。「義務化された」「対応しないと訴えられる」という情報が飛び交い、何が本当で何から手をつければいいのか、判断がつかない状況に追い込まれているのではないでしょうか。

特に困るのは、経営層や上司から「うちのサイト大丈夫？」と聞かれたとき。「なんとなく対応が必要そう」という感覚はあっても、「どこまでやれば十分か」「どの程度のリスクがあるのか」を具体的に説明できないまま、検討が止まっている——そんなケースが多いようです。

この記事では、Webアクセシビリティ対応を検討している企業のWeb担当者・情報システム担当者の方に向けて、法的背景の正確な整理から対応規格の選び方・実践的な手順・費用相場・外注時の発注ポイントまでを一冊の手引きとしてまとめました。

「義務か努力義務か」という混乱を解消し、自社にとって必要な対応レベルを自分で判断できる状態になることを目的としています。それではWebアクセシビリティ対応の全体像から解説していきましょう。

Webアクセシビリティとは？なぜ今対応が求められるのか

Webアクセシビリティとは

Webアクセシビリティ（Web accessibility）とは、障害の有無や年齢・利用環境にかかわらず、すべての人がWebサイトの情報や機能を利用できる状態のことです。

視覚障害者がスクリーンリーダーでWebサイトを読み上げる場面を想像してみてください。画像に説明文（alt属性）がなければ、その画像が何を伝えているのか分かりません。フォームのラベルが適切に設定されていなければ、入力項目が何を求めているのか理解できません。こうした「アクセスのしやすさ」を設計段階から考慮することが、Webアクセシビリティ対応です。

ウェブアクセシビリティ基盤委員会（WAIC）では、Webアクセシビリティを「ウェブコンテンツ、より具体的にはウェブページにある情報や機能の利用しやすさ」と定義しています。

対応が必要な「利用者」とは誰か

アクセシビリティ対応の対象となる利用者は、視覚障害者だけではありません。主に以下のような方々が想定されます。

• 視覚障害: 全盲・弱視・色覚特性のある方。スクリーンリーダーや拡大表示を使用
• 聴覚障害: 動画コンテンツの音声情報が届かない方。字幕が必要
• 運動機能障害: マウス操作が難しく、キーボードのみで操作する方
• 認知・学習障害: 複雑なナビゲーションや長文が理解しにくい方
• 高齢者: 視力低下・細かな操作が難しい方
• 一時的な障害: 利き手を骨折している、明るい屋外でスマートフォンを使うなど

日本の高齢化が進む中、高齢者人口は全体の約30%に達しており（内閣府「高齢社会白書」）、Webアクセシビリティは将来の利用者層に対応するビジネス上の合理的な投資でもあります。

なぜ今、企業が対応を求められているのか

アクセシビリティ対応が企業で議論されるようになった背景には、主に3つの要因があります。

1. 2024年の法改正: 2024年4月1日施行の改正障害者差別解消法により、民間企業への義務範囲が拡大（詳細は次のセクションで説明）
2. デジタル庁のガイドライン整備: 政府調達要件への組み込みが進み、公共サービスとの連携でBtoG向けサービスには実質的な要件になっている
3. グローバルな訴訟リスクの意識: アメリカではアクセシビリティ未対応を理由とした訴訟が急増しており（2023年に4,605件：出典 Web担当者Forum「米国で急増するウェブアクセシビリティ訴訟」）、日本でも注目が高まっている

障害者差別解消法との関係：「義務化」の実態を正確に理解する

「Webアクセシビリティが義務化された」という表現がメディアで多く使われていますが、これは正確ではありません。正確に理解することで、自社のリスク判断ができます。

「合理的配慮の義務化」と「環境整備の努力義務」の違い

2024年4月施行の改正障害者差別解消法で変わったのは以下の点です。

区分	改正前	改正後
合理的配慮の提供（民間事業者）	努力義務	義務
環境整備	努力義務	努力義務（変化なし）

SCROLL→

合理的配慮とは、障害のある人から「このWebサイトが使えない」と申し出があった場合に、その個別の状況に応じた対応をすることです。たとえば「スクリーンリーダーで読めないので別の方法で情報を提供してほしい」という申し出に対して、代替手段を検討・提供することが義務化されました。

一方、Webアクセシビリティ対応（アクセシブルなサイトを事前に整備すること）は「環境整備」に位置づけられており、これは努力義務のままです。

Webアクセシビリティは義務か努力義務か

結論として、Webアクセシビリティ対応（サイトの事前整備）は努力義務です。法律上の強制義務ではありません。

ただし、「努力義務だから対応しなくていい」という判断は危険です。以下の観点からリスクを整理してください。

• 行政指導リスク: 対応の努力が見られず障害者からの申し出を放置した場合、行政から指導・勧告を受ける可能性がある
• 民事訴訟リスク: 合理的配慮義務違反として損害賠償請求の対象になりうる（義務化された「合理的配慮」を果たしていない場合）
• ブランドリスク: SNS時代において、アクセシビリティ未対応が批判を受けると炎上・不買運動に発展する可能性がある
• 機会損失: アクセシブルでないサイトは、障害者・高齢者という潜在的な顧客層へのアクセスを自ら閉じていることになる

対応しなかった場合のリスク（法的リスク・ブランドリスク）

現時点で日本国内にはWebアクセシビリティ未対応に対する直接的な罰則規定はありません。しかし以下を念頭に置いておく必要があります。

• 行政の勧告・公表: 改正障害者差別解消法では、指導に従わない事業者に対して勧告・公表ができる規定がある
• 企業評価への影響: 金融機関や大企業との取引・調達要件にアクセシビリティ対応が含まれるケースが増えている
• 将来の法整備: 諸外国では義務化・罰則化が進んでおり、日本でも法整備が強化される可能性がある

経営層への説明ポイント: 「今すぐ罰則はないが、合理的配慮義務（これは民間も義務）を果たすためにもサイトの整備は有効であり、ブランドリスク・将来の法整備リスクを考えると計画的な対応が合理的な投資である」

準拠すべき規格：WCAG 2.1/2.2 と JIS X 8341-3 の違い

Webアクセシビリティには2種類の規格があります。どちらに対応すればいいのか、混乱している方が多いため整理します。

WCAGとは（国際規格・W3C制定）

WCAG（Web Content Accessibility Guidelines）は、W3C（World Wide Web Consortium）が制定した国際的なWebアクセシビリティのガイドラインです。現在の最新バージョンはWCAG 2.2（2023年10月5日正式勧告）です。

WCAGは「知覚可能・操作可能・理解可能・堅牢性」という4つの原則のもとに達成基準が整理されており、各基準はレベルA（最低）・AA・AAA（最高）の3段階に分けられています。

JIS X 8341-3とは（日本語版・国内規格）

JIS X 8341-3は、WCAGを元に日本産業規格（JIS）として制定された国内規格です。現行のJIS X 8341-3:2016はWCAG 2.0（2008年制定）をベースにしています。

国や地方公共団体のWebサイト、そして政府調達要件ではJIS X 8341-3への対応が求められることが多く、「JIS準拠」という表現は日本でよく使われます。

WCAG 2.2での主な変更点

2023年10月に勧告されたWCAG 2.2では、WCAG 2.1と比較して9つの新しい達成基準が追加されました。そのうちAAレベルに追加されたのは以下の4基準です（W3C WCAG 2.2）。

達成基準	レベル	内容
2.4.11 隠されないフォーカス（最低限）	AA	キーボードフォーカスが他のコンテンツに完全に隠れないこと
2.5.7 ドラッグ動作	AA	ドラッグが必要な操作はドラッグなしでも実行できること
2.5.8 ターゲットサイズ（最低限）	AA	クリック・タップ対象は最低24×24 CSSピクセル以上
3.3.8 アクセシブルな認証（最低限）	AA	認知テスト（謎解き・記憶・計算）を認証に使わないこと

SCROLL→

また、WCAG 2.1で存在した4.1.1「構文解析」（A）はWCAG 2.2で削除されています。

2026年のJIS改正に向けた準備

JIS X 8341-3は2026年度内に改正される見通しで、WCAG 2.2ベースの内容に更新される方針です（JIS X 8341-3改正原案作成委員会は2024年10月に発足：ミツエーリンクス記事）。

今からWCAG 2.2 AAを基準に対応を進めることが、JIS改正後の対応コストを最小化する最善手です。 JIS改正を待ってから動き始めると、将来的に追加の改修コストが発生します。

対応レベル（A/AA/AAA）の選び方：企業サイトの現実的な目標設定

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

WCAGの達成基準は3段階のレベルで分類されています。

レベル	特徴	例
A（最低限）	基本的なアクセシビリティ。これが達成されないと特定のユーザーはサイトを使えない	画像にalt属性を設定する、キーボードのみで操作できる
AA（推奨）	広範なアクセシビリティ。ほとんどのユーザーが利用できる水準	テキストのコントラスト比が4.5:1以上、エラー時にユーザーへの説明がある
AAA（最高水準）	高度なアクセシビリティ。全ての基準を満たすことは一部のコンテンツでは現実的でない	手話通訳の提供、読解レベルが低中学生相当

SCROLL→

企業サイトが目指すべきレベルは「AA」

企業のWebサイトが目指すべき現実的な目標は、WCAG 2.2（またはJIS X 8341-3）のレベルAA準拠です。その理由を説明します。

• Aのみでは不十分: レベルAは「使えなくはない」という最低水準。コントラスト比が低くても達成でき、多くのユーザーが不便を感じる
• AAAは現実的でない: AAAには、すべての音声コンテンツに手話通訳を提供するといった項目が含まれており、一般的な企業サイトでは対応が困難なものも多い
• 公的調達の基準: 国や地方公共団体のWebサイトはAA準拠が求められており、実質的なスタンダードになっている

「準拠」「一部準拠」「配慮」という対応度の表明方法

WAICのガイドラインに基づき、自社サイトのアクセシビリティ対応状況を以下の3段階で公表することができます。

表明区分	基準	適するケース
準拠	対象範囲の達成基準を全て満たしている（試験で確認済み）	AA準拠の試験が完了している
一部準拠	達成できていない基準があり、内容を明示している	大部分は対応しているが例外がある
配慮	特定の規格への準拠は表明しないが、配慮している	試験未実施だが基本的な対応をしている

SCROLL→

多くの企業では最初「配慮」または「一部準拠」として方針を公表し、段階的に「準拠」へ移行するアプローチが現実的です。

実践的な対応手順：何から始めるか（チェックリスト付き）

ステップ1：現状診断（無料ツールでできる初期チェック）

まずは現状把握から始めます。専門業者への依頼前に、無料ツールを使って基本的な問題を洗い出せます。

主要な無料チェックツール:

• axe DevTools（ブラウザ拡張）: Chrome/Firefoxに追加するだけで、ページの問題点をリスト化してくれる。開発者向けだが非エンジニアでも基本操作は可能
• WAVE（ブラウザ拡張）: 視覚的なレポートで問題箇所を表示。色コントラストの確認も可能
• Lighthouse（Chrome DevTools内蔵）: Chrome DevToolsから「Accessibility」スコアを確認できる

ただし、自動チェックツールだけでは全問題の20〜30%程度しか検出できません（出典: WebA11y.jp「チェックツールを使えば、自動的にチェックできるよね？」）。キーボード操作の確認・スクリーンリーダーでの動作確認には人手による試験が必要です。

ステップ2：アクセシビリティ方針の策定と公開

対応を進める前に、会社としての方針を文書化して公開することが重要です。WAICのガイドラインでは「アクセシビリティ方針」の公開が推奨されており、外部への姿勢表明になります。

方針書に含めるべき内容：

• 準拠する規格・レベル（例: WCAG 2.2 AA）
• 対応状況の区分（準拠/一部準拠/配慮）
• 達成できていない基準とその理由
• 対応に向けた計画
• 問い合わせ先

ステップ3：対応範囲と優先度の決定

全ページを一度に対応することは現実的でないケースが多いです。以下の観点で優先度を決めます。

• トップページ・主要サービスページ: 最も多くのユーザーが訪れる
• お問い合わせフォーム・申し込みフォーム: フォームのアクセシビリティ問題は障害者の機会均等に直接影響
• 採用ページ: 合理的配慮義務の観点で特に重要
• 高齢者・障害者が多く利用するサービスのページ

ステップ4：改修と試験の実施

改修は開発会社と連携して進めます。改修後は自動ツール＋人手による試験を実施し、達成基準を満たしているか確認します。JIS準拠を表明する場合は、外部機関による第三者試験の実施が推奨されます。

まずチェックすべき10項目（チェックリスト）

以下の項目は対応コストが比較的低く、効果が高い基本的な確認ポイントです。

#	チェック項目	関連するWCAG達成基準
1	画像に意味のあるalt属性が設定されているか	1.1.1 テキスト以外のコンテンツ（A）
2	装飾目的の画像はalt=""になっているか	1.1.1（A）
3	テキストと背景のコントラスト比が4.5:1以上か	1.4.3 コントラスト（最低限）（AA）
4	キーボードのみですべての機能が操作できるか	2.1.1 キーボード（A）
5	キーボードフォーカスが視覚的に分かるか	2.4.7 フォーカスの可視化（AA）
6	ページにわかりやすいtitleが設定されているか	2.4.2 ページタイトル（A）
7	フォームのラベルが適切に設定されているか	1.3.1 情報と関係性（A）, 3.3.2 ラベルまたは説明（A）
8	エラーが発生したとき、説明が提供されているか	3.3.1 エラーの特定（A）
9	動画コンテンツに字幕があるか	1.2.2 収録済みの音声コンテンツへの代替（A）
10	見出し（h1〜h6）が論理的な階層で使われているか	1.3.1（A）, 2.4.6 見出し及びラベル（AA）

SCROLL→

対応にかかる費用の目安：改修規模別の相場

アクセシビリティ診断の費用相場

外部の専門機関にアクセシビリティ診断を依頼する場合の費用目安です。

診断の種類	費用目安	特徴
自動ツールによる簡易診断	数万円〜20万円程度	問題の概要把握。人手による確認は含まない
専門家による詳細診断（10ページ程度）	27万円〜50万円程度	WCAG/JIS準拠の達成基準ごとに確認
大規模診断（100ページ程度）	50万円〜100万円以上	外部機関への試験委託。1ヶ月弱かかることも

SCROLL→

参考として、BIPROGYチャレンジド株式会社の公開料金（料金ページ）では、ページ数・達成基準レベルによって料金が設定されています。

改修費用の目安と変動要因

診断後の改修費用は、問題の量・種類によって大きく変動します。

費用が低くなるケース:

• 問題がalt属性の追加・色のコントラスト修正など、HTMLやCSSの修正で対応できる場合
• 問題が少なく、重要ページ数ページのみを対象とする場合

費用が高くなるケース:

• デザイン全体の見直しが必要（コントラスト比がデザインに組み込まれている等）
• JavaScriptで構築された複雑なインタラクションの改修
• 動画コンテンツへの字幕追加
• フォーム設計の根本的な見直し

一般的には、既存サイトの部分的な改修で50万〜200万円程度が中央的な目安ですが、サイトの規模・問題の深刻さによって幅があります。

コストを抑えるタイミング：リニューアル時の同時対応

アクセシビリティ対応コストを最小化するには、サイトリニューアルのタイミングでの同時対応が最も効率的です。

リニューアル後に改修する場合と比べると、リニューアル時に要件として含める場合の追加コストは最小限に抑えられます。逆に、リニューアル後に気づいてから対応しようとすると、デザイン変更・コード改修に追加のコストが発生します。

Webリニューアルを検討している場合は、提案要件に「WCAG 2.2 AA準拠」を含めることを強く推奨します。

段階的対応のロードマップ例

一度に全対応することが難しい場合、以下のような段階的アプローチが現実的です。

フェーズ	期間目安	内容
フェーズ1（短期）	1〜3ヶ月	現状診断・アクセシビリティ方針の公開・最重要ページの基本対応（alt属性・コントラスト・フォームラベル）
フェーズ2（中期）	3〜12ヶ月	主要ページへの対応拡大・動画コンテンツの字幕追加・キーボード操作の確認
フェーズ3（長期）	1年以上	全ページへの展開・第三者試験の実施・準拠表明の公開・継続的な品質維持体制の構築

SCROLL→

外注する場合のポイント：開発会社・制作会社への発注時の確認事項

多くの企業では、Webアクセシビリティ対応を開発会社・制作会社に外注することになります。発注者として押さえておくべきポイントを解説します。なお、Web開発の基本的な流れや開発会社の選び方については別記事で詳しく解説しています。

要件定義に「WCAG 2.2 AA準拠」を明記する

最も重要なのは、見積もり段階・要件定義書に「WCAG 2.2 レベルAA準拠」を明記することです。

アクセシビリティ対応をあいまいな形で依頼すると、「配慮しました」という程度の対応で終わるケースがあります。「WCAG 2.2 AA準拠を達成基準とし、試験結果のレポートを成果物として提出すること」と明記しておくことで、受注側も対応コストを見積もりやすくなり、結果的に手戻りが少なくなります。

見積もり時に確認すべき5項目

開発・制作会社に見積もりを依頼する際は、以下を確認してください。

1. 対応範囲: どのページ・どの機能を対象とするか（全ページか主要ページか）
2. 準拠レベルと規格: WCAG 2.2 AA準拠か、JIS X 8341-3準拠か
3. 試験の実施方法: 自動ツールのみか、人手による試験（キーボード操作・スクリーンリーダー）も含むか
4. 成果物の定義: 試験レポート・アクセシビリティ方針文書の作成は含まれるか
5. 改修後のサポート: 定期的な確認・コンテンツ追加時のアドバイスなど継続サポートの有無

開発完了後の検収チェックポイント

成果物を受け取る際の確認点を準備しておきます。

• 試験レポートの確認: 達成基準ごとに「適合/不適合/該当なし」が記載されているか
• 未達成基準の明示: 対応できなかった基準がある場合、理由と代替手段が記載されているか
• 自分でもチェック: axeなどの無料ツールを使って、重大な問題が残っていないか自分でも確認する
• キーボード操作の確認: マウスを使わず、タブキーだけで主要機能にアクセスできるか実際に試す

継続的な品質維持の仕組みを確認する

アクセシビリティ対応は一度やれば完了ではありません。コンテンツが追加されるたびに品質が劣化するリスクがあります。

外注時には「コンテンツ追加・更新時のアクセシビリティ確認」についても仕組みを確認しておきましょう。たとえば「画像追加時にalt属性のルールを共有する」「CMS のコンテンツ入力時のガイドラインを作成する」といった対策が有効です。

対応後の継続運用：どうやって品質を維持するか

アクセシビリティは「一度対応したら終わり」ではない理由

初回対応が完了した後も、以下の理由でアクセシビリティ品質は劣化していきます。

• コンテンツの追加: 新しいページ・画像・動画が追加されるたびにalt属性・字幕の確認が必要
• デザイン変更: キャンペーンバナーや季節に合わせた配色変更でコントラスト比が悪化するケース
• 機能追加: 新しいフォーム・モーダル・インタラクションはキーボード対応の確認が必要
• CMSの更新: WordPressなどのCMS更新でテーマやプラグインの動作が変わるケース

継続運用のための社内フロー構築

アクセシビリティ品質を維持するためには、社内の制作フローに組み込むことが重要です。

具体的な取り組み例:

• コンテンツ追加時のチェックリスト: 新しい画像を追加する際はalt属性を確認する手順書を整備
• 定期診断: 四半期または半期ごとに自動ツールでのスキャンを実施
• 担当者の教育: Web担当者・コンテンツ担当者向けのアクセシビリティ基礎研修
• 発注仕様への組み込み: 今後の外注案件にすべてアクセシビリティ要件を含める

2026年JIS改正に備えた準備

2026年度内に予定されているJIS X 8341-3の改正では、現行のWCAG 2.0ベースからWCAG 2.2ベースへの移行が予定されています。

今からWCAG 2.2 AAへの対応を進めておくことで、JIS改正後の追加対応コストを最小化できます。特に以下の基準はWCAG 2.2で新たに追加されたものであり、JIS改正後に要求されることが想定されます。

• ターゲットサイズ（最低限）: ボタン・リンクのクリック領域の大きさ
• アクセシブルな認証: reCAPTCHAなどの認証方式の見直し
• ドラッグ動作の代替: ドラッグ操作に頼らない代替手段の提供

まとめ：最低限やるべきことのアクションリスト

Webアクセシビリティ対応は、大規模な投資なしに段階的に進められます。以下のアクションリストを参考に、自社の状況に合わせて着手してください。

今すぐできること（費用ゼロ〜低コスト）

• axe、WAVE などの無料ツールでトップページの現状診断を実施する
• 対応状況の概要を確認し、問題の多さ・種類を把握する
• アクセシビリティ方針（「配慮」レベルでOK）を策定し、サイトのフッターまたは会社情報ページに公開する
• 次回のサイト更新・リニューアル要件に「WCAG 2.2 AA準拠」を含めることを決定する

3ヶ月以内に着手すること

• 重要ページ（トップ・お問い合わせ・採用）のalt属性・コントラスト比・フォームラベルを確認・修正する
• キーボードのみでの主要機能の操作確認を実施する
• 社内コンテンツ担当者向けの基本チェック手順書を作成する
• Webサイトのリニューアル・大規模改修の場合は、アクセシビリティ対応コストを見積もりに含める

中長期的な取り組み

• 外部の専門機関による詳細診断を実施し、改修計画を立案する
• WCAG 2.2 AA準拠を目指した系統的な改修を実施する
• 定期的な診断と継続運用フローを構築する
• 2026年JIS X 8341-3改正への対応を見据えた計画を立案する

経営層・上司への報告の際は、「義務化された部分（合理的配慮）と努力義務の部分（環境整備）を区別した上で、将来のリスクを考慮した計画的な投資として対応を進める」という方針を提示することで、現実的な議論ができます。

Webアクセシビリティ対応は、誰もが使いやすいWebを作るという価値と、ビジネスリスクを低減するという実用面の両方から意味のある取り組みです。まずは現状把握から始めてみてください。

秋霜堂株式会社について

秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。

システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。