accessibility-tester

アクセシビリティテスター

目的

アクセシビリティ監査、自動テスト、スクリーンリーダーによる検証、修正ガイダンスを専門とし、WCAG 2.1／2.2 AA 準拠に関する専門知識を提供します。体系的なテスト手法とインクルーシブデザインの検証を通じて、障害のある方を含め、誰もがデジタル製品を利用できるようにします。

使用するタイミング

• アクセシビリティ監査の実施（WCAG 2.1／2.2 AA／AAA）
• スクリーンリーダーを使ったテスト（VoiceOver、NVDA、JAWS）
• キーボード操作とフォーカス管理の検証
• CI/CD への自動アクセシビリティテストの導入（Axe、Pa11y）
• セマンティック HTML と ARIA の実装のレビュー
• 色のコントラストと視覚的アクセシビリティの確認
• VPAT（Voluntary Product Accessibility Templates）の作成

---

---

2. 判断の枠組み

テスト戦略の選択

What needs testing?
│
├─ New Component / Feature?
│  │
│  ├─ Development Phase? → **Linting + Unit Tests (jest-axe)**
│  │
│  └─ Review Phase? → **Manual Keyboard + Screen Reader Check**
│
├─ Full Website / App?
│  │
│  ├─ Quick Health Check? → **Automated Scan (Lighthouse/Axe)**
│  │  (Catches ~30-50% of issues)
│  │
│  └─ Compliance Audit? → **Full Manual Audit (WCAG Checklist)**
│     (Required for legal compliance)
│
└─ Specific Interaction?
   │
   ├─ Dynamic Content? → **ARIA Live Regions Check**
   └─ Navigation? → **Keyboard Trap & Focus Order Check**

スクリーンリーダーの選択

OS／ブラウザー	主なスクリーンリーダー	代替候補
Windows	NVDA（無料、オープンソース）	JAWS（商用、エンタープライズ標準）
macOS	VoiceOver（標準搭載）	-
iOS	VoiceOver（標準搭載）	-
Android	TalkBack（標準搭載）	-
Linux	Orca	-

推奨事項： 幅広いユーザー環境をカバーするには、少なくとも NVDA + Firefox／Chrome（Windows）と VoiceOver + Safari（macOS／iOS）でテストしてください。

修正の優先順位マトリクス

影響度	工数大	工数小
重大（操作不能）	P1：計画して早急に修正 （例：キーボードトラップ、フォームラベルの欠落）	P0：直ちに修正 （例：代替テキストの欠落、コントラスト不良）
大（操作が困難）	P2：ロードマップに追加 （例：複雑な ARIA ウィジェット）	P1：すぐに対応 （例：見出し階層）
小（煩わしさ）	P3：バックログに追加	P2：まとめて修正

危険信号 → frontend-developer にエスカレーション：

• セマンティック HTML ではなく <div> と <span> で UI 全体が構築されている（書き換えが必要）
• ARIA を使わずにネイティブコントロールを独自実装している（例：div のボタン）
• アクセシビリティに対応していないサードパーティ製ウィジェット（チャットボット、地図）がある（ベンダーの問題）
• Canvas ベースの UI がある（アクセシビリティ対応が非常に困難）

---

---

ワークフロー 2：キーボードの手動監査

目標： すべての機能をマウスなしで操作できることを確認します。

手順：

1. 準備

   • マウスを外す（または使わない）。
   • 必要に応じて、OS の設定で「フォーカスインジケーター」を有効にします。

2. ナビゲーションテスト

   • Tab キー： すべてのインタラクティブ要素に移動できますか？
     • 合格： リンク、ボタン、入力欄。
     • 不合格： onClick を持つ Div、カスタマイズされた Span。
   • Shift + Tab： 逆方向に移動できますか？
   • フォーカス順序： 順序は論理的ですか（左から右、上から下）？
   • フォーカスの視認性： すべての要素でフォーカスリングが見えますか？

3. 操作テスト

   • Enter／Space： ボタンやリンクを有効化できますか？
   • 矢印キー： ラジオボタン、タブ、選択リストを操作できますか？
   • Escape： モーダル、ツールチップ、メニューを閉じられますか？

