AIはアクセシビリティをレビューできるのか？

Posted at 2026-10-21

はじめに: 第5回の問い

このシリーズでは、Web上の意味が支援技術へ届くまでの経路、Shadow DOMのカプセル化、Fluent UIのようなUIライブラリが担う複雑な操作、そしてaxe-coreやブラウザー、キーボード、スクリーンリーダーがそれぞれ異なる層を検証することを見てきました。

第4回の記事では、axe-core、Chrome DevTools、Accessibility Tree、キーボード、スクリーンリーダーを、同じものを測る道具ではなく、別々の層を確かめる手段として整理しました。今回はその続きとして、次の問いを考えます。

AIはアクセシビリティをレビューできるのでしょうか。

「AIならできる」「AIにはできない」の二択では答えられません。ソースコードだけを読むのか、実行中のブラウザーを操作できるのか、axe-coreの結果やARIA Snapshotを受け取るのか。AIがアクセスできる情報と実行できる検証によって、レビューできる範囲は変わります。

この記事では、WCAGの達成基準、axe-coreのルール、ブラウザーが公開するアクセシビリティ情報、スクリーンリーダーの読み上げ、そして利用者の体験を分けながら、AIがどこを支援できるかを見ていきます。

「WCAG適合」と「自動テストの合格」は同じではない

WCAG 2.2の達成基準は、特定の技術に依存しない、検証可能な基準として書かれています。日本語では、規格上の用語に沿って「WCAG適合」や「達成基準への適合」と表現します（WAICによる日本語訳でも「適合」と表記されています）。

ただし、達成基準が検証可能であることは、すべてを一つの自動テストで判定できるという意味ではありません。W3CのUnderstanding Conformanceは、達成基準の検証には自動テストと人による評価の組み合わせが必要と説明しています。また、達成基準を満たしていても、さまざまな障害のある人にとって常に使いやすいとは限らず、ユーザビリティ評価も推奨しています。

たとえば、WCAG 2.2の達成基準2.1.1「キーボード」は、次のように始まります。

“All functionality of the content is operable through a keyboard interface”

— WCAG 2.2, Success Criterion 2.1.1 Keyboard（抜粋）

PlaywrightでTabキーを一度押し、特定のリンクにフォーカスが当たることを確認するのは有用です。しかし、その一つの検査だけで「ページ内のすべての機能がキーボードで操作できる」とは言えません。達成基準が求める範囲と、テストが実行した操作の範囲は別だからです。

WCAG適合には、選択した適合レベルの達成基準を満たすだけでなく、ページ全体を対象にすること、プロセスの一部であるページならプロセス全体を満たすこと、アクセシビリティサポートのある技術の使い方で達成することなど、複数の要件があります。WCAG 2.2の適合要件

このため、ある画面のaxe-core実行結果が成功しても、Webサイト全体や購入・申請の一連のプロセスがWCAGに適合したとは結論できません。サイト全体を評価する場合、W3CのWCAG-EMのように、評価範囲を定義し、サイトを調査し、代表ページを選び、評価して結果を報告する方法論もあります。

達成基準、axe-coreのルール、APGのパターン

これらも混同しないようにしましょう。

🧭 用語	何を表すか
WCAGの達成基準	適合性を判断するための規格上の要求事項
axe-coreのルール	ページ上の特定の状態を自動検査する実装可能なチェック
ARIA Authoring Practices Guide（APG）	UIパターンやキーボード操作を示す情報提供のガイド

axe-coreのルールには、WCAGのバージョンや適合レベル、達成基準に対応するタグが付くことがあります。一方で、best-practiceのようにWCAGの達成基準そのものではないルールもあります。たとえばaxe-coreのarea-altルールには、複数の達成基準に対応するタグが付いています。ルールと達成基準は一対一ではありません。 ルールにWCAGタグがあることも、WCAG全体を検証したことを意味しません。axe-core API: Tags

axe-coreにはACTタグが付くルールもあります。ACT Rules Formatは、自動テストと手動テストのルールを一貫した形式で記述するためのW3C仕様です。ACTルールも特定のコンテンツを特定の観点で検査するルールであり、それ自体をWCAGの達成基準やサイト全体の適合判定と同一視するものではありません。W3C: ACT Rules Format 1.1

APGは、ARIA、HTML、CSSなどの仕様を踏まえた実装パターンや操作方法を説明する有用なガイドです。しかしW3C自身が、APGは規範的な標準ではなく、適合モデルを持たない情報提供の資料だと説明しています。したがって、APGのパターンをAIに参照させることは実装レビューに役立ちますが、「APGのサンプルと違う」ことだけでWCAG違反とは言えません。APG: Introduction

