エラーメッセージとマイクロコピーのアクセシビリティ設計｜迷わせない文案・通知・修正導線

フォームでエラーが起きたとき、利用者が必要としているのは叱責ではなく、作業を再開できる情報です。

エラーメッセージには、問題の内容、該当する項目、修正方法を短く示し、画面表示と読み上げの両方で気付けるようにします。

この記事では、文案、表示、フォーカス、通知、テストを一つの流れとして整理します。

エラーメッセージとマイクロコピーの役割

マイクロコピーとは、ラベル、入力例、ヒント、ボタン名、通知など、操作の近くに置く短い文章です。

短いからこそ、曖昧な一語が利用者の迷いに直結します。

認知負荷は、利用者が理解や判断のために一時的に抱える情報量です。

「入力内容に誤りがあります」だけでは、利用者は画面を見直し、対象を探し、正しい形式を推測しなければなりません。

エラーメッセージの役割は、この探索と推測を減らすことです。

ラベルや必須表示を含むフォーム全体の設計は、関連記事「フォームのアクセシビリティ実装ガイド」でも確認できます。

修正につながる三つの情報

実務では、エラーメッセージを「問題」「場所」「修正方法」に分けると、抜けを見つけやすくなります。

情報	答える問い	文案の例
問題	何が違うのか	郵便番号が未入力です。
場所	どの項目か	項目名の「郵便番号」を文中に含めます。
修正方法	どう直すのか	ハイフンなしの7桁で入力してください。

三つを合わせると、「郵便番号が未入力です。ハイフンなしの7桁で入力してください（例：1000001）」となります。

一方、「無効です」「エラーが発生しました」では、対象も直し方も分かりません。

システム用のエラー番号が問い合わせに必要なら、人が読める説明と操作方法を先に示し、番号は補助情報として後ろへ置きます。

エラーを減らす入力前のマイクロコピー

エラー表示を整える前に、入力条件を先に伝えます。

• プレースホルダーだけに頼らず、入力欄の外に常時見えるラベルを置く。
• 桁数、使用できる文字、日付の順序などを入力前に示す。
• 正しい形式を推測しにくい項目には、実際の形式に合う例を添える。
• autocomplete、inputmode、適切な入力型を使い、入力の手間と誤りを減らす。
• 必須であることを記号だけで示す場合は、記号の意味をフォーム冒頭でも説明する。

入力中の検証は、文字を一つ入力するたびにエラーを出す方式を避けます。

入力欄からフォーカスが離れたとき、または入力が落ち着いたときなど、利用者が内容を確認できる時点を選びます。

ただし、ユーザー名の重複確認のように通信を伴う検証は、確認中、成功、失敗の状態も伝えなければなりません。

色に頼らない表示と項目の関連付け

エラーは文章で説明し、色やアイコンは補助として使います。

WCAG 2.2では、色を情報伝達の唯一の手段にしないこと、通常の文字に原則4.5対1以上のコントラストを確保すること、入力欄の境界や状態を示す視覚情報に原則3対1以上のコントラストを確保することが求められます。

赤い枠だけでは、色の違いを認識しにくい利用者や画面を見ていない利用者へエラーが届きません。

• 入力欄の近くにエラー文を表示する。
• aria-invalid="true"で、入力値が不正な状態を伝える。
• aria-describedbyで入力欄とヒントやエラー文を関連付ける。
• アイコンを使う場合も、意味を説明するテキストを残す。
• フォーカス表示を消さず、背景やエラー色の上でも見えるようにする。

関連付けが正しくても、実際の読み上げ方はブラウザと支援技術の組み合わせで異なります。

コードレビューだけで完了とせず、使用対象の環境で確認します。

エラー要約と個別メッセージの導線

複数の入力項目に誤りがある場合は、フォームの先頭にエラー要約を置き、各項目の近くにも個別メッセージを表示します。

W3C WAIのフォーム通知ガイドは、要約に分かりやすい見出しを付け、項目名、エラーの説明、修正方法、該当項目へのページ内リンクを含める方法を示しています。

送信後にページを再読み込みする場合は、ページタイトルや主見出しでもエラー件数を伝えると、利用者が結果を把握しやすくなります。

ページを再読み込みせずに要約を更新する場合は、更新された内容をライブリージョンで通知できます。

ライブリージョンとは、画面の一部が更新されたことを、フォーカスを移さず支援技術へ知らせる仕組みです。

