WCAG 3.3.4: エラー防止（法的、財務、データ）

WCAG 3.3.4 は、法的な約束、金融取引、または機微なデータを含むウェブ上の送信について、最終確定前に確認、修正、または取り消しができることを求めています。これは、すべてのユーザー、特に認知障害や運動障害のあるユーザーを、取り返しのつかない重大なミスから守るためのものです。

この規定の意味

WCAG 達成基準 3.3.4「エラー回避（法的、財務、データ）」は、原則 3（理解可能）およびガイドライン 3.3（入力支援）の下に位置づけられたレベル AA の要件です。これは、利用者が法的な拘束力を持つ約束や金銭取引を発生させることができるウェブページ、または利用者がデータ保存システム内の利用者が制御可能なデータを変更・削除できるウェブページに特に適用されます。

この達成基準は、そのような送信に対して、次の 3 つの安全策のうち少なくとも 1 つを提供することを求めています。

可逆性: 送信後にその操作を取り消すことができる。たとえば、一定時間内であれば注文をキャンセルできる、削除したレコードを復元できる、などです。
検証: 利用者が入力したデータに入力エラーがないか検証し、送信が確定する前にエラーを修正する機会を利用者に与えること。
確認: 最終送信の前に情報を見直し、確認し、修正できる仕組みを提供すること。これは通常、送信ボタンが取引を完了させる前に、要約や確認ステップの形で実装されます。

これら 3 つの条件のうち、1 つだけ満たせば合格となる点に注意が必要です。確認画面だけを提供してもよく、送信後のキャンセル猶予を提供してもよく、修正機会を伴う堅牢なリアルタイム検証を提供しても十分です。ただしベストプラクティスとしては、複数の安全策を組み合わせることが推奨されます。

達成基準の適用範囲: この規定は 3 つの種類の取引に適用されます。第 1 に、サブスクリプションへの登録、契約への同意、法的拘束力のある書類の提出などの法的な約束を対象とします。第 2 に、購入、送金、ローン申請、請求書の支払いなどの金銭取引を対象とします。第 3 に、データ保存システム内の利用者が制御可能なデータを変更または削除するあらゆる行為を対象とします。たとえば、プロフィール情報の更新、クラウドサービスからのファイル削除、管理画面でのレコード編集などです。

合格の例: 最終ステップとして注文内容の要約を表示し、「編集」リンクと「注文を確定」ボタンを提示する EC サイトのチェックアウト。不合格の例: 1 ページだけの購入フォームで、「今すぐ購入」をクリックすると確認画面もキャンセルオプションも検証ステップもなく、即座にカードに請求が行われるもの。

この達成基準には明確な例外があります。誤った情報を送信しても重大な結果を招かず、簡単に再送信できるフォームには適用されません。一般的なお問い合わせフォームやニュースレター登録フォームは、通常この範囲外に該当しますが、それでもこれらのフォームに検証機能を設けることが望ましいとされています。

なぜ重要か

重要な取引の最中に発生するエラーは、深刻で時には取り返しのつかない結果を招くことがあります。たとえば、誤った口座への送金、虚偽の前提で署名された法的合意、誤った情報で更新された医療記録、誤ったプランで購入されたサブスクリプションなどです。障害のない利用者にとっては、こうしたミスを発見して修正することは多くの場合それほど難しくありませんが、多くの障害当事者にとっては、この達成基準が求める安全策がなければ、非常に困難か、場合によっては不可能になります。

認知障害のある利用者（ディスレクシア、ADHD、記憶障害、知的障害などを含む）は、データ入力のエラーを起こしやすく、送信前にそれに気づきにくい傾向があります。確認画面は、ミスに気づくための時間と明瞭さを提供します。世界保健機関によると、世界で約 10 億人が、日常生活に影響を与える何らかの認知・神経・メンタルヘルスの状態を抱えているとされています。

