ページ全体を聞き直さずに、スクリーンリーダーの利用者が物語の追加に気づくには？

行動によって物語が追加されたら、まず短く完了を通知し、見出しの明確な本文領域に結果の全文を置き、いつ読みに行くかは利用者に委ねる方法があります。通知は「先ほどの操作の結果は出たか」、本文は「具体的に何が起きたか」、フォーカス方針は「次はどこで操作するか」に答えます。それぞれの役割を分けることで、一度の更新がページ全体の読み直しにつながるのを防ぎます。

ステータスメッセージは、フォーカスを受け取らずにロールやプロパティを通じて提示できます。ステータスメッセージの解説を参照。これは物語の段落全体を自動で読み上げるよう求めるものではありません。以下の役割表、文言、操作の順序は、学習用に独自に作成した設計であり、特定の製品の実装を説明するものではありません。

この記事で扱うのは「現在のページに以前の物語を残し、行動後に結果を追記する」場面だけです。例に登場する古い灯台、灯台守、操作の流れはすべて架空です。実際の利用者の事例や実測結果、DramaFork の既存機能ではありません。設計の目的も、特定の読み上げ動作を保証することではなく、納品時に確認できる要件を先に定めることです。

納品時には、物語の各ノードとともに次の表を記入します。要件に「スクリーンリーダー対応」とだけ書いてはいけません。それだけでは、追加内容を何が、いつ読み上げるのかがわからないためです。

ステータスメッセージで銅の箱の中身を繰り返す必要はありません。一方、本文は単独で完結している必要があります。通知を聞き逃しても、結果を見つけて理解できなければなりません。入口の名前は移動先がわかるものにします。「表示」や「こちら」では、文脈から切り離されると見分けにくくなります。

フォーカスは現在の操作位置です。スクリーンリーダーの読み上げ位置は、それとは別に確認する必要があります。受け入れ確認でボタンにフォーカスが残っていても、元の文から聞き続けられるとは断定できません。役割表は期待する動作を定めるものであり、実装では、モバイルの読み上げジェスチャー、キーボード操作、内容の更新が実際にどう関係するかを確認する必要があります。

架空の場面で、旅人は古い灯台の入口に立っています。元の文章には「灯台守は銅の箱を机の端へ押しやり、箱の底を調べるようあなたに促した」とあります。利用者は読み終えると「銅の箱を調べる」を実行します。この時点では操作は送信済みですが、結果はまだ準備できていません。画面では待機中と完了を区別し、すぐに「新しい手がかりを発見しました」と通知してはいけません。

結果の準備ができたら、元の文章の後に次を追加します。

銅の箱を調べた結果

箱の下には湿った当番表が一枚挟まっており、裏には「鐘が鳴る前に北門へ」と書かれている。灯台守は紙に書かれた筆跡に見覚えがあるが、説明は会ってからに持ち越す。誰がこの言葉を残したのか、あなたにはまだわからない。

選べる行動：当番表の筆跡について尋ねる。銅の箱を持って北門へ向かう。

同時に、ステータスメッセージには「銅の箱の調査が完了しました。新しい結果を読めます」とだけ記します。操作の終了を伝え、当番表の内容を先回りして読み上げません。読むための入口には表にある名前を省略せずに使い、利用者が選んでから、新しく追加した見出しを起点に本文へ進みます。

待っている間に、利用者が灯台守の直前の言葉を読み返しているとします。結果が届いたからといって、突然北門へ向かう選択肢に移動させるべきではありません。元の操作の近くにとどまっている利用者は、そこから直接読むための入口を見つけることもできます。どちらの経路でも同じ本文にたどり着くため、通知用に短縮した物語を別途保存する必要はありません。

次の行動はこの部分の末尾に置き、結果を読み終えた後に順番に到達できるようにします。「操作領域に戻る」も用意する場合は、移動先をあらかじめ決め、漠然とページの先頭へ戻してはいけません。一連の確認では、送信、待機、通知の受信、結果への移動、次の行動の選択までを対象にします。「完了しました」が聞こえたことだけを確認して終わりにしません。

「現在位置を保ち、読むための入口を用意する」方式は、以前の物語を読み続ける可能性がある追記場面に適しています。ただし、すべてのページで唯一の方式にする必要はありません。操作名がもともと「次の章を開く」であれば、新しい章に入る意図はすでに示されています。章を切り替えた後の読み始める位置は、別途設計できます。このルールを通常の「灯台守に尋ねる」にそのまま当てはめてはいけません。

利用者が自ら有効にする「結果が届いたら追加内容を読み上げる」モードも設計できます。その場合は、読み上げる範囲が今回の結果だけであることを明示し、一時停止と読み上げ位置を移動し直す手段を用意します。これは追加の読み方の選択肢です。ステータス通知があるというだけで、利用者が段落全体の自動読み上げに同意したと解釈してはいけません。

「銅の箱をしまいました」のような短い結果なら、通知に行動の結論を含めてもかまいません。ただし、本文か後から確認できる記録にも、その変化を残す必要があります。追加内容に謎や会話、次の判断に必要な情報が含まれるなら、通知は短く保ち、説明は本文に任せるのがよいでしょう。判断基準は、自分のペースで読む必要があるかどうかです。文字数だけで機械的に区切ってはいけません。

行動によって既存の記録だけが変わり、物語が追加されない場合は「銅の箱の記録を更新しました」と伝え、更新箇所を示します。「新しい結果」の定型文を使い続けると、利用者は存在しない追加文を探すことになります。

第一の失敗は、ページ内の物語全体を更新通知の読み上げ元にすることです。箱の底について一文増えただけなのに、灯台の導入まで読み直してしまいます。確認時には、実際に通知された文章の範囲を記録し、今回の操作の状態だけを伝えるよう求めます。物語全体へのアクセスは、引き続き本文への入口が担います。

第二の失敗は、本文に読める結果がないのに「完了しました」と通知することです。結果の準備ができ、入口が使えることを完了通知の条件にします。リクエストが失敗した場合は、今回は物語が追加されなかったと明示し、元の文章を残して再試行の入口を用意します。再試行でも、同じ結果を重複して追記してはいけません。

第三の失敗は、結果が表示された途端にフォーカスを動かし、同時に要約も読み上げることです。利用者は元の位置を失い、さらに似た内容を続けて二度聞くかもしれません。役割表に沿って通知と移動を別々に確認します。通知は状態の変化に伴い、移動は明示的な読む操作によって起こるものです。

第四の失敗は、連続した行動で起こります。「更新しました」だけでは、どの操作に対応するのかわかりません。結果には識別しやすい行動名を使えます。同じ行動を複数回送信できるなら、各回の結果を区別し、未読の結果も明示する必要があります。見た目で一番新しい項目を示すだけで、この対応関係の説明を済ませてはいけません。

最後に、これらの場面を実際の対象端末でスクリーンリーダーを使って確認します。読み上げの重複、位置の喪失、入口から追加部分の先頭に到達できるか、通知を聞き逃しても本文を見つけ直せるかを記録します。ここで示したのは確認用の手順であり、合格済みのテスト報告ではありません。ポップアップ、ページ全体の移動、制限時間付きの選択肢には別の操作ルールが必要です。既存の内容に結果を追記するためのこのチェックリストで、すべての状況を扱うことはできません。