要約へフォーカスを移す設計と、ライブリージョンで読み上げる設計を同時に使うと、環境によっては同じ内容が重複して聞こえます。

採用する挙動を決め、キーボードとスクリーンリーダーで通して検証します。

静的なエラー状態のHTML例

<div id="error-summary" role="alert" aria-labelledby="error-summary-title">
  <h2 id="error-summary-title">入力内容に2件のエラーがあります</h2>
  <ul>
    <li><a href="#zip">郵便番号を入力してください</a></li>
    <li><a href="#email">メールアドレスの形式を確認してください</a></li>
  </ul>
</div>

<label for="zip">郵便番号（必須）</label>
<input id="zip" name="zip" inputmode="numeric"
       autocomplete="postal-code" required
       aria-invalid="true"
       aria-describedby="zip-hint zip-error">
<p id="zip-hint">ハイフンなしの7桁で入力します。</p>
<p id="zip-error">郵便番号が未入力です。7桁で入力してください。</p>

この例はエラー表示後の状態です。

動的に実装する場合は、エラー文の表示と同時にaria-invalidを更新し、エラーが解消したら属性とメッセージを適切に戻します。

alertとstatusの使い分け

role="alert"は、重要で時間的な優先度が高い更新を強く知らせるライブリージョンです。

すべての個別エラーへ付けると、複数のメッセージが連続して割り込み、かえって内容を追いにくくなります。

role="status"は、保存完了や検索結果件数など、作業を中断させるほどではない状態変化に使います。

状況	候補	設計上の注意
送信後に複数のエラーが判明	要約にalert	個別エラーとの重複読み上げを確認します。
下書き保存の完了	status	フォーカスを奪わず、短く伝えます。
処理中	status	開始だけでなく完了や失敗も通知します。
直ちに判断が必要な確認	ダイアログ	単なるalertで操作を求めず、フォーカス管理を含めて実装します。

WAI-ARIA Authoring Practices GuideのAlertパターンも、アラートがフォーカスへ影響しないことと、頻繁な割り込みや自動消去を避けることを説明しています。

実装例と確認方法は、関連記事「ウェブアクセシビリティのステータスメッセージ」で詳しく扱っています。

フォーム外の失敗に回復手段を添える

入力値が正しくても、通信、サーバー、権限、同時編集、ファイル処理などで操作が完了しないことがあります。

この場合は、原因を断定できる範囲で説明し、次の行動と入力データの状態を伝えます。

• 再試行できるなら、ボタン名を「もう一度保存する」のように具体化する。
• 入力内容を保持している場合に限り、「入力内容は保持されています」と伝える。
• 復旧を待つ必要があるなら、確認先や代替手段を示す。
• 権限がない場合は、必要な権限または連絡先を案内する。
• 同時編集の競合では、破棄、再読み込み、別名保存など、実際に選べる操作を説明する。

「しばらくしてから」のような表現は、待つ時間が分かっている場合だけ具体化します。

復旧時刻を確認できないのに、見込み時間を作るわけにはいきません。

すぐ使える文案テンプレート

テンプレートは、実際の入力条件とシステムの挙動に合わせて置き換えます。

状況	避けたい文案	改善例
未入力	必須です。	氏名が未入力です。氏名を入力してください。
形式違い	無効な値です。	メールアドレスの形式を確認してください（例：user@example.com）。
範囲外	入力エラーです。	数量は設定された範囲内で入力してください。
重複	使用できません。	このユーザー名は使用されています。別のユーザー名を入力してください。
通信失敗	Error -1001	通信に失敗しました。接続を確認して、もう一度送信してください。
権限不足	Forbidden	この操作に必要な権限がありません。管理者へ確認してください。

範囲、保存状態、問い合わせ先などの情報は、実際に確認できる内容だけを入れます。

通知の形式は情報の寿命で選ぶ

• インラインメッセージ：特定の入力項目や操作領域に関係し、修正が終わるまで残す情報に向きます。
• エラー要約：複数の問題を一覧で確認し、各項目へ移動する必要がある場合に向きます。
• ステータス通知：保存完了や処理中など、フォーカスを移さず伝える短い状態変化に向きます。
• バナー：障害や保守など、ページ全体に影響する情報に向きます。
• ダイアログ：利用者の判断や確認がなければ処理を続けられない場合に限って使います。

自動で消える通知は、読み終える前に失われる可能性があります。

操作に必要な情報は自動消去せず、再確認できる場所を用意します。

WCAG 2.2との対応関係

