WCAG 3.3.3: エラー修正の提案

WCAG 3.3.3 は、入力エラーが自動的に検出された場合、セキュリティや目的を損なうおそれがない限り、ユーザーがどのように誤りを修正できるかを示すテキストによる説明をシステムが提供しなければならないと定めています。この基準は、認知障害のあるユーザー、スクリーンリーダー利用者、およびあいまいまたは不足しているエラー案内の理解に苦労するすべての人にとって不可欠です。

このルールの意味

WCAG 3.3.3 Error Suggestion（エラーの修正提案）は、「理解可能」という原則の下にあるレベルAAの達成基準です。これは、エラーをテキストで特定することを求める3.3.1（Error Identification：エラーの特定）を直接土台としています。Error Suggestion はさらに踏み込み、入力エラーが自動的に検出された場合には、そのコンテンツのセキュリティや目的を損なわない範囲で、インターフェイスがユーザーにどのように修正すればよいかを提案しなければならないと定めています。

ここでの重要な違いは、「エラーの特定」と「エラーの修正提案」の区別です。「生年月日が無効です」とユーザーに伝えるのは特定です。「生年月日が無効です — DD/MM/YYYY 形式で入力してください」と伝えるのが提案です。両方ともそれぞれの達成基準の下で求められますが、Error Suggestion は、可能な限り、実行可能で修正につながるガイダンスがエラーメッセージに付随していることを要求します。

この達成基準は、入力エラーが自動的に検出されるあらゆる場面に適用されます。つまり、クライアントサイドまたはサーバーサイドのバリデーションロジックが、送信または入力された値が期待される条件を満たしていないと判断した場合です。これはすべてのフォームコントロールに適用されます：テキスト入力、セレクトボックス、チェックボックス、ラジオボタン、日付ピッカー、ファイルアップロードフィールド、その他ユーザーデータを収集するあらゆるインタラクティブコンポーネントが対象です。

合格とみなされるもの：エラーメッセージがテキストで提示されている（色やアイコンだけではない）、エラーがあるフィールドを明確に特定している、そしてどのように修正すべきかについて具体的なガイダンスを提供していること。例えば、単に「無効なパスワードです」ではなく、「パスワードは8文字以上で、大文字を1文字含めてください」のようなメッセージです。提案はフィールドの近くに表示され、aria-describedby などを通じてプログラム的にそのフィールドと関連付けられ、支援技術から知覚可能でなければなりません。

不合格とみなされるもの：何が問題なのか、どう直せばよいのかを説明せずに、単にエラーが発生したことだけを伝えるエラーメッセージ。文脈のない「エラー」「無効な入力です」「必須フィールドです」といった汎用的なメッセージは、この達成基準に不合格となります。赤い枠線や警告アイコンだけでエラーを伝え、説明的なテキストがない場合も不合格です。

定義された例外：この達成基準には、提案が不要とされる明示的な例外が2つ含まれています。1つ目は、提案を提供することでセキュリティが危険にさらされる場合です。例えば、ログインフォームで、パスワードが失敗した理由（パスワードが間違っているのか、ユーザー名が間違っているのか）を詳しく説明すると、総当たり攻撃を助長する可能性があります。2つ目は、提案を提供することでコンテンツの目的が損なわれる場合です。例えば、正解を明かしてしまうと評価の目的が失われる教育用クイズなどです。これらの例外は限定的であり、通常のフォームにおいて要件を回避するために使うべきではありません。

なぜ重要か

Error Suggestion が存在するのは、フォームの入力が、ユーザーがウェブ上で行う活動の中でも最も認知的負荷が高いものの1つであり、かつ最も結果が重大になり得るものだからです。チェックアウトフォーム、行政の給付申請、医療の問診フォーム、銀行ポータルなどでのエラーは、何がうまくいかなかったのか、どうすれば回復できるのかを理解できないユーザーにとって、現実世界で深刻な影響を及ぼす可能性があります。

認知障害：ディスレクシア、ADHD、学習障害、識字能力の制限があるユーザーは、曖昧なエラーメッセージを解読し、それを特定のフィールドや必要な形式と結びつけることに苦労する場合があります。明確な修正提案がなければ、フォーム入力を完全に諦めてしまったり、誤った情報を送信してしまったりすることがあります。世界保健機関によると、世界人口の約6人に1人、つまり13億人以上が何らかの障害とともに生活しており、その中でも認知障害は最も一般的でありながら、最も配慮が行き届いていないカテゴリーの1つです。

