HTMLとARIAから、スクリーンリーダーに何が伝わるか

利用者が聞く内容は、4つの層を通って届きます。

1. DOM： HTMLとスクリプトが作る要素と属性です。
2. アクセシビリティツリー： AccName 1.1の1章は「ユーザーエージェントはDOMから情報を取得し、アクセシブルなオブジェクトからなるアクセシビリティツリーという並行した構造を作る」と説明しています。
3. プラットフォームのアクセシビリティAPI： ブラウザーは各オブジェクトをOSのアクセシビリティAPIで公開し、変化があればイベントで知らせます。
4. 支援技術： スクリーンリーダー、音声操作、画面拡大ソフトなどがAPIに内容と変化を問い合わせ、音声や点字、コマンドに変えます。

ブラウザーが対応させるAPIは、Core Accessibility API Mappings（Core-AAM）1.2の1.1節に挙げられています。

プラットフォーム	アクセシビリティAPI
Windows	MSAAとIAccessible2、UI Automation
macOS	macOS Accessibility Protocol（AX API）
Linux	ATKとAT-SPI
Android	Androidのアクセシビリティ API

この一覧にiOSはありません。どのAPIに渡る場合も、ツリーの各オブジェクトが持つ情報の種類は同じです。

情報	例	元になるもの
ロール	button、checkbox、link	要素そのもの、または role 属性
名前	「下書きを削除」	中身、label、alt、aria-label、aria-labelledby
説明	「プロフィールに表示されます」	aria-describedby、名前に使われていない title
状態とプロパティ（値を含む）	チェック済み、展開、無効、スライダーの値	要素自身の状態、または aria-* 属性
関係	ラベル付け、制御、所有、親子	label for、aria-labelledby、aria-controls、aria-owns、入れ子

ツリーに届かない内容もあります。WAI-ARIA 1.2は、要素かその祖先が描画されていない（display: none）か、aria-hidden="true" を持つ場合に、その要素を隠れているものとして扱います。AccName 1.2は visibility: hidden も隠れているものに含めています。opacity: 0 の文字や画面外へ移した文字は隠れておらず、ブラウザーはツリーに残します。そのため、aria-hidden のリンクの中のバッジはリンクと一緒にツリーから消えます（画面に見えるのにスクリーンリーダーが読まないテキスト）。一方、画面外へ移して aria-hidden で隠したリンクには、フォーカスが移ってしまいます（Tabで届くのに読み上げられない、aria-hiddenの要素）。

HTMLの要素にはそれぞれ暗黙のロールがあります。role 属性がないときに対応するロールで、HTML Accessibility API Mappings（HTML-AAM）の3.5節が定めています。

要素	暗黙のロール
<button>	button
<a href="…">	link
href のない <a>	generic
<input type="checkbox">	checkbox（チェックの状態も伝わる）
<nav>	navigation
<section>	アクセシブル名があればregion、なければgeneric
<div>、<span>	generic

role 属性は暗黙のロールを置き換えます。WAI-ARIA 1.2の1.1節によれば、ARIAのロールを付けた要素は、HTMLから受け継ぐ意味にかかわらず、そのウィジェットや構造として扱われます。WAI-ARIA 1.2の5.3節は、ロールを6つに分類しています。

分類	ロールの例	作成者にとっての意味
抽象ロール	command、composite、input、landmark、range、roletype、section、sectionhead、select、structure、widget、window	「作成者は抽象ロールをコンテンツに使ってはならない（MUST NOT）」。体系を作るためだけにある
ウィジェット	button、checkbox、option、slider、switch、tab、textbox。複合ウィジェットのcombobox、grid、listbox、menu、radiogroup、tablist、tree	操作できる部品。キー操作と動作はページが用意する
文書構造	article、generic、heading、img、list、none、table、toolbar、tooltip	内容を整理する。通常は操作しない
ランドマーク	banner、complementary、contentinfo、form、main、navigation、region、search	移動の目印になる領域
ライブリージョン	alert、log、marquee、status、timer	変化が読み上げられる内容
ウィンドウ	alertdialog、dialog	ページの中のウィンドウ

aria-* 属性は、ステートとプロパティに分かれます。WAI-ARIA 1.2の6.1節によれば、aria-labelledby のようなプロパティは、aria-checked のように操作でよく変わるステートより、値が変わりにくいものです。ただし、これは決まりではなく、aria-valuetext のように頻繁に変わるプロパティもあるとしています。仕様書では、両方をまとめて「属性」と呼ぶことがほとんどです。

どれも、要素の動作は変えません。WAI-ARIA 1.2の1.3節は、ARIAはアクセシビリティAPIに公開する内容を改善するだけで、それ以外はユーザーエージェントは本来どおりに動作すると説明しています。たとえば次のコードです。

<div role="button">変更を保存</div>

ツリーには「変更を保存」という名前のボタンが入ります。それでも div にはフォーカスが移らず、EnterキーもSpaceキーも効きません。フォーカスとキー操作は、要素と tabindex、スクリプトが決めるもので、ARIAが決めるものではないためです。続きは「Tabキーで到達できないdivのボタン」で説明しています。

W3CのUsing ARIAは、HTMLでARIAを使うときのルールをまとめた文書です。最後の草案（2018年9月27日）にはルールが5つありました。2026年2月24日、W3Cはこの文書を作業中止の草案として公開しました。ルールは「経緯を残し、参照しやすくするため」4つが残され、それ以上の指針はARIA Authoring Practices Guideを参照するよう書かれています。もともと参考情報で、要件ではありません。

