米国の判例から学ぶWebアクセシビリティ：日本企業が押さえる法律・基準・実務

Webアクセシビリティとは、障害や利用環境にかかわらず、必要な情報や機能を利用できる状態を目指す考え方です。
視覚に頼らず内容を伝える、マウスを使わずに操作できる、動画の音声を字幕でも理解できるといった設計が含まれます。

米国では、利用できないWebサイトやアプリが障害者差別に当たるかを争った訴訟が積み重なってきました。
ただし、個々の判決や和解は、裁判所の管轄、サービスの内容、実店舗との関係、問題となった機能によって射程が異なります。
一つの事例を「米国のすべてのWebサイトに同じ基準が適用される」と読み替えることはできません。

日本では、2024年4月から事業者による合理的配慮の提供が法的義務になりました。
一方、障害者差別解消法、JIS X 8341-3、WCAGは役割が異なるため、同じものとして扱わないことが実務の出発点になります。

この記事は2026年7月時点の一般的な情報を整理したものであり、個別案件への法的助言ではありません。
具体的な法的判断が必要な場合は、対象地域と事業分野に詳しい専門家へ相談してください。

Web上の障壁はどこで生まれるのか

スクリーンリーダーは、画面上の文字やHTMLの構造を音声または点字で伝える支援技術です。
画像に代替テキストがない、フォームの入力欄にラベルがない、見出しが正しい順序で設定されていないと、画面を見て理解できる情報でも利用者には伝わらないことがあります。
実装の考え方は、サイト内のスクリーンリーダーと読み上げ環境の実装ガイドでも確認できます。

Webアクセシビリティの問題は、特定の端末でページを表示できるかどうかだけではありません。
利用者が情報を理解し、必要な操作を完了できるかどうかが問われます。

• 商品画像や図の意味がテキストで伝わらない
• キーボードだけではメニュー、ダイアログ、購入手続を操作できない
• 入力エラーの場所と修正方法が読み上げられない
• 動画に字幕がなく、音声情報を受け取れない
• 文字や操作部品のコントラストが低く、内容を判別しにくい
• 拡大すると文章やボタンが画面外へ隠れる

このような障壁は、情報収集だけでなく、予約、購入、申請、問い合わせといった重要な手続を止めます。
米国の訴訟でも、抽象的な「見やすさ」ではなく、利用者が具体的なサービスを使えなかったことが争点になってきました。

米国の判例が示したこと

ADA（Americans with Disabilities Act、アメリカ障害者法）は、障害を理由とする差別を禁止する米国の連邦法です。
Webサイトやアプリに関する民間事業者の訴訟では、主に不特定多数に商品やサービスを提供する施設を扱うTitle IIIが問題になります。
ADAの章立ちと対象分野は、ADAの基本構成を解説した記事で詳しく紹介しています。

米国司法省は、一般向けに商品やサービスを提供する事業者のWeb上の提供内容にもADAの要件が及ぶという立場を示しています。
しかし、Webサイト自体を公共的施設とみるか、実店舗との結び付きを必要とするかなどについて、裁判所の考え方は一様ではありません。

Domino’s事件の米国最高裁判所での手続

原文では、米国最高裁判所が「WebサイトとアプリはADAに準拠する必要がある」と判断したように説明されていました。
実際には、同裁判所はDomino’sによる上告の受理を拒否しただけで、Webアクセシビリティに関する全国共通の判断を新たに示したわけではありません。
この区別を省くと、判例の効力を実際より広く伝えてしまいます。

米国事例から得られる教訓は、「裁判になった企業と同じ修正だけを行えばよい」というものではありません。
利用者が商品やサービスへ到達する一連の流れを確認し、障壁がある機能を継続的に直す必要があるということです。

日本の法律とアクセシビリティ基準

日本の障害者差別解消法は、不当な差別的取扱いを禁止し、行政機関等と事業者に合理的配慮の提供を求めています。
2024年4月1日の改正法施行により、事業者による合理的配慮の提供は努力義務から法的義務へ変わりました。

