ログイン

スクリーンリーダーとは：視覚障害のあるユーザーはどのようにウェブを操作しているのか

1 min read
・全体の意味と文脈を把握する ・原文のトーンとスタイルを維持する ・日本語で一般的な用語を選択する ・数値や記号などは原文どおり維持する ・改行やテキスト構造をそのまま保つ スクリーンリーダー盲目支援技術

世界には推定で3,600万人の全盲の人々がいますが、いまだに96%以上のウェブサイトには検出可能なアクセシビリティ上の不備があります。このガイドでは、スクリーンリーダーが実際にどのように機能するのか、全盲のユーザーがどのようにウェブを操作しているのか、そして開発者やウェブサイトの所有者が本当にインクルーシブなデジタル体験を構築するために何をしなければならないのかを、具体的に解説します。

世界には推定3,600万人の全盲の人々が存在し、さらに約2億1,700万人が中等度から重度の視覚障害とともに生活しています。それにもかかわらず、2025年になっても96%以上のウェブサイトには、少なくとも1つは検出可能なアクセシビリティ上の不具合があります。スクリーンリーダーに依存している全盲のユーザーにとって、ラベルの欠落、見出し階層の破綻、アクセスできないCAPTCHAのたった1つが、自力でタスクを完了できるか、あなたのサイトを完全に諦めて離脱するかの分かれ目になります。スクリーンリーダーが実際にどのように動作するのか――理論だけでなく実践レベルで理解すること――は、アクセシブルなウェブを構築するための土台です。

スクリーンリーダーとは何か、誰が使うのか

スクリーンリーダーは、画面上のコンテンツを合成音声または点字ディスプレイの出力に変換する支援技術ソフトウェアです。単にテキストを読み上げるのではなく、スクリーンリーダーはインターフェース要素の構造、役割、状態、相互関係を解釈し、視覚的な提示に頼ることなく、ユーザーにウェブページの包括的な理解を提供します。ナレーターというよりも、視覚的インターフェース全体を音声または触覚の情報ストリームに翻訳する、知的な通訳だと考えてください。

スクリーンリーダーは主に、全盲またはロービジョンの人々によって使用されていますが、特定の認知障害や読字障害のあるユーザーも支援します。WebAIMが2023年末に実施し2024年2月に公開した第10回スクリーンリーダーユーザー調査によると、スクリーンリーダーユーザーの約77%は全盲の人々であり、次いでロービジョンやその他の視覚障害のある人々が約20%を占めています。残りは、聴覚障害、認知障害、運動障害によるものです。これはニッチなオーディエンスではありません。米国の成人の4.9%が、失明または重大な見えにくさを伴う視覚障害を持っており、世界全体では視覚障害のあるユーザーは数億人規模に上ります。

また、スクリーンリーダーユーザーは一枚岩の集団ではないことも重要です。研究は一貫して、スキル、好み、ナビゲーション戦略、トラブルシューティングのアプローチに大きなばらつきがあることを示しています。生まれつき全盲で20年間JAWSを使っているユーザーは、最近視力を失い、支援技術をまだ学んでいる人とはまったく異なるナビゲーションを行います。技術的にはアクセシブルなウェブサイトであっても、要求されるメンタルモデルがユーザーの期待と一致しない場合、大きな困難をもたらし得ます。デザイナーや開発者は、単一の典型的なスクリーンリーダーユーザー像を思い描く誘惑に抗わなければなりません。

スクリーンリーダーの実際の動作: アクセシビリティツリー

スクリーンリーダーを本当に理解するには、彼らが「何を読んでいるのか」を理解する必要があります――それはあなたの視覚レイアウトではありません。スクリーンリーダーは、ブラウザがHTML DOMから構築するページの構造化表現であるアクセシビリティツリーにアクセスすることで動作します。ブラウザは、このツリーをプラットフォーム固有のアクセシビリティAPIを通じて公開します。WindowsではUI Automation、macOSではNSAccessibility、AndroidではAccessibilityServiceです。スクリーンリーダーはこのAPIに問い合わせ、あらゆる要素のセマンティック情報を受け取り、それを音声または点字出力に変換します。