視覚障害・ロービジョンのユーザー：スクリーンリーダー利用者は、バリデーションエラーを理解するためにテキストによる説明だけに頼っています。エラーメッセージが「無効です」とだけ表示され、提案がない場合、そのフィールドにとって「無効」とは何を意味するのかを知る手段がありません。期待される形式を推測するために、隣接するラベル、プレースホルダーテキスト、視覚的なフォーマットの手がかりを「目で見る」ことはできません。aria-describedby を通じて入力とプログラム的に関連付けられた明確な提案こそが、唯一信頼できる情報チャネルです。

運動障害のあるユーザー：スイッチアクセス、音声コントロール、代替入力デバイスに依存しているユーザーは、フォーム入力に大きな身体的負荷を伴います。送信に失敗した後、何を変更すべきか分からないままフォームに戻って再度操作しなければならないのは、過度な負担となります。明確な提案は再入力の負担と送信失敗のサイクル回数を減らします。

非母語話者や高齢ユーザー：フォームの言語に堪能でないユーザーや、ウェブの慣習に不慣れなユーザーも、明示的な修正提案から大きな恩恵を受けます。「電話番号をスペースやハイフンなしで入力してください（例：05321234567）」といったメッセージは、そうでなければフォームを最後まで完了できないかもしれないユーザーにとって、曖昧さを取り除きます。

実際のシナリオ：トルコ国民が、電子政府ポータルを通じて社会扶助給付を申請するケースを考えてみましょう。申請には、特定の11桁形式であるTR Identity Number（TC Kimlik Numarası）が必要です。ユーザーが10桁を入力し、「TC Kimlik Numarası hatalı」（TC Identity Number は間違っています）というメッセージだけを受け取った場合、認知障害のあるユーザー、高齢ユーザー、スクリーンリーダーユーザーは、その番号が短すぎるのか、不正な文字が含まれているのか、フォーマットの問題なのかを判断できないかもしれません。「TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901」（TC Identity Number は11桁でなければなりません。例：12345678901）と付け加えることで、曖昧さは即座に解消され、ユーザーは自力で修正できるようになります。

ユーザビリティとコンバージョンへの効果：アクセシビリティを超えて、フォーム離脱は重要なビジネス指標です。調査では一貫して、不明瞭なエラーメッセージが、ユーザーがECサイトのチェックアウトや登録フローを離脱する主な理由の1つであることが示されています。具体的で実行可能なエラーの修正提案は、フォーム離脱率を下げ、すべてのユーザーにとって完了率を高めます。したがって、この達成基準はアクセシビリティ要件であると同時に、強力なビジネス上の根拠にもなります。

テスト方法

自動スキャンによるベースライン：フォームを含むページに対して axe DevTools や Lighthouse を実行します。フォームラベル、ARIAロール、エラーの特定（3.3.1）に関連する既存の違反を確認します。これらは、効果的なエラー修正提案の前提条件であるため、まず解決しなければなりません。自動スキャンは、提案の欠如を検出しません — あくまで構造的なベースラインを確立するだけです。
すべてのバリデーション条件をトリガー：各フォームフィールドについて、考えられるすべてのエラー状態を意図的にトリガーします。必須フィールドを空のまま送信する、誤った形式でデータを入力する（誤った日付形式、無効なメールアドレス、短すぎるパスワード、数値フィールドに非数値を入力する）、文字数制限を超えるなどです。表示される各エラーメッセージを記録します。
提案の質を評価：各エラーメッセージについて、(a) 特定のフィールドを識別しているか？ (b) 何が間違っているかを説明しているか？ (c) 入力をどのように修正すべきかについて実行可能なガイダンスを提供しているか？を確認します。3つすべてに答えているメッセージは 3.3.3 に合格します。(a) のみを満たすメッセージは 3.3.1 には合格しますが、3.3.3 には不合格です。
NVDA + Firefox によるスクリーンリーダーテスト：Tab キーでフォームに移動します。無効な値を入力し、送信するかフォーカスを移動します。NVDA が何を読み上げるかを確認します。エラー修正提案テキストが、aria-live リージョンやエラーへのフォーカス移動を通じて、自動的に読み上げられ、ユーザーが手動で探しに行く必要がないことを確認します。
VoiceOver + Safari（macOS/iOS）によるスクリーンリーダーテスト：同じ手順を実行します。VO+右矢印でフィールドとその関連説明を読み上げます。提案テキストが、単なる近接テキストではなく、そのフィールドのアクセシブルな説明の一部として読み上げられることを確認します。
JAWS + Chrome によるスクリーンリーダーテスト：エラーのあるフォームを送信した後、JAWS が、フォーカス管理（フォーカスがエラーサマリーに移動する）または aria-live リージョンの更新を通じて、エラー修正提案を読み上げることを確認します。JAWS の仮想カーソルでフィールドに移動し、そのフィールドの説明の一部として提案が読み上げられることを確認します。
キーボードのみでのナビゲーション：スクリーンリーダーを使わずに、Tab、Shift+Tab、Enter だけでフォームを操作します。送信に失敗した後、フィールドにフォーカスが戻った際に、エラー修正提案がビューポート内に表示されており、画面外に隠れていたり、他の要素に隠れていたりしないことを確認します。
セキュリティ例外の検証：ログインや認証フォームについては、具体的な提案の省略が意図的で文書化されていること、そしてセキュリティ例外が必要最小限のフィールドに限定されていることを確認します。

