1. アクセシビリティレビューで本当によくある会話
レビュー担当
「スクリーンリーダーで操作しづらいですね」
開発者
「でもaxeは通っています」
どちらかが間違っているのでしょうか。そうとは限りません。
axe が検出するルール違反がなくても、スクリーンリーダーで目的の操作を完了できないことはあります。反対に、操作しづらいという指摘があっても、axe が検出する種類の違反とは限りません。
これは、アクセシビリティに単一の正解ツールがないからです。ツールごとに見ている場所が違います。今回は「どのツールが優れているか」ではなく、それぞれが何を検証しているのかを整理します。
2. そもそも我々は何を検証しているのか
第 1 回では、情報がユーザーに届く経路を次のように整理しました。
HTML
↓
DOM
↓
Accessibility Tree
↓
Platform Accessibility API
↓
支援技術
↓
ユーザー
ここでいう DOM は Document Object Model の略です。Platform Accessibility API（プラットフォームのアクセシビリティ API）は、ブラウザーが OS を通じて支援技術へ意味を伝える接点です。API は Application Programming Interface の略です。
シリーズの第 1 回では HTML からスクリーンリーダーまでの経路を、第 2 回では Shadow DOM と支援技術の関係を、第 3 回では Fluent UI とアクセシビリティを扱いました。
第 3 回で見たように、UI ライブラリはフォーカスやキーボード操作の実装を助けます。しかし、ライブラリを使うことと、ユーザーが実際に操作できることを確かめるのは別の話です。今回は、実装を支える仕組みから一歩進み、何をどの層で検証するかを考えます。
この図は情報伝達を考えるためのモデルです。すべてのブラウザーに共通する単一の内部ツリーがあり、それをそのまま各スクリーンリーダーが読む、という意味ではありません。
WAI-ARIA（Web Accessibility Initiative - Accessible Rich Internet Applications）はロール・状態・プロパティなどの意味を定義します。Accessible Name and Description Computation（AccName）は、名前や説明の計算方法を扱います。
HTML Accessibility API Mappings（HTML-AAM）と Core Accessibility API Mappings（Core-AAM）は、HTML や ARIA の意味をプラットフォームのアクセシビリティ API にどう対応づけるかを記述します。WAI-ARIA 1.2 / AccName 1.2 / HTML-AAM 1.0 / Core-AAM 1.2
仕様は意味や対応づけを説明しますが、ブラウザーや OS が実際に何を公開するかは実装の話です。また、リンク先の W3C 文書はバージョンごとに状態が異なります。2026 年 10 月時点では WAI-ARIA 1.2 は Recommendation、AccName 1.2 と HTML-AAM 1.0 は Working Draft、Core-AAM 1.2 は Candidate Recommendation Draft です。仕様の役割と、製品で確認できる挙動は分けて考えましょう。
axe、DevTools、スクリーンリーダーは、この経路の同じ場所を見ているわけではありません。
3. axeは何を見ているのか
axe-core は、Web サイトや HTML ベースの UI を検査するアクセシビリティテストエンジンです。ページ上で JavaScript として実行し、検査結果を受け取って、違反を修正したりテストで結果を確認したりします。axe-core の READMEとJavaScript API の説明には、既存のテスト環境に組み込むワークフローが示されています。
axe DevTools は axe-core を基盤とする開発者向けツール群です。ブラウザー拡張やテスト用 API などを通じて検査をワークフローに組み込めます。axe DevTools for Web の公式ドキュメントも、axe-core をそのエンジンとして説明しています。
検査対象は、呼び出した時点でページ上に現れているコンテンツと、その DOM や ARIA などの情報です。axe-core の API ドキュメントは、非表示のメニューやモーダルは検査されないため、表示させてから再度検査するよう説明しています。つまり、ページを一度スキャンして終わりではなく、メニューを開いた状態、入力エラーが出た状態など、ユーザーが通る画面状態ごとに検査する必要があります。
たとえば初期状態の画面で axe の違反がゼロでも、メニューを開いた後にフォーカスが適切に移動するか、キーボードだけで操作できるかは別に確認します。
WCAG と axe のルールも同じものではありません。Web Content Accessibility Guidelines（WCAG）2.2 の達成基準は、特定の技術に依存しないテスト可能な記述です。一方、axe のルールには WCAG の達成基準に対応するものだけでなく、ベストプラクティスとして分類されるものもあります。WCAG 2.2 / axe-core のルール一覧 / Playwright のアクセシビリティテストガイド
自動で判定しやすいのは、たとえば必須属性の欠落や、ARIA の使い方に関する一定のルール違反です。しかし、属性があることと、その内容がユーザーにとって適切であることは別です。Deque の image-alt ルールは画像に代替テキストがあるかを検査しますが、同じページは代替テキストが画像の目的や意味を伝えるべきだと説明しています。テキストが存在することだけでは、伝わる内容の質までは証明できません。 Deque の image-alt ルール
axe-core は検出できる問題を早く、繰り返し見つけるために重要です。一方で、自動検査の結果がゼロでも、キーボードで操作を完了できるか、読み上げが文脈に合うかまでは保証しません。axe-core 自身も、判断を確定できない項目を incomplete として返し、手動確認が必要になる場合を説明しています。
4. Chrome DevToolsは何を見ているのか
Chrome DevTools の Accessibility タブ（Accessibility Pane）では、DOM のノードを選び、Accessibility Tree 上での位置や ARIA 属性、計算されたアクセシビリティプロパティを確認できます。たとえば、ブラウザーが要素をどのロールとして扱い、どんな Accessible Name（アクセシブルネーム）や状態を計算したかを調べるのに役立ちます。Chrome DevTools Accessibility reference / WAI-ARIA 1.2
ここで見ているのは、ブラウザーがそのページをどう解釈したかです。DOM に aria-label を書いたつもりでも、名前の計算結果が想定と違う。あるいは、要素に指定した ARIA の状態が期待どおり表現されていない。そうした「ソースに書いた値」と「ブラウザーが計算した結果」の食い違いを調べられます。
ただし、Chrome DevTools のツリーを、すべての支援技術が受け取る情報と同一視することはできません。Chrome の説明では、DevTools のツリーは Chromium 内部の情報を表示し、プラットフォームごとにアクセシビリティ API や属性の扱いが異なるとされています。また、ツリー表示には見やすさのための表示上の処理もあります。Chrome の Full Accessibility Tree 解説
さらに、ツリーに名前やロールが表示されても、Tab キーでその要素に到達できるか、Enter や Space で期待した操作ができるかは別の確認です。Chrome DevTools の公式ガイドも、キーボードやスクリーンリーダーでの移動を確かめるには、実際にページを操作する必要があると説明しています。
5. スクリーンリーダーは何を見ているのか
ブラウザーは Web の意味をプラットフォームのアクセシビリティ API に対応づけ、スクリーンリーダーなどの支援技術はその情報を受け取って、ユーザーが読み、移動し、操作できる形にします。W3C の仕様はこの対応づけを説明し、Microsoft の UI Automation は Windows 上で支援技術や自動テストが UI 情報を取得・操作するための API として説明されています。Core-AAM / HTML-AAM / Microsoft UI Automation
ここに、読み上げや点字出力だけでなく、各支援技術の操作モデルが加わります。たとえば NVDA のユーザーガイドには Browse Mode があり、Microsoft の Narrator ガイドには Scan Mode があります。VoiceOver には VoiceOver カーソルやローターがあり、JAWS の公式トレーニングには Web 閲覧やキーボード操作の手順があります。NVDA User Guide / Narrator の完全ガイド / VoiceOver User Guide / JAWS documentation / JAWS Getting Started
Microsoft のアクセシビリティ資料も、スクリーンリーダーの振る舞いは製品やユーザー設定によって異なり、すべての支援技術が同じプロパティをサポートするわけではないため、複数の支援技術で確認するよう勧めています。Microsoft Accessibility overview
したがって、次のような単純な変換ではありません。
Accessibility Tree
↓
そのまま音声
ブラウザーの公開情報に加えて、スクリーンリーダー固有の移動、読み上げ方、ショートカット、仮想的な読み取り位置などが関わります。DevTools のツリーだけでは、実際のユーザーがどのように情報を受け取り、目的の操作にたどり着くかを再現できません。
6. Playwrightや自動テストはどこを見るのか
Playwright はブラウザーを操作し、ページの現在の状態に対してアサーションやテストを実行します。アクセシビリティテストガイドでは、@axe-core/playwright を使い、画面を表示したり操作したりした後に axe-core のスキャンを実行する流れを紹介しています。操作後の状態を待ってからスキャンする必要があることも説明しています。
また、Playwright の ARIA Snapshot は、ページのアクセシブルな構造をスナップショットとして検証する仕組みです。ロール、名前、階層、状態などに対して期待する構造をテストできます。ただし、公式ドキュメントが説明するのはアクセシビリティツリーに対するアサーションであり、スクリーンリーダーの音声や操作体験そのものではありません。テンプレートはツリー全体の完全なシリアライズではなく、一部だけを指定した検証もできます。Playwright: Accessibility testing / Playwright: ARIA snapshots
つまり、Playwright を使えばブラウザーを自動操作できるからといって、Playwright のテストがスクリーンリーダーのテストになるわけではありません。どの状態を作り、何をアサートしているかが検証範囲を決めます。
7. だから全部必要になる
ここまでを整理すると、検証対象は次のように分かれます。
axe
↓
ルール違反を検出する
DevTools
↓
ブラウザーが計算した意味を確認する
Keyboard
↓
フォーカスと操作を確認する
Screen Reader
↓
支援技術を通した利用体験を確認する
axe は自動化できるルール違反を繰り返し検出します。DevTools は DOM と Accessibility Tree を行き来し、名前やロールなどブラウザーの解釈を調べます。キーボード操作では、フォーカス順、フォーカスの見え方、操作の完了、キーボードトラップの有無を確認します。WCAG にもキーボード操作やトラップに関する達成基準があります。WCAG 2.2: Keyboard Accessible
スクリーンリーダーでは、情報の読み上げ順、移動のしやすさ、状態変化の伝わり方、タスクを完了できるかを実際に確かめます。Microsoft の Accessibility Insights for Web も、FastPass の中で自動チェックに加えて Tab stops の確認や、人の判断を必要とする項目を扱っています。Accessibility Insights for Web / FastPass
Playwright はこの並びに単独の「検証層」として加わるというより、ページを所定の状態にし、axe-core のスキャンや ARIA Snapshot のようなアサーションを自動化するテスト基盤です。何をテストするかで観測対象は変わり、スクリーンリーダーでの操作確認の代わりにはなりません。
どれかひとつを「正解」にするのではなく、確かめたいことに合わせて使い分けます。WCAG のキーボード操作、キーボードトラップの防止、フォーカス順序、フォーカスの可視化も、それぞれ確かめる内容が異なります。
8. Accessibility Treeを見れば十分なのか
答えは No です。
それでも Accessibility Tree を見る価値はとても大きいです。DOM の構造だけでは分からない、ブラウザーが計算したロールや名前、状態を確認できます。スクリーンリーダーで問題が起きたときに、意味がブラウザーから公開される段階ですでに欠けているのか、それとも次の層に原因があるのかを切り分ける手掛かりにもなります。Accessibility Tree は重要ですが、ユーザー体験そのものではありません。
ただし、そのツリーが正しく見えても、キーボード操作が成立するとは限りません。プラットフォーム API を通った先で、使っている支援技術がどう読み上げ、どう操作させるかも確認が必要です。
DOMだけ見る ×
Accessibility Treeだけ見る ×
スクリーンリーダーだけ見る ×
必要なレイヤーを全部見る ○
axe ≠ DevTools ≠ Screen Reader
「全部見る」は、すべての組み合わせを無制限に試すという意味ではありません。対象ユーザーと重要な操作経路に合わせて、ルール検査、ブラウザーの解釈、キーボード、支援技術の確認を組み合わせるということです。
9. AIはどこまでレビューできるのか
GitHub Copilot や Coding Agent にコードをレビューさせ、Playwright で操作を自動化し、axe-core や ARIA Snapshot で回帰を検知する。こうした仕組みは、アクセシビリティの問題を早く見つける助けになります。
ただ、テストが何を見ているかを理解せず、結果だけを「アクセシブル」の証明にしてしまえば、これまでと同じ落とし穴にはまります。AI がどの層を検証でき、どこから先に人の操作や利用者の視点が必要なのか。
次回は、**「AIはアクセシビリティをレビューできるのか？」**を考えます。