EAA施行から1年：Webアクセシビリティ違反で初の制裁通知が届き始めた

背景：施行から約1年で制裁フェーズに移行

European Accessibility Act（EAA、指令2019/882） は2025年6月28日に施行された。2026年4月現在、EU各加盟国の規制当局が本格的な執行フェーズに入り、アクセシビリティステートメント未掲載の企業に制裁通知が送られ始めていることが報告されている。

GDPRが施行から数年後に本格的な制裁事例が増えたパターンと同様に、EAAも2026年から実務上のリスクが高まっている。「まだ様子見で大丈夫」という認識は危険な段階に入った。

対象範囲：どの企業・サービスが対象か

EAAの最大の特徴は GDPR同様の域外適用だ。EU域内の企業だけでなく、EU市場に向けてデジタルサービスを提供するすべての企業が対象になる。

対象条件（以下を同時に満たす場合）:
  ✅ EUの消費者・企業に向けてサービスを提供している
  ✅ 従業員10名以上 OR 年間売上高200万ユーロ以上

対象サービスの例:
  - ECサイト（欧州からの購入を受け付けている）
  - SaaS（EU市場向けプラン・ユーザーがいる）
  - モバイルアプリ（App Store EU向けに配信）
  - 電子書籍・デジタルコンテンツ
  - 銀行・金融サービスのデジタルUI

明示的な除外:
  - 零細企業（10名未満 AND 売上200万ユーロ未満）

日本の企業でも「EU向け英語サイト」「欧州在住ユーザーがいるSaaS」は対象になり得る。

技術基準：WCAG 2.1 AA が事実上の必須

EAA自体は具体的な技術仕様を規定していないが、EU標準 EN 301 549 を準拠基準として参照しており、これは WCAG 2.1 Level AA を内包している。実務上、WCAG 2.1 AA に準拠していればEAA準拠と推定される。

最低限チェックすべき項目

1. キーボードだけで全操作が完結するか

<!-- ❌ クリックイベントのみ -->
<div onclick="openModal()">メニューを開く</div>

<!-- ✅ フォーカス・キーボード対応 -->
<button type="button" aria-expanded="false" aria-controls="menu" onclick="openModal()">
  メニューを開く
</button>

div や span のクリックハンドラだけでは Tab キーでフォーカスが当たらず、スクリーンリーダーでも操作できない。

2. 画像に代替テキスト（alt）があるか

<!-- ❌ 空のalt（スクリーンリーダーがファイル名を読み上げる） -->
<img src="product-photo.jpg" />

<!-- ✅ 意味のあるalt -->
<img src="product-photo.jpg" alt="有機栽培きゅうり 3本入り" />

<!-- ✅ 装飾画像はalt=""で明示的にスキップ -->
<img src="decorative-divider.svg" alt="" />

3. カラーコントラスト比が4.5:1以上か

/* ❌ コントラスト不足（灰色テキスト on 白背景: 約2.3:1） */
body {
  color: #aaaaaa;
  background: #ffffff;
}

/* ✅ WCAG AA準拠（黒テキスト on 白背景: 21:1） */
body {
  color: #333333;
  background: #ffffff;
}

/* ✅ 小さいテキストは4.5:1、大きいテキスト（18pt以上）は3:1でOK */
.large-heading {
  color: #767676;
} /* 大テキストなら3:1でOK */

4. フォームのラベルが正しく紐付いているか

<!-- ❌ placeholder頼み（入力開始で消える） -->
<input type="email" placeholder="メールアドレス" />

<!-- ✅ 明示的なlabelと紐付け -->
<label for="email">メールアドレス</label>
<input type="email" id="email" autocomplete="email" />

EAA必須の非技術要件

EAAはWCAGへの準拠だけでなく、2つの文書・仕組みを要求している。

1. アクセシビリティステートメント

必須記載事項:
  - 準拠レベル（WCAG 2.1 AA）の宣言
  - 未準拠の項目と代替手段
  - ステートメントの作成日
  - 最終レビュー日

公開場所: サイトフッターからリンクが一般的

2. アクセシビリティ問い合わせ窓口

ユーザーが問題を報告し、回答を受け取れる 専用の連絡先 が必要。監視されているメールアドレスかフォームを設置する。

<!-- フッターの例 -->
<footer>
  <a href="/accessibility">アクセシビリティステートメント</a>
  <a href="mailto:accessibility@example.com"> アクセシビリティに関するお問い合わせ </a>
</footer>

アクセシビリティオーバーレイは非準拠

「AccessiBe」「UserWay」などの アクセシビリティオーバーレイツール（JSを1行追加するだけで対応と謳う製品）は、EAAの観点で準拠とみなされない。欧州障害者フォーラム（EDF）および複数の裁判所が明確に否定しており、むしろ法的リスクを高める可能性がある。

❌ オーバーレイで済ませる
  → WCAG違反がDOMレベルで残存
  → EDF・規制当局が明示的に拒否
  → スクリーンリーダーとの競合でむしろ障害になる場合も

✅ 根本から実装する
  → セマンティックHTMLを正しく使う
  → キーボード・フォーカス管理を設計段階で組み込む
  → 継続的な自動テスト（axe / Lighthouse）でリグレッション防止

自動テストで継続検証する

手動チェックだけでは対応漏れが出る。CI/CDに組み込んだ自動テストが現実的だ。

// playwright + axe-core での自動検証例
import { test, expect } from "@playwright/test";
import { injectAxe, checkA11y } from "axe-playwright";

test("ホームページがWCAG 2.1 AAに準拠している", async ({ page }) => {
  await page.goto("/");
  await injectAxe(page);
  await checkA11y(page, null, {
    runOnly: {
      type: "tag",
      values: ["wcag2a", "wcag2aa", "wcag21aa"],
    },
  });
});

axe-core は自動検出可能な違反の約30〜40%をカバーする。残りは手動とユーザーテストで補完する必要があるが、自動化で主要な漏れを防げる。

落とし穴・注意点

「欧州ユーザーがいない」という思い込み: グローバルIPからのアクセス解析でEU比率を確認していない企業は要注意
PDFの見落とし: PDFドキュメントも対象。スキャン画像PDFは全滅するため、テキストレイヤー付きPDF化が必要
動画の字幕: 全動画コンテンツに字幕が必要。自動字幕（YouTube等）は精度が不十分なケースが多く手動補正が現実的
第三者ウィジェット: 組み込んだチャットボット・地図UIなどが非準拠でも、サイト運営者の責任になる

まとめ

EAAは「気にしておいた方がいい法律」から「今すぐ対応しないと制裁リスクがある法律」に2026年で移行した。WCAG 2.1 AA への技術準拠、アクセシビリティステートメント、問い合わせ窓口——この3点が最低ラインだ。GDPRの轍を踏まないよう、施行後に慌てるのではなく今から着手することが実務上最善である。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感