はじめに
「この画面をアクセシブルにしてください」と人工知能（AI）に頼めば、WCAG（Web Content Accessibility Guidelines）に準拠した Web アプリができあがるのでしょうか。便利な道具が増えるほど、私たちは「直した」という言葉の意味を慎重に考える必要があります。
この記事では、GitHub Issue から GitHub Copilot app のエージェントに依頼する場合の流れと、プルリクエスト（PR）を人が検証するための観点を整理します。今回は実験結果の報告ではなく、Playwright と axe-core による自動チェックや、人による利用体験の確認を含む検証設計を紹介します。
この記事で扱う検証はまだ実施していません。対象コードベースの調査、Copilot への依頼、PR 作成、テスト実行はいずれも行っておらず、以下は検証の設計と評価観点です。別の Web アプリを対象にした一度の確認記録は、記事末尾の参考記事として分けて紹介します。🧭
WCAG は、Web コンテンツのアクセシビリティに関するガイドラインです。WCAG 2.2 の AA 適合には、適合要件を満たしたうえで、適用されるレベル A と AA のすべての達成基準を満たす必要があります。自動テストの合格だけでは適合を宣言できません。まず、開発の品質要件として扱う理由を確認します。
— W3C, WCAG 2.2: Conformance Requirements
アクセシビリティは品質要件
アクセシビリティは、リリース直前に追加する「特別な機能」ではありません。フォーム入力やページ内の移動、エラーからの回復など、基本機能がさまざまな利用者に理解・操作できるかという品質の一部です。後回しにすると、画面構造や操作方法まで見直すことになります。
一方で、WCAG に適合することと、使いやすいことは同じではありません。達成基準を満たすことは大事な土台ですが、文脈に合った説明、迷いにくい操作、納得できるエラー回復まで自動で保証するわけではありません。
自動検出と人の判断
ツールは、フォームのラベルやアクセシブルネーム（支援技術に伝わる名前）、ARIA（Accessible Rich Internet Applications）構造、見出しの機械的な問題、色のコントラスト（1.4.3 Contrast (Minimum)）、重複 ID などを検出する手がかりになります。ただし範囲はツールと画面状態に依存し、達成基準全体は判断できません。
axe-core には、無効な ARIA 属性やアクセシブルネームの不足などを検出するルールがあります。見出しレベルの順序を確認する heading-order もありますが、これはベストプラクティスとしての指摘です。見出しだけを読んで内容の流れが伝わるかは、人が確認する必要があります。
| 確認方法 | 主に見ること |
|---|---|
| 🤖 自動チェック | 名前やラベルの欠落、ARIA 構造の機械的な問題、見出し構造、重複 ID、特定条件でのコントラストなど |
| 🧑 人による確認 | 画像の代替テキストが目的に合うか、操作の目的が伝わるか、フォーカス順序が自然か、エラーから回復できるか |
| 🧑🦯 支援技術での確認 | スクリーンリーダーで情報や状態を理解でき、次の操作を見つけられるか |
alt の有無は検出できても、その文が画像の目的を伝えるかは文脈判断です。前半では「自動チェックだけでは十分でない」という原則を押さえ、後半で PR の具体的な確認方法を見ていきます。
Step 1: 自動チェックの一例 — Playwright と axe-core
Playwright のアクセシビリティテストガイドは、@axe-core/playwright によるチェック例と、自動テストに手動評価を組み合わせる必要性を説明しています。
— Playwright, Accessibility testing
Playwright と axe-core は検証方法の一例です。いつも依頼文にツール名や手順を列挙する必要はありません。リポジトリにあるテストや利用可能なツールを調べ、課題に合った方法をエージェントに選んでもらう進め方もできます。たとえば、私が別記事に記録した一度の観察では、目標を短く伝えた依頼に対し、ブラウザー上の確認や Lighthouse Snapshot などが使われていました。ただし、これはそのときの一例であり、同じ方法が毎回選ばれることや、WCAG 2.2 AA への適合を保証するものではありません。
— Qiita: WCAG 2.2 AA を目標にしたアクセシビリティ監査の記録
次は、NUnit と Microsoft.Playwright、axe-core の .NET 向け統合パッケージを使う一般的な C# の例です。テストプロジェクトに Microsoft.Playwright.NUnit と Deque.AxeCore.Playwright を追加します。URL は例示用なので、実際のプロジェクトではテスト対象の URL に置き換えてください。このコードは実行していません。
dotnet add package Microsoft.Playwright.NUnit
dotnet add package Deque.AxeCore.Playwright
using System.Threading.Tasks;
using Deque.AxeCore.Playwright;
using Microsoft.Playwright.NUnit;
using NUnit.Framework;
[TestFixture]
public class AccessibilityTests : PageTest
{
[Test]
public async Task Page_has_no_automatically_detectable_violations()
{
await Page!.GotoAsync("https://example.com/");
var results = await Page.RunAxe();
Assert.That(results.Violations, Is.Null.Or.Empty);
}
}
Playwright には .NET 用の NUnit、MSTest、xUnit のテスト基底クラスが用意されています。上の例は NUnit の PageTest を使い、Deque.AxeCore.Playwright の RunAxe() で axe-core を実行します。
このテストが調べるのは、呼び出し時点のページ状態です。メニューを開いた状態や送信後のエラー表示などは、操作してから個別にスキャンします。ルートや状態を増やしても、全ページ・全操作・全達成基準の網羅を意味しません。
違反名だけで修正を決めず、該当ノード・原因・利用者への影響・期待挙動を確かめます。診断は設計判断の代行ではありません。検出した候補を、原因・対象状態・期待する利用体験とともに Issue に整理すると、次の依頼が具体的になります。
Step 2: Issue を具体的な作業依頼にする
2026 年 9 月時点の GitHub Docs では、GitHub Copilot app の My work から Issue を開き、New session でそのコンテキストを引き継げます。Plan で計画を先に確認したり、Interactive で対話したりできます。Cloud agent はリポジトリを調査し、ブランチ上で変更や自動テストを行えます。機能や手順は環境・権限に依存するため、ここでは一般的な依頼フローとして説明します。
- GitHub Docs: Managing issues and pull requests with the GitHub Copilot app
- GitHub Docs: About GitHub Copilot cloud agent
「アクセシビリティを改善してください」のような短い依頼でも、エージェントがコードを調査し、利用できるツールから検証方法を選べる場合があります。実際にどこまで進められるかは、作業環境やツールへのアクセスに左右されます。また、依頼が短いほど、対象範囲や品質の判断を人が後から補う必要が出やすくなります。
たとえば、具体的な手順を任せたいときは、達成したい状態と報告してほしいことを伝え、Playwright や Lighthouse などの手段はエージェントに選ばせる書き方ができます。
このアプリのアクセシビリティを改善してください。
実装と検証に適した方法は、リポジトリと利用可能なツールを調べて選んでください。
選んだ方法と理由、確認した範囲、結果、未確認事項を Pull Request に記載してください。
対象画面や受け入れ条件を細かく指定したい場合は、Issue に追加します。どこまでを指示するかは、委譲したい判断の範囲と、必要なレビューの確かさに応じて調整できます。
具体的な Issue 本文テンプレートは、この節の後半に載せます。まず、依頼で達成基準を指定する際の参照例を確認します。
Issue で参照する達成基準を選ぶ
WCAG 2.2 の達成基準は番号と名称で参照し、内容を取り違えないようにします。以下では W3C の原文を引用し、続けて日本語で要点を説明します。いずれか一つの達成基準を満たしても、それだけで WCAG 2.2 AA 適合を表すものではありません。
1.1.1 Non-text Content（非テキストコンテンツ）
“All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.”要約: 原則として、利用者に提示する非テキストコンテンツには、同等の目的を果たすテキスト代替を提供します（例外があります）。
2.4.3 Focus Order（フォーカス順序）
“If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.”要約: ページを順次ナビゲートでき、その順序が意味や操作に影響する場合、フォーカス可能なコンポーネントは意味と操作性を保つ順序でフォーカスを受け取ります。
4.1.2 Name, Role, Value（名前・役割・値）
“For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”要約: UI コンポーネントの名前と役割をプログラムから判別でき、ユーザーが設定できる状態なども設定可能にし、その変更を支援技術を含むユーザーエージェントに伝えます。
達成基準の詳細な適用条件や例外は W3C の原文を参照し、Issue には該当する番号を明記しましょう。
Issue 本文テンプレート
以下は記入用テンプレートです。角括弧は置き換え用で、特定アプリの実装や確認済みの違反ではありません。未調査なら「確認して報告」とします。
## 目的
[ページ／コンポーネント名・URL] のアクセシビリティを改善します。
## 現象・対象
- 対象画面: [ルート、コンポーネント、操作状態]
- 確認できている問題: [再現手順と観察内容。未確認なら「調査して報告」]
- 関連する達成基準: WCAG 2.2 AA の [番号・名称]（該当する場合）
- 期待する利用者体験: [キーボード／スクリーンリーダー等で何ができるべきか]
## 制約
- 既存のフレームワーク、デザイン、命名規則を尊重し、変更範囲を必要最小限にする。
- まず意味のある HTML 要素を使う。ARIA は不足する意味や状態を補う必要がある場合に限る。
- UI の見た目や既存機能を不用意に変更しない。
- 問題や影響範囲を確認できない場合は、推測で変更せず質問・報告する。
## 受け入れ条件
- [対象状態] で問題が解消し、目的の操作・情報が利用できる。
- リポジトリで利用できるテストやブラウザー監査の方法を確認し、課題に合った方法で受け入れ条件を確かめる。ツールの選定は、必要に応じて実装担当のエージェントに任せる。
- 実行したテストや監査の方法・対象状態・結果・限界を報告する。実施できない確認があれば、その理由と未確認範囲を明記する。
- 関連する既存テストを実行し、失敗があれば変更との関係を説明する。
- 変更の理由、確認した達成基準、未確認の項目を PR に記載する。
## 検証方法に関する制約（必要な場合）
- [既存のCIで実行すること、特定のツールを使うことなど、必要な条件があれば記入]
- 指定がない場合は、既存の構成と利用可能なツールを調べて適切な方法を選び、選択理由を報告する。
## PR に記載すること
- 変更内容と対象画面
- 実行したテスト・自動チェックと結果
- 手動確認の内容、未実施の確認
- 既知の制約や、追加で必要な判断
Step 3: Issue から PR まで依頼する
流れは、Issue 作成、Copilot app での New session、計画・調査・変更・テスト、PR のレビューです。Plan を使える場合は対象範囲と変更方針を先に確認します。実装担当のエージェントは、依頼に書かれた目標と完了条件を踏まえ、既存テストや利用できるブラウザー監査などから方法を選ぶことがあります。ただし、選べる方法は実行環境やツールへのアクセスに左右されるため、必ず自律的にテストできるとは限りません。作業後は差分と結果を人が読み、未実施の確認を把握します。
PR を作成できることと、変更が利用者にとって正しいことは別です。変更をレビューし、必要なら反復します。PR をゴールにせず検証へ進みましょう。🧭
Step 4: PR で確かめること
PR では、少なくとも次の四つを分けて確認します。
- 問題は解消したか — Issue の再現手順と期待挙動に照らし、対象状態を実際に確認します。
- 自動チェックは再現できるか — 指定した、またはエージェントが選んだテスト・監査について、対象ページ・操作状態・結果・限界を確認します。Playwright と axe-core や Lighthouse など、使われた手段を記録します。継続的インテグレーション（CI）に組み込む場合は、PR ごとに同じ手順が走ることも確かめます。
- 既存機能は維持されたか — 関連するユニットテスト・エンドツーエンド（E2E）テストと主要操作を実行し、画面や挙動の回帰がないかを見ます。
- 利用体験は改善したか — 名前や状態が伝わるか、操作に迷わないか、エラーから戻れるかを人が確かめます。
ARIA 属性を足しただけで正解とは限りません。 ネイティブ HTML の意味を活用したほうが単純で堅牢な場合がありますし、誤った aria-label やロールは、見た目には変化がなくても情報を誤って伝える可能性があります。変更の理由とユーザーに伝わる結果を確認してください。
手動確認の観点
- マウスを使わず、キーボードだけで操作できるか。フォーカスが見え、順序が画面の意味と操作に合っているか。
- ブラウザーのズームや文字拡大で、内容が欠けたり操作不能になったりしないか。
- スクリーンリーダーで、ラベル・役割・状態・見出し・更新内容を理解できるか。
- 入力エラーが起きたとき、問題箇所と直し方が分かり、修正後に処理を続けられるか。
自動チェックは、実行したページと状態の証拠として PR に残します。「違反ゼロ」だけで適合を宣言せず、未確認の画面・支援技術・操作も明示します。最後に、誰が何を担うべきかを整理しましょう。
AI に任せる作業、人が担う責任
AI に委譲しやすいのは、対象範囲が明確な調査、機械的な候補の列挙、テスト追加、修正案の作成、関連テストの実行と結果の記録です。既存のコード規約に沿った変更を提案させることもできます。
一方で、代替テキストがその場の目的に合っているか、操作順序が利用者にとって理解しやすいか、画面の変化がスクリーンリーダーで適切に伝わるか、エラー回復が十分かは、人が責任を持って判断します。障害のある利用者を含む実際の利用者からのフィードバックも、必要に応じて評価に加えます。
理想は、Issue で目標と完了条件を明確にし、エージェントが既存構成やツールに応じた方法で作業・検証し、人が PR をレビューするサイクルです。必要に応じて Playwright + axe-core のような CI チェックを組み合わせ、手動確認や利用者評価の結果を次の Issue に反映します。CI は対象画面での回帰を継続的に見つける助けになりますが、実行対象に含まれない状態や人の判断を肩代わりしません。
おわりに
GitHub Issue から PR・CI で確認する流れを整理しました。対象の実装や違反内容は提示されておらず、Copilot への依頼やテストも実施していません。
持ち帰りは三つです。
- アクセシビリティは後付け機能ではなく、開発時から扱う品質要件です。
- 自動検出で見つかった問題は、原因と期待挙動を理解してから修正します。
- 方法を委ねる場合も、PR で選ばれた検証方法・確認範囲・未確認事項を読み、必要な操作体験を人が確認します。
AI に任せるのは責任ではなく作業です。 AI だけで WCAG 準拠を保証できませんが、達成したい状態を伝え、選ばれた方法と結果を人が確かめることで改善を支援できます。♿
関連記事
- WCAG 2.2 アクセシビリティ完全ガイド — 原則・設計・テスト
- 別の Web アプリで行った、範囲を限定したブラウザーアクセシビリティ監査の記録（Qiita） — 対象と検証が異なる別の記事であり、本記事で扱う検証結果ではありません。