メッセージを読み上げないチャットウィジェット

パネルを開くとフォーカスがメッセージ欄に移り、ラベルの「メッセージ」だけが読まれるため、あいさつは読まれません。会話はただの div なので、返信を追加しても変わるのは画面だけです。パネルのほかの部分は動きます。起動ボタンと閉じるボタンは名前のあるボタンで、Escapeでもパネルが閉じ、フォーカスはパネルに入り、閉じると起動ボタンに戻ります。

パネルを開くと、メッセージ欄の aria-describedby にすべてのメッセージのidが入るため、メッセージ欄はそれまでの会話と一緒に「メッセージ、編集テキスト。Birchwood：こんにちは。ご注文についてお気軽にお尋ねください。」と読まれます。後でもう一度開くと、最初からのすべてのメッセージが読まれます。idで指すのはログではなく各メッセージです。ログを指すと、説明が中身ではなく、ログの名前の「メッセージ」になることがあるからです。説明はフォーカスが最初にメッセージ欄を離れたときに外れるため、「送信」へ移って戻っても、会話がもう一度読まれることはありません。

role="log" は、会話をライブリージョンにします。初期値がpoliteなので、スクリーンリーダーは読み上げ中の内容を終えてから、末尾に追加された各メッセージを読み、フォーカスは動きません。ログは返信が届く前からページのHTMLにあり、そのためにブラウザーは各返信を変化として捉えられます。スクリーンリーダーが何の領域かを伝えられるよう、ログには名前を付けます。ここでは「メッセージ」です。各メッセージには送り手が視覚的に隠したテキストで入っているため、返信は「Birchwood：はい。発送前であれば『ご注文履歴』から変更できます。」と読まれます。

どちらも、パネルを開いたときに会話を読み、フォーカスを動かさずにすべての返信を伝えます。ログはコードが少なく、W3Cがチャットの履歴について示している方法です。会話が名前のある一つの領域になり、二つの内容をそろえておく必要もありません。ただし、追加されたものはすべて読むため、送った瞬間の利用者自身のメッセージも読まれます。送信の確認として役立つと感じる人もいれば、うるさく感じる人もいます。会話が末尾にメッセージを足す以外のことをする場合は、別の読み上げ領域を選んでください。さかのぼってスクロールすると過去のメッセージを先頭に読み込む、メッセージのたびに一覧全体を描き直す、入力中の表示や既読の表示を一覧の中に入れる、といった場合です。ログはそれらもすべて読みます。別の領域は書き込んだ内容だけを伝えますが、その代わり、各返信の二つ目の写しを一つ目とそろえて管理する必要があります。

多くのチャットウィジェットは、サービス提供元のスクリプトです。起動ボタンもパネルも、提供元のドメインから配信されるフレームの中に描かれることが多く、その場合は自社のCSSやスクリプトから中には一切手が届きません。できることは次のとおりです。

• 導入する前に、「修正の確認」の手順でウィジェットを試す。提供元のデモページか、自社のテスト用ページで行います。
• ウィジェットの設定を確認する。数秒後に自動で開くパネルや、ページの上に飛び出すあいさつの吹き出しは無効にし、設定で選べるなら、起動ボタンにはアイコンだけでなく文字のラベルを表示します。
• 提供元にアクセシビリティ適合報告書（ACR）を求める。そのうえで、パネルを開いたときにあいさつやそれまでのメッセージが読まれるか、新しいメッセージがログかライブリージョンに入るか、起動ボタンと閉じる操作が名前のあるボタンか、Escapeでパネルが閉じて起動ボタンにフォーカスが戻るか、どのスクリーンリーダーで試したかを、具体的に尋ねます。
• 提供元のスクリプトが新着メッセージのイベントを提供している場合は、二つ目の修正のように、ページ側に用意した自前の読み上げ領域へ各返信を書き込めます。その前に、ウィジェット自身が読み上げていないかを確認してください。読み上げていれば、返信が2回ずつ聞こえます。
• うまくいかない点を、再現手順を添えて提供元に報告する。直るまでは、アクセシビリティ方針に既知の問題として記載し、チャットの横に、メールアドレスなど別の問い合わせ方法を示します。