修正方法

汎用的なエラーメッセージ — 不適切な例

<!-- 問題の修正方法についての提案を提供していないエラーメッセージ -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

汎用的なエラーメッセージ — 適切な例

<!-- aria-describedby が提案テキストを入力に関連付けている。
     提案は期待される形式を正確に説明している -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

パスワードバリデーションに形式のガイダンスがない — 不適切な例

<!-- パスワードが間違っていることだけを伝え、理由や修正方法を伝えていない -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

パスワードバリデーションに形式のガイダンスがない — 適切な例

<!-- 提案がパスワードに必要な要件を正確に列挙しており、
     ユーザーは推測せずに自力で修正できる -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

日付フィールドの形式エラーが曖昧 — 不適切な例

<!-- どのような日付形式が期待されているかの示唆がない -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

日付フィールドの形式エラーが曖昧 — 適切な例

<!-- 必要な形式を明示し、具体例を示すことで
     あらゆる曖昧さを取り除いている -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

サーバーサイドのエラーサマリーを持つ複数フィールドフォーム — 不適切な例

<!-- エラーサマリーは存在するが、リンクが個々のフィールドに
     提案を関連付けておらず、メッセージも曖昧 -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

サーバーサイドのエラーサマリーを持つ複数フィールドフォーム — 適切な例

<!-- エラーサマリーにリンク付きの具体的な提案が含まれている。
     各リスト項目は該当フィールドへのリンクになっている。
     各フィールドの近くにもインラインエラーが表示される -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

よくある間違い

エラー修正提案の代わりに placeholder を使う：プレースホルダーテキストは、ユーザーが入力を始めるとすぐに消えてしまい、エラーとしてスクリーンリーダーに確実に読み上げられるわけではありません。エラー発生後に必要な形式を伝える手段として、プレースホルダーだけに頼ってはいけません。
数秒で消えるトースト通知だけでエラーメッセージを表示する：一時的な通知はすべてのユーザーに知覚されるわけではありません。スクリーンリーダーユーザーは読み上げを聞き逃すかもしれず、読字速度の遅いユーザーはメッセージを読み終える前に消えてしまいます。エラー修正提案は、エラーが修正されるまで持続して表示されなければなりません。
aria-invalid='true' を設定しているが、提案テキストを指す aria-describedby を付けていない：aria-invalid を設定すると、そのフィールドにエラーがあることは伝えられますが、aria-describedby で提案要素にリンクしていなければ、フィールドにフォーカスが当たったときにスクリーンリーダーは提案テキストを読み上げません。
提案を DOM ではなく視覚デザイン（ホバー時のツールチップなど）だけで提供する：ホバー専用のツールチップは、キーボードユーザーやスクリーンリーダーユーザーにはアクセスできません。提案テキストは DOM 上に存在し、フィールドとプログラム的に関連付けられていなければなりません。
どのフィールドにエラーがあるかを色やアイコンだけで示す：赤い枠線や警告アイコンだけでは、エラー修正提案とはみなされません。提案は、修正すべき行動を説明するテキストでなければならず、単なる視覚的なインジケーターでは不十分です。
問題を特定するだけで解決策を示さない提案を書く：「パスワードが短すぎます」はエラーを特定していますが、修正方法を提案していません。「パスワードは8文字以上でなければなりません」は必要な修正ガイダンスを提供しています。3.3.3 に準拠するには、両方の要素が必要です。
セキュリティ例外を広く適用しすぎる：セキュリティ例外は、提案を提供することで本当にセキュリティが損なわれる状況 — 通常は認証フィールドに限定 — にのみ狭く適用されます。氏名、住所、電話番号などの標準的なフォームフィールドにおいて、汎用的なエラーを正当化するものではありません。
エラー修正提案を送信ボタンの後やフィールドから離れた場所に配置する：エラー修正提案は、視覚的にもプログラム的にも、それが説明するフィールドの近くにある必要があります。長いフォームの一番下にすべてのエラーをまとめて表示し、各フィールドにインラインの提案を表示しない場合、ユーザーはどの提案がどのフィールドに対応するのかを切り替えながら覚えておかなければならなくなります。
サーバーサイドの送信失敗後にフォーカスをエラーサマリーへ移動しない：送信に失敗してページが再読み込みされると、フォーカスは通常ページの先頭に戻ります。エラーサマリーや最初のエラーフィールドへのプログラム的なフォーカス移動がなければ、スクリーンリーダーユーザーは何が問題だったのかを知るためにページ全体をナビゲートしなければなりません。
「入力内容を確認してください」「問題が発生しました」のような曖昧な文言を使う：これらのメッセージは、何が問題なのか、どう直せばよいのかについて何も情報を提供しません。すべてのエラー修正提案は、そのフィールドと違反した特定のバリデーションルールに固有でなければなりません。

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