ここには重要な含意があります。画面上で見えているものと、スクリーンリーダーが知覚しているものは、まったく異なり得るということです。もしあなたのビジュアルデザインが、ボタンのように見えるようスタイルされた<div>を使っている場合、アクセシビリティツリー上にボタンの役割がないため、スクリーンリーダーはそれをボタンとしてアナウンスしません。スクリーンリーダーはピクセルが示すものではなく、コードが示すものをアナウンスします。<button>、<nav>、<h1>、<form>のようなセマンティックなHTML要素は、アクセシビリティツリーに自動的に公開される組み込みの役割を持っています。開発者がこれらを避け、ARIAロールを付与した汎用要素を好んで使うと、不要な複雑さを生み出し、新たなエラーを頻繁に導入してしまいます。

スクリーンリーダーは、画面上には見えないコンテキストも提供します。ユーザーがリストに遭遇すると、スクリーンリーダーはその項目数をアナウンスします。テーブルに到達すると、行と列の数をアナウンスします。フォーカスがフォームフィールドに移動すると、そのフィールドのラベル、タイプ、現在の状態を読み上げます。このコンテキスト情報は、完全に構造化されたセマンティックHTMLに依存しています。これを取り除けば、ユーザーが自分が何に向き合っているのかを理解する能力も奪ってしまいます。

主要なスクリーンリーダー: JAWS、NVDA、VoiceOver、TalkBack

スクリーンリーダー市場は、いくつかのツールが支配しており、それぞれに明確な特徴があります。ユーザーがどのツールに依存している可能性が高いかを理解することは、サイトをどのようにテストすべきかに直結します。

JAWS (Job Access With Speech)は、Freedom Scientificによって開発され、1995年に初めてリリースされました。特にエンタープライズ用途において、長らく業界標準と見なされています。WebAIMの2024年の調査では、JAWSは回答者のおよそ41%にとって主要なスクリーンリーダーでした。これは商用製品であり、ライセンス費用は年間$90から$1,400超まで幅があります。JAWSは広範なカスタマイズ、Microsoft Officeやプロフェッショナルアプリケーションにおける複雑なワークフローとの高い互換性、そしてページをナビゲート可能な線形環境に変換し、直感的なキーストロークで見出し、ランドマーク、フォームフィールド間をジャンプできる「Browse Mode」を提供します。

NVDA (NonVisual Desktop Access)は、NV Accessによって開発され、2006年に登場したWindows向けの無料・オープンソースのスクリーンリーダーです。2024年のWebAIM調査では、NVDAは回答者の約38%にとって主要なスクリーンリーダーであり、その割合はJAWSとほぼ同じでした。NVDAは、無料モデル、頻繁なアップデート、堅牢なパフォーマンスにより大きな人気を獲得しています。2025年には、シングルページアプリケーションにおけるフォーカス管理の扱いが改善され、コンテンツがいつ変化し、フォーカスがどこに移動したのかをユーザーが理解しやすくなりました。推奨ブラウザの組み合わせはFirefoxですが、Chromeのサポートも強力です。

VoiceOverはAppleの内蔵スクリーンリーダーで、macOS、iOS、iPadOSで利用でき、インストールは不要です。デスクトップではVO修飾キー（Control + Option）を用いたキーボードショートカットを使用し、iOSではスワイプ、ダブルタップ、ローターといったタッチジェスチャーに依存します。モバイルデバイスでは、VoiceOverは最も広く使われているスクリーンリーダーであり、モバイルスクリーンリーダーユーザーの70.6%がこれに依存しています。VoiceOverはSafariとの組み合わせで最もよく機能し、SafariはmacOS/iOSのアクセシビリティAPIをVoiceOverに完全に公開している唯一のブラウザです。

