公開2025.07.11更新2026.10.26 Webサイト

非視覚系ユーザーエージェントとは？HTML 4.01由来の意味とスクリーンリーダーが読む情報

非視覚系ユーザーエージェントとは、Webページを画面表示ではなく音声や点字で利用者に届けるソフトウェアや機器のことです。スクリーンリーダー、点字ディスプレイ、音声ブラウザが該当します。この言葉はHTML 4.01仕様の11.4節「Table rendering by non-visual user agents」の邦訳で使われた語で、表の見出しを音声でどう伝えるかという文脈で登場しました。

この記事では、用語の出どころとWCAG 2.2での定義、2026年の調査で見たスクリーンリーダーの利用シェア、ブラウザが支援技術に情報を渡す仕組みを整理します。そのうえで、HTML 4.01で非視覚系向けに用意された表の属性が現行HTMLでどう扱われているかと、Chrome 154で実測したアクセシビリティツリーの違いを示します。

まとめ：非視覚系ユーザーエージェントの意味と対応の要点

非視覚系ユーザーエージェントは、音声合成や点字でWebを提示するソフトウェア・機器の総称。HTML 4.01は例として「speech synthesizers and Braille-based devices」を挙げる
WCAG 2.2では、ユーザーエージェント（Webコンテンツを取得して提示するソフトウェア）に支援技術も含まれると定義されている
WebAIMの調査#11（2026年7〜8月、有効回答1,780件）では、PCの主なスクリーンリーダーはJAWS 55.0%、NVDA 32.9%、VoiceOver 6.5%
スクリーンリーダーは画面の見た目ではなく、ブラウザがOSのアクセシビリティAPIへ渡す「アクセシビリティツリー」を読む
HTML 4.01の表属性のうち、tableのsummary、tdのabbr、axis、tdのscopeは現行HTMLで廃止。thのscope・abbrとheadersは有効
OpenAIは、ChatGPT AtlasがARIAのラベルや役割を使ってページ構造と操作要素を解釈すると公式FAQで説明している

非視覚系ユーザーエージェントの定義とHTML 4.01での出どころ

HTML 4.01仕様11.4節「非視覚系ユーザエージェントによる表のレンダリング」

「非視覚系ユーザーエージェント」は、W3CのHTML 4.01仕様（1999年勧告）にある「non-visual user agents」の訳語です。日本語訳では11.4節の見出しが「非視覚系ユーザエージェントによる表のレンダリング」となっており、検索で見つかる用例の多くはこの邦訳に由来します。

原文の11.4.1節は、対象を次のように例示しています。

Non-visual user agents such as speech synthesizers and Braille-based devices may use the following TD and TH element attributes to render table cells more intuitively

音声合成や点字機器が、セルを読み上げる前に対応する見出しを読めるようにすることが狙いです。仕様には、表を「Name: T. Sexton, Cups: 10, Type: Espresso」のように見出しとセットで読み上げる例まで載っています。目で見れば一瞬で分かる行と列の対応を、音声では1セルずつ順番に伝えるしかないため、見出しとデータの関係をマークアップで明示する必要がある、という考え方です。

WCAG 2.2での「ユーザーエージェント」と「支援技術」の定義

現行のアクセシビリティ基準であるWCAG 2.2の用語集は、ユーザーエージェントを「any software that retrieves and presents web content for users」と定義し、例にWebブラウザやメディアプレーヤーと並べて支援技術（assistive technologies）を含めています。

支援技術は「単独で、または一般のユーザーエージェントと組み合わせて」障害のある利用者の要求に応えるハードウェア・ソフトウェアと定義されています。WCAGは例として、合成音声または点字でテキストを読むスクリーンリーダー、画面拡大ソフト、テキスト読み上げソフト、音声認識ソフトなどを挙げています。このうち画面を見ずに使うものが、本記事でいう非視覚系ユーザーエージェントにあたります。WCAGの全体像はWCAGの4原則と達成基準の解説で扱っています。