スイッチアクセス、視線入力装置、代替キーボードなどに依存する運動障害のある利用者は、意図しない操作や誤入力を起こしやすくなります。確認ステップは重要なバッファとして機能します。「送信」が誤ってアクティブになっても、取引が完了する前にキャンセルする機会がもう一度与えられるからです。この安全策がなければ、たった 1 回の誤タップで、利用者が取り消せない金銭取引が発生してしまう可能性があります。

スクリーンリーダー利用者は、長いフォームを線形にたどっていくため、自分が入力した内容を全体として把握しづらいことがあります。確認段階で入力値を読み上げる要約があれば、視覚的に一覧できないエラーを発見することができます。

不安や注意の困難を抱える利用者は、安全網があると分かっていることで大きな恩恵を受けます。利用者がプロセスを「エラーに寛容」と認識すると、より自信を持って操作し、取引を途中で放棄する頻度が下がることが、研究で一貫して示されています。これはコンバージョン率と利用者満足度の向上に直結し、3.3.4 への準拠は倫理的義務であると同時に、ビジネス上の利点にもなります。

実際のシナリオ: イスタンブール在住の視覚障害のある利用者が、スクリーンリーダーを使って国内線の航空券を予約しています。彼女は日付を選択しますが、誤って搭乗者数のフィールドを飛ばしてしまい、1 人ではなくデフォルトの 2 人のままにしてしまいます。もし予約サイトが「確認」ボタンを押した瞬間にカードへ請求を行う仕様であれば、彼女は 2 枚のチケットを購入したことになり、払い戻し不可の運賃ペナルティに直面するかもしれません。「搭乗者 1 名: Ayşe Yılmaz、アンカラ発イスタンブール行き、3 月 14 日、エコノミー — 合計: ₺850」と読み上げる確認画面があれば、彼女はすぐに誤りに気づくことができます。

テスト方法

高リスクなフォームの棚卸し: テストを始める前に、サイト上のすべてのフォームやインタラクティブなワークフローのうち、金銭取引（チェックアウト、支払い、請求）、法的拘束（契約署名、サブスクリプション登録、同意書）、データの変更・削除（プロフィール編集、ファイル削除、アカウント削除）を伴うものをリストアップします。3.3.4 の対象となるのは、これらのフローだけです。
関連する問題の自動スキャンを実行: axe DevTools や Lighthouse を使用して、対象ページごとにフォームレベルのアクセシビリティの不備を特定します。これらのツールは 3.3.4 自体を直接は検出しませんが、ラベル欠如、autocomplete 属性の欠如、エラー通知の欠如といった問題を解消することで、エラー回避の安全策を評価する前にフォーム品質のベースラインを整えることができます。
「検証」安全策のテスト: 対象となる各フォームに、意図的なエラーを含めて送信します（カード番号の数字の入れ替え、不正な日付、確認用メールアドレスとの不一致など）。システムが送信を停止し、どのエラーが発生したかを特定し、どのように修正すべきかを説明し（3.3.3 に従って）、利用者をフォーム上に留めて修正させるかどうかを確認します。フォームが何も言わずに送信される、またはどのフィールドが失敗したかを示さない一般的なエラーだけを表示する場合、この安全策は満たされていません。
「確認」安全策のテスト: 対象となる各フォームに正しいデータを入力し、フローを最後まで進めます。最終送信の前に確認ステップが提示されるかどうかを確認します。確認ステップで、入力したすべてのデータが読みやすい形式で表示されていること、戻って編集できる仕組みがあること、送信を完了するために意図的な最終操作が必要であることを検証します。NVDA + Firefox および JAWS + Chrome を使用し、スクリーンリーダーでこの確認ステップを操作して、すべての値が読み上げられること、編集と確認のコントロールにキーボードで到達できることを確認します。
「可逆性」安全策のテスト: 実際に送信を完了させ、その後で取り消しを試みます。EC サイトであれば、確認メールや注文履歴ページにキャンセルリンクがあるかを確認します。データ削除であれば、復元やごみ箱の仕組みがあるかを確認します。取り消し可能な期間が、送信後ではなく送信前に利用者へ明確に伝えられているかどうかも評価します。
スクリーンリーダーでの一連の操作（macOS/iOS の VoiceOver + Safari）: キーボードと VoiceOver のみを使って、チェックアウトまたは送信フロー全体を操作します。確認画面で入力値が論理的な順序で読み上げられること、「配送先住所を編集」のように編集リンクが十分な文脈とともにアナウンスされること（単に「編集」だけではないこと）、最終確認ボタンの目的が曖昧でないことを確認します。
認知負荷の確認: 確認ステップが平易な言葉で提示されているかを評価します。データベースのフィールド名をそのまま列挙したり、説明なしに法律用語を用いたりする要約は、形式上は確認画面といえるかもしれませんが、認知障害のある利用者にとっては実質的に機能しない可能性があります。

