WCAG 3.3.6: エラー防止（すべて）

このルールの意味

WCAG 3.3.6 — Error Prevention (All) は、「理解可能」という原則の下にあるレベルAAAの達成基準です。これは 3.3.4（Error Prevention: Legal, Financial, Data）の要件を拡張し、ユーザーに情報の送信を求めるすべてのページを対象にします。送信内容が法的な約束、金融取引、または個人を特定できるデータを含むかどうかに関わらず適用されます。

この達成基準の核心は、ユーザーが情報を送信するあらゆるウェブページにおいて、次の3つの条件のうち少なくとも1つを満たすことを求めている点です。

• 可逆性（Reversible）: 送信後であっても取り消しが可能であること。ユーザーが合理的な時間内に操作を元に戻したり、キャンセルしたり、撤回したりできること。たとえば、送信済みメッセージを取り消せる、送信済みフォームを確認キューからキャンセルできる、などです。
• 検証（Checked）: 最終送信前に、ユーザーが入力したデータが入力エラーについてチェックされ、ユーザーにそのエラーを修正する機会が与えられること。これにはインラインバリデーション、送信前の要約表示、ステップごとの確認フローなどが含まれます。
• 確認（Confirmed）: 送信が確定する前に、情報を見直し、確認し、修正できる仕組みが提供されていること。レビュー画面、確認ダイアログ、最終確認ステップを備えたマルチステップウィザードなどが該当します。

3.3.4 と 3.3.6 の主な違いは適用範囲です。達成基準 3.3.4 は、法的合意、金融取引、テストの回答、ユーザーが管理するデータの削除にのみ適用されます。達成基準 3.3.6 はこれを拡張し、あらゆる形式のユーザー入力送信を必要とするすべてのページ—問い合わせフォーム、ニュースレター登録、コメント欄、アンケート回答、プロフィール更新、検索設定、その他ユーザーが管理するあらゆるデータ入力—を対象にします。

合格とみなされる条件: フォームは、上記3つの仕組みのうち少なくとも1つを一貫して実装していれば合格です。最終送信前の確認ページ、「編集」オプション付きの要約画面、エラー修正の機会を伴うクライアントサイドまたはサーバーサイドのバリデーション、明確に伝えられた「取り消し可能な時間枠」などはいずれもこの達成基準を満たします。

不合格とみなされる条件: ボタンをクリックすると即座にデータを送信し、バリデーションもレビュー画面も取り消し機能もない単一ステップのフォームは、この達成基準に不合格となります。同様に、バリデーションは行うものの、再送信前にエラーを修正する機会を提供しないフォームも不合格です。

WCAG仕様は、3つすべての仕組みを同時に実装することを求めてはいません。いずれか1つを満たせば十分です。ただし、2つまたは3つを組み合わせることで多重防御となり、より幅広いユーザーや利用状況に対応できます。

なぜ重要なのか

エラー防止は単なる使い勝手の向上ではなく、入力エラーのリスクが障害や状況的な制約によって高まるユーザーにとって、本質的なアクセシビリティ要件です。

認知・学習障害: 失読症、ADHD、記憶障害のあるユーザーは、タイプミスをしたり、数字を入れ替えたり、多数の入力欄がある複雑なフォームで内容を見失ったりしがちです。レビューの仕組みがなければ、問い合わせフォームでメールアドレスを打ち間違えるだけで返信を受け取れなくなったり、配送フォームで住所を誤入力して荷物が届かなくなったりします。これは例外的なケースではありません。世界保健機関によれば、世界で約10億人が、日常生活に影響する何らかの認知または神経学的な状態を抱えています。

運動障害: 震えがある、細かい運動の制御が難しい、スイッチアクセスや音声入力ソフトに依存しているユーザーは、誤ってフォームを送信したり、意図しない文字を入力したりしやすくなります。たとえば、パーキンソン病のあるユーザーがスイッチインターフェースで複雑なフォームを操作しているとき、誤って不完全または誤った内容のフォームを送信してしまうかもしれません。取り消しや確認ステップがなければ、こうしたエラーはそのまま固定されてしまいます。

スクリーンリーダーユーザー: JAWS、NVDA、VoiceOver などで操作する視覚障害のあるユーザーは、送信前にフォーム全体を視覚的に俯瞰できる晴眼者と同じ感覚を持てません。スクリーンリーダーによって読み上げられる確認画面や要約は、データが取り返しのつかない形で送信される前に、内容を最終確認する機会を提供します。

