スクリーンリーダーでサイトを確認するには？読み上げ・見出し・操作の点検手順

一つの用事と、試す環境をそろえる

「サイトを一周する」より先に、読む人が何を知り、何を終えたいかを決めます。その用事に必要なページと状態を、試す端末・ブラウザー・スクリーンリーダーの組合せへ結びます。

スクリーンリーダーでは、説明と操作の意味も聞く

スクリーンリーダーは、ページの情報を音声や点字などで伝える支援技術です。本文だけでなく、見出し、リンク、操作する部品の種類や名前、必要な状態などを利用して読み進めます。Tabキーで次の部品へ進めることと、その部品の目的が分かることは別です。

自動ツールは実装上の問題候補を探す助けになりますが、今の説明と操作で用事を進められるかは、それだけでは分かりません。反対に、読み上げられた文章でも、小さい文字や重なりなど別の困難が残る場合があります。一般のキーボード・見出し・入力・拡大の点検とも組み合わせます。

最初に、対象と開始条件を合わせる

この架空例の用事は、設備点検の対応地域と相談前に必要な確認を探し、相談方法を確かめることです。会社案内の全ページやすべての部品を、最初から同じ手順で試す計画にはしません。

• 対象と状態：案内ページと相談先のURL、試すページの版、ログインの有無、開いたメニューなどの開始状態をそろえます。
• 組合せ：OS・ブラウザー・スクリーンリーダーとその版、日本語などの言語、キー配列と変更した設定を記録します。
• 操作する人の準備：使う道具の基本操作を練習し、読む位置と操作位置、モードの切替を確かめます。
• 試す範囲：入力、エラー、確認や送信をどこまで試すかを会社と決め、試験環境・試験データ・宛先を合わせます。

本文ではWindows・Chrome・NVDAを説明の例にします。実際には利用状況や対象の対応条件に合わせて組合せを選びます。一組の確認を、ほかのOSやソフトでも使えた結果に広げません。この架空計画では版、URL、設定は未確認で、実際の組合せは未試行です。

この掲載案で「対応地域」と「相談前に確認すること」を探し、「点検について相談する」へ進む場面を追います。掲載文が見えることから、実際の読み上げ結果を先に決めないでください。

読む操作と入力の操作を、モードで分ける

NVDAでは、本文や構造を読むブラウズモードと、入力欄などへキーを渡すフォーカスモードを区別します。キーが期待どおりに働かないときは、サイトの不具合と決める前に、今の場所とモードを確かめます。

読む位置は、本文のどこをたどっているかです。フォーカスは、今キー操作を受けるリンクや欄などの位置です。両者が同じとは限りません。画面の見える枠だけを見て、どの文章が出力されたかを推定しないことが大切です。

1. 読むとき：ページの内容へ戻り、ブラウズモードで矢印キーなどを使い、本文を順にたどります。
2. 見出しなどへ移るとき：ブラウズモードの一文字のキーで、特定の種類の要素へ進みます。本文を順に読む経路と、見出しへ移る経路をそれぞれ試します。
3. 入力するとき：対象の欄へ移り、フォーカスモードで文字入力などを行います。戻って周りの説明も読めるかを確かめます。

標準の動作では、対象によって自動でモードが切り替わります。NVDA制御キーとSpaceを組み合わせる操作は、両モードの切替です。NVDA制御キーは、ほかのキーと組み合わせるために設定されたキーを指します。使っている配列と設定を公式案内で確かめてください。

会社の検証手順で自動切替などを変更する場合は、その設定を記録します。他社の検証用設定を、ソフトの初期設定やすべての利用者の条件と同一にしません。初心者が入力欄で見出し移動のキーを押して文字が入った場合などは、操作とモードを見直してから再現を確かめます。

本文を読み、見出しとリンクから目的の場所へ進む

最初は本文を順に読み、次に見出しやリンクを使って必要箇所へ移ります。聞こえた言葉だけでなく、どの説明と結び付き、どこへ進んだかを確認します。

題名から本文まで、話のまとまりをたどる

試験するページの先頭から、ページの題名、主な内容、各まとまりを順に確認します。共通のメニューが続く場合は、本文へ進む経路やランドマークも使います。ランドマークは、ナビゲーションや主要な本文など、ページの領域を表す手がかりです。

架空例では「設備点検のご案内」の主題から、「対応地域」とその本文、「相談前に確認すること」とその本文が関係を保って伝わるかを聞きます。横並びの見た目だけで読む順を決めず、画像に大切な条件がある場合は、その説明も用事に足りるかを確かめます。

見出しとリンクの移動を、本文の文脈へ戻して確かめる

NVDAのブラウズモードで、Hは次の見出し、Kは次のリンクへ移ります。NVDA制御キーとF7の組合せは要素一覧です。Kはリンク一覧を開くキーではありません。目的に合う操作を使い、見出し一覧や本文を行き来します。

画面で大きい太字になっていても、見出しとして扱われるとは限りません。「対応地域」へ移れたか、その後に地域の説明を読めたかを別に確認します。リンクでは「点検について相談する」の目的を聞いてから、許可された移動を行い、移動先の「お問い合わせ」とのつながりを確かめます。

この案内で、地域と条件を見つけてから相談先へ進むとき、何を聞き、どこへ移るでしょうか。

読む順で条件を確認し、見出し移動でも同じ情報へ戻れるかを試します。相談リンクへ到達しただけで終えず、目的と移動先まで確かめます。図の経路は予定で、実出力と到達は未確認です。