範囲の取り方は解説によって異なり、ミツエーリンクスの用語集は音声ブラウザやスクリーンリーダーに加えて「検索エンジンのロボット」も含めています。HTML 4.01の例示は音声合成と点字機器だけなので、人に情報を届ける支援技術を指すのか、視覚を使わずにページを解釈するプログラム全般を指すのかを文脈で確かめてください。

なお、HTTPリクエストに付く「User-Agent」ヘッダーの文字列と同じ語ですが、ここでいうユーザーエージェントはソフトウェアそのものを指します。ブラウザの判別に使うUA文字列の話とは別物です。

非視覚系ユーザーエージェントの種類と2026年の利用実態

種類	出力	代表例
スクリーンリーダー（PC）	合成音声・点字	JAWS、NVDA、VoiceOver、ナレーター
スクリーンリーダー（モバイル）	合成音声・点字	VoiceOver（iOS）、TalkBack（Android）
点字ディスプレイ	点字（ピンの上下）	スクリーンリーダーと接続して使用
音声ブラウザ	合成音声	読み上げ機能を内蔵したブラウザ

スクリーンリーダーの利用シェア（WebAIM調査#11）

米ユタ州立大学のWebAIMは、スクリーンリーダー利用者への調査を2009年から続けています。11回目の調査は2026年7〜8月に実施され、有効回答は1,780件でした。主に使うPC用スクリーンリーダーの回答は次のとおりです。

主に使うPC用スクリーンリーダー	#10（2023年12月〜2024年1月）	#11（2026年7〜8月）
JAWS	40.5%	55.0%
NVDA	37.7%	32.9%
VoiceOver	9.7%	6.5%

前回は拮抗していたJAWSとNVDAの差が開き、WebAIMも「2026年はJAWSを主に使う回答が再び増えた」と書いています。モバイルで普段使うスクリーンリーダー（複数回答）はVoiceOverが72.2%、TalkBackが29.5%でした。回答者は欧米の利用者が中心で、無作為抽出による調査でもないため、この回答比率を世界全体や日本国内の市場シェアとして扱うことはできません。国内で無料のNVDA日本語版を使う場合はNVDA日本語版2025.1.2jpの主な機能と改善点、Android側はTalkBack 16.0の新機能が参考になります。

動作確認を1種類に絞るなら、Windowsは無料で入手できるNVDA、iPhoneは標準搭載のVoiceOverが現実的な組み合わせです。JAWSは有償のため、想定利用者の利用環境に含まれる場合や、発注元の検証要件にある場合に追加で確認します。

点字ディスプレイと音声ブラウザの位置づけ

点字ディスプレイは単体でWebを読むのではなく、スクリーンリーダーが組み立てたテキストを点字セルのピンで表示する出力装置です。点字の利用を尋ねたWebAIM調査#10（2023年12月〜2024年1月）では、障害のある回答者の38%が点字を使うと答えています（#11には同じ設問がありません）。仕組みや価格、給付制度は点字ディスプレイの仕組みと価格・給付基準額にまとめています。

音声ブラウザは読み上げ機能をブラウザ自体に組み込んだもので、OS標準のスクリーンリーダーが普及する前に使われた形態です。現在の主流は、一般のブラウザとスクリーンリーダーを組み合わせる方式です。

非視覚系ユーザーエージェントがページを読む仕組み：アクセシビリティツリー

スクリーンリーダーはHTMLを直接解析しているわけではありません。ブラウザがDOMから「アクセシビリティツリー」を作り、各要素の役割（role）・名前（name）・状態をOSのアクセシビリティAPIへ公開し、スクリーンリーダーはそのAPIから情報を受け取ります。WCAG 2.2も支援技術の注記で、支援技術は一般のユーザーエージェントとAPIを使って情報をやり取りすることが多い、と書いています。

