スクリーンリーダーと聞くと、「画面の文字を上から順に読み上げるソフト」と思いがちです。実際の使い方は、もう少し違います。今どこにいるかを音声や点字で伝え、見出しやリンクといった目印を頼りにページを飛び回ります。目でレイアウトを把握する代わりに、構造を聞いて把握する道具です。
この記事は、まず家族・職場など隣にいる方に向けて書いています。Webやアプリの作り手にも役立つ部分は後半にまとめています。仕組みの輪郭を知っておくと、「遅い」「聞き取れない」と見える場面の意味が変わります。
この記事の要点
- スクリーンリーダーは、画面の情報を音声や点字で伝える支援技術である。
- 利用者は上から全部聞くのではなく、見出し・リンク・フォームなどへジャンプして読むことが多い。
- 日本では PC-Talker の利用が多く、NVDA などとの併用も広がっている。
- 困りの多くは操作の未熟さではなく、名前のないボタンや見出しのないページなど、環境側の問題である。
画面を「見る」代わりに、構造を聞く
読み上げの対象は、画面に出ている文字だけではありません。ボタン、メニュー、通知、入力欄も含まれます。マウスでクリックする代わりに、フォーカス（いま操作の対象になっている場所）をキーボードやジェスチャーで動かし、その都度、合成音声や点字で内容を伝えます。
Windows なら NVDA（無料のオープンソース）、PC-Talker（国内で長く使われてきた製品）、OS標準のナレーターなどがあります。Mac や iPhone には VoiceOver、Android には TalkBack が標準で入っています。製品ごとに操作は違いますが、「フォーカスを動かして、そこを読む」という骨格は共通です。
全盲の人だけが使うわけではありません。ロービジョンの人が拡大表示と併用したり、画面を長時間見られない場面で音声に頼ったりすることもあります。
上から順に読むとは限らない
Webページを開いたとき、最初のフォーカスはだいたいページの先頭にあります。矢印キーで一行ずつ進むこともできます。ただ、長いページを全部聞き通すのは現実的ではありません。多くの利用者は、見出しだけを順に拾って全体像をつかみ、リンク一覧から目的の操作を探し、フォームのラベルを確認して入力します。
NVDA のブラウズモードでは、Hキーで次の見出しへ、Kキーでリンクへ、といったジャンプができます。VoiceOver にも、見出しやリンクなどへ切り替えて移動する仕組みがあります。スクリーンリーダーは「朗読機」というより、「構造をたどるナビゲーション」に近いです。
隣で待っていると、同じ画面なのに操作が止まって見えることがあります。実際には、見出しをたどっていまどの節にいるかを確認している最中かもしれません。見た目だけ大きくした文字や、装飾画像のファイル名が長々と読み上げられると、その確認はさらに長くなります。見出しやラベルが整っていると、同じページでも移動のコストが大きく下がります。
日本では、検証を一製品で終わらせない理由がある
日本視覚障害者ICTネットワークの第4回調査（2024年実施）では、パソコンで使うことがある支援技術として PC-Talker が約75％、NVDA が約58％でした（複数選択可）。Windows 利用者の多くが複数製品を併用しています。
検証で NVDA だけを試して「問題ない」と断定すると、実際の利用者環境を取りこぼすことがあります。サイトやアプリの挙動は製品によって違う、という前提が必要です。
読み上げ速度も、周囲が見誤やすい点です。慣れとともに速くなりがちで、「早口で聞き取れない」と感じても、本人にはちょうどよいペースであることが多いです。速度を勝手に落とすより、本人の設定を尊重するほうが負担は少ないです。
困りごとの多くは、ページ側に原因がある
慣れた利用者でも詰まりやすいのは、ページの作りです。たとえば申込み画面で、赤い枠のエラーだけが出て読み上げが何も言わないと、「なぜか進まない」まま迷います。リンク一覧に「こちら」「詳しく」が並ぶと、行き先を区別できません。
ほかにも、情報を伝える画像に代替テキストがない、見出しを文字の大きさだけで表現している、入力欄にラベルがない、といった状態があります。ダイアログを開いてもフォーカスが動かない。名前のないアイコンが「ボタン」としか読めない。保存完了が画面表示だけ。こうした状態は、操作の未熟さでは説明しきれません。視覚に頼った設計が、そのまま音声の設計になっていないだけです。
当事者視点の解説でも、繰り返し強調されるのは次の三点です。見出しによる骨組み。画像の役割に合わせた代替テキスト。キーボードでの到達。
隣にいる人が先にできること
急かさないことです。読み上げを聞きながら判断している時間は、作業の一部です。読み上げ速度やキー操作は、本人の了解を得てから触る。うまくいかない場面を、習熟不足だけに帰さない。まずはそこからです。
作り手や改修に関わる人は、次も見てください。
- 「全部聞けばわかるはず」と思わず、見出し・リンク名・フォームのラベルで目的地にたどり着けるかを確認する。
- 画像には、役割に合わせた短い代替テキストを付ける。装飾だけの画像は空の代替テキストにして、読み上げから外す。
- 「こちらをクリック」を避け、行き先や動作がリンク名だけでわかるようにする。
- キーボードだけで操作できるか、ダイアログの開閉でフォーカスが迷子にならないかを確認する。
- 送信エラーや保存完了など、重要な変化は色だけでなく読み上げでも伝える。
- 検証は一つの製品だけで終わらせない。可能なら NVDA と、国内で利用の多い環境の両方を見る。
かえって負担になることもあります。「目で見ればわかるのに」と名前のないUIを放置する。代替テキストにファイル名や「画像」とだけ入れる。後付けの読み上げツールだけで対応完了とみなす。見出しやキーボード操作など、本体の作りは、そうした後付けでは置き換えられません。
コントラストや見え方の個人差については、コントラスト比の記事でも触れています。画面が見える・見えないの二分法だけでは、足りない場面があります。
おわりに
スクリーンリーダーは、見え方の違う人が同じ情報や操作にたどり着くための道です。周囲に求められるのは、NVDA や VoiceOver のショートカットを全部覚えることではありません。「いま、構造を頼りに移動しているのかもしれない」と見ておくことです。
見出しがあるか。リンクに名前があるか。変化が音声でも届くか。その確認だけで、聞き取りにくさや迷いの多くは減ります。読めないのは、耳の問題ではなく、伝え方の問題です。