Webアクセシビリティは、見た目を整えるだけでは実現できません。
利用者が目的の操作を完了でき、入力を間違えても原因を理解して修正できることまで確認する必要があります。
Webアクセシビリティの基本と改善の優先順位を押さえたうえで、本記事ではキーボード操作、ラベル、フォーカス、フォームの入力検証、エラー通知を実務の流れに沿って整理します。
開発者、UX設計者、デザイナー、アクセシビリティ担当者のほか、行政、教育、医療など公共性の高いWebサービスの管理者にも使える確認手順です。
「障壁」と「入力制約」を分けて考える
Webアクセシビリティ上の障壁とは、利用者が情報を受け取る、操作する、内容を理解する、または処理結果を確認することを妨げる設計や実装です。
キーボードで到達できないボタン、読み上げられないラベル、意味が伝わらないアイコン、見えないフォーカス表示などが該当します。
入力制約とは、必須項目、入力形式、文字数、値の範囲など、フォームが受け付ける値の条件です。
入力検証は、入力値がその条件を満たしているかを確認する処理を指します。
両者を区別すると、操作そのものを妨げる障壁と、入力後に生じるエラーを別々に検証できます。
検証で確認する四つの観点
- 操作：マウスを使わなくても、すべての操作対象へ到達して実行できるか。
- 知覚：ラベル、フォーカス、エラー、状態の変化を視覚や支援技術で把握できるか。
- 理解：入力条件、ボタンの目的、エラーの原因、次の操作が明確か。
- 復帰：入力を間違えたとき、入力済みの内容を失わずに修正へ戻れるか。
検証では、個々の部品だけでなく、「入力する」「送信する」「エラーに気付く」「修正して再送信する」という一連の流れを通して確認します。
よくある問題と検証方法
| 問題 | 確認方法 | 改善の方向 |
|---|---|---|
| 操作対象へ到達できない | TabキーとShift＋Tabキーで順番に移動し、ボタンやリンクを実行する | まずHTML標準のボタン、リンク、入力欄を使い、文書上の順序を整える |
| フォーカス位置が分からない | キーボード操作中に、現在位置を常に目で追えるか確認する | フォーカス表示を消さず、背景との違いが分かる輪郭や色を設定する |
| 入力欄の目的が伝わらない | 表示されたラベルとスクリーンリーダーの読み上げを確認する | <label>のforと入力欄のidを対応させる |
| 色だけで必須やエラーを示す | 色を見分けにくい状態でも意味が残るか確認する | 色に加えて、文字、記号、見出しなどで状態を示す |
| 送信失敗の場所と理由が分からない | 未入力、形式違いなど複数の誤りを意図的に発生させる | エラーの概要と各項目の近くに、原因と修正方法を文章で示す |
| 処理結果が読み上げられない | 送信後や画面更新後のメッセージを支援技術で確認する | 必要に応じてライブリージョンを使い、変更内容を通知する |
tabindexを一律に追加すると、見た目の順序と移動順序がずれて操作が分かりにくくなることがあります。
まずHTML標準の操作要素と自然な文書順を使い、独自部品で必要な場合にだけフォーカス管理を設計します。
実装例と確認項目は、キーボード操作とフォーカス表示の実務でも詳しく整理しています。
自動検査と手動検査の役割
axe、Lighthouse、WAVEなどの自動検査ツールは、機械的に判定できる問題を見つけるために使います。
しかし、操作順が自然か、説明が理解できるか、エラーから復帰できるかは、実際の操作で確かめる必要があります。
NVDAやVoiceOverなどのスクリーンリーダー、キーボード操作、表示の確認を組み合わせ、多様な利用者によるテストで不足を補います。
読み上げの基本を確認したい場合は、スクリーンリーダーの仕組みと実装ポイントも参照してください。
フォームで起きる三種類のエラー
- 入力エラー：必須項目が空欄、形式が条件と異なる、許容範囲から外れているなど、入力値が制約を満たしていない状態です。
- 処理エラー：通信やサーバー処理の失敗などにより、正しい入力でも完了できない状態です。
- 説明不足によるつまずき：入力条件や操作手順が曖昧なため、利用者が求められている内容を判断できない状態です。
処理エラーを入力エラーのように表示すると、利用者は修正する必要のない項目を何度も見直すことになります。
エラーの原因に合わせて、「入力を直す」「時間を置いて再試行する」「別の連絡手段を使う」など、次に取れる行動を具体的に示します。
エラーメッセージの設計
入力エラーは、「どの項目で」「何が条件に合わず」「どう直すか」を一続きで伝えます。
- エラーを対象項目の近くに表示し、複数ある場合はフォームの冒頭にも一覧を置く。
- 色だけに頼らず、項目名と原因を文章で示す。
- 入力欄に
aria-invalid="true"を付け、aria-describedbyで説明とエラーを関連付ける。 - 送信後も修正不要な入力値を残し、同じ内容を最初から入力させない。
- エラーを修正した後は、表示とアクセシビリティ情報の両方を更新する。
次の例は、メールアドレスが形式条件を満たしていない時点のHTMLです。
<label for="email">メールアドレス（必須）</label>
<p id="email-hint">例：name@example.com</p>
<input
type="email"
id="email"
name="email"
required
aria-invalid="true"
aria-describedby="email-hint email-error">
<p id="email-error">メールアドレスは「name@example.com」の形式で入力してください。</p>aria-invalid="true"とエラー文は、検証で誤りが確定したときに表示します。
エラー文を動的に追加する場合は、状況に応じてrole="alert"やaria-liveを検討しますが、すべてのメッセージに機械的に付けるのではなく、実際の読み上げ順と割り込み方を確認します。
W3Cの入力検証チュートリアルは、HTMLの検証機能と独自のエラー通知を組み合わせる際の基礎資料です。
エラー文の作り方とテスト手順は、フォームの入力エラーを分かりやすく伝える方法でも確認できます。
WCAG 2.2との対応
W3Cは、WCAGを参照する際に最新バージョンの利用を推奨しています。
既存記事で挙げていた次の達成基準は、WCAG 2.2でも引き続きフォームと操作の検証に関係します。
| 達成基準 | 本記事での確認対象 |
|---|---|
| 1.3.1 情報及び関係性 | ラベル、説明、エラーと入力欄の関係 |
| 2.1.1 キーボード | キーボードだけで操作できること |
| 3.3.1 エラーの特定 | 誤りのある項目と原因を文章で示すこと |
| 3.3.3 エラー修正の提案 | 修正方法が分かる場合に具体的な提案を示すこと |
| 4.1.3 ステータスメッセージ | フォーカスを移さなくても処理結果を支援技術が把握できること |
規格の位置付けはW3CによるWCAG 2の概要で、エラーを文章で特定する要件は達成基準3.3.1の解説で確認できます。
WCAG 2.1から2.2への変更点をサイト内で確認する場合は、WCAG 2.2で追加された達成基準の実務解説が参考になります。
実務で使える検証手順
- 問い合わせ、予約、検索、購入など、利用者が完了したい主要な操作を選ぶ。
- マウスを使わず、Tabキー、Shift＋Tabキー、Enterキー、Spaceキーなどで最後まで操作する。
- フォーカスの位置と移動順を目で確認する。
- スクリーンリーダーで見出し、ラベル、必須条件、エラー、処理結果を確認する。
- 未入力、形式違い、処理失敗などの状態を意図的に発生させ、修正して再送信する。
- 自動検査ツールで検出できる問題を確認し、手動検査の結果と合わせて記録する。
- 修正後に同じ操作を最初から再実行し、別の箇所へ問題が移っていないか確かめる。
公開前のチェックリスト
- すべての操作対象へキーボードで到達できる。
- フォーカス位置が常に見える。
- 入力欄に目的が分かる表示ラベルがある。
- 必須条件と入力形式が送信前に分かる。
- エラーを色だけで示していない。
- エラー文から対象項目と修正方法が分かる。
- エラーと入力欄がプログラム上も関連付けられている。
- 処理結果や状態の変化をスクリーンリーダーで確認できる。
- 自動検査だけで完了とせず、主要な操作を人が通して確認している。
検証結果を改善につなげる
アクセシビリティ検証の目的は、チェック項目を埋めることではなく、利用者が操作を完了し、問題が起きても自力で復帰できる状態を作ることです。
障壁、入力制約、処理エラーを分けて記録すると、設計、実装、文言のどこを直すべきか判断しやすくなります。
公開前の検証に加え、実際の問い合わせや利用状況から見つかった問題を次の改善へ戻すことで、使い続けられるWebサービスになります。