フォームのアクセシビリティ実装ガイド｜ラベル、入力支援、エラー通知をWCAG 2.2で見直す

フォームで起きるつまずきは、入力欄の見た目だけでは解決できません。質問の意味が分かること、必要な情報を無理なく入力できること、間違えたときに直し方が分かること、送信結果を確認できることまでを一続きの操作として設計する必要があります。

この記事では、問い合わせ、会員登録、予約、購入などに共通する実装ポイントを、設計、マークアップ、エラー処理、テストの順に整理します。基準にはW3CのWeb Content Accessibility Guidelines（WCAG）2.2を用います。ただし、コード例を取り入れただけで適合を宣言できるわけではありません。実際のページと一連の手続きに対する試験が必要です。

WCAG 2.2でフォームを捉える

WCAGは、Webコンテンツを知覚しやすく、操作しやすく、理解しやすく、堅牢にするための国際的な指針です。WCAG 2.1もW3C勧告として有効ですが、W3Cは新規開発や方針更新でWCAG 2.2を使うことを勧めています。2.2で追加された達成基準については、サイト内のWCAG 2.2の変更点をまとめた解説も参照できます。

入力の流れとグループを先に設計する

入力欄を実装する前に、利用者が何を、どの順番で判断するかを決めます。たとえば購入手続きなら、配送先、配送方法、支払い、確認という順序が画面表示とDOMの両方で一致していれば、画面を見ている利用者とキーボード利用者が同じ流れをたどれます。CSSで見た目だけを並べ替えると、この一致が崩れることがあります。

複数の選択肢が一つの質問に答えるラジオボタンやチェックボックスには、fieldsetとlegendを使います。legendが質問、各labelが回答候補という関係になります。一方、単独のテキスト入力まで機械的にfieldsetで囲む必要はありません。

長いフォームを複数画面に分ける場合は、現在位置と残りの手順を示し、戻ったときに入力済みの内容を保持します。条件によって追加項目を表示するなら、表示のきっかけとなった操作の直後に配置し、キーボードでも到達できることを確認します。

可視ラベル、名前、説明を結び付ける

アクセシブルネームとは、支援技術が入力欄を識別するための名前です。通常のHTMLフォームでは、可視のlabelを入力欄に関連付ける方法が最も理解しやすく、保守もしやすい実装です。W3Cのフォームのアクセシビリティ解説でも、ラベルと構造要素の関連付けが、音声入力、スクリーンリーダー、細かな操作が難しい利用者を支えると説明されています。

• ラベルは入力前にも入力後にも見える位置へ置く。プレースホルダーだけで代用しない。
• forとidを一致させ、ラベルを選択しても入力欄へフォーカスできるようにする。
• 必須表示は色や記号だけにせず、ラベル付近に「必須」と書く。
• 入力例や制約はaria-describedbyで関連付ける。項目名そのものは説明文へ押し込まない。
• aria-labelで可視ラベルを上書きしない。音声操作で画面上の言葉を指定できなくなる場合がある。

次の例では、項目名、入力例、エラーの役割を分けています。エラーが発生したら、アプリケーション側でエラー文のhiddenを外し、aria-invalidをtrueへ更新します。

<label for="email">メールアドレス（必須）</label>
<p id="email-hint">例：user@example.com</p>
<input id="email"
       name="email"
       type="email"
       autocomplete="email"
       required
       aria-invalid="false"
       aria-describedby="email-hint email-error">
<p id="email-error" hidden>
  「@」を含むメールアドレスを入力してください。
</p>

入力支援は「間違えにくさ」から考える

入力支援は、誤りを指摘する機能だけを指しません。入力する量を減らし、適切なキーボードや保存済み情報を利用できるようにして、間違いが起きる前の負担を下げる設計も含みます。

同じ手続きの中で入力済みの情報を再び求める場合、WCAG 2.2の3.3.7「冗長な入力」は、自動入力するか、利用者が選択できる形にすることを求めています。配送先と請求先が同じ場合にチェックで転記できるようにすることは、その具体例です。ただし、情報が無効になった場合や、再入力がセキュリティ上必要な場合などには例外があります。

バリデーションはタイミングと直し方をそろえる

バリデーションとは、入力値が必須条件や形式、業務上の制約を満たすかを検証する処理です。ブラウザ上の検証は利用者を助けますが、改変や通信経路を考慮すると、サーバー側の検証も省けません。

入力中にエラーを出し続けると、まだ入力を終えていない値まで誤りとして通知してしまいます。形式チェックは、利用者が項目から離れた後、または送信後に行うのが出発点です。入力中に通知する場合は、入力が正しい状態になったことを静かに知らせるなど、作業を遮らない設計にします。

エラーメッセージに必要な情報

「入力に誤りがあります」だけでは、利用者は直せません。メッセージには対象、問題、修正方法を含めます。

送信時に複数のエラーがある場合は、フォームの先頭に要約を置き、各項目へのリンクを用意します。送信に失敗した直後は要約へフォーカスを移す方法があります。各リンクを選ぶと該当欄へ移動でき、入力済みの正常な値は保持されるようにします。

<div id="error-summary" tabindex="-1"
     aria-labelledby="error-title">
  <h2 id="error-title">入力内容を確認してください</h2>
  <ul>
    <li><a href="#email">
      メールアドレスに「@」を含めてください
    </a></li>
  </ul>
</div>

エラー要約、個別メッセージ、ライブリージョンを同時に更新すると、読み上げが重複する場合があります。採用する通知方法を決め、実際のブラウザとスクリーンリーダーの組み合わせで確認します。

キーボード操作とフォーカスを一続きで確認する