AIが見ているものによって、レビューの範囲は変わる

「AIによるアクセシビリティレビュー」という単一の機能があるわけではありません。AIが受け取る情報と、使える検証ツールに応じて、観察できる対象は変わります。

ソースコードだけを見るAI
        ↓
HTML / JSX / CSSから静的な問題を推測する

実行中のページを見るAI
        ↓
レンダリング後のDOMや、操作後の状態を観察する

axe-coreの結果を受け取るAI
        ↓
自動検出された違反や、手動確認が必要な結果を解釈する

Playwrightを操作できるAI
        ↓
ページ遷移、操作、DOM、フォーカスなどをテストする

ARIA Snapshotを利用するAI
        ↓
ブラウザーが公開するアクセシビリティ上の構造を比較する

人間と利用者
        ↓
意味、理解しやすさ、操作体験、認知負荷、期待との一致を判断する

これはAIの能力の順位を表すものではなく、レビューに使う根拠の違いを表しています。ソースコードの指摘に実行結果が添えられていなければ、その指摘はコードからの推測です。ブラウザーを操作したというなら、対象ページ、操作した状態、実行ログなどを確認したいところです。

GitHub Copilotの「レビュー」も一種類ではない

GitHub Copilot Chat、Copilot code review、Copilot cloud agentは、それぞれ役割が異なります。

🤖 機能	主な役割	アクセシビリティレビューで見るポイント
Copilot Chat	質問への回答やコードの説明、提案	与えたコードや会話、利用可能なリポジトリ情報
Copilot code review	Pull Requestの変更をレビューし、指摘や修正案を提示	差分、リポジトリの文脈、利用可能なエージェント機能やツール
Copilot cloud agent	リポジトリを調査し、コードを変更してテストなどを実行	実際に読み書きしたファイル、実行したコマンドやテスト

Copilot code reviewができること、できたと確認できること

GitHubの公式ドキュメントでは、Copilot code reviewはPull Requestをレビューし、問題を指摘して修正案を提案する機能として説明されています。提案は利用者が確認して適用します。既定のレビューは「Comment」であり、Pull Requestの必須承認数には数えられません。Copilotによる承認機能は、執筆時点ではPublic Previewです。GitHub Copilot code review

同じドキュメントは、エージェント機能によるリポジトリ全体の文脈収集や、GitHub Actionsランナーを使う構成についても説明しています。さらに、関連するレビューではMCPサーバーを利用でき、GitHub MCPとPlaywright MCPが有効であると記載されています。

これは重要な変化です。Copilot code reviewを「差分だけを読む静的なAI」と決めつけることはできません。一方で、ツールを利用できることと、個々のレビューで実際にブラウザーを操作し、対象画面を検証したことは同じではありません。GitHub ActionsやMCPの利用可能性は、特定のPRでどのページや状態を検査したかの証拠にはなりません。

カスタム指示も、機能や利用環境ごとに対応状況が異なります。GitHub.com上のCopilot code reviewでは、.github/copilot-instructions.mdによるリポジトリ全体の指示、.github/instructions/**/*.instructions.mdによるパス固有の指示、AGENTS.mdなどのエージェント指示がサポート対象として記載されています。ただし、公式のカスタム指示サポート一覧を見ると、Copilotの機能やIDEごとに対応範囲は異なります。

たとえば、指示ファイルに「ダイアログを開いた状態も確認する」「aria属性の存在だけでなく、意味のある名前かを検討する」と書けば、レビューの観点を共有できます。しかし、その指示を書いただけでは、ダイアログを開いたテストが実行されたことにも、ラベルが利用者にとって理解しやすいことにもなりません。カスタム指示はレビューのガイドであり、検証結果そのものではありません。

GitHubのドキュメントでは、Copilot code reviewは一般提供（GA）として扱われ、GitHub.com、GitHub CLI、GitHub Mobile、VS Code、Visual Studio、Xcode、JetBrains IDEsなどの利用面が案内されています。Azure DevOps連携とCopilot approvalsはPublic Previewとして記載されています。利用できる機能や料金はプラン、管理者ポリシー、リポジトリ設定によって変わるため、導入時には公式の提供状況を確認してください（2026年10月21日確認）。

Copilot cloud agentはコードを動かせるが、テスト範囲は別に確認する

Copilot cloud agentは、Copilot code reviewとは異なり、リポジトリの調査、計画、ファイルの編集、テストやリンターの実行をクラウドの開発環境で行うエージェントとして説明されています。GitHub.com上のCopilot Chat、cloud agent、code reviewは、同じ画面や会話から利用できる場合があっても、実行する作業は別です。GitHub Copilot on GitHub.com