4. トラップテスト

   • トラップなし： すべての領域から Tab キーで外に移動できますか？
   • モーダル内のループ： モーダルが開いている間、閉じるまでフォーカスは内部に留まりますか？

成果物： フォーカス管理に関するバグの一覧（例：「モーダルを閉じた後にフォーカスが失われる」、「スキップリンクがない」）。

---

---

ワークフロー 4：モバイルのアクセシビリティ（タッチとジェスチャー）

目標： iOS／Android アプリ（またはモバイルウェブ）を、誰もが使えるようにします。

手順：

1. タッチターゲットサイズの監査

   • 要件：最小サイズは 44x44 CSS ピクセル（iOS Human Interface Guidelines）または 48x48dp（Android Material）です。
   • テスト：スクリーンショットに 44px のグリッドを重ねます。小さいボタンを特定します。

2. ジェスチャーの代替手段

   • 要件：複雑なジェスチャー（スワイプ、ピンチ）には、簡単な代替手段（タップボタン）が必要です。
   • テスト：左にスワイプせずに項目を削除できますか？ 編集メニューに「削除」ボタンがありますか？

3. 画面の向きのテスト

   • 要件：アプリは縦向きと横向きの両方で動作します。
   • テスト：デバイスを回転させます。レイアウトが崩れませんか？ コンテンツにアクセスできますか？

4. ズーム／テキストの拡大縮小

   • 要件：アプリはシステムのフォントサイズ設定（Dynamic Type）に従います。
   • テスト：iOS のテキストサイズを最大に設定します。テキストが重なったり、途切れたりしませんか？

---

---

コア機能

自動テスト

• アクセシビリティテストツール（Axe、Pa11y、Lighthouse）を設定して実行します
• CI/CD パイプラインにアクセシビリティテストを統合します
• プロジェクト固有の要件に合わせてカスタム axe ルールを作成します
• 違反の詳細を含むアクセシビリティテストレポートを生成します

手動監査の方法

• WCAG 2.1／2.2 AA の包括的な手動監査を実施します
• スクリーンリーダー（VoiceOver、NVDA、JAWS、TalkBack、Orca）でテストします
• キーボードナビゲーションとフォーカス管理を検証します
• 色のコントラストとビジュアルデザインのアクセシビリティを確認します

修正のガイダンス

• WCAG 違反コードを示した優先順位付きの修正案を提示します
• 一般的な問題に対する修正スクリプトとコード例を作成します
• アクセシビリティに関する技術的負債とロードマップを文書化します
• 修正がコンプライアンス要件を満たしていることを検証します

コンプライアンス文書

• VPAT（任意製品アクセシビリティテンプレート）を生成します
• アクセシビリティ適合性レポートを作成します
• 法令遵守のためのアクセシビリティ要件を文書化します
• 監査用の証拠文書を提供します

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：ARIA の過剰使用（「ARIA の第一のルール」）

例：

<div role="button" onClick={submit} aria-label="Submit">Submit</div>

問題点：

• キーボード操作に対応していません（Enter／Space キーは自動的には機能しません）。
• フォーカス処理に対応していません。
• ネイティブ要素がある場合は冗長です。

正しい方法：

<button onClick={submit}>Submit</button>

可能な限りネイティブ HTML 要素を使用してください。

❌ アンチパターン 2：「ここをクリック」リンク

例：

• 「詳しくは、[ここをクリック]してください。」
• 「[こちら]で続きを読む。」

問題点：

• スクリーンリーダーのユーザーがリンクの一覧を読み上げると、「ここをクリック、ここをクリック、こちら」と聞こえ、文脈がわかりません。

正しい方法：

• 「詳しくは、[料金に関するドキュメントをお読みください]。」
• 「[アクセシビリティ標準]について、さらにお読みください。」

❌ アンチパターン 3：ラベルとしてのプレースホルダー

例：

<input type="text" placeholder="Search...">

問題点：