デジタルリテラシーが低いユーザーと高齢者: 高齢者やデジタルインターフェースに不慣れなユーザーは、誤送信の影響を特に受けやすい層です。平易な言葉で要約を示す確認ステップは、安全網として機能し、サポートコストとユーザーのフラストレーションを大幅に減らします。

実際のシナリオ: たとえば、トルコの電子政府ポータルで、市民が事業登録のための長い官僚的なフォームに入力している状況を考えてみてください。市民が必須項目をうっかり空欄にしたり、税番号を誤入力したりしたにもかかわらず、フォームがレビューなしで即座に送信されてしまうと、数日後に正式な却下通知を受け取るまでエラーに気づかないかもしれません。最終送信前に入力内容をすべて表示する簡単な確認画面があれば、こうした事態は完全に防げたはずです。

SEOとユーザビリティの利点: 強固なエラー防止を実装しているページは、フォーム離脱率が低く、コンバージョン率が高く、ユーザー満足度も高い傾向があります。検索エンジンはユーザー体験のシグナルをランキングにますます反映しており、フォームエラーによる直帰率が高いページは、間接的にオーガニック検索での可視性が低下します。

関連する Axe-core のルール

WCAG 3.3.6 は手動テストを必要とします。なぜなら、どのフォーム送信フローが可逆性、エラーチェック、確認の要件を満たしているかを、自動ツールが判断することはできないからです。axe-core のような自動アクセシビリティスキャナーは、個々の ARIA 属性、ラベル、エラーメッセージの有無は検証できますが、送信フロー全体のロジック、確認ステップの有無、取り消し機能が実際に動作しているかどうかまでは評価できません。この達成基準は本質的に、インタラクションデザインとユーザー体験のフローに関するものであり、静的なマークアップだけの問題ではないのです。

• 3.3.6 専用の axe-core ルールは存在しません。 Axe-core や類似のエンジンは、個々の DOM 要素を特定の属性やロールの要件に照らしてテストします。マルチページフォームに最終送信前のレビューステップが含まれているかどうかを判断するには、アプリケーションのナビゲーションフローやサーバーサイドの挙動を理解する必要がありますが、これは静的解析ツールがアクセスできない情報です。コンプライアンスを評価するには、人間のテスターが送信プロセス全体を実際に辿る必要があります。
• （3.3.6 に特化してはいないが）フォーム全体の品質を支える関連ルール: label（すべての入力に対応するラベルがある）、aria-required-attr（必須の ARIA 属性が存在する）、form-field-multiple-labels（入力に矛盾するラベルが付いていない）といったルールは、アクセシブルなフォームの基盤を形作ります。これらをクリアすることは意味のあるエラー防止の前提条件ですが、それだけで 3.3.6 準拠が保証されるわけではありません。
• 自動化が不十分な理由: チェックアウトページの自動スキャンでは、すべての入力欄にラベルがあるか、エラーメッセージがプログラム的に入力と関連付けられているかは確認できます。しかし、「送信」をクリックしたときにユーザーがレビュー画面に遷移するか、「キャンセル」オプションが存在するか、システムがキャンセルリンク付きの確認メールを送信するかどうかまでは判断できません。これらは挙動やプロセスに関する問題であり、人による評価でしか答えが出せません。

テスト方法

