ECサイトで画像のaltを付け、色のコントラストを直したのに、スクリーンリーダーでは配送方法を選べず、キーボードでは決済へ進めない。European Accessibility Actへの対応で起きやすいのは、画面単位の改善が購入という一連のサービスにつながっていないことです。
EAA対応の合格は診断ツールの点数ではなく、障害のある利用者が商品を理解し、本人確認し、支払い、注文結果を受け取り、困った時に支援へ到達できることです。
本記事は2026年9月2日時点のDirective (EU) 2019/882と欧州委員会資料を基に、EU向けECを運営する日本企業の実務へ翻訳しています。EAAはDirectiveであり、罰則、監督、手続は加盟国法へ実装されます。販売国の国内法、主管当局、言語要件を別途確認してください。
越境サイトだから対象外、とは限らない
法人所在地ではなく、EU消費者へ提供するe-commerce serviceと加盟国法を確認します。
EAAはe-commerce servicesを、消費者契約の締結を目的として、遠隔で、ウェブサイトやモバイルサービスを通じ、消費者の個別要求に応じて提供されるサービスとして扱います。日本からEUの消費者へ商品・サービスを販売する導線があるなら、法人所在地だけで対象外とは判断できません。
まず対象サービス、提供国、対象顧客、契約主体、販売方法を並べます。企業間専用の受発注と消費者向けEC、商品紹介だけのサイトとオンライン契約、EUへ発送しない国内サイトを分けます。言語、通貨、配送国、EU向け広告、現地ドメインも販売対象を判断する材料になります。
サービスを提供するmicroenterpriseには免除があります。EU基準のmicroenterpriseは従業員10人未満かつ年間売上または貸借対照表合計200万ユーロ以下ですが、関連企業を分断して形式的に小さく見せる判断はできません。また製品を市場へ置くメーカー等には同じサービス免除をそのまま当てはめません。
microenterprise免除は「日本法人が小さいから」で決めず、EU定義の企業関係、人数、財務、提供するものが製品かサービスかを記録して判断します。
トップページではなく購入タスクを分解する
検索から注文確認までを一つの利用目的として通し、途中の障壁を特定します。
アクセシビリティのテスト対象をURL一覧だけで作ると、商品詳細は合格してもサイズ選択や在庫通知、クーポン、本人認証で止まります。利用者の目的ごとに、検索、比較、選択、カート、配送、支払い、確認、変更、取消、返品、問い合わせをタスクとしてつなぎます。
スクリーンリーダー、画面拡大、キーボードのみ、音声入力、色覚の違い、認知負荷など、利用条件で失敗点は変わります。自動検査はHTMLの一部を早く見つけますが、モーダルを閉じられるか、エラー内容を理解できるか、入力後にフォーカスがどこへ移るかは人が操作しないと分かりません。
クリック可能かではなく、フォーカス順序、名称、状態、エラー、完了通知を購入タスク全体で確認します。
一つの部品がWCAGに沿っていても、配送方法を選ぶとフォーカスが消える、エラーが色だけで示される、制限時間を延長できないなら購入サービスは完了できません。
ECのプロセス標準化で例外注文を整理し、標準購入だけでなく予約、定期購入、ギフト、年齢確認、越境配送もテスト範囲へ入れます。
商品情報を販売者の責任だけにしない
責任事業者から届くアクセシビリティ情報を、ECの商品データへ載せる仕組みが必要です。
EAAのe-commerce固有要件には、責任を負うeconomic operatorから商品・サービスのアクセシビリティ情報が提供された場合、それを消費者へ示すことが含まれます。ECモールや小売事業者が、メーカーの説明を受け取っても商品ページへ掲載できないデータ構造では要件を実行できません。
商品マスターに、アクセシビリティ機能、対応する支援技術、利用上の制約、説明書の代替形式、問い合わせ先を持たせます。自由記述だけでは検索・比較できないため、商品カテゴリごとに項目を定義し、原文、翻訳、更新日、提供者を保存します。
画像内の文字を商品説明の唯一の情報にしません。動画の音声情報には字幕、視覚情報には必要な代替説明を用意します。色、サイズ、素材、互換性、警告を、見た目の位置だけに依存せず構造化します。
EC事業者は商品そのものの適合を勝手に保証するのではなく、責任事業者から受けたアクセシビリティ情報を欠落・改変なく購入判断へ届けます。
認証・セキュリティ・決済を例外扱いしない
セキュリティを保ちながら、識別、署名、支払いを複数の利用条件で完了可能にします。
ログイン、ワンタイムパスワード、CAPTCHA、本人確認、電子署名、3Dセキュア、決済画面は、セキュリティを理由にアクセシビリティ確認から外されがちです。EAAはe-commerceで提供される識別方法、電子署名、決済サービスをperceivable、operable、understandable、robustにすることを求めています。
認証画像の代替、コード受信手段、入力時間の延長、パスワード条件の説明、エラー修正、外部決済からの戻り先を確認します。本人確認書類の撮影が難しい利用者に、法令上許される代替経路や人の支援があるかも設計します。
決済ページを外部事業者へ委託しても、利用者から見れば一つの購入です。PSP、本人認証、住所検索、チャットの各社と、障害報告、修正期限、代替手段、テスト環境、変更通知を契約に入れます。
外部決済を使うことは責任の消滅ではありません。購入完了率を支援技術別に測り、委託先の更新で失敗が増えた時に切り戻せる責任分界が必要です。
PCI DSSの決済ページ対策と両立させ、セキュリティ制御を弱めずに操作方法を複数用意します。
WCAG合格証ではなく適合を説明できる記録を残す
利用した基準、試験環境、既知障害、代替手段を、サービス提供中追える形にします。
EAAはサービス提供者に、適用されるアクセシビリティ要件をどのように満たすか説明する情報をAnnex Vに従って作り、書面・口頭かつ障害のある人が利用できる形で公開し、サービス提供中は保持することを求めます。
記録にはサービス概要、動作理解に必要な説明、適用要件、利用した規格・技術仕様、責任者、試験方法、既知の不適合、代替手段、改善予定、連絡先を含めます。「WCAG 2.1 AA準拠」と一行書くだけでは、注文、認証、決済、サポートのどこを確認したか分かりません。
自動検査、専門家レビュー、支援技術テスト、障害当事者によるタスク検証を分け、使用ブラウザ、OS、スクリーンリーダー、テスト日、ビルド番号を残します。法的な適合判断と、社内の改善目標を混同しません。
アクセシビリティ情報は免責文ではなく、利用者が使える機能と残る障壁を知り、監督当局が試験範囲と改善履歴を追える運用記録です。
変更一件ごとに再発を止める
広告、A/Bテスト、外部SDKを含むリリース変更を、購入タスクの回帰試験へ接続します。
サービスは公開後も変わります。セール用バナー、A/Bテスト、タグ管理、決済SDK、レビュー投稿、cookie同意、チャット追加で、合格した導線が壊れます。年一回の監査では変更直後の障害を長期間残します。
デザインシステムへフォーカス、ラベル、エラー、コントラスト、拡大、読み上げ順の受入条件を組み込みます。コードレビューでは自動検査を行い、購入に関わる変更はキーボードとスクリーンリーダーの回帰試験を必須にします。
部品の点数ではなく、検索、商品選択、認証、決済、注文確認の成功をリリース判定へ入れます。
KPIは指摘件数だけにしません。キーボード完了率、スクリーンリーダー完了率、支援技術別の決済離脱、重大障害の平均修正日数、再発率、問い合わせ経由の代替完了率を測ります。利用者数が少ないことを「問題なし」の根拠にしません。
90日で売上を止めずに直す
重大な購入障害から直し、共通部品と継続運用へ広げます。
最初の30日で販売国、対象サービス、免除、委託先を確定し、売上の多い購入タスクを実操作します。自動診断の一覧を全件直す前に、購入不能、誤購入、情報欠落につながる障害を優先します。
31日目から60日目は、共通部品と商品データを直し、認証・決済・配送など外部サービスの責任分界を合意します。高頻度画面だけでなく、返品、解約、エラー、在庫切れの経路も含めます。
61日目から90日目は、適合説明を公開し、リリースゲート、監視、問い合わせ、主管当局への情報提供手順を運用します。当事者テストで発見した障害を個別修正で閉じず、デザインシステムと自動テストへ戻します。
EAA対応を最短で進める順番は、全ページの点数改善ではなく、購入不能の除去、共通部品の修正、委託先境界の合意、継続的な回帰防止です。
SaaSのアクセシビリティ設計とECの品質トレーサビリティを使い、障害報告を部品・リリース・担当へ追跡します。
苦情をサポートの一件で閉じない
個別の代替支援から、原因部品、横展開、利用者への結果通知までを追います。
利用者から「ボタンが押せない」「読み上げでは金額が分からない」と連絡が来た時、端末の使い方を案内して終了すると、同じ障害が他の利用者に残ります。注文番号、利用タスク、画面、端末、ブラウザ、支援技術、発生日時、回避方法を、本人の同意を得て記録します。
緊急度は売上額だけで決めません。購入不能、誤注文、二重決済、解約不能、個人情報の誤送信につながる障害を重大とし、代替注文、電話支援、返金などを先に提供します。代替手段を用意しても、恒久的に障害のある利用者だけへ電話を強いる状態は改善完了ではありません。
修正後は連絡者だけでなく、同じ部品を使う商品ページ、会員登録、返品、別言語サイトへ横展開します。問い合わせ文をAIで要約する場合も、障害の具体的操作や利用者の表現を抽象化して失わないよう、原記録へ戻れる状態にします。
問い合わせ窓口自体もアクセシブルである必要があります。音声電話だけ、画像CAPTCHAだけ、営業時間だけでは使えない人がいます。フォーム、メール、テキスト、relay serviceなど、複数の経路と応答期限を示します。
アクセシビリティ苦情の完了は個別注文を通した時ではなく、原因部品を直し、同じ導線の回帰試験に加え、連絡者へ結果を返した時です。
文字拡大とreflowを実商品の情報量で試す
文字を200％へ拡大した時に横スクロールが出ないだけでは、実用性を保証できません。長い商品名、割引条件、複数配送先、税・関税、定期購入の解約条件を入れた状態で、ラベルと入力欄、価格と単位、ボタンが離れないか確認します。
スマートフォンでは端末を横向きにしなくても読めるか、固定ヘッダーやcookie bannerが画面を覆わないか、ソフトウェアキーボード表示後もエラーと送信ボタンへ到達できるかを見ます。文字を小さく戻すことを回避策にしません。
翻訳で文が長くなると、日本語版では起きなかった重なりが生じます。販売国ごとの実データを使い、商品名、通貨、小数、住所、電話番号、法定説明の最大長をテストケースへ入れます。
割引前後の価格と税も読み上げ順で確認します。
アクセシビリティのレイアウト試験は短いダミー文ではなく、最も長い商品名・住所・規約を入れ、200％拡大と390pxの購入完了を同時に通します。
まとめ
アクセシビリティは公開時の検査ではなく、購入可能性を守り続けるサービス品質です。
European Accessibility ActへのEC対応は、見た目を整えるプロジェクトではありません。消費者が購入契約を結ぶための情報と操作を、知覚、操作、理解、互換性の面から通し、変更後も壊さないサービス運営です。
日本のEC事業者が最初に示すべき成果はアクセシビリティ方針ではなく、障害のある利用者が実際の商品で検索から注文確認まで完了した証拠と、失敗を修正する期限です。
参考情報
以下は2026年9月2日に確認した一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
Q日本からEUへ販売するECサイトもEAAの対象ですか？
AEU消費者との契約締結を目的にe-commerce serviceを提供している場合、法人所在地だけで対象外とは限りません。販売国、消費者向けか、配送・広告・通貨、契約主体を確認し、各加盟国の実装法で判定します。
QWCAG 2.1 AAに合格すればEAA対応は完了ですか？
AWCAGはウェブ技術の重要な基準ですが、EAAでは商品情報、認証、決済、サポート、適合説明、変更管理、加盟国法も確認します。規格準拠の表明だけでサービス全体の法的適合を断定しません。
Qmicroenterpriseなら何もしなくてよいですか？
Aサービス提供microenterpriseには免除がありますが、EUの企業規模定義と関連企業を含めて判定します。製品のメーカー等には同じ免除が適用されず、取引先や利用者から情報提供を求められる場合もあります。
Q決済を外部サービスへ委託すれば責任はありませんか？
A利用者から見れば購入導線の一部です。外部画面を含めて操作を確認し、障害報告、修正期限、代替決済、変更通知を委託先との契約と運用へ入れます。
Q自動アクセシビリティ診断だけで十分ですか？
A自動診断は一部の技術的問題を効率よく見つけますが、フォーカス移動、エラー理解、スクリーンリーダーでの購入完了などは実操作が必要です。自動、専門家、支援技術、当事者テストを組み合わせます。
Qアクセシビリティ情報には何を書きますか？
Aサービス概要、適用要件を満たす方法、利用した規格・技術仕様、試験方法、既知の障壁、代替手段、問い合わせ先、更新履歴を、障害のある人も利用できる形で公開・維持します。