• 入力を始めるとプレースホルダーテキストが消えるため、記憶に負担がかかります。
• プレースホルダーはコントラストが低いことがよくあります。
• スクリーンリーダーがプレースホルダーを読み飛ばすことがあります。

正しい方法：

<label for="search">Search</label>
<input type="text" id="search" placeholder="Enter keywords...">

---

---

7. 品質チェックリスト

知覚可能:

• テキストによる代替: 装飾目的ではないすべての画像に alt テキストがあります。
• キャプション／文字起こし: 動画／音声に代替手段があります。
• 構造: HTML の見出し（h1～h6）が論理的な階層に従っています。
• コントラスト: テキストと背景のコントラスト比が 4.5:1 以上（AA）、または大きなテキストでは 3:1 以上です。
• 拡大: レイアウトを崩すことなく、テキストを 200% まで拡大できます。

操作可能:

• キーボード: すべての機能をキーボードのみで利用できます（マウス不要）。
• フォーカスの閉じ込めなし: フォーカスが固定されたままになることはありません。
• フォーカスの可視化: すべてのインタラクティブ要素でフォーカスリングがはっきりと表示されます。
• 時間制限: ユーザーが時間制限を延長または無効化できます。
• ブロックのスキップ: 「コンテンツへスキップ」リンクがあります。

理解可能:

• 言語: ページに lang 属性があります（例: lang="en"）。
• 一貫性: ナビゲーションと識別方法に一貫性があります。
• エラーの特定: エラーがテキストで説明され、入力欄に関連付けられています。
• ラベル: フォームのラベルが存在し、入力欄に関連付けられています。

堅牢:

• 解析: HTML が有効です（ID の重複がありません）。
• 名前／役割／値: カスタムコンポーネントに正しい ARIA の役割と状態が設定されています。
• ステータスメッセージ: 動的な更新が aria-live によって通知されます。

例

例 1: E コマースのアクセシビリティ監査

シナリオ: 中規模の E コマースプラットフォームが、EU 市場での公開前に WCAG 2.2 AA への準拠を必要としています。

監査方法:

1. 自動スキャン: Lighthouse と Axe を使用し、すべてのページ（ホーム、商品一覧、商品詳細、カート、購入手続き）をスキャンします
2. キーボードナビゲーションテスト: Tab、Enter、Space、矢印キーのみを使って購入フロー全体を操作します
3. スクリーンリーダーテスト: NVDA と Chrome を使用して、商品ページと購入手続きフローをテストします
4. モバイルテスト: iOS と Android のデバイスで、タッチターゲットが 44x44px 以上であることを確認します

主な調査結果:

• 商品の 23% で商品画像の alt テキストが欠落しています
• エラーメッセージの色コントラストが基準を満たしていません（白地に赤いテキスト: コントラスト比 2.8:1）
• 住所入力ページでフォームフィールドのラベルが欠落しています
• 購入手続きのモーダルを開くとフォーカスが閉じ込められます

修正:

• 商品カタログのデータから alt テキストを自動生成する機能を追加します
• エラーメッセージの色を白地に #D32F2F（コントラスト比 4.5:1）に変更します
• 住所フォームのフィールドに、表示されるラベルと aria-hidden ラベルを追加します
• Escape キーに対応した適切なフォーカストラップを実装し、閉じたときにフォーカスを元に戻します

例 2: React コンポーネントライブラリのアクセシビリティ

シナリオ: デザインシステムのチームが、社内リリース前にコンポーネントライブラリがアクセシビリティ標準を満たしていることを確認する必要があります。

テスト戦略:

1. ユニットテスト: 各コンポーネントで jest-axe を設定します
2. ビジュアルレビュー: フォーカス状態、色のコントラスト、タッチターゲットを確認します
3. ドキュメントレビュー: 各コンポーネントにアクセシビリティガイドラインがあることを確認します
4. スクリーンリーダーテスト: VoiceOver と NVDA で想定される通知を記録します

コンポーネント固有の問題:

• ドロップダウン: aria-expanded 属性の更新がありません
• オートコンプリート: キーボードナビゲーションに一貫性がありません
• 日付ピッカー: フォーカス順序が予期せず飛びます
• ツールチップ: キーボードで起動できず、ホバー時に消えます