提供元のスクリプトは、自社のリリースと関係なく変わります。提供元の更新やウィジェットの設定の変更のたびに、確認を繰り返してください。

領域を先に置く。 ログや読み上げ領域は、最初の返信より前にページにある必要があります。コンポーネントのフレームワークでは、パネルと一緒に描画し、最初のメッセージと一緒に現れる条件の中には決して入れません。メッセージと一緒に追加された領域は読み上げられません。仕組みは画面に出ても読み上げられないステータスメッセージで説明しています。領域を含むパネルの一部に aria-hidden="true" を付けた場合も同じです。

後から届くあいさつ。 多くのウィジェットは、パネルを開くと入力中の表示を出し、少し後にあいさつを追加します。ログなら、そのあいさつは返信と同じように読み上げられます。別の読み上げ領域を使う場合は、あいさつもその領域に書き込みます。どちらの場合も、そのあいさつはまだメッセージ欄の説明に入っていないため、2回ではなく1回だけ読まれます。

長い会話。 履歴の長いパネルを開くと、メッセージ欄と一緒にそのすべてが読まれます。スクリーンリーダーの利用者はCtrlキーで読み上げを止め、読みたいところから読み進められます。会話が長くなりがちなら、メッセージ欄の説明には、前回パネルを開いてからのメッセージか、最後の数件だけを入れます。

誰の発言かを伝える。 左右に分かれた2色の吹き出しは、誰が書いたかを晴眼の利用者に伝えますが、ほかには何も伝えません。スニペットのように、各メッセージに送り手を視覚的に隠したテキストで入れるか、吹き出しの上に名前を表示します。

雑音を入れない。 入力中の表示を数秒ごとにログへ書き込むと、数秒ごとに読まれます。ログの外に表示するか、1回だけ伝えます。返信に aria-live="assertive" や role="alert" は使いません。利用者が読んでいる内容に割り込むからです。

閉じている間に届いた返信。 パネルを閉じた後に届いた返信は、隠れた領域に入るため読み上げられません。代わりに起動ボタンで伝えます。ボタンの文字を「チャットで相談、新着メッセージ1件」のように変えます。返信を見せるために、パネルを自動で開くことはしません。

新しいメッセージにフォーカスを移さない。 そうすれば読まれはしますが、利用者が次の質問を入力している途中で、カーソルがメッセージ欄から外れてしまいます。

モーダルにするかどうか。 パソコンではパネルがページを操作不能にしないため、利用者はチャットしながらページを読めます。Tabでパネルを閉じずに外へ出てもかまいません。ただし、フォーカスが離れたときに閉じることもしません。それで何が起きるかはTabで閉じてフォーカスを見失う検索パネルを参照してください。パネルが画面全体を覆うことが多いスマートフォンでは、モーダルとして振る舞います。背後にフォーカスが残るモーダルのように、showModal() でダイアログとして開きます。

閉じるボタン。 ×は名前のある本物の button にします。クリック処理を付けた span で描くと、Tabでは届かず、パネルが起動ボタンの代わりに開くため、キーボードの利用者にはチャットを閉じる方法がなくなります。Tabキーで到達できないdivのボタンと同じ問題です。

起動ボタン。 div で描いた起動ボタンも同じように問題になり、アイコンだけの起動ボタンには、名前がないアイコンだけのボタンのように名前が必要です。隅に浮いている間は、フォーカス中の操作要素を覆うこともあります。フォーカス中のボタンを一部隠すチャットボタンを参照してください。拡大表示では、起動ボタンや開いたパネルが、ほかの浮いた要素とともに画面のずっと大きな部分を占めます。拡大するとページを覆う、浮いた購入バーを参照してください。パネル自体はページの最後、フッターの後に追加されることがよくあります。ここでの修正は開いたときにフォーカスをパネルへ移しますが、パネルを起動ボタンの次に置く方法はフォーカス順の最後に回る、フローティングボタンとパネルで扱っています。