標準のHTML要素は、キーボード操作と役割があらかじめ実装されています。ボタンにはbutton、リンクにはa、選択には標準の入力要素を優先します。見た目を整えるためだけにdivへクリック処理とARIAを足すと、キー操作や状態通知を個別に再実装する必要が生じます。

• TabキーとShift+Tabキーで、見た目どおりの順序に移動できる。
• tabindexの正の値で順序を作らない。DOM順を直す。
• フォーカス表示を消さず、背景と区別できる状態にする。
• 固定ヘッダー、Cookieバナー、モーダルでフォーカス中の要素を完全に隠さない。
• ダイアログを開いたら内部へフォーカスを移し、閉じたら起点へ戻す。aria-modal='true'だけではフォーカス管理は実装されない。

具体的な確認方法は、サイト内のキーボード操作とフォーカス表示の実務解説で詳しく確認できます。

モバイルでは大きさと間隔を分けて考える

WCAG 2.2の2.5.8「ターゲットのサイズ（最低限）」は、ポインターで操作する対象を原則24×24 CSSピクセル以上にするか、小さい対象の周囲に十分な間隔を設けることをAAの基準としています。例外もあるため、44〜48ピクセルを一律のAA要件として扱うのは正確ではありません。44×44 CSSピクセルは強化基準の目安であり、主要な送信ボタンや小さなチェックボックスでは、より押しやすい設計目標として採用できます。

• チェックボックスとラジオボタンは、ラベルを含む領域を選択できるようにする。
• 隣接する操作対象の間隔を確保し、誤操作を減らす。
• user-scalable=noや過度なmaximum-scaleで拡大を妨げない。
• 狭い画面や文字拡大でも、ラベル、入力欄、エラーの対応関係が崩れないようにする。
• 日付入力などブラウザ依存のUIは、対象環境で直接入力と選択操作の両方を確認する。

CAPTCHAと認証で記憶や転記を強制しない

画像CAPTCHAの代替として計算問題や文字の聞き取りを置くだけでは、認証をアクセシブルにしたことになりません。計算、記憶、文字列の転記はいずれも認知機能へ負担をかけるためです。WCAG 2.2の3.3.8「アクセシブルな認証（最低限）」は、認知機能テストを求める場合に、別の認証方法または作業を助ける仕組みを用意することを求めています。

• パスワード管理ツールによる自動入力と、コピーして貼り付ける操作を妨げない。
• autocomplete='username'とautocomplete='current-password'を適切に使う。
• 可能であれば、別端末での承認など、文字列の記憶や転記を必要としない経路を用意する。
• 確認コードには有効期限と再送方法を明示し、入力途中で内容を不必要に消さない。

送信状態は見た目と支援技術へ伝える

送信ボタンを無効化するだけでは、処理中なのか故障したのかが分かりません。「送信中です」「送信が完了しました」「送信できませんでした」のように状態を文字で示します。フォーカスを移す必要がない短い状態通知には、role='status'やaria-live='polite'を検討します。

通信に失敗した場合は、再送方法を示し、入力内容をできる限り保持します。法的な同意、決済、個人データの変更など重大な結果を伴う送信では、確認、訂正、取消の手段も設計対象です。

公開前に行う手動テスト

1. ラベル：各入力欄の目的、必須か任意か、制約を入力前に理解できるか。
2. キーボード：TabキーとShift+Tabキーだけで全項目を移動し、選択し、送信できるか。
3. エラー：空欄や誤った形式で送信し、要約から各項目へ移動して修正できるか。
4. フォーカス：現在位置が見え、固定要素やダイアログに隠れないか。
5. 拡大と小画面：文字を200%にし、幅320 CSSピクセル相当でも情報と操作を失わないか。
6. コントラスト：通常文字、入力欄の境界、エラー、フォーカス表示を測定する。
7. 読み上げ：主要なスクリーンリーダーで、ラベル、ヒント、エラー、状態の順序と重複を確認する。
8. 入力補完：ブラウザとパスワード管理ツールで、自動入力と貼り付けが使えるか。
9. 通信失敗：再送時に入力内容が保持され、同じ送信が重複しないか。

自動検査は、ラベルの欠落や一部の属性、コントラストなどを見つける助けになります。しかし、質問の分かりやすさ、フォーカスの流れ、エラーからの回復は人が操作して確かめる必要があります。公開後の点検と修正を継続する方法は、Webアクセシビリティの運用ガイドに整理しています。

チームで再発を防ぐ

フォームの不具合をページごとの修正で終わらせると、次の画面で同じ問題が繰り返されます。入力コンポーネントの仕様に、通常、必須、エラー、無効、送信中、完了の各状態を定め、デザインと実装とテストで共通の受入条件を使います。

• デザインにはラベル、ヒント、必須表示、エラー、フォーカスの全状態を含める。
• 実装レビューでは、HTMLの意味、名前、役割、状態、キーボード操作を確認する。
• 自動テストでは、ラベルの関連付けやエラー時の属性更新など、機械的に判定できる部分を固定する。
• リリース前後に、キーボードとスクリーンリーダーによる短い回帰テストを行う。
• 問い合わせや離脱の傾向から問題を見つけても、原因を推測だけで決めず、操作観察と再現試験で確かめる。

フォーム改善の優先順位

最初に直すのは、入力できない、エラーから戻れない、送信結果が分からないといった手続きを止める問題です。次に、ラベルと説明、入力補完、操作対象の大きさを整えます。その後、表現の分かりやすさと処理時間を改善します。この順序なら、見た目の微調整だけで終わらず、利用者が目的を完了できるかを基準に判断できます。

フォームのアクセシビリティは、属性を追加する作業ではありません。質問を理解し、少ない負担で入力し、誤りを修正し、結果を確認できる流れを設計して、実際の操作で検証する取り組みです。