修正方法

確認画面のない 1 ステップのチェックアウト — 不適切

<!-- 問題: 「Complete Purchase」をクリックすると即座にカードに請求される -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

確認ステップを追加した 1 ステップのチェックアウト — 適切

<!-- ステップ 1: データを収集し、最終ではない確認ページに送信 -->
<form action='/checkout/review' method='post'>
  <!-- 支払いおよび配送先のフィールド -->
  <button type='submit'>Review Order</button>
</form>

<!-- ステップ 2: 確認ページで入力データを要約し、編集リンクを提供 -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- 最終ボタンは拘束力のある操作であることを明確にラベル付け -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

確認なしの取り消し不能なデータ削除 — 不適切

<!-- 問題: 削除ボタンが確認ダイアログなしに直接 POST する -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

確認ダイアログ付きの取り消し不能なデータ削除 — 適切

<!-- トリガーボタンは破壊的操作ではなく確認ダイアログを開く -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

インライン検証のない金融フォーム — 不適切

<!-- 問題: 検証がなく、誤った IBAN も黙って受け付けてしまう -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

検証と確認付きの金融フォーム — 適切

<!-- エラー関連付けのための aria-describedby を用いたインライン検証 -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- 実行ではなく確認ページに送信 -->
  <button type='submit'>Review Transfer</button>
</form>

よくある間違い

ツールチップを「確認」手段として使う: 送信ボタンの前に、入力値をホバーツールチップで表示しても、それは確認ステップとはみなされません。ツールチップはキーボードのみの利用者やスクリーンリーダー利用者にはアクセスできず、利用者が操作する前に消えてしまうからです。
最終ボタンを行為を説明せずに「続行」とラベル付けする: 確認ページで「Continue」と表示されたボタンは、それをクリックすると金銭取引が完了することを明確に示しません。ボタンは「Place Order and Pay ₺850」や「Sign Contract」のように、拘束力のある操作を曖昧さなく説明する必要があります。
キャンセルポリシーを利用規約のみに記載する: 取り消しの仕組みを、多くの利用者が読まないリンク先の法的文書の中に埋もれさせることは、可逆性の要件を満たしません。キャンセルの可否とその猶予期間は、取引フローの中で直接伝えられなければなりません。
window.confirm() を唯一の確認手段として使う: ブラウザ標準の confirm ダイアログは、一部の支援技術でのサポートが不十分であり、可読性のためのスタイル変更もできず、ブラウザ設定によってはブロックされることもあります。高リスクな送信に対する唯一の安全策として使うべきではありません。
検証失敗時に有効なフィールド値を保持せずフォームをリセットする: フォームが検証に失敗した際にすべてのフィールドをクリアしてしまうと、特に運動障害のある利用者はすべてのデータを再入力しなければならなくなります。クリアまたは強調すべきなのは無効なフィールドだけであり、有効な入力値はすべて保持しなければなりません。
確認ページの「編集」リンクにプログラム上の関連付けがない: 各データグループの横にある「Edit」リンクには、「aria-label='Edit billing address'」のような説明的なアクセシブルネームが必要です。同じ「Edit」が何度も繰り返されるだけでは、リンク単位で移動するスクリーンリーダー利用者にとって曖昧です。
確認ステップをスクリーンリーダーに通知しない: 確認ページが読み込まれても、フォーカスが見出しや要約領域に移動しない場合、スクリーンリーダー利用者は自分が確認ページにいることに気づかず、要約を読まずに送信ボタンを押してしまうかもしれません。
この達成基準を支払いページだけに適用されるものとみなす: 適用範囲には、あらゆる法的拘束（サブスクリプション登録、同意書、契約の承諾）や、あらゆる利用者データの変更（ファイル削除、医療記録の更新、アカウント設定の変更）が含まれます。開発者は、管理画面や設定ページを見落としがちです。
電話やメールだけで取り消しを受け付ける: キャンセルにサポート窓口への電話が必要な場合、音声や聴覚に障害のある利用者は取り消しの手段にアクセスできないかもしれません。取り消しの経路自体もアクセシブルでなければならず、理想的にはアプリ内のキャンセルフローであるべきです。
モバイルの Web ビューでは達成基準を省略する: 一部のチームは、デスクトップでは確認ステップを実装していても、画面スペースを節約するためにモバイルでは簡略化された 1 ステップフローを採用しています。この達成基準はすべてのビューポートサイズに等しく適用され、レスポンシブやモバイル Web 実装で省略してはなりません。

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

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、技術標準として WCAG 2.2 を参照する包括的な国家アクセシビリティ枠組みを定めています。この通達は、デジタルサービスが少なくとも WCAG 2.2 レベル AA に準拠することを義務付けており、その中には WCAG 3.3.4「エラー回避（法的、財務、データ）」も含まれます。