1. 自動スキャンをベースラインとして実行する: axe DevTools、Lighthouse、または Accsible ウィジェットの組み込み監査モードを使って、フォームを含むすべてのページをスキャンします。これらのツールは 3.3.6 の違反を直接は検出しませんが、ラベルの欠如、エラーメッセージの不在、不適切に関連付けられたバリデーションフィードバックなどを特定し、基盤を整えるのに役立ちます。手動テストに進む前に、自動テストで検出された問題をすべて解消してください。
2. サイト上のすべての送信フォームを特定する: ユーザー入力を受け付けて送信するすべてのページ—問い合わせフォーム、登録フォーム、ログインフォーム、検索設定フォーム、プロフィール更新ページ、コメント欄、ニュースレター登録、マルチステップウィザードなど—の完全な一覧を作成します。それぞれを個別にテストする必要があります。
3. 意図的なエラーを含む「ハッピーパス」をテストする: 各フォームで、意図的に誤った、不完全な、または不正な形式のデータ（例: 無効なメールアドレス、文字を含む電話番号、必須項目の未入力）を入力します。フォームを送信し、次の点を観察します。ページは送信を防ぎ、エラーメッセージを表示するか。エラーメッセージは正しい入力欄に関連付けられているか。ユーザーにはエラーを修正して再送信する明確な機会があるか。
4. 確認・レビューの仕組みをテストする: バリデーションを通過するフォームについては、有効なデータを入力して送信します。データが取り返しのつかない形で送信される前に、確認画面、要約ダイアログ、レビューのステップが表示されるかどうかを確認します。レビューのステップから、ユーザーが戻って入力内容を編集できることを検証します。
5. 送信後の可逆性をテストする: 正常に送信された後、キャンセル、取り消し、撤回の仕組みが存在するかを確認します。これは、確認メール内の「送信をキャンセル」リンク、管理画面のキュー管理画面、アプリ内通知の「元に戻す」アクションなどかもしれません。この仕組みが機能し、ユーザーに明確に伝えられていることを検証します。
6. NVDA + Firefox によるスクリーンリーダーテスト: NVDA と Firefox を使って各フォームに移動します。すべての入力欄をタブで移動し、データを入力してフォームを送信します。エラーメッセージが表示されたときに読み上げられるか、レビュー画面（存在する場合）が文書順に従って完全に読み上げられるか、確認画面上のすべてのインタラクティブ要素（編集ボタン、確認ボタン、キャンセルボタン）がキーボードで操作可能で、適切にラベル付けされているかを確認します。
7. VoiceOver + Safari（macOS/iOS）によるスクリーンリーダーテスト: 上記と同じ手順を、Safari 上の VoiceOver を使って繰り返します。特に動的コンテンツの更新に注意してください。バリデーションエラーが JavaScript によってページリロードなしで動的に表示される場合、aria-live を使ったライブリージョンを通じて VoiceOver によって自動的に読み上げられるか、ユーザーがページを手動で探索し直さなくても済むかを確認します。
8. キーボードのみのテスト: マウスを使わず、Tab、Shift+Tab、Enter、Space キーだけでフォーム送信フロー全体を操作します。レビュー画面上の編集、戻る、確認、キャンセルボタンを含むすべてのインタラクティブ要素が、ポインティングデバイスなしで到達・操作可能であることを確認します。

修正方法

バリデーションもレビューもない問い合わせフォーム — 不適切

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

バリデーションと確認ステップを備えた問い合わせフォーム — 適切

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

要約ステップのないマルチステップウィザード — 不適切

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

最終レビューステップを備えたマルチステップウィザード — 適切

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

即時送信で取り消し不可のフォーム — 不適切

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

確認ダイアログ付きの破壊的操作 — 適切

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

よくある間違い

