【ITニュース解説】NBA Live Score Accessibility: Building Live NBA Scores That Screen Readers Can Follow

リアルタイムに更新される情報をWebページで提供する際、視覚に頼るユーザーだけでなく、スクリーンリーダーを利用するユーザーにも同じ情報が正しく伝わるようにすることは、システムエンジニアにとって非常に重要な課題となる。特に、バスケットボールの試合のライブスコアのように、状況が目まぐるしく変化するコンテンツでは、その難易度が一層高まる。この課題は、単に「表示されるテキストを読み上げれば良い」という単純なものではなく、情報が「ノイズ」にならないように、意味のある情報だけを的確に伝える高度な設計が求められるのだ。

通常のライブスコアボードは、得点、試合時間、ピリオド、試合状況（開始前、試合中、ハーフタイム、延長戦、終了など）が常に変化している。視覚的にこれらの変化を捉えることは容易だが、スクリーンリーダーを利用するユーザーが同じ情報を得るためには、単に画面上の数字が変わっただけでは不十分で、その変化をプログラムが理解できる形で明示的に伝える必要がある。この目的は、Webページ上のあらゆる変更を機械的に読み上げることではなく、どの変化がユーザーにとって本当に意味があるのかを判断し、それを安定した構造で、かつユーザーの作業を邪魔しない方法で通知することにある。アクセシビリティは、情報が正しく伝わるための基本的な設計の一部と捉えるべきで、後付けの「おまけ」ではない。

この問題の解決策の一つが「ARIAライブリージョン」の活用だ。これは、Webページのコンテンツがユーザーのフォーカスが移動することなく動的に変化する場合に、その更新内容を支援技術（スクリーンリーダーなど）に自動的に通知させるためのWAI-ARIAの仕組みである。具体的には、aria-liveという属性を使うことで、更新の重要度に応じて通知の仕方を制御できる。スポーツのスコア変更のような場合、通常は「polite（控えめな）」通知が適している。例えば、得点が入ったとしても、ユーザーが現在聞いている内容を途中で強制的に中断するほど緊急性が高いことは稀だからだ。実践的な方法としては、通常の視覚的なスコアボードとは別に、スクリーンリーダー向けの短いステータス表示領域を設ける。スコアが変わったら、視覚的な数字を更新するだけでなく、このステータス領域に「訪問チーム98点、ホームチーム97点」のようなコンパクトな文章を書き込む。role=statusという属性を持つ要素は、暗黙的に「polite」なライブリージョンとして機能し、ユーザーのフォーカスを奪うことなくアプリケーションのステータスメッセージを通知するために使われる。

しかし、全ての動的な要素を読み上げれば良いというわけではない。特に試合時間はその典型的な例だ。試合の残り時間が「2分15秒、2分14秒、2分13秒…」と毎秒読み上げられたら、Webページは使い物にならない「音声の洪水」と化してしまうだろう。スクリーンリーダーのユーザーは、本当に知りたい情報（得点、クォーター終了、ハーフタイム、延長戦、最終結果など、意味のある節目）が大量の時計の読み上げの中に埋もれてしまう。時計は読み取り可能で操作可能な状態に保ちつつ、意味のある変化があった場合にのみ通知を予約する、というのがより良い設計だ。アクセシビリティとは、通知の頻度を最大化することではなく、情報の品質を高めることなのだ。

さらに、スコアの更新はしばしば、アウェイチームの得点、ホームチームの得点、ピリオド、時計、試合状況など、複数の情報が同時に変更される。これらの情報がバラバラに通知されると、「100点」「97点」「第4クォーター」のように断片的に聞こえ、どの数字がどのチームの得点なのか、どの情報が何を示しているのかが分からなくなる恐れがある。これを解決するのがaria-atomicという属性だ。この属性を使うと、ある領域の一部が変更された場合でも、支援技術に対してその領域全体をまとめて提示するように指示できる。バスケットボールのライブスコアページであれば、「訪問チーム100点、ホームチーム97点。第4クォーター、残り1分48秒」のように、チーム名を明示し、完全な文章として一括で更新を伝えるのが効果的だ。また、複数のUIフィールドがまとめて更新される際には、aria-busy属性を使って、更新が完了するまで支援技術からの通知を一時的に抑制し、未完成な状態の情報をユーザーに伝えないようにすることもできる。