エージェントがPlaywrightのテストを実行し、その結果を得たなら、AIはコードだけでなく、そのテストが通ったという追加の根拠を使えます。ただし、その意味は「実行したテストで、記述された条件を確認できた」です。対象ページや状態が限られていれば、サイト全体や全ユーザーフローへの結論にはなりません。GitHubも、エージェントセッションのログは作業やツールを確認する手がかりになる一方、人間によるレビューやテストの代わりにはならないと説明しています。

axe-coreの結果をAIに渡すとき

Playwrightの公式ガイドは、JavaScript / TypeScript向けに@axe-core/playwrightのAxeBuilderを使う例を示しています。C#ではDequeの.NET向け統合パッケージDeque.AxeCore.Playwrightを使い、Page.RunAxe()で現在のページ状態を検査できます。

using System.Threading.Tasks;
using Deque.AxeCore.Playwright;
using Microsoft.Playwright.NUnit;
using NUnit.Framework;

[TestFixture]
public class AccessibilityTests : PageTest
{
    [Test]
    public async Task PageHasNoReportedAxeViolations()
    {
        var page = Page!;
        await page.GotoAsync("https://example.test/");

        var results = await page.RunAxe();

        Assert.That(results.Violations, Is.Null.Or.Empty);
    }
}

violationsが空であることは、この実行時のページ状態と、実行対象になったaxe-coreのルールで、違反として報告されたものがなかったという意味です。これは「このサイトはWCAG 2.2 AAに適合している」という判定ではありません。

axe-coreの結果には、違反のviolations、ルールに合格したpasses、判定が確定できず手動確認を要するincomplete、該当要素がなかったinapplicableがあります。特にincompleteは「問題なし」ではありません。axe-coreは、技術的な制約などで合否を決められなかった項目を、追加評価の対象として分けています。axe-core API: Results Object

また、axe-coreは画面の状態を自動で全て作り出すわけではありません。たとえば閉じたメニューを検査した後、ボタンを操作してメニューを開き、表示状態でもう一度RunAxe()を実行する必要があります。Dequeの.NET向け統合パッケージも、Page.RunAxe()は呼び出し時点のページ状態を検査すると説明しています。検査ルールを絞る場合、JavaScript版のwithTags()やC#版のAxeRunOptions.RunOnlyで選んだタグと、利用中のaxe-coreがそのタグに対応しているかを確認します。Playwright: Accessibility testing Deque.AxeCore.Playwright: Usage and API

AIに結果を渡すときは、「axeが合格した」と一言で済ませず、次の情報も一緒に渡すとレビューの根拠が明確になります。

どのURL、ブラウザー、画面状態を検査したか
どのaxe-coreのバージョンとルールタグを使ったか
violationsとincompleteの内容、および修正後の再検査結果

AIはルール違反の説明や修正案の整理を支援できます。しかし、incompleteを自動的に「問題なし」へ読み替えたり、実行範囲外のページまで問題がないと結論づけたりしてはいけません。

Playwrightで検証できる操作とARIA Snapshot

Playwright for .NETでは、GetByRole()で要素のroleやアクセシブルネームを指定して操作できます。公式ガイドは、ユーザーや支援技術から見える属性に近い方法としてrole locatorを推奨しています。ただし、role locatorはアクセシビリティ監査や適合性評価の代わりではないとも明記されています。Playwright for .NET: Locators

Playwrightからキーボードイベントを送り、フォーカス先をアサーションすることもできます。

using System.Threading.Tasks;
using Microsoft.Playwright;
using Microsoft.Playwright.NUnit;
using NUnit.Framework;

[TestFixture]
public class KeyboardAccessibilityTests : PageTest
{
    [Test]
    public async Task TabMovesFocusToSkipLink()
    {
        var page = Page!;
        await page.GotoAsync("https://example.test/");

        var skipLink = page.GetByRole(
            AriaRole.Link,
            new() { Name = "本文へ移動" });

        await page.Keyboard.PressAsync("Tab");
        await Expect(skipLink).ToBeFocusedAsync();
    }
}

これは、指定した状態でTabキーを押したとき、指定のDOM要素にフォーカスがあることを検証します。フォーカスが視覚的に十分見えるか、操作順序が利用者の目的に合うか、すべての機能をキーボードだけで使えるかまでは、このアサーションだけでは判断できません。Playwright for .NET: Keyboard API LocatorAssertions: ToBeFocusedAsync

Playwright for .NETのARIA Snapshotは、ページや要素のアクセシビリティツリーをYAML形式で表し、期待する構造と比較するための機能です。API名はToMatchAriaSnapshotAsync()で、Playwright for .NET v1.60で追加されました。

