`） | `role="status"`（TypingIndicator） | なし | 完了を通知する仕組みの追加 |
| Vercel AI Elements | `role="log"` | 回答本文が暗黙に通知される | なし | 履歴の `aria-live="off"` 化と状態通知の分離 |
| CopilotKit | なし（`
`） | なし | なし | 開始・完了の通知をすべて追加 |
| shadcn/ui Chat Components | `role="log"` + `aria-relevant="additions"` | `aria-busy="true"` で保留 | 完了後に本文をまとめて読み上げ | 状態通知への置き換えと支援技術ごとの検証 |
このように、ライブラリごとに対応はあまり統一されていません。共通して言えるのは、どのライブラリを選んでも、回答の開始と完了を短いテキストで通知する仕組みはアプリケーション側で用意する必要があるということです。実際にスクリーンリーダーで検証することも重要です。支援技術ごとに挙動が異なる場合があるためです。
## トークンごとに読み上げられた実際の Issue
ストリーミング回答をライブリージョン内で更新した結果、実際に問題となった事例があります。OpenClaw では、`role="log"` と `aria-live="polite"` を持つチャット履歴の中で回答をストリーミングしていました。その結果、NVDA と Firefox の組み合わせで、[回答がトークンやチャンクごとに読み上げられる Issue](https://github.com/openclaw/openclaw/issues/65538)が報告されています。読み上げを停止しても次の更新で再開され、回答中は UI を使用することが難しい状態でした。
この Issue では、生成中だけ `aria-live="off"` へ切り替える方法や、`aria-busy` で更新を保留する方法が提案されました。しかし、実際の支援技術による検証が不足していたことや、スクリーンリーダー間の互換性が不明なことから、提案された PR はそのままでは採用されませんでした。
現在の OpenClaw は、履歴を [`role="log" aria-live="off"`](https://github.com/openclaw/openclaw/blob/c7b7fe4c328b/ui/src/pages/chat/components/chat-thread.ts#L1927) とし、別の視覚的に隠された [`role="status" aria-live="polite" aria-atomic="true"`](https://github.com/openclaw/openclaw/blob/c7b7fe4c328b/ui/src/pages/chat/components/chat-thread.ts#L1962) から完成した回答について通知する構成です。この構成では、回答本文自体はスクリーンリーダーへ通知されず、「回答が完了しました」のような短いテキストだけが通知されます。
この事例からも、ストリーミングされる本文と、自動的に読み上げる内容を分けて設計することの重要性が分かります。
## アクセシビリティを考慮したチャット UI の実装例
ここまで調査した内容を踏まえて、アクセシビリティ上、チャット UI に必要な要件を整理しましょう。主に以下の 3 点が重要です。
- 回答本文はスクリーンリーダーへ自動通知されない
- 回答の開始・完了・停止・エラーはスクリーンリーダーへ通知される
- 視覚的な表現に頼らず、メッセージの送信者がスクリーンリーダーからも分かるようにする
これらの要件を満たしたサンプルのチャット UI を実装してみましょう。まず、チャット履歴のコンテナには `role="log"` を指定したうえで、`aria-live="off"` を指定します。
```html
```
`aria-live="off"` を指定すると `role="log"` の暗黙のライブリージョンが無効になるため、ストリーミングされる回答本文が自動で読み上げられることはなくなります。
それなら `role="log"` を指定する意味はないのではという疑問が浮かぶでしょう。しかし `aria-live` が無効になっても、ロールとアクセシブルネームはアクセシビリティツリーに残ります。実際に Chrome のアクセシビリティツリーを確認すると、`aria-live="off"` を指定した状態でも「チャット履歴」という名前を持つ `log` として公開されていました。
つまり、自動通知を止めることと、その領域が何であるかを表すことは別の話です。`role="log"` は、この領域が「古い情報が消えず、新しい情報が順に追加されていく履歴である」という意味を支援技術へ伝えるために残しています。
`tabindex="0"` を指定しているのは、履歴の領域がスクロール可能だからです。スクロールできる領域にフォーカスを置けないと、マウスを使わないキーボードユーザーが過去のメッセージまでスクロールできません。`aria-label` を指定してあるため、フォーカスしたときに「チャット履歴」と読み上げられます。
ただし、これだけではスクリーンリーダーを利用するユーザーが回答の開始や完了に気づけません。
そこで、履歴とは別に空の `role="status"` を用意します。回答の開始・完了・停止・エラーのタイミングで、ここのテキストを更新することで、スクリーンリーダーへ通知します。`role="status"` を持つ要素を動的に DOM へ挿入した場合、その内容は通知されないことがあるため、最初から DOM に配置しておく必要があります。
```html
```
`role="status"` は暗黙に `aria-live="polite"` と `aria-atomic="true"` を持つため、属性を省略しても同じ意味になりますが、ここではわかりやすさのために明示しています。
このコンテンツは画面上には表示せず、スクリーンリーダーからのみ読み上げられるようにします。先述のとおり `display: none` や `hidden` はアクセシビリティツリーからも削除されてしまうため、ここでは `.sr-only` クラスを定義して視覚的に非表示にします。
```css
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
```
回答のライフサイクルに合わせて、`status` のテキストだけを更新します。
```javascript
function announce(message) {
const status = document.querySelector("#chat-status");
status.textContent = "";
setTimeout(() => {
status.textContent = message;
}, 100);
}
announce("回答を生成しています");
// ストリーミング中は回答本文だけを更新する
announce("回答が完了しました");
```
`textContent` をいったん空にしてから、`setTimeout` で少し遅らせて設定している点に注意してください。スクリーンリーダーはライブリージョンの変更を検出して読み上げるため、直前とまったく同じ文言を代入しても変更とみなされず、読み上げられないことがあります。一度空文字にしてから設定し直すことで、同じ文言を再通知する場合に、変更として検出されやすくするための実装上の工夫です。ただし、通知結果はブラウザと支援技術の組み合わせに依存します。
同じ `status` から、停止とエラーも `polite` に通知します。
```javascript
announce("回答の生成を停止しました");
announce("回答を生成できませんでした。もう一度お試しください");
```
生成エラーは通常、現在の操作へ即座に割り込む必要がある緊急事態ではないため、`role="alert"` や `aria-live="assertive"` は使用していません。
### メッセージの送信者を見た目だけで表現しない
チャット UI は、ユーザーのメッセージを右側、AI の回答を左側へ配置したり、吹き出しの色を変えたりして送信者を表現します。しかし、位置や色の違いだけではスクリーンリーダーへ送信者が伝わりません。
サンプルでは、各メッセージを `
` とし、`sr-only` の見出しで送信者を示しています。
```html
AI の回答
回答本文
```
これにより履歴を後から読み進めたときにも、誰の発言なのかを確認できます。
### 送信後も入力欄にフォーカスを残す
回答が始まったときや完了したときに、回答へ強制的にフォーカスを移動してはいけません。ユーザーが入力中の内容や、現在読んでいる場所を失う可能性があるためです。[`status` ロールの仕様](https://www.w3.org/TR/wai-aria-1.2/#status)でも、状態が変化したという理由で `status` へフォーカスを移動しないよう求めています。
サンプルでは、送信後もフォーカスを入力欄に残します。生成中に表示される「停止」ボタンは通常の `