トルコのアクセシビリティ環境は、2025年6月21日に官報第32933号で公布された大統領通達 2025/10 によって大きく前進しました。この通達は、WCAG 2.2 に整合したウェブおよびモバイルのアクセシビリティ要件を義務化し、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行する Erişilebilirlik Logosu（アクセシビリティロゴ）を取得しようとする主体に対してレベルAA準拠を求めています。

レベルAAの達成基準である WCAG 3.3.3 Error Suggestion は、この義務要件の範囲内に含まれます。登録、支払い、サービス申請、アカウント管理などのフォームを運用するすべての対象組織は、エラーメッセージが単にエラーを特定するだけでなく、この達成基準で説明されているような実行可能な修正提案を提供していることを保証しなければなりません。

大統領通達 2025/10 の対象となる組織は、幅広いセクターにまたがります。公的機関および政府機関は遵守が求められ、すべての電子政府ポータル（例：e-Devlet サービス、自治体ポータル、給付申請システム）は、適合したエラー修正提案の実装を提供しなければなりません。多くの行政サービスでは、国民が複雑な個人情報 — 身分証番号、住所コード、税番号など — を提出する必要があるため、この文脈では明確なエラー修正提案が特に重要です。

銀行および金融機関も対象であり、オンラインバンキングプラットフォーム、投資口座の登録フォーム、ローン申請ポータルなどが含まれます。これらのフォームは、機密性が高く厳密な形式が求められるデータを日常的に収集しており、修正提案がないことは、障害のある顧客にとって実質的な障壁となるだけでなく、法的リスクを生む可能性があります。

病院および医療提供者も遵守が必要であり、患者登録システム、予約フォーム、保険請求ポータルが対象となります。医療フォームは、診断コード、保険証券番号、厳密な日付形式など、複雑なフィールド要件を伴うことが多く、高齢者や認知障害のある患者にとって、明確なエラー修正提案が特に重要です。

20万件以上の加入者を持つ通信会社も対象であり、大手事業者の顧客ポータル、SIM登録フォーム、アカウント管理インターフェイスが含まれます。ECプラットフォーム — チェックアウトフローやアカウント登録を含む — も遵守が必要であり、Error Suggestion は、ビジネスの中核となる商品およびカート管理フォームに直接関係します。

旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校も対象範囲に含まれます。これらの組織が運営する予約フォーム、入学申請、支払いインターフェイスは、3.3.3 を含むレベルAA基準を満たさなければなりません。

実務的なコンプライアンスの観点から、Erişilebilirlik Logosu の取得を目指す組織は、WCAG 3.3.3 をあらゆるアクセシビリティ評価における重要な監査ポイントとして扱うべきです。クライアントサイドとサーバーサイドの両方のエラー状態を含む、すべてのフォームバリデーションフローの手動テストが必要であり、修正提案を意図的に省略しているフィールドについては、セキュリティ例外の根拠を文書化しておく必要があります。Error Suggestion を含むレベルAA要件を満たせない場合、ロゴの付与が行われないだけでなく、この通達の下で行政上の措置を受ける可能性もあります。

出典と参考資料

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