エラー設計に関係の深い達成基準を表にまとめます。

達成基準	エラー設計で確認すること
1.3.1 情報及び関係性	ラベル、入力欄、ヒント、エラーの関係がプログラムで判別できる。
1.4.1 色の使用	色だけでエラーや成功を伝えていない。
1.4.3 コントラスト（最低限）	通常の文字は原則4.5対1以上のコントラストを確保する。
1.4.11 非テキストのコントラスト	入力欄の境界や状態を示す視覚情報は原則3対1以上を確保する。
2.1.1 キーボード	送信、要約のリンク、修正、再送信をキーボードで完了できる。
2.4.3 フォーカス順序	エラー後のフォーカス移動が操作の順序を壊さない。
2.4.7 フォーカスの可視化	現在のフォーカス位置を視覚で確認できる。
2.5.3 ラベルを含む名前	音声操作で使う名前に、画面上のラベル文言が含まれる。
2.5.8 ターゲットのサイズ（最低限）	例外を除き、ポインター入力の対象を24×24 CSSピクセル以上にするか、規定の間隔を確保する。
3.3.1 エラーの特定	エラーがある項目と問題の内容を文字で説明する。
3.3.2 ラベル又は説明	入力に必要なラベルや説明を用意する。
3.3.3 エラー修正の提案	修正方法が分かり、セキュリティや目的を損なわない場合は提案を示す。
4.1.2 名前、役割及び値	独自UIの名前、役割、状態を支援技術へ伝える。
4.1.3 ステータスメッセージ	フォーカスを受け取らない状態変化も支援技術が判別できる。

24×24 CSSピクセルはWCAG 2.2のレベルAAにある最低条件で、44×44 CSSピクセルは例外を伴うレベルAAAの強化基準です。

操作頻度や誤操作の影響を考え、最低条件より大きな押下領域を採用する判断も必要です。

この表はフォーム周辺の確認範囲であり、サイト全体のWCAG 2.2適合を保証する一覧ではありません。

リリース前の確認手順

1. 必須項目を空のまま送信し、要約と個別エラーの両方が表示されるか確認する。
2. 形式の異なる値を入力し、項目名、問題、修正方法が伝わるか確認する。
3. キーボードだけで送信、要約から項目への移動、修正、再送信を完了する。
4. フォーカス表示が背景やエラー表示に埋もれないか確認する。
5. スクリーンリーダーで、要約と個別エラーが過不足なく読み上げられるか確認する。
6. ブラウザ拡大や文字拡大で、メッセージやボタンが重ならないか確認する。
7. 通信を切断して、失敗の説明、再試行、入力内容の扱いを確認する。
8. 言語を切り替え、項目名、例、日付、数値の形式がそろっているか確認する。

キーボード操作と表示の確認は、関連記事「キーボード操作とフォーカス表示をどう整えるか」も参考になります。

チームで文案と実装を保つ方法

エラー文を画面ごとに作ると、同じ問題へ異なる用語や対応方法が使われます。

言語スタイルガイドとUIコンポーネントを対応させ、文案だけでなく表示と通知の挙動も共通化します。

• 未入力、形式違い、範囲外、重複、権限、通信失敗の文案を分類する。
• 項目名、制約、入力例、回復手段を差し替えられる形で管理する。
• エラー要約、個別メッセージ、ステータス通知の役割をコンポーネント仕様に記す。
• デザインレビュー、コードレビュー、支援技術テストの担当範囲を決める。
• 問い合わせで繰り返し尋ねられる内容を、次の文案改善へ反映する。

ただし、テンプレートの統一は「どの状況でも同じ文を出す」ことを意味しません。

利用者が取れる行動とシステムの実際の状態に合わせて、説明を具体化します。

修正できる言葉と導線を一体で設計する

エラーメッセージは、項目名、問題、修正方法を伝えて初めて操作を支えます。

その文章を入力欄へ関連付け、複数の問題を要約し、適切なフォーカスと通知で届けます。

通信失敗などのフォーム外の問題には、再試行や問い合わせといった回復手段も必要です。

文案、見た目、HTML、読み上げを別々に点検せず、入力から修正、再送信までを一つの利用体験として試してください。

この記事に関連する株式会社greedenの取り組み

入力エラーの言葉と実装は、公開後の点検まで含めて整える必要があります。株式会社greedenは、Webアクセシビリティ対応を始めたい企業に向け、UUUの導入とWebアクセシビリティチェックを支援しています。