トピックを検索
定型の通知でもVoiceOverの読み上げを遮るアラート
計画アプリが「Samさんがこのタスクを開きました」から「接続が切れました」まで、すべての通知を一つの role="alert" の領域に書き込むため、VoiceOverではありふれた更新のたびに読み上げが遮られ、ほかのスクリーンリーダーでは急ぎの通知がほかと同じに聞こえます。
<div id="notices" class="notices" role="alert"> 問題
アプリがありふれたことを知らせるたびに、VoiceOverの利用者は読んでいる途中で遮られ、どのスクリーンリーダーでも、肝心の急ぎのメッセージがほかと同じように聞こえます。
チームの計画アプリは、タスクを1件ずつ表示します。タイトル、期日、やることを書いた数行の説明です。ページの上端には、細い通知バーがあります。同じタスクを同僚が開くと「Samさんがこのタスクを開きました」、期日が動くと「Samさんが期日を5月14日に変更しました」、コメントが届くと「Alexさんから新しいコメント」と出ます。接続が切れると「接続が切れました。これから行う変更は保存されません。」です。スクリプトはこれらをすべて同じ要素に書き込み、その要素には role="alert" が付いています。
iPadでVoiceOverを使う利用者が、タスクの説明を1行ずつ読んでいます。最初の行の途中で読み上げが止まり、「Samさんがこのタスクを開きました」と聞こえます。行に戻って読み直すと、少し進んだところで「Samさんが期日を5月14日に変更しました」。次はコメントです。一つひとつの通知は短く、害もありません。それでも、どの通知も読んでいた文を途中で断ち切ります。本当に接続が切れたとき、その警告は、それまでの3つの通知とまったく同じように聞こえます。
ノートパソコンでJAWSやナレーターを使う利用者には、違って聞こえます。各行が最後まで読まれ、そのあとに、読んでいる間に届いた通知が読まれます。途中で切れることはありませんが、alertの役割も何の違いも生みません。「接続が切れました」も「Samさんがこのタスクを開きました」と同じように行の終わりを待ち、同じ調子で読まれます。
role="alert" は、assertive のライブリージョンです。ARIAは、assertive の領域の更新を最優先ですぐに伝えるものとし、待っていたメッセージを捨てることも認めています。今すぐ対応が必要なメッセージには欠かせない性質ですが、定型の通知には、あってはならない性質です。達成基準4.1.3は、ステータスメッセージをフォーカスを受け取らずに利用者へ伝えられるようにすることを求めています。そのUnderstandingは、目的を「作業を不必要に妨げない方法で」伝えることだとし、重要でも急ぎでもない内容に role="alert" や aria-live="assertive" を使うことを失敗例に挙げています。この失敗例の解説ページは、まだ書かれていません。「Samさんがこのタスクを開きました」は、重要でも急ぎでもありません。ただし、スクリーンリーダーがすべて領域の求めどおりに動くわけではありません。2026年のリリースでは、macOSとiPadOSのVoiceOverは、assertive の領域とアラートで読み上げに割り込み、macOSでは読み上げを止めました。Firefoxで試したNVDAも role="alert" では割り込み、「alert」という言葉を添えて読んでから、遮った内容を読み直しました。JAWSとナレーターは、アラートを polite の領域と同じように扱い、読んでいる文や行が終わってから読みました。開発者がalertの役割を選んだのは、確実に読み上げられるからです。ただ、その役割が割り込みも起こすことを、ブラウザーは何も警告しません。
通知は、利用者が何もしなくても届きます。同じタスクに関わる人が多いほど、VoiceOverの利用者が遮られる回数も増えます。スマートフォンやタブレットでは、スクリーンリーダーの利用者の多くがVoiceOverを使っています。WebAIMの2024年の調査では、モバイルの回答者の70.6%がVoiceOverを使い、パソコンで主に使うスクリーンリーダーにVoiceOverを挙げたのは9.7%でした。画面が見える人は、バーをちらりと見るか、見ないまま読み続けます。
10グループ中2グループに影響
- 全盲 （影響あり）
- 弱視 （影響なし）
- 色覚 （影響なし）
- ろう （影響なし）
- 難聴 （影響なし）
- 発話 （影響なし）
- 手の操作 （影響なし）
- 届く範囲・力 （影響なし）
- 認知 （影響あり）
- 光過敏 （影響なし）
- 視覚を使わない VoiceOverでは、定型の通知が届くたびに読んでいた行が途中で止まり、戻って読み直しても次の通知でまた遮られます。JAWSとナレーターでは通知は行のあとに読まれますが、肝心の急ぎのメッセージをほかと区別できません。
- 言語・認知・学習の能力が限られる 文字を読むのが難しいためスクリーンリーダーで聞いている人は、文が途中で切れるたびに話の流れを見失い、どこまで読んだかを探し直すことになります。
スキャンはライブリージョンを見つけ、最初からページにあることを確かめて合格にします。メッセージが急ぎかどうかは意味の問題で、どのルールにも読み取れません。この診断は、フォームやダイアログの外でメッセージを待っている空の role="alert" や aria-live="assertive" の領域を、人が中身を確認する対象として挙げます（IDやクラス名からエラー用と分かるものは除きます）。ただし、アプリが実際に送るまで、メッセージそのものは見えません。通知をアクセシブルにするよう頼まれたAIアシスタントも、開発者と同じ理由で、すべてに role="alert" を付けることがあります。通知が届く中で聞いてみて、初めて割り込みに気づきます。
試してみる
スクリーンリーダーの利用者が下矢印キーを押すように「次の行を読む」を押し、通知が届く中で読み上げを聞いてください。
各行を読み始めて少したつと、通知が1件届きます。下の欄にスクリーンリーダーの読み上げが出て、ページでは読み終えた部分が色付きになり、読まれなかった部分が赤で示されます。最初はVoiceOverの読み方です。行の途中で割り込むのは、どの通知ですか？ 次にJAWSとナレーターの読み方に切り替えると、急ぎの通知を聞き分けられますか？
問題あり 修正できますか？
告知メールを書く
告知メールは、最終校正のあと、月曜の9:00に送ります。
短くまとめ、新しいコレクションへのリンクを1つ入れます。
金曜までに、Alexさんに商品写真をもらいます。
木曜までに下書きをチームに送り、コメントをもらいます。
スクリーンリーダーの読み上げ：
（「次の行を読む」を押してください）
修正方法
定型の通知はステータス領域に送り、アラート領域は待てないメッセージだけに使います。
- 1定型の通知には role="status" を使い、順番を待たせる。
- 2role="alert" は、今すぐ対応が必要なメッセージだけに使う。
- 3両方の領域を最初から空の状態でページに置き、通知へフォーカスを移さない。
<div id="notices" class="notices" role="alert"></div><div class="notices"> <p id="notice-status" role="status"></p> <p id="notice-alert" role="alert"></p></div>この方法を選ぶ理由：遮るのは、待てない知らせだけにする
領域は最初からページにあるため、通知はすべて読み上げられます。そして、すべてがアラートとして読み上げられます。VoiceOverとFirefoxのNVDAは、「接続が切れました」のときと同じように、「Samさんがこのタスクを開きました」でも文を途中で切ります。JAWSとナレーターでは、二つは同じように聞こえます。
定型の通知は、ステータス領域に送られるようになりました。role="status" は polite のライブリージョンです。スクリーンリーダーは読んでいる行を読み終えてから、「Samさんがこのタスクを開きました」と読みます。待てないメッセージだけは、これまでどおりアラート領域に送られ、VoiceOverとNVDAでは割り込んで読まれます。割り込むのがそれだけになったため、かえって目立ちます。JAWSとナレーターでは読まれるタイミングが変わらないので、急ぎであることは警告の言葉そのものが伝えます。最初に「接続が切れました」と言い、そのあとで変更への影響を伝えます。どちらの領域も最初から空のままHTMLにあり、通知バーの見た目は変わりません。メッセージの種類は、メッセージを送る呼び出し側で、その場で一度だけ決めます。
急ぎのメッセージとは。 利用者が何かを失いそうなとき、または今すぐ対応が必要なときです。接続が切れた、保存や支払いに失敗した、セッションが切れそう、作業を止めるエラーが出た、などです。それ以外は定型の通知です。保存した、追加した、更新された、誰かが参加した、コメントが届いた、などです。迷ったら定型の通知として扱います。急ぎでも誰も対応できないメッセージなら、そもそも伝える必要があるかを考えます。
急ぎであることは言葉で伝えます。 JAWSとナレーターは、アラートをステータスメッセージと同じように読むため、急ぎのメッセージは言葉で急ぎだと分かるようにします。最初の数語で何が起きたかを言い（「接続が切れました」「支払いに失敗しました」）、そのあとで何を意味し、何をすればよいかを伝えます。次の通知と一緒に消えないよう、事実でなくなるまで画面に残し、あとでバーに来た人も見つけられるようにします。
逆の失敗。 急ぎのメッセージを polite の領域に入れると、スクリーンリーダーが話し終えるまで待ち、ほかの通知のあとに回ることもあります。よくあるのは、セッションが切れる前の警告です。警告と延長の方法は、警告も延長もないセッションタイムアウトで扱っています。
領域は切り替えず、二つ置きます。 スクリプトがメッセージのたびに aria-live を変える一つの領域ではなく、ステータス領域とアラート領域を並べて置きます。二つの領域が固定されていれば、直前のメッセージ用に設定した緊急度で次のメッセージが送られることはありません。
続けて届く通知。 領域に書き込むと、前の内容は置き換わります。定型の通知がすぐあとにもう一つ届くと、読まれる前に置き換わることがあります。両方が大事なら、一つのメッセージにまとめるか（「Samさんがこのタスクを開き、期日を5月14日に変更しました」）、直近のいくつかをバーに行として残します。複数のアラートを同時に出すのは、さらに問題です。ARIAは、assertive のメッセージが届いたときに、待っていたメッセージを捨ててもよいとしているため、最後の一つしか聞こえないことがあります。MDNも、複数のアラートを同時に出すことや不要なアラートは、使い勝手を損なうと警告しています。
通知やトーストのコンポーネント。 多くは、メッセージの種類ごとに役割を選べます。既定の動きを確認してください。すべてのメッセージをアラートとして表示するものもあります。成功や案内のメッセージはステータスに、今すぐ対応が必要なエラーだけをアラートに割り当てます。トーストを画面に出しておく時間は別の問題で、読む前や元に戻す前に消えるトーストで扱っています。
事実でなくなったアラートは消します。 接続が戻ったら、アラート領域を空にし、ステータス領域に「オンラインに戻りました」と書き込みます。警告を残したままにすると、あとでバーを読んだ人に、変更は保存されないという古い内容がまた読まれます。
修正にならないもの。 通知へフォーカスを移せば、どのスクリーンリーダーでも読み上げられますが、通知のたびに読んでいた場所から引き離されるため、割り込みより悪くなります。通知をライブリージョンからすべて外すと割り込みはなくなりますが、「接続が切れました」も聞こえなくなります。メッセージと一緒にページへ追加した領域は、まったく読み上げられないことがよくあります。この失敗は画面に出ても読み上げられないステータスメッセージで扱っています。
AI コーディングアシスタントで修正しますか？ このガイドを Markdown で取得、または全ガイドをコーディングエージェントで使う。
修正の確認
マウスを使わない4つの確認
確認方法： スクリーンリーダー、キーボード
OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。通知のコンポーネントや、送るメッセージの一覧を変更した際は、再度確認します。
制限
ライブリージョンの動きは、スクリーンリーダーやブラウザーによって、またバージョンによっても異なります。このガイドの記述は、2026年時点の各リリースでの動きです。Understanding 4.1.3も、支援技術が利用者の設定に合わせてステータスメッセージを遅らせたり、抑えたり、形を変えたりすることがあると述べています。メッセージが急ぎかどうかは製品についての判断で、そのチームにしかできません。このガイドは、読んでいる間に届く通知を扱っています。読み上げられないメッセージは画面に出ても読み上げられないステータスメッセージで、毎秒読み上げる時計はスクリーンリーダーが読み上げ続けるカウントダウンタイマーで、確認を求めるダイアログは質問が読み上げられない確認ダイアログで扱っています。割り込みそのものを後回しにできるようにすること（レベルAAA）は、別のトピックです。利用者が使うスクリーンリーダーで確認してください。
よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。
コードを更新しても、使いやすさを保つために
ガイドの内容を、コーディングエージェントやCIで使える開発ルールにまとめます。更新後は、キーボードとスクリーンリーダーで再テストし、問題が再発していないか確認します。