TalkBackはAndroidの内蔵スクリーンリーダーで、音声フィードバックとバイブレーションを提供し、ユーザーがデバイスをナビゲートできるようにします。これはAndroidモバイルテストの標準ツールであり、Chromeとの組み合わせが最適です。WindowsにもNarratorという内蔵スクリーンリーダーが搭載されており、着実に改善されていますが、依然としてJAWSやNVDAの一部機能には及びません。これらのツールはそれぞれ挙動がやや異なります――NVDAでは正しく動作するパターンがJAWSでは失敗することもあります――そのため、複数のスクリーンリーダーでテストすることは、本格的なアクセシビリティプログラムにとって不可欠です。

全盲ユーザーの実際のナビゲーション: すべてを変えるメンタルモデル

開発者が自分の仕事の捉え方を根本的に変える最も重要な洞察はこれです。スクリーンリーダーユーザーは、ページを上から下へと線形に読むわけではないということです。彼らは、視覚ユーザーが視線でざっと流し読みするのと同じように、コンテンツを効率的にスキャンしジャンプするための高度なナビゲーション戦略を使います。これらの戦略をサポートしなければ、技術的にはアクセシブルなページであっても、疲弊する使い物にならない体験になってしまいます。

最も一般的なナビゲーション戦略は見出しナビゲーションです。情報を探すための見出しの利用は時間とともに増加しており、依然として主要な方法です――88.8%の調査回答者が、見出しレベルは非常に有用またはある程度有用だと回答しています。上級ユーザーは初心者よりも見出しによるナビゲーションを行う可能性がはるかに高いです。実際には、ユーザーはJAWSやNVDAでHキーを押してページ上の次の見出しにジャンプし、構造を素早くスキャンします。1から6を押すと、そのレベルの見出しに直接ジャンプします。ページに見出しがなかったり、文書構造ではなく見た目のサイズだけを基準に見出しが使われている場合、全盲ユーザーはジャンプするためのランドマークを持てません――ページ全体を最初から最後まで聞かざるを得なくなります。

2つ目の主要な戦略はランドマークナビゲーションです。HTML5のランドマーク要素――<main>、<nav>、<header>、<footer>、<aside>、およびラベル付きの<section>――は、スクリーンリーダーユーザーがローターやランドマーク用ショートカットキーを使ってジャンプできる名前付き領域を作ります。2025年には、ネイティブの<main>要素の利用拡大に牽引され、ARIAランドマークの採用がわずかに増加し、現在では47%のページに<main>が存在します。31.7%の回答者は、ランドマークが存在する場合には常にまたは頻繁にランドマークを使用すると答えていますが、ランドマークを主要なナビゲーション方法として使うのはわずか3.7%に過ぎません――これは、ランドマークが補助的なツールではあるものの、位置把握にとって重要であることを示唆しています。

ユーザーはまた、単一キーのショートカットを使ってリンク、フォームフィールド、ボタンでナビゲートし、ページ上のすべての見出し、すべてのリンク、またはすべてのフォームフィールドを一度に表示する要素リストを頻繁に呼び出して、必要な場所へ直接ジャンプします。この行動はリンクテキストに非常に大きな影響を与えます。「Read more, Read more, Read more」と並んだリンクリストは、ナビゲーション上の価値をまったく提供しません。すべてのリンクとボタンは、文脈から切り離されても意味が通じる、説明的で一意のアクセシブルネームを持たなければなりません。

モバイルでは、パラダイムはタッチジェスチャーに移行します。VoiceOverとTalkBackのユーザーは、右スワイプで次の要素に移動し、ダブルタップでそれをアクティブにし、ロータージェスチャーでナビゲーションモードを切り替えます。モバイルアプリ利用の好みは2021年の51.8%から増加し、2024年には58%になりました。これは、レスポンシブデザインとモバイルアクセシビリティがオプションの付加機能ではなく、多くのスクリーンリーダーユーザーにとって主要なユースケースであることを意味します。

