ADAとWCAGについて

Published 2026/07/17

米国向けのWebサイトの制作事情を追っていると「ADA compliance」や「WCAG Level AA」といった言葉を目にします。どちらもアクセシビリティの話なので似たものに見えますが実際には役割が違います。ADAは米国の法律でWCAGはWebコンテンツを評価するための技術標準です。

私たちは表現や予算とのバランスを見ながら可能なかぎりアクセシビリティに尽力しますが、米国向けウェブサイト制作の場合は事情が少し異なるので注意が必要です。制作の途中で迷わないようにこのメモではADAとW3Cが公開するWCAGの関係を実装の視点から整理します。

※ この記事は技術的な整理であり法的助言ではありません。適用法や個別案件の判断は米国の有資格者へ確認してください。

ADAとWCAGは役割が異なる

ADA（Americans with Disabilities Act）は障害を理由とする差別を禁止する米国の連邦法です。Webサイトと関係が深いのは州・地方政府を対象とするTitle IIと公衆向けの施設やサービスを提供する事業者などを対象とするTitle IIIです。

WCAG（Web Content Accessibility Guidelines）はW3CのWeb Accessibility Initiativeが策定する技術標準です。コンテンツを次の四原則へ分けて成功基準を定めています。

Perceivable：知覚可能
Operable：操作可能
Understandable：理解可能
Robust：堅牢

ADAが「誰にどのようなアクセスを保障するか」という法的な義務を扱うのに対してWCAGは色のコントラストやキーボード操作、フォームのラベルなどを検証可能な基準へ変換します。WCAGへの適合はアクセシビリティを実装する重要な根拠になりますがそれだけでADA上の責任をすべて判定できるわけではありません。

Title IIはWCAG 2.1 Level AAを指定している

米司法省は2024年にADA Title IIの規則を更新し州・地方政府が提供するWebコンテンツとモバイルアプリの技術標準としてWCAG 2.1 Level AAを採用しました。外部事業者との契約やライセンスを通じて提供するものも原則として対象に含まれます。一部のコンテンツには例外があり、過度な負担やサービスの本質的な変更に関する規定もあるため対象範囲は規則本文で確認する必要があります。

2026年4月の暫定最終規則により遵守期限は一年延長されました。2026年7月時点の期限は次の通りです。

公的機関の区分	遵守期限
人口50,000人以上	2027年4月26日
人口50,000人未満	2028年4月26日
Special district government	2028年4月26日

期限が延びてもTitle IIに基づく既存のアクセシビリティ義務がなくなるわけではありません。またこの規則が指定するのはWCAG 2.2ではなくWCAG 2.1です。新しいバージョンを採用すればよいと自己判断せず監査と納品では指定された版を基準にします。

Title IIIではWCAGが実装上の基準になる

Title IIIは店舗、ホテル、銀行、医療機関など公衆に開かれた事業の財やサービスを障害のある人も利用できることを求めます。米司法省はその財やサービスをWebで提供する場合にもADAの要件が及ぶという立場を示しています。

一方でTitle IIIのWebサイトに対して特定バージョンのWCAGを一律に指定する連邦司法省の詳細な技術規則は2026年7月時点でありません。司法省のガイダンスはWCAGをアクセシブルなWeb機能を実装するための有用な技術標準として挙げています。

そのため民間サイトで「WCAG 2.2 Level AAを満たしたのでADAに完全準拠した」と短絡させるのは正確ではありません。まず事業とサイトの関係、提供するサービス、適用される州法や契約を確認し、そのうえでWCAGを設計と検証の共通基準にします。

WCAGのバージョンと適合レベル

WCAG 2.2は2023年10月にW3C Recommendationとして公開されました。2.1へ九つの成功基準を追加し古くなった4.1.1 Parsingを削除しています。追加項目にはキーボードフォーカスが固定UIに隠れないこと、ドラッグ操作の代替、ポインターターゲットの最小サイズ、認証で認知機能テストを必須にしないことなどが含まれます。

W3Cは新規制作や更新ではWCAG 2.2の利用を勧めています。WCAG 2.2へ適合するコンテンツは2.1と2.0にも適合します。ただし法令や契約がWCAG 2.1を名指しする場合は2.1の達成状況を確認できる形で記録を残します。

適合レベルはA、AA、AAAの三段階です。AAはAとAAの成功基準をすべて満たすという累積関係でいくつかのAA項目だけを満たすという意味ではありません。AAAをサイト全体の一般要件にすることはW3Cも推奨していません。

また適合はページの一部ではなくページ全体で判断します。購入や申請のように複数ページで完了するプロセスでは途中の画面も対象です。トップページだけの高得点や自動検査でエラーがないことをサイト全体の適合と置き換えることはできません。

