フォームを送信した後や検索結果を更新した後、画面にメッセージが表示されても、その変化がすべての利用者に伝わるとは限りません。
特に、画面を見ずに操作している利用者は、処理が進んでいるのか、完了したのか、入力を直す必要があるのかを判断できないことがあります。
ステータスメッセージとは、フォーカスを移さずに、操作の結果、待機状態、進行状況、エラーの発生などを伝える短い通知です。
適切な役割やライブリージョンを設定すると、スクリーンリーダーなどの支援技術が画面の変化を利用者へ知らせやすくなります。
ステータスメッセージが伝える情報
ステータスメッセージは、ページ上の新しい情報をすべて読み上げる仕組みではありません。
利用者が現在の操作を続けるために必要な、短い状態変化を伝えるために使います。
| 通知の種類 | メッセージ例 | 主な実装 |
|---|---|---|
| 操作の成功や結果 | 「設定を保存しました」 | role="status" |
| 待機状態や進行状況 | 「検索結果を読み込んでいます」 | role="status"またはaria-live="polite" |
| 即時に伝える必要がある警告やエラー | 「接続が切れました。再接続してください」 | role="alert"またはaria-live="assertive" |
モーダルダイアログを開いてフォーカスを移す場合や、別のページへ移動する場合は、ここで扱うステータスメッセージとは異なります。
ステータスメッセージは、利用者の現在位置を保ったまま変化を知らせる通知です。
role、aria-live、aria-atomicの役割
通常の通知にはrole=”status”を使う
role="status"は、成功、検索結果の件数、保存状態など、利用者の作業を中断しない通常の通知に適しています。
この役割には穏やかな通知を示すaria-live="polite"が暗黙に含まれるため、一般的なステータス通知ではaria-liveを重ねて指定する必要はありません。
<p id="save-status" role="status" aria-atomic="true"></p>
aria-atomic="true"は、領域内の一部だけが変わった場合でも、メッセージ全体を一まとまりとして伝える指定です。
role="status"にはこの性質も暗黙に含まれますが、メッセージ全体を確実に扱いたい場合は明示すると意図が分かりやすくなります。
aria-liveで通知の優先度を指定する
aria-liveは、領域内の文字列が更新されたときに、その変化を支援技術へ通知するための属性です。
主な値は次の二つです。
polite:現在の読み上げや操作をなるべく中断せず、次の自然なタイミングで通知します。assertive:優先度の高い変化として、すぐに通知するよう支援技術へ伝えます。
assertiveは利用者の読み上げを中断することがあるため、通常の保存完了や読み込み完了には使いません。
その場で把握しないと操作を続けられない通知に絞ります。
緊急性のある通知にはrole=”alert”を使う
role="alert"は、重要で時間的な制約のある通知を伝える役割です。
この役割にはaria-live="assertive"とaria-atomic="true"が暗黙に含まれます。
すべてのエラーをrole="alert"にすると、入力中の利用者を何度も中断しかねません。
送信時に初めて判明したエラーなど、即時に知らせる必要がある場面へ限定します。
通知されやすい実装手順
1. 空の通知領域を操作前から置く
通知領域は、メッセージが発生する前から文書内に用意します。
操作後に役割付きの要素ごと追加するのではなく、空の領域へ文字列を入れるほうが、支援技術が変化を検出しやすくなります。
<button type="button" id="save-button">保存</button>
<p id="save-status" role="status" aria-atomic="true"></p>
初期状態の通知領域をdisplay: noneやhiddenで隠すと、支援技術からも参照できなくなる場合があります。
空のまま配置し、操作結果に応じてテキストを更新します。
2. 要素の表示状態ではなく文字列を更新する
処理の開始時、成功時、失敗時に、実際の状態と一致する文言を通知領域へ設定します。
成功が確定する前に「保存しました」と表示しないことも、通知設計の一部です。
const statusMessage = document.querySelector('#save-status');
function updateSaveStatus(message) {
statusMessage.textContent = message;
}
// 保存処理を始めたとき
updateSaveStatus('保存しています。');
// 保存の成功を確認したとき
updateSaveStatus('設定を保存しました。');
3. 画面にも同じ内容を表示する
ライブリージョンは、スクリーンリーダー専用の隠し通知にする必要はありません。
画面上のメッセージと読み上げられる内容をそろえると、見え方と伝わり方の差を減らせます。
4. メッセージだけで結果を判断できるようにする
「完了しました」「エラーです」だけでは、何が完了し、何を直せばよいのか分かりません。
対象、結果、必要な操作を短い文で示します。
| 伝わりにくい文言 | 具体的な文言 |
|---|---|
| 完了しました | プロフィールを更新しました |
| エラーです | メールアドレスの形式を確認してください |
| 処理中です | 検索結果を読み込んでいます |
フォームエラーを通知する例
フォームのエラーでは、メッセージを読み上げるだけでなく、どの入力欄に問題があるのかも分かるようにします。
入力欄とエラーメッセージを関連付け、エラー状態を属性で示したうえで、通知領域の文字列を更新します。
<label for="email">メールアドレス</label>
<input
id="email"
type="email"
aria-invalid="true"
aria-describedby="email-error"
>
<p id="email-error" role="alert" aria-atomic="true"></p>
const emailError = document.querySelector('#email-error');
emailError.textContent = 'メールアドレスの形式を確認してください。';
エラーがないときは通知領域を空にし、aria-invalidを削除するかfalseに戻します。
項目名、問題の内容、修正方法を伝える考え方は、フォームのエラーを正しく伝える実装で詳しく確認できます。
実装時の確認項目
- 通知領域を、メッセージが発生する前から文書内に置いているか
- 通常の通知と、即時に伝える警告を区別しているか
assertiveやrole="alert"を必要以上に使っていないか- 通知内容が画面上にも表示され、色やアイコンだけに頼っていないか
- 何が起きたのか、利用者が次に何をすべきかを文面から判断できるか
- 通知のたびにキーボードフォーカスが意図せず移動しないか
- 同じ操作を繰り返したときも、最新の状態が通知されるか
- 対象とするブラウザとスクリーンリーダーの組み合わせで読み上げを確認したか
自動検査で属性の有無を確認した後は、実際の操作順に沿って読み上げを確かめます。
保存、検索、送信、入力エラーなど、画面が動的に変わる場面を一つずつ試すと、通知の抜けや過剰な割り込みを見つけやすくなります。
通知の種類から実装を選ぶ
通常の成功通知や待機状態はrole="status"を基本とし、即時性が必要な警告だけをrole="alert"で伝えます。
どちらの場合も、通知領域を先に用意し、実際の状態に合わせて、短く具体的な文字列を更新します。
ステータスメッセージは、画面の変化を読み上げに置き換えるだけの機能ではありません。
利用者が現在地を失わず、操作の結果と次の行動を判断できるようにするためのインターフェースです。
ウェブアクセシビリティ対応を進めるために
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティウィジェットツールを提供しています。
アクセシビリティ向上に関心のある方は、サービスの詳細をご覧ください。