現在のウェブで最も問題の多いバリア

WebAIMの調査では、回答者に最も問題の多い項目を挙げてもらいました。その結果は10年以上にわたって驚くほど一貫しており、あなたのサイトが確実に対応しなければならない項目のチェックリストそのものです。

  • CAPTCHAは、かなりの差をつけて最大の不満点です。スクリーンリーダーユーザーは、CAPTCHAが14年以上連続で最も問題の多い項目であることに同意しています。従来型のCAPTCHAの使用は、全盲の人々にとって明らかに問題です。彼らが頼りにしているスクリーンリーダーは画像を処理できないため、フォームが要求する情報を取得できません。音声CAPTCHAでさえ、多くのユーザーにとっては失敗します――意図的な歪みによって聞き取れないものになっているからです。実務的な推奨は、可能な限りreCAPTCHA v3やハニーポット技術のような不可視の行動ベースの認証を使用することです。
  • 予期しない挙動をするインタラクティブ要素――メニュー、タブ、ダイアログウィンドウ、確立されたキーボードインタラクションパターンに従わないカスタムウィジェット――もCAPTCHAに次いで大きな問題です。これらの要素はしばしば過剰なARIA属性で構築され、不規則なインタラクション挙動やブラウザとスクリーンリーダー間の互換性問題を抱えています。
  • 曖昧なリンクやボタンは、ユーザーを常に苛立たせます。「click here」「learn more」「read more」といったフレーズは、リンクリストの中で単独で聞いたとき、遷移先やアクションについて何の手がかりも与えません。
  • 予期しない画面の変化――事前の予告なしに発生する動的コンテンツの更新――は、何かが変わったという視覚的な手がかりを持たない全盲ユーザーを混乱させます。これは特に、React、Vue、Angularで構築されたシングルページアプリケーションで顕著であり、ページリロードなしにコンテンツが変化することがあります。
  • 壊れた見出し階層は、ほとんどの上級ユーザーにとって主要なナビゲーション戦略を損ないます。約39%のウェブサイトには壊れた見出し階層があり、スクリーンリーダーユーザーがコンテンツを適切にナビゲートすることを困難にしています。
  • 代替テキストの欠如または不十分なaltテキストを持つ画像。altテキストがない場合、スクリーンリーダーは画像の存在だけを示すか、あるいはさらに悪いことに、「IMG_4823.jpg」のような意味のないファイル名を読み上げるだけです。

スクリーンリーダーユーザーの大多数――67%――は、バリアについてウェブサイトの所有者に連絡することはほとんど、あるいはまったくありません。彼らは単に離脱します。あなたは苦情を受け取ることはありません。ただユーザーを失うだけです。

スクリーンリーダーが実際に解釈できるコードを書く

ユーザーのナビゲーションパターンを理解すると、技術的要件ははるかに具体的になります。マークアップやJavaScriptにおけるあなたのあらゆる決定は、全盲ユーザーにとって直接的で可聴な結果をもたらします。ここでは最も重要な原則を示します。

セマンティックHTMLは、最初にして最も強力なツールです。ARIAの第一原則はこう述べています。「必要とするセマンティクスと振る舞いがすでに組み込まれているネイティブHTML要素や属性を使えるのであれば、要素を別用途に流用してARIAのrole、state、propertyを追加してアクセシブルにしようとするのではなく、それを使いなさい。」<button>、<nav>、<header>、<form>のような要素には、アクセシビリティが最初から組み込まれています。ネイティブコントロールを使用することで、追加コードなしに、ブラウザと支援技術との互換性が保証されます。