• バリデーションを実装しているがスクリーンリーダーに伝えていない: CSS の色変更やアイコンだけで視覚的にエラーメッセージを表示し、aria-describedby で入力欄と関連付けない、あるいは aria-live リージョンに挿入しない場合、視覚障害のあるユーザーはエラーを聞くことができません。フォームは実際には未完了であるにもかかわらず、送信に成功したように見えてしまいます。
• 3.3.4 準拠だけで AAA を満たしているとみなす: チームが金融や法的なフォームに対してのみエラー防止を実装し（3.3.4 を満たし）、すべてのフォームがカバーされていると誤解することがあります。達成基準 3.3.6 は、ニュースレター登録、コメント、プロフィール更新など、サイト上のすべてのフォームに同じ保護を求めています。
• 編集経路のない読み取り専用の確認画面を提供する: 送信済みデータを表示するだけで「確認」ボタンしかなく、戻ってエラーを修正する手段がないレビュー画面は、この達成基準の趣旨を十分に満たしておらず、ユーザーがレビュー中に誤りに気づいても打つ手がありません。
• window.confirm() を唯一の確認手段として使う: ブラウザネイティブの confirm ダイアログは、すべてのユーザーにとってアクセシブルとは限らず、明瞭さのためにスタイルや構造を調整することもできません。また、支援技術によって挙動が一貫しないこともあります。代わりに、適切な ARIA 属性を備えた <dialog> 要素を使用してください。
• バリデーション失敗時にフォーム全体をリセットし、有効な入力を保持しない: ユーザーが10項目のフォームを送信し、そのうち1項目だけにエラーがあったにもかかわらず、フォームがすべての入力欄をクリアしてしまうと、ユーザーはすべてのデータを再入力しなければなりません。これは、運動障害や認知的疲労のあるユーザーにとって特に負担となります。常に有効なデータは保持し、注意をエラーのある項目だけに向けるようにしてください。
• エラー要約メッセージをビューポート外やキーボードフォーカス順序の外に配置する: 送信失敗後にページ上部へ挿入されるエラー要約バナーは、フォームの途中にフォーカスがあるユーザーには何の役にも立ちません。要約コンテナに aria-live='assertive' を設定し、送信失敗時にはプログラム的にフォーカスをそこへ移動させてください。
• 「OK」や「Yes」のような曖昧なラベルの確認ボタンを使う: レビュー画面では、ボタンが何を行うのかを明確に伝える必要があります。「Confirm and Send Message」は明確ですが、「OK」はそうではありません。特に、周囲の視覚的コンテキストを利用できないスクリーンリーダーユーザーにとってはなおさらです。
• サーバーサイドバリデーションだけで達成基準を満たしているとみなす: クライアントサイドバリデーションがない場合、ユーザーはエラーを知る前に毎回サーバーへの往復を強いられます。回線が遅いユーザーや送信中にネットワークが切断されたユーザーは、明確なエラーフィードバックがない不確かな状態に取り残されるかもしれません。
• 現実的な条件下で可逆性の仕組みをテストしない: チームが確認メールに「キャンセル」オプションを実装しても、そのキャンセルリンクがアクセシブルかどうか、有効期限後にどう動作するか、スクリーンリーダーで利用可能かどうかをテストしないことがあります。アクセシブルでない取り消し機能は、この達成基準を満たしているとは言えません。
• レビュー画面でのオートフィルの端ケースを考慮しない: ブラウザやパスワードマネージャーのオートフィルがフォーム欄を自動入力する場合、レビュー画面に表示される値が、実際に送信された値と一致しないことがあります。これは、オートフィルが完了する前に JavaScript が DOM から値を取得してレビュー画面を生成してしまうと起こります。レビュー画面を描画する直前に値を取得し、初回ページロード時には取得しないようにしてください。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10 は、2025年6月21日付官報第 32933 号で公布され、トルコで事業を行う幅広い主体に対して、デジタルアクセシビリティに関する義務を定めています。この通達は、対象組織に対し、ベースラインとして WCAG 2.2 レベルAAへの準拠を求めています。対象として明示されているのは、公的機関・行政機関、eコマースプラットフォーム、銀行・金融機関、病院・医療提供者、20万件以上の加入者を持つ通信会社、認可旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などです。

WCAG 3.3.6 はレベルAAAの達成基準であり、そのため 2025/10 通達の下で直接的な法的要件とはなりません。しかし、トルコの規制文脈におけるその重要性は軽視すべきではありません。対象となる組織のうち、特に銀行、eコマースプラットフォーム、医療提供者は、エラー防止が単なるベストプラクティスではなく、法的かつ倫理的な必須事項である高リスクの取引フォームを運用しています。トルコの銀行のオンライン送金フォーム、医療ポータルの予約システム、確認ステップやエラー修正の仕組みを欠いた eコマースのチェックアウトフローは、法的に強制可能な意味で 3.3.6 に違反していないかもしれませんが、障害のあるユーザーに重大な危害のリスクを生じさせ、組織に評判面・業務面のリスクをもたらします。

さらに、この通達は、トルコが整合を進めている European Accessibility Act（EAA）フレームワークと一致する形で、時間の経過とともにアクセシビリティ要件を強化していく明確な方向性を示しています。3.3.6 のような AAA 達成基準を今のうちから実装しておく組織は、将来の規制強化に先回りして備えることができ、最低限のコンプライアンスを超えたインクルーシブデザインへのコミットメントを示すことになります。高齢者や認知・運動障害のあるユーザーを相対的に多く抱える民間病院や金融機関のような組織にとっては、すべてのフォームで 3.3.6 を実装することは、その法的地位とは無関係に、健全なリスクマネジメント上の判断と言えます。Accsible のオーバーレイ SDK は、エラーメッセージの表示、バリデーション状態の強化、追加の確認プロンプトの提供を支援し、アクセシビリティのリーダーを目指すトルコの組織にとって、強化された保護レイヤーとして機能します。