チャットウィジェットのアクセシビリティ｜公開前テスト項目

サイト右下のチャットボタンは見えていても、Tabキーでは到達できないことがあります。開いた後にフォーカスがページの背後へ抜けたり、AIの回答が表示されてもスクリーンリーダーでは何も通知されなかったりすることもあります。チャットウィジェットは小さな部品に見えますが、複数の操作と状態変化が連続するため、公開前に確認すべき項目は少なくありません。 チャットボットのウィジェットのアクセシビリティは、色やラベルを一つ直せば完了するものではありません。**起動する、開く、質問する、送信状態を知る、新着回答を読む、エラーから復帰する、閉じる**までを一連の操作として試す必要があります。 ## チャットは開閉から終了まで一つの操作として試す テストは画面が静止した状態だけでなく、実際の利用順に沿って行います。ページを開き、キーボードだけで起動ボタンへ移動し、チャットを開きます。その後、質問を入力して送信し、回答を待ち、履歴を読み、チャットを閉じて元のページへ戻ります。 各段階で、視覚表示、キーボード操作、スクリーンリーダー、拡大表示の四つの観点を確認します。すべての支援技術と端末を網羅できない場合でも、想定する利用者と実際の利用状況に合わせて代表環境を選び、確認結果と未確認範囲を記録します。 たとえば、起動ボタンが見えることだけでは合格にしません。Tabキーで到達できるか、Enterキーで開けるか、開いたことが読み上げで分かるか、200%拡大時にもボタンが隠れないかを同じ操作の中で確認します。 自動検査への合格は、手動検査を始めるための材料です。DOM上にラベルが存在していても、読み上げ名から目的を判断できない、フォーカスが予想外の場所へ移る、新着回答が何度も読み上げられるといった問題は、自動検査だけでは判断できません。 ## 起動ボタンの名前と状態を伝える 起動ボタンには、見た目の吹き出しアイコンだけでなく、支援技術から目的を理解できる名前が必要です。読み上げ結果が単に「ボタン」では、何を起動する操作なのか分かりません。「チャットを開く」のように、操作の結果が判断できる名前になっているかを確認します。 開いているときと閉じているときの状態も区別します。ボタンを押すと何が開くのか、現在チャットが開いているのかを確認し、同じボタンで閉じる設計なら、表示名、読み上げ名、実際の動作が矛盾していないかを試します。 確認時は、ページ右下の起動ボタンへTabキーで移動し、読み上げられる名前と状態を記録します。Enterキーで開いた後は、見た目だけでなく、支援技術へ伝わる状態も変化したかを確認します。再度操作して閉じる場合も同じ手順で検証します。 起動ボタンがページ末尾に挿入される場合は、Tabキーで到達するまでに過剰な操作が必要にならないかも確認します。一方で、フォーカス順の先頭へ置けばよいとは限りません。ページの主要な導線とチャットの優先度を踏まえ、利用者が位置を予測できる順序にします。 ## フォーカスを予測可能に移す チャットを開いた後、キーボードフォーカスをどこへ移すのかを設計時に決めます。入力欄、チャットの見出し、閉じるボタンのどれが適切かは、チャットの構造や事前説明の有無によって異なります。重要なのは、利用者が開いた直後の現在位置を理解できることです。 背後のページを操作させないモーダル設計を採用している場合は、その設計上の受入条件として、TabキーやShift+Tabキーを繰り返してもフォーカスがチャット外へ抜けないことを確認します。Escapeキーまたは閉じるボタンで終了でき、終了後はページ先頭ではなく起動ボタンへ戻ることも試します。 非モーダルなら、ページとチャットの間を移動する順序が自然かを確認します。チャットを開いたことでページ内の既存要素へ到達できなくなったり、逆にチャットへ戻れなくなったりしてはいけません。開始前、開いた直後、チャット内を一巡した後、閉じた直後のフォーカス位置をそれぞれ記録すると、移動の問題を再現しやすくなります。 見た目上の位置だけでなく、可視フォーカスも確認します。背景色やサイトテーマが変わってもフォーカス枠が見え、閉じる、添付、送信など隣接する操作を区別できるかを試します。埋め込み先のCSSを含むページ側との競合は、後述する専用節で条件別に確認します。 ## 入力と送信をキーボードだけで行う 入力欄には目的が分かるラベルを用意します。プレースホルダーだけに説明を任せると、文字を入力した後に説明が見えなくなります。文字数制限や入力してはいけない情報がある場合は、入力を始める前に確認できる形で伝えます。 Enterキーが送信、Shift+Enterキーが改行などの操作を採用する場合は、その操作方法を利用者が確認できるようにします。説明どおりに動くかを、短文だけでなく複数行の文章でも試します。貼り付けた文章に改行が含まれる場合や、音声入力ソフトを利用する場合も、意図しない送信が起きないかを確認します。 日本語入力では、文字の変換確定にもEnterキーを使います。未確定文字を含む状態でEnterキーを押し、変換の確定だけが行われるか、質問が同時に送信されないかを検証します。変換確定後にもう一度Enterキーを押した場合は、設計どおりに送信されることを確認します。 送信ボタンが無効な場合は、その理由を色だけで示しません。入力が空、送信処理中、上限に達しているなど、操作できない理由と次に必要な行動が分かるかを確認します。連続してキーを押した場合にも二重送信されず、送信済みか失敗したかを利用者が判断できる状態にします。 ## 新着回答と状態変化を読み上げる AIの回答は、通常のページ読み込み後に追加されます。画面上では吹き出しが増えても、支援技術へ通知されなければ、利用者は回答が届いたことを把握できません。送信中、回答開始、回答完了、通信失敗のうち、操作を続けるために必要な状態を選んで伝えます。 通知を増やしすぎると、生成途中の断片や入力中の表示が繰り返し読み上げられ、かえって操作を妨げます。会話履歴全体ではなく、新しく確定した回答と重要な状態だけが伝わるかを、実際のスクリーンリーダーで確認します。 確認時は、質問を送った後もフォーカスを入力欄付近に残し、回答の到着を把握できるかを試します。回答が届くたびにフォーカスが強制的に移ると、次の質問の入力やページ内の確認を妨げます。状態の通知とフォーカス移動は分けて判断します。 回答そのもののリンク、リスト、長文、生成途中の読み上げは、後述する「回答コンテンツ自体も読みやすくする」でまとめて確認します。この節では、新着回答の到着と状態変化が過不足なく通知されるかを判定します。 ## エラーを色だけで伝えない 通信失敗、入力超過、利用上限、ファイル形式エラーが起きたとき、赤色だけでは内容が伝わりません。エラーの内容、対象となる入力や操作、修正方法、再試行の可否を文章で示します。 エラー文を入力欄の近くに表示するだけでなく、支援技術を利用している人がエラーの発生を知り、対象箇所を確認できるかを試します。エラー通知を聞いた後に、修正対象へキーボードで移動できることも必要です。 通信を意図的に失敗させ、入力内容が保持されるか、同じ内容を再試行できるか、再試行によって二重送信にならないかを確認します。再試行できない場合は、次に取れる操作や代替窓口が明確かを確認します。 システム障害時には、チャットの再試行だけを求め続けず、フォームや電話など承認済みの代替窓口を示します。代替窓口そのものがキーボードとスクリーンリーダーで利用できることも必要です。また、エラー文に内部情報や認証情報が表示されていないかも確認します。 ## 拡大とモバイルキーボードを確認する この記事では、200%程度の拡大を公開前の受入条件として設定し、起動ボタン、見出し、履歴、入力欄、送信、閉じる操作を利用できるか確認します。固定幅のパネルが画面外へはみ出し、横方向へ移動しなければ送信や終了ができない状態は、この受入条件に対する不合格として記録します。 拡大後は、単に各要素が表示されているかを見るだけでなく、操作順に確認します。起動して質問を入力し、長い回答を読み、チャットを閉じるまでを通して実行します。履歴だけがスクロールし、閉じるボタンや入力欄へ戻れない状態がないかも確認します。 スマートフォンでは、ソフトウェアキーボードが画面の大部分を占めます。キーボードを表示したまま、入力欄が背後へ隠れないか、送信ボタンへ到達できるか、チャットを閉じられるかを実機で試します。縦向きと横向きを切り替えた後も、入力内容と現在位置を保って操作を続けられるか確認します。 テスト用の回答には、長い段落、長いURL、リンク、リスト、表、連続した改行を含めます。短い回答だけでは、履歴領域が伸びたときに閉じるボタンが消える問題や、フォーカス位置がずれる問題を見つけにくいためです。 ## 自動検査と手動検査を分ける 自動検査は、名前のないボタン、重複ID、一部の色コントラスト、構造上の問題を早い段階で見つけるために使います。ただし、フォーカス順が利用者の操作として自然か、新着回答の通知量が適切か、閉じた後に元の場所へ戻れるかまでは判断できません。 手動検査では、まずマウスを使わずに起動から終了までの全操作を行い、可視フォーカスと移動順を記録します。次に代表的なスクリーンリーダーで、起動ボタン、見出し、入力欄、送信状態、回答、エラー、閉じる操作を確認します。拡大表示とモバイル実機の結果は、デスクトップ環境とは別のテスト行に残します。 日本語変換中のEnterキー、ソフトウェアキーボード表示中の送信、回答到着時の通知量などは、実際の操作を通さなければ判定できません。自動検査で問題が検出されなかった場合も、これらの手動検査を省略しないようにします。 ブラウザ、OS、支援技術、それぞれのバージョン、確認日時、実際の結果、再現手順、証拠を残します。「問題なし」だけでは、修正後や更新後に同じ条件で再試験できません。画面録画、スクリーンショット、読み上げ内容の記録など、問題を再現できる証拠をテスト結果にひも付けます。 ## 公開前テスト表を作る |場面|操作|期待結果| |---|---|---| |起動|Tabでボタンへ移動しEnter|名前と状態が伝わりチャットが開く| |開始|開いた直後を確認|現在位置が分かり予測した要素へ移る| |入力|日本語変換、改行、送信|誤送信せず操作説明と一致する| |待機|回答を待つ|必要な状態だけが通知される| |回答|リンク・リストを読む|順序とリンク先が理解できる| |失敗|通信を失敗させる|エラーと回復方法が通知される| |拡大|画面を拡大する|操作が隠れず横移動を強制しない| |終了|Escapeまたは閉じる|起動元へフォーカスが戻る| 実際の受入表には、場面と操作、期待結果に加えて、開始状態、実際の結果、OS、ブラウザ、支援技術、各バージョン、証拠、再現手順、重要度、未確認事項を記録します。同じ操作でも環境によって結果が異なる場合は、一つの欄にまとめず環境ごとに行を分けます。 不合格時は、影響を受ける利用者、再現性、代替手段の有無を受入表へ記録します。公開可否は、後述する「テスト結果を公開判定へつなげる」の基準で判断します。 公開前テスト表を作成した後は、実際の設置条件も確認します。タグの設置やWebサイトへの組み込み手順は[Webサイト埋め込み・LINE連携の手順](/usage/integration-web-line)を参照してください。本記事で扱う操作や支援技術の確認に加えて、会話内容や回答品質を含む試験が必要な場合は、[チャットボットのテストケース](/usage/chatbot-prelaunch-test-cases)で担当範囲を切り分けられます。 対象端末、支援技術、合格条件、未確認範囲を整理したら、Socratesの導入時に必要な受入条件や実環境での確認方法を公式窓口へ相談してください。個別環境での結果は、埋め込み先のCSS、ブラウザ、設定などの条件によって変わるため、一部の確認だけでアクセシビリティへの適合を断定せず、実環境で判断する必要があります。 以降では、役割分担、回答コンテンツ、回帰テスト、公開判定、埋め込み先との干渉を順に整理します。よくある質問は、これらの判断基準を確認した後にまとめます。 ## 役割別に確認責任を分ける ウィジェット提供者、サイト実装担当、コンテンツ担当、受入担当では、確認できる範囲が異なります。提供者は部品の構造と操作仕様、実装担当は埋め込み先との競合、コンテンツ担当はラベルとエラー文、受入担当は実際の操作結果を確認します。 不具合票には「アクセシビリティ問題」とだけ書かず、開始状態、操作、期待結果、実際の結果、環境、影響を記録します。たとえば「Windowsの対象ブラウザでチャットを閉じると、フォーカスがページ先頭へ移り、起動元へ戻れない」と書けば、修正担当者が同じ条件を再現できます。 問題の担当先を決めるときは、ウィジェット単体でも起きるのか、特定の埋め込み先だけで起きるのかを切り分けます。ラベルやエラー文の設定で修正できるのか、サイト側のCSSやイベント処理が原因なのかも記録します。 外部ウィジェットでコードを直接修正できない場合は、提供者への照会、設定変更、代替リンクの設置、公開延期から対応を選びます。サイト側のCSSで無理に上書きすると、ウィジェット更新後に再発することがあります。責任範囲と正式な変更方法を確認してから修正します。 ## 回答コンテンツ自体も読みやすくする 操作できても、AIの回答が長い一段落になっていたり、曖昧なリンクや見出しのない列挙が続いたりすると、内容を把握しにくくなります。重要な結論を先に置き、手順は順序付きリスト、選択肢は短い項目に分けます。絵文字や記号だけで意味を表さないことも必要です。 リンクには行き先が分かる文言を付け、新しい画面へ移る場合の挙動を一貫させます。表を使う場合は、見出しと読み順を確認します。スマートフォンで横幅に収まらない場合は、各項目を縦に並べても関係を理解できるか検討します。 長い段落、長いURL、リンク、順序付きリスト、表を含む回答をテスト用に用意し、見出しと項目が意図した順序で読まれるかを確認します。リンクだけを一覧表示した場合にも、各リンクの行き先を区別できる名前になっているかを試します。 回答が生成される途中で内容が頻繁に書き換わる場合は、読み上げが混乱しないかを確認します。確定したまとまりごとに提示する、生成中であることだけを通知するなど、視覚表示と支援技術への通知を分けて設計します。 ## 回帰テストに残すケース - 起動ボタンをキーボードだけで開閉する - ページの前後要素からチャットへ移動し、元へ戻る - 日本語変換中にEnterを押し、意図しない送信が起きないことを確認する - 長文、改行、リンク、リストを含む回答を読む - 回答待機、完了、通信失敗の状態を把握する - エラー後に入力内容を失わず再試行する - 200%拡大と狭い画面で全操作へ到達する - モバイルキーボード表示中に入力、送信、終了を行う - 高コントラスト設定でも色だけに依存せず状態を判別する - ウィジェット更新後に同じケースを再実行する 回帰ケースには重要度を付け、前回の公開判定で使用した重要度と対応状況を引き継ぎます。公開可否は、再試験の結果を「テスト結果を公開判定へつなげる」の基準へ再度当てはめて判断します。 再試験の起点には、ウィジェット自体の更新だけでなく、サイトテーマ、Cookie同意管理、タグ管理、ページ側のキーボード処理の変更も含めます。変更箇所がチャットから離れて見えても、重なりやフォーカス順へ影響する場合があります。 各回帰ケースには、実施対象の環境と期待結果を残します。前回の合格日だけでなく、変更内容、実施した環境、未実施の環境を記録すれば、確認範囲を誤って広く解釈することを防げます。 ## テスト結果を公開判定へつなげる テスト結果は不具合の件数だけでなく、誰がどの操作を完了できないかで評価します。一件でも主要操作を妨げる問題があれば、自動検査で検出された問題が少なくても、公開を保留する判断が必要です。 公開停止、条件付き公開、公開可能の判断基準は、試験前に決めます。起動できない、質問を送信できない、回答の到着を把握できない、エラーから復帰できない、チャットを閉じられない問題は公開停止の候補です。 条件付き公開は、問題が限定された環境でのみ再現し、影響範囲と再現手順を特定でき、同じ問い合わせ目的を完了できる代替手段があり、修正担当と再試験の予定が決まっている場合に検討します。未確認環境は合格扱いにせず、公開条件とともに記録します。 公開可能とするのは、対象に選んだ各環境で主要操作を完了でき、重大な未解決問題がなく、軽微な問題についても影響、担当、対応予定を記録できた場合です。自動検査の合格だけでは公開可能と判断しません。 修正できない問題には、チャットと同じ問い合わせ目的を完了できるフォームや連絡先を用意します。ただし、代替手段があることを理由に、修正可能な問題を放置しません。代替導線そのものもキーボードとスクリーンリーダーで操作できるかを確認します。 公開後の再試験は「回帰テストに残すケース」に従い、更新内容、実施環境、結果、未実施範囲を記録します。利用者からの連絡を受ける窓口と、再現情報を開発側へ渡す手順も決め、報告された問題を次回の回帰ケースへ反映します。 ## 埋め込み先ページとの干渉を確認する ウィジェット単体では操作できても、実際のページへ埋め込むと、固定ヘッダー、Cookie同意バナー、別の問い合わせボタンと重なることがあります。画面幅、拡大率、言語、ログイン状態を変え、起動ボタンや入力欄、送信ボタンが隠れないかを確認します。 ページ側のキーボードショートカットやフォーカス制御が、チャット内の操作を奪う場合もあります。Tab、Shift+Tab、Escape、Enter、矢印キーを使い、親ページとウィジェットのどちらが処理するかを確認します。意図しないページ遷移やチャットの終了が起きた場合は、イベント処理の境界を切り分けます。 Cookie同意バナーを表示した状態では、バナーとチャット起動ボタンが重ならないか、同意の前後でフォーカス順が予期せず変わらないかを確認します。別の固定ボタンがあるページでも同じ操作を行い、拡大時と狭い画面での重なりを記録します。 遅い通信や読み込み失敗も試します。ウィジェットがまだ読み込まれていないのに空のボタンだけが残る、読み込み後にフォーカス順が突然変わるといった状態がないかを確認します。読み込めない場合はページの主要内容を妨げず、代替問い合わせ先へ到達できることが必要です。 サイトの言語を切り替えられる場合は、ボタン名、入力説明、エラー、送信状態が同じ言語になるかも確認します。長い翻訳でボタンの文字が切れたり、表示は切り替わっても読み上げ名だけ元の言語に残ったりしないよう、画面表示とアクセシブルな名前を一緒に試します。 チャット以外のフォームやナビゲーションも含め、ページ全体のフォーカス順を記録します。ウィジェット内だけを調整しても、ページ本体へ戻れなければ、利用者は一連の目的を完了できません。 ## よくある質問 判断の前提となる環境や対象範囲が異なる場合は、回答だけを流用せず、自社の受入条件と照らして確認してください。 ### 自動アクセシビリティ検査だけで十分ですか 十分ではありません。ラベルや構造の一部は検出できますが、フォーカス順、新着回答の通知量、閉じた後の戻り先、日本語入力、モバイルキーボード表示中の操作は手動で確認します。自動検査と、キーボード、スクリーンリーダー、実機による確認を組み合わせて判断してください。 ### 新着回答はすべて読み上げるべきですか 履歴全体を毎回読み上げるのではなく、新しく追加された必要な内容と重要な状態を伝えます。生成途中の断片を繰り返し通知すると操作を妨げるため、実際の支援技術で通知内容と回数を確認します。 ### チャットを開いたら入力欄へ移動すればよいですか 一律には決められません。見出しや利用上の説明を先に確認する必要がある設計では、別の要素が適切な場合もあります。開いた直後の位置を利用者が理解でき、設計した順序で操作でき、閉じた後に起動元へ戻れるかを確認します。 ### WCAG準拠と表示してよいですか 一部のテストへ合格しただけで、適合を断定しないでください。対象範囲、適用する基準、評価方法、確認した環境、未確認事項を整理し、必要に応じて専門的な評価を受けます。本記事の公開前テスト項目は、個別環境への適合を保証するものではありません。 ### どの環境でテストすべきですか 実際の利用状況、アクセス解析、組織の対応方針を基に、代表的なOS、ブラウザ、支援技術、スマートフォンを選びます。各環境の名称とバージョン、確認日時を結果へ残し、試していない組み合わせも明記してください。