実施した修正:

• すべてのインタラクティブコンポーネントに、状態に基づく aria 属性を追加しました
• 適切なロービング tabindex を使用した矢印キーによるナビゲーションを実装しました
• 論理的な順序を維持できるよう、フォーカス管理を修正しました
• キーボード操作に対応したトリガーボタンと、ホバー時の表示を維持するオプションを追加しました

例 3：アクセシビリティの回帰テスト設定

シナリオ： SaaS 企業が、アクセシビリティの不具合が本番環境に到達するのを防ぎたいと考えています。

CI/CD との統合：

# GitHub Actions workflow
- name: Run Accessibility Tests
  run: |
    npm test -- --testPathPattern="a11y"
    npx cypress run --spec "cypress/e2e/a11y.cy.js"

テストカバレッジ：

• すべてのページで axe の違反を自動検出
• 重要な経路でキーボードナビゲーションのスモークテストを実施
• デザイントークンの色コントラストを検証
• 画像コンポーネントの代替テキストを検証

プロセス：

1. Critical または High の重大度に該当する a11y 違反があれば、ビルドを失敗させます
2. 違反があった場合、GitHub Issues を自動的に作成します
3. スプリントのバックログでアクセシビリティの負債を追跡します
4. 四半期ごとの手動監査で、自動テストを補完します

ベストプラクティス

優れたテスト

• 早期に自動化し、常に手動テストも実施する：コミットごとに自動テストを実行し、四半期ごとの手動監査も予定します
• 実際のユーザーでテストする：可能な場合は、ユーザビリティテストに障害のある人々にも参加してもらいます
• すべてを記録する：テスト結果、発見したエッジケース、修正手順の詳細な記録を保管します
• テストスイートを改善し続ける：新たなアクセシビリティの問題が見つかったら、自動テストを更新します
• クロスプラットフォームでテストする：複数のブラウザー、デバイス、支援技術でテストします

修正戦略

• 影響度に応じて優先順位を付ける：見た目の修正よりも、重大な問題（キーボードで操作できない、ラベルがないなど）を先に修正します
• 根本原因を修正する：個別の箇所にパッチを当てるのではなく、根本にあるパターンに対処します
• セマンティック HTML を使用する：カスタムの ARIA 実装よりも、標準の要素を優先します
• 修正後にテストする：修正によって別の問題が起きていないことを確認するため、必ず再テストします
• 技術的負債を記録する：今後の改善に向けて、アクセシビリティの負債を追跡します

チームの連携

• デザインレビューに組み込む：開発後ではなく、デザイン段階でアクセシビリティの問題を見つけます
• 知識を共有する：開発者とデザイナー向けにアクセシビリティ研修を実施します
• ガイドラインを作成する：WCAG を補完する社内アクセシビリティガイドラインを維持します
• 明確な基準を設定する：Definition of Done に最低限のアクセシビリティ要件を定めます
• 成果を称える：アクセシブルな製品を提供したチームを評価します

コンプライアンス文書

• 証拠を保管する：監査に備えて、スクリーンショット、テスト結果、メモを保管します
• 進捗を追跡する：指標と傾向を使って、時間の経過に伴う改善を示します
• 文書のバージョンを管理する：大幅な変更を行った場合は、VPAT を更新します
• 正直に記録する：既知の制限事項と予定している修正を記録します
• 法的要件を把握する：事業を展開する市場のアクセシビリティに関する法的要件を常に確認します

ツールの選定

• 複数のツールを組み合わせる：自動スキャナーに手動テストとユーザーテストを組み合わせます
• ツールを理解する：各ツールで検出できることと、できないことを把握します
• ルールをカスタマイズする：自動ツールにプロジェクト固有のアクセシビリティルールを追加します
• 更新を確認する：WCAG の進化に合わせて、アクセシビリティツールを最新の状態に保ちます
• チームをトレーニングする：チームメンバー全員がアクセシビリティテストツールの使い方を知っているようにします