対応範囲は案件ごとに考える

WCAGは全面的な適合を宣言しない場合にも実装の判断材料として利用できます。すべての成功基準を満たせなくても見出しを正しく組む、キーボードで主要な導線を移動できるようにする、フォームのエラーを文字で伝えるといった対応にはそれぞれ意味があります。

ただし一部の基準を採用した状態と「WCAG 2.2 Level AAに適合している」という表明は分けて考えます。後者にはLevel AとAAの成功基準を対象ページとプロセス全体で満たしていることが必要です。

一般的なWeb制作では表現とアクセシビリティ、工数のバランスを見ながら優先順位を決められます。米国向けの案件や契約上の要件としてADA、WCAGが挙げられている案件では制作を始める前に対象範囲と検証方法を確認します。以下の実装例はすべての案件で必須とするものではなく対応を検討するときの基準です。

まずHTMLの意味を利用する

対応を検討するときは公開直前にARIA属性を加えるだけでなくHTML本来の意味を利用するところから始められます。見出し、リンク、ボタン、フォームをそれぞれの要素で組むとブラウザが名前と役割と状態を支援技術へ伝えられます。

クリックできるUIをdivで作るとキーボード操作やボタンとしての役割を別途再実装することになります。実行する操作にはbutton、移動にはaを使う方が実装範囲を小さくできます。

<button type="button" aria-expanded="false" aria-controls="site-menu">
	メニュー
</button>

<nav id="site-menu" aria-label="主要ナビゲーション" hidden>
	<a href="/about/">私たちについて</a>
	<a href="/projects/">プロジェクト</a>
</nav>

ARIAはネイティブHTMLで表せない関係や状態を補うために使います。この例ではbuttonという役割をARIAで作り直さず、開閉状態と対象の関係だけをaria-expandedとaria-controlsで伝えています。JavaScriptでメニューを開閉するときはhiddenとaria-expandedを同時に更新します。

const button = document.querySelector( '[aria-controls="site-menu"]' );
const menu = document.querySelector( '#site-menu' );

button.addEventListener( 'click', () => {
	const expanded = button.getAttribute( 'aria-expanded' ) === 'true';

	button.setAttribute( 'aria-expanded', String( !expanded ) );
	menu.hidden = expanded;
} );

フォームのエラーを文字でも伝える

入力欄へ画面上で読めるlabelを関連付けることも比較的取り入れやすい対応です。エラー時に枠を赤くするだけでは色を識別しにくい人や画面を見ていない人へ内容が伝わりません。どの項目に何が起きたかをテキストで示し、入力欄から参照できるようにします。

<form id="contact-form" novalidate>
	<label for="email">メールアドレス</label>
	<p id="email-hint">返信を受け取れるアドレスを入力してください</p>
	<input
		id="email"
		name="email"
		type="email"
		autocomplete="email"
		aria-describedby="email-hint email-error"
		required
	>
	<p id="email-error" aria-live="polite"></p>
	<button type="submit">送信</button>
</form>

const form = document.querySelector( '#contact-form' );
const email = document.querySelector( '#email' );
const error = document.querySelector( '#email-error' );

function validateEmail() {
	let message = '';

	if ( email.validity.valueMissing ) {
		message = 'メールアドレスを入力してください';
	} else if ( email.validity.typeMismatch ) {
		message = 'メールアドレスの形式で入力してください';
	}

	email.setAttribute( 'aria-invalid', String( message !== '' ) );
	error.textContent = message;

	return message === '';
}

form.addEventListener( 'submit', ( event ) => {
	if ( !validateEmail() ) {
		event.preventDefault();
		email.focus();
	}
} );

email.addEventListener( 'input', () => {
	if ( email.getAttribute( 'aria-invalid' ) === 'true' ) validateEmail();
} );

aria-liveは変化したエラーメッセージを支援技術へ通知します。すべての文章へ付けるのではなく操作の結果として更新され、ユーザーが次の判断に必要とする場所に限定します。

フォーカスと操作領域を設計する

WCAGを基準にする場合はキーボード操作で現在位置が見え、論理的な順番で移動でき、どのコンポーネントにも閉じ込められない状態を確認します。outline: noneでブラウザのフォーカス表示を消さないだけでも基本的な操作性を保ちやすくなります。

:where(a, button, input, select, textarea):focus-visible {
	outline: 3px solid #005fcc;
	outline-offset: 3px;
}

:where(a, button, input, select, textarea) {
	scroll-margin-block: 6rem;
}

.icon-button {
	min-inline-size: 44px;
	min-block-size: 44px;
}