ARIAは代替ではなく補完です。ARIA（Accessible Rich Internet Applications）は、HTMLだけでは必要なセマンティクスを表現できない場合のアクセシビリティギャップを埋めるために設計されたHTML属性のセットです――たとえば、カスタムで構築したスライダーをアクセシブルにする、動的コンテンツの変更をアナウンスする、折りたたみメニューが現在展開されていることを示す、などです。危険なのは誤用です。ARIAを使用しているホームページは、ARIAを使用していないページに比べて、平均して2倍以上のアクセシビリティエラーがあります。ARIAが多いことは、アクセシビリティが高いことを意味しません――多くの場合、エラーが多いことを意味します。ARIAを誤って使用しているページは、使用していないページに比べて検出可能なエラーが70%多いことが示されています。ネイティブ要素で代替できない場合に限り、外科的に使ってください。

次のコード例は、アクセシブルでないカスタムボタンと、適切にアクセシブルなボタンの違いを示しています。

<!-- Inaccessible: a div with click handler, no role, no keyboard support -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native button with built-in role, keyboard support, and focus -->
<button type='submit'>Submit</button>

<!-- If you must use a non-button element, add role, tabindex, and keyboard event -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

ARIAライブリージョンは、動的コンテンツの変更をアナウンスするための正しいメカニズムです。ページが完全なリロードなしにコンテンツを更新する場合――フォームのバリデーションメッセージ、カートの合計、通知など――その変更は、ライブリージョンを使用しない限り、スクリーンリーダーユーザーには無音のままです。aria-live='polite'属性は、スクリーンリーダーに対し、ユーザーの現在の操作が完了した後に変更をアナウンスするよう指示します。一方、aria-live='assertive'は即座に割り込んでアナウンスします――これは緊急のアラートにのみ、慎重に使用してください。2025年には、約33%のサイトがaria-live属性を使用しており、2024年から4%増加しましたが、展開されている動的インターフェースの数を考えると、採用率は依然として低すぎます。

インタラクティブコンポーネントにおけるフォーカス管理――モーダルダイアログ、フライアウトメニュー、アコーディオンなど――は明示的に扱わなければなりません。モーダルが開いたとき、フォーカスはその内部に移動しなければなりません。閉じたときには、フォーカスはそれをトリガーした要素に戻る必要があります。モーダルを開いたのに、フォーカスが背後のボタンに残ったままのスクリーンリーダーユーザーは、実質的にダイアログのコンテンツにアクセスできない状態になります。

スクリーンリーダーでサイトをテストする

自動アクセシビリティスキャナーは有用ですが、限界があります。自動ツールはWCAG違反の30〜40%を検出しますが、実際の支援技術によるテストは、ユーザーがサイトをどのように体験しているか――欠落したコンテキスト、混乱するナビゲーション、単に動作しないインタラクション――を明らかにします。どのスキャナーも、モーダルの見出しが周囲の視覚的コンテキストなしでは意味をなさないことや、カスタムドロップダウンがあるブラウザとスクリーンリーダーの組み合わせでは状態を誤ってアナウンスしているが、別の組み合わせではそうではない、といったことを教えてはくれません。

多くのチームにとって実務的な出発点は、Firefoxと組み合わせたNVDAです――無料で広く使われており、一般的な問題の大半を検出するのに有効です。これに、macOSとiOSユーザーをカバーするためにSafariと組み合わせたVoiceOverを追加します。エンタープライズ環境や高いコンプライアンス要件を持つクライアント向けには、ChromeまたはEdgeと組み合わせたJAWSを含めます。各スクリーンリーダーは特定のブラウザとの組み合わせで最もよく機能します。誤った組み合わせを使用すると、誤解を招くテスト結果を生む可能性があります。

テストの際には、実際のユーザーが採用しているナビゲーションパターンを取り入れてください。マウスは使わないでください。Hキーを使って見出しでナビゲートします。リンクリストを表示し、すべてのリンクが文脈から切り離されても意味をなすか確認します。フォームフィールドをTabキーで移動し、すべてのラベルが正しくアナウンスされるか確認します。モーダルダイアログを開き、フォーカスがその中に移動することを検証します。フォームに入力し送信し、すべてのバリデーションメッセージを聞きます。モニターをオフにして、代表的なユーザータスクを最初から最後まで完了しようとしてみてください――視覚ユーザーのテスターにとってどれほど不快であっても、それが全盲ユーザーの日常の現実です。