W3CのCore-AAM 1.2が対象とするAPIは、WindowsのMSAA＋IAccessible2 1.3とUI Automation、LinuxのATK/AT-SPI、macOSのAccessibility Protocol（AXAPI）、AndroidのAccessibility APIです。つまり、同じHTMLでもブラウザとOSの組み合わせによって伝わり方が変わります。divに見た目だけボタンの装飾をしても、ツリー上でbuttonの役割を持たなければスクリーンリーダーにはボタンとして伝わりません。

Chrome 154で見た表と画像のアクセシビリティツリー

Chrome 154（154.0.8037.93）をpuppeteer-coreで動かし、DevToolsプロトコルのAccessibility.getFullAXTreeで同じ内容の表と画像をマークアップ違いで比べました（2026年10月4日実施）。

マークアップ	ツリー上の役割	名前
caption＋th scope=”col”の表	table・columnheader	table：キャプション／columnheader：見出しセルの文言
tdと太字だけで見出しを表現	LayoutTable	なし
alt属性のないimg	image	空
alt=””のimg	ツリーから除外	－
alt属性のない画像だけのリンク	link	空

見出し行をtdと太字で作った表は、Chromeがレイアウト用の表（LayoutTable）と判定し、列見出しの関係がツリーに出ませんでした。見た目は同じでも、非視覚系ユーザーエージェントにとっては見出しのない表です。また、alt属性のない画像はツリーに名前の空いた画像として残り、画像だけのリンクではリンク名も空になりました。装飾画像はalt=""にすればツリーから外れ、読み上げの雑音になりません。

HTML 4.01の表属性と現行HTMLでの扱い

HTML 4.01が非視覚系ユーザーエージェントのために用意した表の属性は、現行のHTML Living Standardで扱いが分かれています。古い解説記事をもとに実装すると、廃止済みの属性を使ってしまうので注意してください。

属性	HTML 4.01での役割	現行HTMLでの扱い
tableのsummary	音声・点字向けの表の要約	廃止（caption等で説明）
thのabbr	見出しの短縮形	有効
tdのabbr	セル内容の短縮形	廃止
axis	セルの分類	廃止（thのscopeで代替）
thのscope	見出しが及ぶ範囲	有効
tdのscope	tdを見出し扱いにする	廃止（thを使う）
headers	データセルと見出しの対応	有効

WHATWGの廃止機能一覧は、tdのabbrについて「見出しならabbr属性を持つthを使う」、axisについて「関連するthにscope属性を使う」と代替を示しています。HTML 4.01自体も、axisの情報をユーザーエージェントが処理することは必須としていませんでした。

現行HTMLで書くなら、まずcaptionとthで足ります。headersが必要になるのは、見出しが2段に重なる表など、scopeだけでは対応関係が決まらない場合です。

<table>
  <caption>部署別の月平均残業時間（時間）</caption>
  <thead>
    <tr>
      <th scope="col">部署</th>
      <th scope="col" abbr="4月">2026年4月</th>
      <th scope="col" abbr="5月">2026年5月</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">営業</th>
      <td>35</td>
      <td>28</td>
    </tr>
  </tbody>
</table>

abbr属性とabbr要素の混同

thのabbr属性は、読み上げで毎回繰り返される見出しを短くするためのものです。略語や専門用語に正式名称を添える用途ではありません。略語の説明には<abbr title="...">のabbr要素がありますが、title属性はスクリーンリーダーによって読まれないことがあるため、初出で「WCAG（Web Content Accessibility Guidelines）」のように本文に正式名称を書くほうが確実です。

AIエージェントとARIA：ChatGPT Atlasの公式説明

ページに付けた役割やラベルは、支援技術に加え、AIエージェントによるページの解釈にも使われています。OpenAIは「Publishers and Developers – FAQ」で、ブラウザChatGPT Atlasについて次のように説明しています。

ChatGPT Atlas uses ARIA tags—the same labels and roles that support screen readers—to interpret page structure and interactive elements.