await Expect(Page!).ToMatchAriaSnapshotAsync(@"
  - main:
    - heading ""設定"" [level=1]
    - button ""保存""
");

これにより、特定の画面状態でrole、名前、階層などが意図した構造になっているかを回帰テストできます。一方、Snapshotが一致しても、ボタンの「保存」という名前が文脈上適切か、キーボード操作が一貫しているか、スクリーンリーダーで期待どおりに読み上げられるかを保証するわけではありません。Playwright自身も、Snapshotと個別アサーションには異なる用途があると説明しています。Playwright for .NET: ARIA snapshots

Accessibility Tree、スクリーンリーダー、利用体験

ブラウザーのAccessibility Treeは、DOMそのものではなく、DOMなどからユーザーエージェントが構成し、アクセシビリティAPIを通じて支援技術に公開する情報のモデルです。W3CのAccessible Name and Description Computationは、ユーザーエージェントがアクセシブルオブジェクトの名前や説明を計算し、その情報をアクセシビリティAPIへ公開すると説明しています。執筆時点でWAI-ARIA 1.2はW3C Recommendation、Accessible Name and Description Computation 1.2はWorking Draftです。WAI-ARIA 1.2 Accessible Name and Description Computation 1.2

Chrome DevToolsでは、Accessibilityタブからアクセシビリティツリーや、計算されたアクセシビリティプロパティを調べられます。Playwright MCPも、Playwrightを通じて構造化されたアクセシビリティスナップショットをAIに提供する仕組みです。Chrome DevTools: Accessibility reference Microsoft Playwright MCP

ただし、ブラウザーが公開するツリーと、スクリーンリーダーが実際に読み上げる音声は同じものではありません。プラットフォームのアクセシビリティAPI、ブラウザー、支援技術、操作方法が関わります。名前やroleがツリーに存在することと、その説明が利用者に伝わることも別です。スクリーンリーダーでの読み上げや実際の利用者の操作を確かめる工程は、ARIA Snapshotの比較だけでは置き換えられません。

AIをアクセシビリティレビューに使うときの進め方

AIに「アクセシビリティを確認して」とだけ依頼するより、何を見て、何を確認したかを明らかにする方が有効です。

範囲を決める: 対象ページ、重要なユーザーフロー、表示状態、目標とするWCAGの適合レベルを明示します。
観察手段をそろえる: ソースコード、axe-coreの報告、Playwrightテスト、ARIA Snapshotなど、使った根拠を渡します。
主張と根拠を分ける: 各指摘について、関連する達成基準、axeルール、検査した状態、実行結果を分けて記録します。
未検証の領域を残す: incomplete、未実行のページ、テストしていない操作、スクリーンリーダーの確認などを「未確認」として明示します。
人が確かめる: キーボードやスクリーンリーダーで実際に操作し、必要に応じて利用者を含むユーザビリティ評価を行います。

レビュー結果を、たとえば次のように区別できると、過大な結論を避けられます。

📝 結果の種類	記録例
自動検出された事実	axe-coreの`button-name`ルールが、対象ページの特定ボタンを違反として報告した
テストで確認した事実	メニューを開いた状態で、Tabキーの後にフォーカスが指定要素へ移動した
AIの推論・提案	ボタン名が「開く」だけでは対象が分かりにくい可能性がある
未確認事項	画面読み上げ、他の画面状態、利用者にとっての分かりやすさは未確認

「検査が成功した」ことを伝えるなら、何が実行され、どの範囲が対象だったのかをセットで説明します。これはAIに限らず、アクセシビリティの自動検査結果を共有するときに必要な姿勢です。

おわりに

AIはアクセシビリティレビューを支援できます。コードから意味的な問題を見つけ、axe-coreの結果を読み解き、Playwrightで指定した状態を操作し、ARIA Snapshotの差分を説明することもできます。支援の幅は、モデル名だけでなく、何にアクセスでき、どのツールを実行し、どの結果を受け取ったかで決まります。

しかし、テストの成功はWebサイト全体のWCAG適合ではありません。達成基準、axe-coreのルール、ブラウザーが公開するアクセシビリティ情報、スクリーンリーダーの読み上げ、キーボード操作、利用者の体験は、それぞれ別の対象です。

だからこそAIのレビューには、結論だけでなく根拠と範囲を求めたいところです。自動化できる確認を継続的に行い、未確認のことを未確認として残し、人と利用者による評価につなげる。その役割分担の中で、AIはアクセシビリティを前進させる実用的なレビュー支援者になれると考えています。

参考情報

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up