aria-liveは画面内で変わった結果だけを短く伝えform全体を読み直させない

aria-liveは、JavaScriptで画面内の内容が変わったとき、その変化をassistive technologyへ伝えるための属性です。問い合わせformの送信結果、検索件数、入力errorのように、利用者が操作したあとで追加される短い案内に使えます。page全体の文章や長い説明を何度も読み上げさせるための属性ではありません。

画面にmessageを表示することと、そのmessageが利用者へ届くことは別です。視覚的にはbuttonの近くに「送信しました」と出ていても、keyboardやscreen readerを使う人は、画面のどこが変わったか分からない場合があります。変わった内容を伝える場所と、必要なら入力欄へ戻す操作を分けて作ります。

変化した結果だけをlive regionへ入れる

WAI-ARIAは、aria-liveで更新を知らせるlive regionを定義しています。politeは利用者の作業を不必要に中断せずに知らせるための値で、assertiveはより急いで知らせる必要がある変化に使います。どちらを使うかは、messageの重要さと、利用者が何を操作しているかで決めます。

説明用の仮例として、資料請求formで必須入力を確認する場面を考えます。送信buttonを押したあと、メールaddressが空なら「メールaddressを入力してください」と短く知らせます。このmessageをform全体の先頭へ追加し、必要な項目にもerrorの文を出せば、利用者は何が起きたかと、どこを直すかを確認できます。全ての入力欄、利用規約、長い説明をlive regionへ入れる必要はありません。

検索結果の件数が絞り込み操作で変わる場合も同じです。「結果は12件です」のように、変わった数と対象を短く伝えます。各商品のtitleや説明を一度に読み上げれば、利用者は操作の結果を聞き終える前に迷います。live regionへ入れる文は、次の操作を選ぶために必要な最小限にします。

politeとassertiveを一律に決めない

assertiveを使えば重要なmessageが必ず伝わる、と考えるのは早すぎます。入力中の文字、読んでいる説明、別の操作に割り込む可能性があるため、全てのform errorへ使うと利用者の操作を妨げます。通常の検索件数や保存完了の案内は、politeで知らせる判断があります。

一方で、送信ができず、次の操作を止める必要があるerrorでは、より早い通知が必要になる場合があります。たとえば、sessionが切れて入力を保存できない、支払い処理を進められない、入力した内容に重大な問題があるときです。それでも、messageを読み上げるだけで終わらせません。画面に同じmessageを表示し、直す項目または代替の連絡先へ進めるようにします。

重要度は実装する人だけで決めず、formの目的で決めます。資料請求のemail addressが空なら、項目を直せばよい状態です。予約日時がすでに埋まったなら、別の日時を選ぶ必要があります。サービスを停止していて受付できないなら、送信し直すより、いつ再開するかや連絡先を示す必要があります。どのmessageも同じ緊急度ではありません。

見えるerrorと読まれるerrorを同じ内容にする

live regionだけにmessageを入れ、画面に何も出さない構成は避けます。screen readerを使わない人も、送信後に何が起きたかを確認する必要があります。反対に、色の変化や赤い枠だけでerrorを示して、live regionに何も入れない構成も足りません。項目名、問題、直し方を文字で出します。

たとえば「入力内容に誤りがあります」だけでは、利用者はどの欄を見ればよいか分かりません。「電話番号を数字で入力してください」「送信先のmail addressを確認してください」のように、項目と操作を示します。live regionには同じ内容を短く入れ、各inputの近くには必要な補足を置きます。二つのmessageが矛盾すると、読み上げを聞いた人と画面を見た人で直す場所が変わります。

formをAJAXで送る場合も、serverが返したmessageをそのまま表示しません。内部のfile pathやdatabase errorを含む文を利用者へ出せば、必要以上の情報を渡します。利用者向けには次の操作を示し、status、発生時刻、調査に必要な情報はserver側へ残します。aria-liveはserver errorを見せる仕組みではなく、利用者が画面で次に何をするかを知らせる場所です。

公開前にはkeyboard操作と送信結果を順に試す

確認は、画面を見てmessageが出たかだけで終わらせません。keyboardだけでformへ移動し、必須項目を空にして送信し、error messageが出るか、問題の項目へ戻れるかを試します。次に正しい入力で送信し、完了message、送信buttonの状態、受付後の案内が読めるかを確認します。

screen readerを使う検証では、formを読み始めた状態から、入力error、送信完了、検索結果の更新を順に試します。messageが何度も繰り返されないか、入力中に不必要な割り込みがないか、どの項目を直せばよいかが分かるかを見ます。利用者の環境ごとの挙動を一つのtextだけで保証できないため、画面の本文と操作の順序も確認します。

制作会社へ依頼する場合は、「aria-liveを入れる」とだけ伝えません。対象form、変わる結果、画面に出す文、読み上げる文、politeまたはassertiveを選ぶ理由、error時に移動する項目、公開後に試す操作を渡します。属性を追加したことではなく、利用者が操作を終えられる状態を完了条件にします。

最初の一手は、JavaScriptでmessageが変わる場所を一つ選び、操作前、操作後、失敗時に利用者へ何を伝えるかを書き出すことです。変わった結果だけを短く知らせ、画面の本文と次の操作をそろえます。