同じFAQは、サイトのアクセシビリティを高めるとAtlasのエージェントがページを理解しやすくなる、とも書いています。スクリーンリーダー向けに整えた役割と名前が、そのままAIエージェントの操作精度にも効くということです。利用者の側でもAIの併用が進んでおり、WebAIM調査#11では回答者の60.1%が画像の説明や代替テキストの生成にAIを使っていると答えており、同設問に挙げられた用途でのAI利用を申告しなかった回答者は8.2%でした。

ただし、FAQの「要素にロール・ラベル・状態を追加する」という助言を、ARIA属性を足すことだと受け取るのは避けるべきです。buttonやa、labelなどのネイティブ要素はARIAなしで役割と名前を持ちます。ネイティブHTMLを優先し、それだけでは伝えられない名前・状態・関係をARIAで補います。この使い分けはWAI-ARIAの使い方とネイティブHTMLを優先すべき理由で詳しく扱っています。

非視覚系ユーザーエージェント対応で点検する5か所

まず、操作や内容理解を妨げる名前・役割の欠落を確認します。以下の5項目を点検し、送信ボタンを識別できないなど、利用者が作業を完了できない問題を優先して修正します。

画像の代替テキスト：情報を持つ画像は内容をaltに書き、装飾画像はalt=""にする。「画像」「写真」とだけ書いたaltは名前があっても情報がない
リンクとボタンの名前：アイコンだけのリンクやボタンに名前を付ける。「こちら」「詳細」が並ぶと、リンク一覧で読んだときに区別できない
見出しの階層：スクリーンリーダー利用者は見出しジャンプでページを移動する。見た目だけ大きくしたpやdivは見出しとして伝わらない
フォームのラベル：入力欄とlabelをfor属性で結び付ける。プレースホルダーだけでは入力後に項目名が消える
データ表の見出し：thとcaptionを使う。レイアウト目的で表を使わない

名前と役割は、Chromeの開発者ツールにあるAccessibilityペインで確認できます。実際の読み上げ順や操作感はスクリーンリーダーで確かめる必要があり、手順はNVDA・VoiceOverでの実機検証と読み上げ順序の設計、優先順位の決め方はウェブアクセシビリティ向上の進め方にまとめています。

法的な位置づけは、2024年4月施行の改正障害者差別解消法で事業者に義務化されたのが「合理的配慮の提供」で、Webサイトを事前に改善する「環境の整備」は努力義務です。線引きの詳細はWebアクセシビリティは義務化されたのか？2024年改正法の線引きを参照してください。

よくある質問

ユーザーエージェントとは何ですか？

Webコンテンツを取得して利用者に提示するソフトウェアのことです。WCAG 2.2はWebブラウザ、メディアプレーヤー、プラグインに加え、スクリーンリーダーなどの支援技術も含めて定義しています。HTTPのUser-Agentヘッダーは、このソフトウェアが自分の種類を名乗る文字列です。

非視覚系ユーザーエージェントにはどんな種類がありますか？

主にスクリーンリーダー（JAWS、NVDA、VoiceOver、ナレーター、TalkBack）、スクリーンリーダーと組み合わせて使う点字ディスプレイ、読み上げ機能を内蔵した音声ブラウザがあります。現在はブラウザとスクリーンリーダーを組み合わせる使い方が主流です。

a11yとは何の略ですか？

accessibilityの先頭のaと末尾のyの間に11文字あることから作られた略記で、アクセシビリティを指します。i18n（internationalization）と同じ作り方です。

画像のalt属性は画面に表示されないのですか？

通常は表示されません。altは画像を読み込めないときに代わりに表示されるほか、スクリーンリーダーが画像の名前として読み上げます。Chrome 154ではalt属性がない画像は名前が空のままツリーに残り、alt=""の画像はツリーから除外されました。設定値は開発者ツールのAccessibilityペインで確認できます。