ルール	内容	例
1	必要な意味と動作を備えたHTML標準の要素や属性があれば、別の要素にARIAを足さずにそれを使う	Tabキーで到達できないdivのボタン
2	どうしても必要な場合以外は、HTML標準の意味を変えない。<h2 role="tab"> ではなく <div role="tab"><h2>…</h2></div> と書く	Using ARIA自身の例。ただしWAI-ARIA 1.2ではtabの子孫は表示のためだけのもの（5.2.9節）で、ブラウザーはh2を見出しとして公開しないことになっている
3	ARIAで作った操作部品は、すべてキーボードで使えるようにする	ウィジェットの中の矢印キー：roving tabindexとaria-activedescendant
4	フォーカス可能な要素に role="presentation" や aria-hidden="true" を使わない	Tabで届くのに読み上げられない、aria-hiddenの要素
5（2018年の草案のみ）	操作できる要素には、すべてアクセシブル名を付ける	名前がないアイコンだけのボタン

5つ目のルールは作業中止の版にはありません。ただし、求められていること自体は変わらず、WCAG 2.2の達成基準4.1.2が、すべてのユーザーインターフェイスコンポーネントに名前を求めています。

ブラウザーは、Accessible Name and Description Computation（AccName）に従ってアクセシブル名を決めます。W3C勧告は1.1（2018年12月18日）で、1.2はこの記事の日付の時点で草案（2026年10月21日）です。どちらも次の順に調べ、最初に名前が得られたところで決まります（AccName 1.1の4.3節。ラベルの中に埋め込まれたコントロールの手順は省いています）。

1. 隠れた要素： 名前になりません。aria-labelledby、aria-describedby、label から直接指されている場合は別です。
2. aria-labelledby： 指している要素の文字を、書いた順につなげます。ページにないidは飛ばされます。「読み上げを誤らせる、無効なARIA」はこの例です。
3. aria-label： その値です。要素の中の文字に代わって名前になります。ボタンに「かごに入れる」と表示しながら別の名前にできてしまうのはこのためで、「表示と名前が食い違うボタンとリンク」で説明しています。
4. 要素自身のラベル： label 要素、alt、表の caption などです。
5. 中身： button、link、checkbox、option、tabなど、中身から名前を得るロールでは、中の文字を子要素ごとに、CSSの ::before と ::after の文字も含めて集めます。titleのないSVGしかないボタンでは何も得られません（名前がないアイコンだけのボタン）。
6. ツールチップ： title です。ほかのどれからも名前が得られなかったときだけ使います。

HTML-AAMの4.1節は、要素ごとにこの中の順番を定めています。テキストの入力欄では、aria-labelledby か aria-label、label、title、placeholder の順です。button では、aria-labelledby か aria-label、label、中身、title の順です。img では、aria-labelledby か aria-label、alt、title の順です。

名前を付けられないロールもあります。WAI-ARIA 1.2の5.2.8.6節にgenericやparagraphなどが挙げられ、AccName 1.2は、作成者がそれらに aria-label や aria-labelledby を使ってはならない（MUST NOT）としています。普通の span に付けた aria-label がスクリーンリーダーに届かないことがあるのはこのためで、「読み上げられないことが多い、divやspanのaria-label」で説明しています。

アクセシブルな説明は、名前とは別のプロパティです。AccName 1.1の4.2節では、aria-describedby が指す要素から作ります。草案のAccName 1.2とHTML-AAMの4.2節は、もう少し詳しい順番を示しています。aria-describedby、aria-description、名前に使われていない表の caption などの要素、名前に使われていない title の順です。aria-description はWAI-ARIA 1.2にはありません。説明をいつ読むかはスクリーンリーダーごとの対応の問題で、ツリーの問題ではありません。組み合わせごとの確認はスクリーンリーダーの対応状況にまとめています。名前を付ける属性の違いは、名前と説明の比較にまとめています。

次の2つのブラウザーでは、ページから作ったアクセシビリティツリーを見られます。Firefoxのインスペクターが示すのはFirefox自身のツリーで、どのプラットフォームでも同じです。プラットフォームのAPIに渡った形ではありません。

• Chrome： Elementsパネルで要素を選び、Accessibilityタブを開きます（ボタン名などは英語版の表示です。タブはMore Tabsボタンの奥にあることもあります）。ツリーの中での位置、ARIA Attributes、Computed Propertiesが表示されます。Show accessibility treeをオンにすると、DOMツリーの代わりにページ全体のアクセシビリティツリーが表示されます。
• Firefox： 開発ツールのAccessibilityタブを開くか、ページを右クリックしてInspect Accessibility Propertiesを選びます（英語版の表示です）。左のパネルに各オブジェクトのロールと名前が並び、右のパネルに名前、ロール、操作、値、説明、状態、関係などが表示されます。Check for issuesでは、Contrast、Keyboard、Text Labelsの問題だけに絞り込めます。Show Tabbing Orderをオンにすると、フォーカス可能な要素に番号が付きます。

ロールの呼び方はブラウザーによって違い、Firefoxではボタンが「pushbutton」と表示されます。コントロールごとにロール、名前、説明、状態を読み、画面の表示と合っているか確かめます。ツリーで分かるのは情報があるかどうかまでです。スクリーンリーダーがそれをどう読むかは、製品、モード、バージョンによります。ほかの確認方法は「無料のアクセシビリティツール」にあります。