通達の対象として明示されている主体は、多岐にわたるセクターに及びます。公的機関・行政機関は、オンライン申請、電子政府ポータル、デジタル ID サービスなど、住民向けのすべてのデジタルサービスをアクセシブルにする義務があります。これらはしばしば法的拘束やデータ変更を伴います。BDDK（銀行規制監督庁）の規制下にある銀行および金融機関も準拠が求められ、提供するすべてのオンラインバンキング取引、送金、ローン申請にとって 3.3.4 は直接的に関連します。デジタル患者ポータル、予約システム、電子カルテを運用する病院および医療機関は、それらのシステムにおけるあらゆるデータ入力や変更がエラー回避基準を満たすようにしなければなりません。20 万人以上の加入者を持つ通信事業者（Turkcell、Vodafone TR、Türk Telekom を含む）は、サブスクリプション管理、プラン変更、支払いフローが対象となります。さらに、EC プラットフォーム、旅行代理店、民間の交通事業者、および国民教育省（MoNE）に認可された私立学校も対象に含まれ、トルコ市場における高トランザクションな Web サービスの相当部分をカバーしています。

この枠組みにおいて 3.3.4 への準拠は、単なる技術的チェック項目ではありません。家族・社会サービス省が発行するErişilebilirlik Logosu（アクセシビリティロゴ）を取得しようとする組織は、WCAG 2.2 AA への完全準拠を証明しなければなりません。このロゴは公共の信頼のシグナルとして機能し、消費者や調達機関からの期待も高まっています。財務または法的なワークフローにおいてエラー回避の安全策を実装しない場合、このロゴの付与が拒否されるだけでなく、通達の執行規定に基づく行政措置の対象となる可能性もあります。

特にトルコの EC およびフィンテック分野の組織にとって、3.3.4 はトルコ法における既存の消費者保護要件と密接に一致しています。消費者保護法（第 6502 号）および関連する EC 規制は、すでに通信販売契約における明確な契約前情報とキャンセル権を求めています。WCAG 3.3.4 に準拠した確認・承認ステップを実装することは、アクセシビリティ要件を満たすと同時に、購入者を拘束する前に注文内容を提示するという消費者法上の義務も満たすことになります。この二重の準拠により、適切なエラー回避 UX への投資は、トルコのデジタルサービス提供者にとって高い価値を持ちながら重複の少ない取り組みとなります。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）