また、ブラウザのエミュレーターやシミュレーターではなく、実際の支援技術でテストすることも重要です。ブラウザの開発者ツールにあるアクセシビリティパネルは、アクセシビリティツリーを表示してくれるためデバッグには有用ですが、聴覚的な体験を再現することはできず、実際のスクリーンリーダーソフトウェアを使ったときにのみ現れるインタラクションの癖を明らかにすることもできません。

無視できないビジネスと法的な理由

アクセシビリティの倫理的な理由を商業的な現実で補強する必要があるなら、数字は厳然としています。米国だけでも、視覚障害のある人は約700万人おり、重要な消費者層を形成しています。世界的には、米国の成人の26%が障害を持っており、推定$13兆の市場機会を表しています。アクセシブルでないデザインによって全盲ユーザーをサイトから締め出すことは、倫理的義務を果たしていないだけでなく、顧客を拒んでおり、組織を法的リスクにさらしていることになります。

WCAG 2.2は、現在、数千件のADA訴訟で参照される法的標準となっており、2025年6月に民間企業に全面適用されたEuropean Accessibility Actは、EU全域にコンプライアンス要件を拡大しています。スクリーンリーダーユーザーの大多数は、バリアについてウェブサイトの所有者に連絡することはありません――彼らは単に離れ、ビジネスを他所へ持っていきます。問題を決して報告しない67%のユーザーは、満足しているのではなく、打ちのめされているのです。開発プロセスの最初からスクリーンリーダー対応を組み込むことで、高額な改修を回避し、法的リスクを軽減し、実際に利用できるデジタル体験を積極的に求めているオーディエンスに製品を開放することができます。

重要なポイントのまとめ

  • スクリーンリーダーはビジュアルではなく構造をナビゲートする。スクリーンリーダーは、プラットフォームのアクセシビリティAPIを通じてブラウザのアクセシビリティツリーに問い合わせます。セマンティックHTML――適切な見出し、ランドマーク、ネイティブコントロール――は、スクリーンリーダー対応において最も効果の高い投資です。
  • 全盲ユーザーは、行を上から順に読むのではなく、見出し、ランドマーク、要素リストでナビゲートする。スクリーンリーダーユーザーの88%以上が、ナビゲーションにおいて見出しレベルは非常に有用またはある程度有用だと感じています。壊れた、あるいは欠落した見出し階層は、ウェブ上で最も一般的で破壊的なアクセシビリティの不具合の1つです。
  • ARIAは良いマークアップも悪いマークアップも増幅する。ARIAを使用しているページは、使用していないページに比べて、平均して2倍以上のアクセシビリティエラーがあります。ARIAは、ネイティブHTMLでは必要なセマンティクスを表現できない場合にのみ使用し、実装後は必ず実際の支援技術でテストしてください。
  • CAPTCHA、曖昧なリンク、アナウンスされない動的コンテンツの変更が、現実世界での最大のバリアである。ビジュアルCAPTCHAを行動ベースの認証に置き換え、説明的なリンク・ボタンテキストを書き、動的更新にARIAライブリージョンを実装することは、全盲ユーザーのユーザビリティに即時かつ測定可能な影響を与えます。
  • 複数のブラウザ組み合わせで、実際のスクリーンリーダーを使ってテストする。自動スキャナーが検出できるWCAG違反は30〜40%に過ぎません。Firefoxと組み合わせたNVDAと、Safariと組み合わせたVoiceOverは、追加コストなしでユーザーベースの大半をカバーし、マウスなしでサイトをナビゲートする体験は、どの自動ツールも表面化できない問題を明らかにします。