WCAG 2.2 Level AAのターゲットサイズは原則24×24 CSS px以上で間隔などの例外も定められています。対応範囲に含める場合は最小値ぎりぎりを目標にせず指や手の震えでも押しやすい余白を検討します。固定ヘッダーやCookieバナーがある場合はTab移動した要素を覆わないかも確認項目になります。

ドラッグで並べ替えるUIでは上下ボタンやメニューなど単一ポインターで完了できる操作が代替になります。WCAG 2.2 Level AAへ適合させる場合は見た目が同じでなくても同じ結果へ到達できる方法が必要です。

色と動きの役割を分ける

WCAG 2.2 Level AAでは通常サイズのテキストに4.5:1以上、大きなテキストに3:1以上のコントラストが求められます。ロゴや非アクティブな要素など例外もあるため数値だけで一括判定せず成功基準の条件まで確認します。

色はブランド表現として使いながら状態を色だけへ依存させない方法を検討できます。エラーには文章、選択状態には形やアイコン、グラフにはラベルを組み合わせる方法があります。

動きも一律に削除するのではなく役割を分けて考えます。装飾的な移動や視差はOSの設定に応じて止め、状態変化の理解に必要な動きは時間や距離を抑える方法があります。

@media (prefers-reduced-motion: reduce) {
	html {
		scroll-behavior: auto;
	}

	.decorative-motion {
		animation: none;
		transform: none;
		transition: none;
	}
}

CanvasとWebGLで考える優先順位

CanvasやThree.jsを使ったサイトではすべての表現を同じ方法でアクセシブルにすることが難しい場合があります。まず3Dが装飾なのか、情報なのか、操作なのかを分けると対応範囲を考えやすくなります。

3Dが装飾なら支援技術の読み上げ対象から外しページの見出しや本文をHTMLとして残す方法があります。表現を保ちながら中心となる情報と主要な導線をWebGLから切り離せます。

<section class="hero" aria-labelledby="hero-title">
	<canvas class="hero__canvas" aria-hidden="true"></canvas>
	<div class="hero__content">
		<h1 id="hero-title">Garden Eight</h1>
		<p>デザインと開発を行うスタジオです</p>
		<a href="/projects/">プロジェクトを見る</a>
	</div>
</section>

3D内のラベルやオブジェクトが情報を担う場合にaria-hiddenで隠すとその情報は支援技術へ届きません。対応範囲に含める場合は見出しや説明をDOMに置きオブジェクトを選択する操作へHTMLのボタンやラジオボタンからも到達できる経路を検討します。

すべての3D操作に代替を作ることが案件の条件に合わない場合もあります。その場合も中心情報や問い合わせなどの主要な操作までWebGLだけへ依存させないことは比較的優先しやすい対応です。米国向けでWCAGへの適合が要件になっている場合は難易度と工数を制作前に共有し、表現を含めた範囲を合意する必要があります。

自動検査と手動検査を分ける

自動検査はラベルの欠落、コントラスト、属性の不整合などを早く見つけるために有効です。しかし文章に合った代替テキストか、フォーカス順が理解しやすいか、スクリーンリーダーで操作が成立するかまでは単独で判断できません。W3Cも適合判定には知識を持つ人の評価が必要だとしています。

WCAGへの適合が要件になっている場合は確認を次のように層へ分けます。すべての案件で同じ検査を行うという意味ではなく必要な精度に合わせて範囲を決めます。

HTMLとコンポーネントの静的検査
自動アクセシビリティテスト
Tab、Shift+Tab、Enter、Space、Escapeによるキーボード操作
ズーム、文字拡大、狭いビューポートでのリフロー
代表的なブラウザと支援技術による読み上げと操作
可能な範囲で障害のあるユーザーを含む評価

検査範囲を決めるときはテンプレートの種類だけでなく購入、予約、問い合わせなど完了までのプロセスも確認します。モーダル、メニュー、カルーセル、フォームエラーのように状態を持つUIは初期表示以外にも確認箇所があります。

米国向けでは対応範囲を先に共有する

アクセシビリティは一度の監査で固定されません。CMSの記事追加、外部サービスの更新、新しいキャンペーンページで状態は変化します。特に米国向けやWCAGへの適合が契約条件に含まれる案件では次の点を制作前に共有できると判断しやすくなります。

対象とするWCAGのバージョンとレベル
対象ページ、コンポーネント、主要プロセス
第三者コンテンツと外部サービスの範囲
自動検査と手動検査の方法
既知の問題と修正方針
利用者が問題を報告できる連絡経路
公開後の更新と再検査の担当

ADAとWCAGを分けて考える目的はすべてのサイトへ同じ対応を求めることではありません。法的な対象と技術的な検証方法を明確にし、その案件でどこまで対応するかを判断できるようにすることです。

参考

※ 法令と技術標準に関する記載は2026年7月時点の公式情報を基準にしています。

Back to List