合理的配慮とは、障害のある人から社会的な障壁を取り除くための申出があったときに、負担が過重でない範囲で必要な変更や調整を個別に検討することです。
すべての利用者に向けてWebサイトの構造や運用をあらかじめ改善する「環境の整備」と、特定の利用者が直面した障壁に対応する「合理的配慮」は、関連していますが同じ取組ではありません。
詳しい区別は、障害者差別解消法と事業者の義務で確認できます。

「JIS X 8341-3に準拠すれば、あらゆる法的義務を自動的に満たす」という関係ではありません。
反対に、個別の申出へ対応するだけで、日常的なWebサイト改善が不要になるわけでもありません。
法律上の対応と、技術基準を使った事前の改善を分けて管理し、両方をつなげる必要があります。

企業が進めるWebアクセシビリティ対応

1. 利用者が完了したい手続から対象を決める

最初に、問い合わせ、会員登録、予約、購入、解約、資料閲覧など、利用者にとって重要な手続を洗い出します。
ページ数だけで優先順位を決めると、少数の画面で構成された重要なフォームを見落とすことがあります。

2. 自動検査と人による確認を組み合わせる

自動検査ツールは、代替テキストの欠落や一部のHTMLエラーを効率よく見つけられます。
一方、リンクの文言が目的を伝えているか、キーボード操作の順序が自然か、エラーメッセージから修正できるかといった問題には、人による確認が必要です。

• 自動検査ツールで機械的に検出できる問題を確認する
• キーボードだけで主要な手続を完了する
• 画面を拡大し、内容の欠落や二方向スクロールを確認する
• スクリーンリーダーで見出し、リンク、フォームの意味と順序を確認する
• 可能な範囲で障害当事者による利用確認を行う

3. 部品と制作ルールを先に直す

同じ問題が複数ページにある場合は、ページを一枚ずつ直す前に、ヘッダー、メニュー、ボタン、フォーム部品、CMSテンプレートを確認します。
共通部品を修正すれば、改善を広い範囲へ反映でき、更新時の再発も抑えやすくなります。

4. 方針、試験結果、相談窓口を公開する

アクセシビリティ方針には、対象範囲、参照する規格、目標とする適合レベル、期限、対象外とした範囲を具体的に記載します。
試験結果と残っている課題を示し、利用者が障壁を報告できる問い合わせ方法も用意します。

5. 更新のたびに品質を守る

Webサイトは、画像の追加、フォームの改修、外部サービスの埋め込みによって変化します。
公開前のチェック項目、担当者、修正期限を運用に組み込み、定期試験と日常確認を分けて続けます。
運用設計は、公開後の試験、改善、体制づくりも参考になります。

対応状況を確認するチェックリスト

• 主要な情報と手続をキーボードだけで利用できる
• 画像、アイコン、動画に内容に応じた代替手段がある
• 見出し、リスト、表、フォームがHTMLの意味に沿って実装されている
• 入力エラーの場所、原因、修正方法がテキストで伝わる
• 文字拡大や狭い画面でも情報と機能が失われない
• 自動検査だけで完了とせず、操作確認と支援技術による確認を行っている
• 障壁の報告を受け、代替手段と恒久的な修正を検討する担当が決まっている
• 新規制作、調達、更新、公開後の保守に共通の基準がある

支援機能や検査ツールの導入は、改善を始める手段の一つです。
ただし、ツールを設置した事実だけで、サイト全体の適合や個別の法的義務への対応が自動的に証明されるわけではありません。
対象範囲を定め、利用者が実際に手続を完了できるかを確認し、残る障壁を継続して修正することが必要です。

当社では、Webアクセシビリティへの取組を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
導入を検討する際は、利用できる機能、対象となる障壁、サイト側で必要な改善を確認したうえで活用してください。