一覧で分かりやすいリンク名は役立ちます。ただし、「詳細」など一語だけを抜き出して全体の不適合とは断定しません。本文とのプログラム上の関係を含む文脈で目的を判断し、実際にどこで意味を見失ったかを残します。見えるフォーカスや本文への移動の実装は、フォーカス表示の点検や本文へ進むリンクの確認と分けて扱えます。

欄名と状態を聞き、許可された操作を試す

対象へ移動できることに加え、何の欄・操作か、必要な値や状態が分かるかを確かめます。開閉、入力の誤り、確認後の変化があるなら、変化した意味まで対象にします。

架空の相談ページでは、入力場所に進んだとき「相談内容」の欄であることと、「確認する」という次の操作を区別できるかを見ます。欄の名前は、その欄で何を入れるかを伝える情報です。役割は、入力欄・ボタンなど、どう扱う部品かを伝える情報です。

欄に進めた後、その名前と次の操作、操作後に変わる説明をどう確かめるでしょうか。

欄名と操作の意味を聞き、試験が許可されている場合に操作して変化を確認します。この計画では出力や変化は未確認です。確認ボタンという掲載案から、送信・受付・成功メッセージを作らないでください。

1. 操作前：欄やボタンへ進み、名前・種類・必要な値や状態を確認します。周囲の説明も読み、何をするかを判断します。
2. 操作：同意された試験環境とデータで、入力や開閉などの動きを試します。入力中はモードと、今操作している対象を確かめます。
3. 変化後：新しい説明、入力エラー、確認内容などが現れる場合、その意味へ気付けるか、必要箇所へ移って直せるかを確かめます。

HTMLに名前や状態の属性があることだけでは、実際の出力と操作の成功は確認できません。期待した意味が伝わらない場合は、画面の状態、押したキー、実出力、今の位置を制作担当へ返します。原因を調べる前に、属性を足せば直ると決めないでください。

この例では実送信の許可がありません。顧客への問い合わせ、注文や受付を試験として実行しません。送信や通知も必要な評価範囲なら、会社が許可した別の試験条件を先に決めます。

期待と実出力を分け、原因を決めずに伝える

「読み上げが変だった」だけでなく、どこで何をし、何が伝わるはずで、実際はどうだったかを残します。出力を聞いていない箇所は、未確認のままにします。

実出力の記録を補助する方法を使う

NVDAのスピーチビューアーは、現在読み上げている文字を表示する補助機能です。ツールメニューから開き、聞き取れなかった部分や操作の順と照らします。画面の文章を手作業で貼ったものを、スピーチビューアーの実出力として扱わないでください。

ビューアーへマウスを重ねたり、その中へフォーカスを置いたりすると、更新が一時的に止まります。対象のページへ操作を戻してから、どの操作に対する出力かを読みます。文字の出力、音声の聞き取り、操作の結果、実利用者の使いやすさは、それぞれ確認した範囲を分けて記録します。

未試行の計画を、失敗の記録に変えない

この原票の三地点では、期待する意味と予定操作だけが決まっています。読み上げ、移動結果、問題の確定はすべて未確認です。結果欄が空だから無音だった、到達できなかった、と解釈しません。

実際に問題らしい動きが出た場合は、ページの開始状態をそろえ、今のモード、設定変更、基本キーの理解を確認して再現します。操作の取り違え、特定環境の差、実装上の問題、まだ原因が特定できない状態を分けます。再現できた観測と、原因の推測を同じ欄にしないことが役立ちます。

制作担当への連絡文の型

対象のURLとページの版、OS・ブラウザー・読み上げソフトの版、言語・モード・設定を添えます。「どこから、どのキーで、どの対象へ進んだか」「期待する意味」「実際の出力と動き」「用事のどこで困るか」を分けて伝えてください。

この計画なら、対応地域と相談前の条件を見つける経路を対象に、見出し移動と本文の読み進めの両方を確認すると依頼できます。実出力・問題・原因は未確認と明記し、まだ起きていない不具合の文章を作りません。

修正した版で、同じ経路をもう一度確かめる

変更した版を、元の問題と同じ用事・開始位置・環境・操作で確かめます。直した部品だけでなく、前後の説明や移動先も確認し、まだ試せていない範囲を残します。

1. 変更点を聞く。制作担当に対象の箇所と版、どんな意味や操作を直したかを説明してもらいます。
2. 同じ条件で試す。以前の操作と実出力の記録を使い、同じ入口から地域・条件・相談先へ進みます。条件を変えた確認は、別の結果として記録します。
3. 関係する経路も見る。見出しから戻る、リンク先へ移る、入力して説明を読み直すなど、変更に関係する前後を確かめます。
4. 確認範囲を確定する。どの版・組合せ・状態で何を確認したか、残る状態や環境は何かを報告へ残します。

一つのNVDA環境で予定どおりに進めても、全OS・全ソフトの対応や、WCAG全体の適合を証明するものではありません。支援技術の利用者自身による評価は、社内担当が操作を学んで行う点検と目的を分けて計画します。検査を外部へ頼む範囲から整理する場合は、業務の状態と検査方法を結ぶ依頼の例を参照できます。

この架空計画では再確認は未実施で、変更後の版・環境・結果・担当者の評価も未確認です。本文の図や掲載案を読めたことを、実ソフトでの確認完了へ数えません。

まとめ：一ページの用事を、実出力と操作で確かめる

スクリーンリーダーの点検は、対象の用事と環境を決め、読む順・見出しとリンク・入力と状態を、実際の出力と動きへ結びます。期待した意味、観測したこと、まだ分からないことを分けると、必要な修正と再確認を頼めます。

Tabで到達したことやHTMLの属性を、意味が伝わった結果へ置き換えないことが大切です。迷った箇所は実出力と操作を添えて返し、変更した版でも同じ条件で確かめましょう。