Webページの表示内容とスクリーンリーダーが読み上げる内容との間にズレが生じることは、よくあるバグの一つだ。例えば、表示されているスコアは最新の情報源から更新される一方で、ライブリージョンのテキストは別の情報源から生成されている場合、ユーザーは画面上のスコアと一致しない情報を聞かされることになる。このような不整合を避けるためには、視覚的なスコアボードをレンダリングするのと同じ「正規化されたゲームオブジェクト」（つまり、信頼できる唯一の情報源）から、スクリーンリーダー向けの通知テキストも生成すべきだ。一つのイベント発生に対して、アプリケーションの状態は一度だけ更新され、その統一された状態から、視覚的な表示と音声による通知の両方が生成されるように設計する。試合中にスコアの修正が入る可能性も考慮する必要がある。修正によって表示スコアが変わった場合、スクリーンリーダーのステータスもそれに合わせて更新するべきであり、一度通知した古いメッセージをそのまま残してはいけない。

具体的な実装パターンは非常にシンプルだ。視覚的なスコアは通常のHTML要素で構成し、別途用意したステータス領域には、意味のあるイベントが発生したときにだけ短い要約テキストを書き込む。例えば、HTMLでスコアやピリオド、時計を表示する要素を用意し、スコアの変更イベントがアプリケーションの状態に反映された後、JavaScriptを使って、ステータス用の要素のtextContentに「訪問チーム${away}点、ホームチーム${home}点。${periodLabel}、${clockLabel}」といった形で、一貫性のある文章を一度だけセットする。重要なのは、JavaScriptの具体的な構文ではなく、「アプリケーションが現在のゲーム状態を正確に把握した上で、ユーザーにとって意味があり、矛盾のない状態をイベント駆動で通知する」という方針である。

最後に、複数の試合が同時に進行しているような「今日のNBAスコア」ページでは、全ての試合カードを常時アクティブなライブリージョンにすると、複数の試合が立て続けに更新された場合に、大量の通知で「音声の洪水」が発生してしまう可能性がある。この問題を避けるためには、ユーザーが通知をコントロールできる仕組みを提供することが重要だ。例えば、グローバルなスコアページでは、ほとんどの試合カードは静かに保ち、ユーザーが特定の試合を選択した場合にのみ、その試合の詳細なスコア通知をアクティブにする、といった設計が考えられる。あるいは、試合の開始、終了、ハーフタイムといった状態遷移のみをグローバルに通知し、詳細な得点情報はユーザーが特定の試合のページに移動した場合に限定する、という方法もある。

これらのアクセシビリティ対策は、静的なWebページのチェックだけでは不十分だ。実際のリアルタイムの動作を、スクリーンリーダーやキーボード操作などのアシスティブテクノロジーを使って徹底的にテストする必要がある。最初の読み込みから、最初の得点変化、立て続けの得点、クォーターの切り替わり、ハーフタイム、延長戦、最終結果、通信の再接続、そしてスコアの訂正といった、あらゆるシナリオを想定してテストする。このとき、情報が繰り返し読み上げられたり、文脈が失われたりしていないか、ユーザーのフォーカスが意図せず移動していないか、時計が過剰に読み上げられていないか、チーム名がスコアと結びついて明確に伝わっているか、そして色だけでなくテキストで状態が表現されているかなどを確認する。単にWebページのソースコードやDOMインスペクターを見るだけでなく、実際にスクリーンリーダーを使い、キーボード操作で全ての機能を試すことが不可欠だ。

高速に更新されるライブスコアのフィードは、ユーザーがその情報を理解できて初めて価値を持つ。アクセシビリティへの対応は、製品の動作を遅くするものではなく、むしろアプリケーションの状態モデルをより明確にする。視覚的に古くなったスコアを表示しないために使われる「正規化されたゲームオブジェクト」は、同時にスクリーンリーダーに読み上げられる文章をより良くし、視覚的な表示をより洗練させ、最終的な状態の挙動もより信頼できるものにするのだ。アクセシビリティは、製品の基本的な設計の一部であり、ゲームの状態を正しく、あらゆるユーザーに伝えるためのもう一つの「正しい見方」なのである。