開発中の画面に対してアクセシビリティチェックリストを生成するClaudeのカスタムコマンドを作った

この記事は カオナビ Advent Calendar 2025 15日目の記事です。

FigmaMCPとAtlassianMCPを使用して、開発中の画面のアクセシビリティチェックリストの作成をAIにやってもらえるようにしました。

チェックリストのサンプル（クリックして開閉）

# アクセシビリティチェックリスト

**対象画面:** データ一覧画面（例）

---

## 1. 基本的なキーボード操作テスト（スクリーンリーダーなし）

**目的:** 視覚的なフォーカス表示と基本的な操作性を確認

[] 【A】Tabキーで全てのインタラクティブな要素にフォーカスできること

**操作:** Tabキーでフォーカスを移動
**期待値:**
- 期待されるフォーカス順序（上から下、左から右）でフォーカスが移動すること
  - サイドナビゲーション開閉ボタン
  - 並び替えドロップダウン
  - ソート順ラジオボタン（昇順/降順）
  - アクションボタン（複数）
  - テーブルの各行のリンク
  - テーブルの各行の操作メニューボタン
  - ページネーションコントロール

[] 【AA】フォーカス時に枠線やハイライトが表示されること

**期待値:** 各要素にフォーカス時、枠線や背景色で視覚的に強調されること

[] 【A】静的表示項目にフォーカスが当たらないこと

**操作:** Tabキーでフォーカスを移動
**期待値:** 読み取り専用のテキスト（テーブルヘッダー、ステータスアイコン、各種表示項目）にフォーカスが当たらないこと

---

## 2. スクリーンリーダーを使った総合テスト（キーボード操作含む）

**目的:** 実際のスクリーンリーダーユーザーの操作体験を確認

### 2-1. ページ構造の確認

[] 【A】ページタイトルが適切に読み上げられること

**期待値:** 「ページ名 - セクション名 - アプリケーション名」のように読み上げられること

[] 【A】見出しキー（H）でページの見出しが確認できること

**期待値:** 「ページタイトル、見出し」と読み上げられること

### 2-2. インタラクティブ要素の操作と読み上げ

**ボタン要素**

[] 【A】サイドナビゲーション開閉ボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「開く、ボタン」または「閉じる、ボタン」のように読み上げられること
- EnterまたはSpaceキーでサイドナビゲーションが開閉されること

[] 【A】アクションボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「ボタン名、ボタン」と読み上げられること
- EnterまたはSpaceキーで該当の操作が実行されること

[] 【A】新規作成ボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「新規作成、ボタン」と読み上げられること
- EnterまたはSpaceキーで新規作成画面に遷移すること

[] 【A】操作メニューボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「操作、ボタン」または「メニュー、ボタン」と読み上げられること
- EnterまたはSpaceキーで操作メニューが展開されること

[] 【A】編集メニュー項目

**操作:** 操作メニューを展開後、Tabキーまたは矢印キーでフォーカス
**期待値:**
- 「編集、メニュー項目」と読み上げられること
- Enterキーで編集画面に遷移すること

[] 【A】複製メニュー項目

**操作:** 操作メニューを展開後、Tabキーまたは矢印キーでフォーカス
**期待値:**
- 「複製、メニュー項目」と読み上げられること
- Enterキーで複製が実行されること

[] 【A】削除メニュー項目

**操作:** 操作メニューを展開後、Tabキーまたは矢印キーでフォーカス
**期待値:**
- 「削除、メニュー項目」と読み上げられること
- Enterキーで削除確認ダイアログが表示されること

[] 【A】ページネーションの前へボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「前へ、ボタン、無効」または「前へ、ボタン」と読み上げられること（ページ位置により変化）
- 有効な場合、Enterキーで前のページに移動すること

[] 【A】ページネーションの次へボタン

**操作:** Tabキーでフォーカス
**期待値:**
- 「次へ、ボタン、無効」または「次へ、ボタン」と読み上げられること（ページ位置により変化）
- 有効な場合、Enterキーで次のページに移動すること

**ドロップダウン**

[] 【A】並び替えドロップダウン

**操作:** Tabキーでフォーカス
**期待値:**
- 「並び替え、コンボボックス、現在の選択値」のように読み上げられること
- 矢印キーまたはEnterキーで選択肢を変更できること

**ラジオボタン**

[] 【A】ソート順ラジオボタン（昇順）

**操作:** Tabキーでフォーカス
**期待値:**
- 「昇順、ラジオボタン、選択済み」または「昇順、ラジオボタン」と読み上げられること
- 矢印キーまたはSpaceキーで選択状態を変更できること

[] 【A】ソート順ラジオボタン（降順）

**操作:** Tabキーでフォーカス
**期待値:**
- 「降順、ラジオボタン、選択済み」または「降順、ラジオボタン」と読み上げられること
- 矢印キーまたはSpaceキーで選択状態を変更できること

**リンク要素**

[] 【A】データ名リンク

**操作:** Tabキーでフォーカス
**期待値:**
- 「データ名、リンク」と読み上げられること
- Enterキーで詳細画面に遷移すること

### 2-3. 静的表示項目の読み上げ

**テキスト要素:**

[] 【A】件数表示の読み上げ

**操作:** スクリーンリーダーで読み上げ
**期待値:**
- 「N件」と読み上げられること

[] 【A】テーブルヘッダーの読み上げ

**操作:** スクリーンリーダーで読み上げ
**期待値:**
- 各列のヘッダー名が「列名、列ヘッダー」と読み上げられること

[] 【A】テーブルセルの読み上げ

**操作:** スクリーンリーダーで読み上げ
**期待値:**
- セル内の情報が適切に読み上げられること
- セル内の情報が行と列の関係性と共に読み上げられること

**非テキスト要素（画像・アイコン）:**

[] 【A】ステータスアイコンの代替テキスト

**操作:** スクリーンリーダーで読み上げ
**期待値:**
- アクティブ状態のアイコン: 「有効」または「アクティブ」と読み上げられること
- 非アクティブ状態のアイコン: 「無効」または「非アクティブ」と読み上げられること

### 2-4. 装飾的なアイコンの確認

[] 【A】装飾的なアイコンが余分に読み上げられないこと

**期待値:**
- テキストラベルと併記されているアイコンは読み上げられず、テキストのみ読み上げられること
- 例: 新規作成ボタンのプラスアイコン、編集メニューのペンアイコンなど

---

## 3. 動的コンテンツのアクセシビリティテスト

**目的:** モーダル、トースト通知などの動的コンテンツがアクセシブルか確認

### 3-1. 操作メニューのキーボード操作

[] 【A】メニュー表示時のフォーカス移動

**操作:** 操作メニューボタンを押下
**期待値:**
- メニューが表示されたら、自動的にメニュー内の最初の項目にフォーカスが移動すること
- メニュー表示中、背景のコンテンツにフォーカスが移動しないこと

[] 【A】Escキーでメニューを閉じられること

**操作:** メニュー表示中にEscキーを押下
**期待値:**
- メニューが閉じること
- フォーカスがメニューを開いたボタンに戻ること

[] 【A】矢印キーでメニュー内を移動できること

**操作:** メニュー表示中に矢印キー（上下）を押下
**期待値:**
- 矢印キーでメニュー項目間を移動できること
- 最後の項目から下矢印キーを押すと、最初の項目に戻ること

---

## 参考情報

### WCAG 2.1関連ガイドライン

- **達成基準 2.1.1（キーボード操作・レベルA）:** すべての機能がキーボードで操作可能
- **達成基準 2.1.2（キーボードトラップなし・レベルA）:** キーボードでフォーカスを移動できる場合、フォーカスを外すこともできる
- **達成基準 2.4.3（フォーカス順序・レベルA）:** フォーカスは論理的な順序で移動
- **達成基準 2.4.7（フォーカスの可視化・レベルAA）:** フォーカスされた要素が視覚的に識別可能
- **達成基準 4.1.2（名前、役割、値・レベルA）:** すべての要素に適切な名前と役割が設定されている
- **達成基準 1.3.1（情報及び関係性・レベルA）:** 構造と関係性がプログラムによって解釈可能
- **達成基準 1.1.1（非テキストコンテンツ・レベルA）:** すべての非テキストコンテンツに代替テキストが提供されている

機械的なテストではカバーしにくい、キー操作やスクリーンリーダーの操作に焦点を当てた内容になっています。

また、サンプルは記事へ載せるためにボタン名などをぼかしていますが、実際は具体的な名称で記載され、チェックしたい画面に合わせて記載されています。

カオナビのアクセシビリティと、チームの状況

カオナビではWCAG2.1の基準に配慮してアクセシビリティの改善に取り組んでいます。

私たちのチームでは、アクセシビリティを他の品質基準と同様に重要なものとして捉えています。Jiraで管理している各ストーリーチケットごとに、通常の機能テストと同じくアクセシビリティのテストも実施し、WCAG2.1のAを満たしているかどうかを確認しています。

みんなが同じように知識を持ってアクセシビリティの改善に取り組むことができたら理想的ですが、現状はまだ「やった方がいいのはわかるけど、何をしたら良いかわからない」という声もあり、「みんなでやっていく」というところには課題があります。

そこで「誰でも始められる」ことを目標にチェックリストの生成を自動化することにしました。

解決策としてのAI活用

弊社ではQA含め100名以上がClaudeを利用しており、カスタムコマンドなら多くの人にとって使いやすいだろうと考えて、Claudeと一緒にアクセシビリティチェックリストを作成するカスタムコマンドを作りました。

Claudeに伝えた要件

• テスト担当者がユーザー目線で期待される振る舞いについてチェックを行うためのアクセシビリティチェックリストを生成する
• WCAG2.1のレベルAおよびレベルAAに準拠
• FigmaMCPとAtlassian MCPを使う
• チェック対象のFigmaファイル/JiraチケットのURLはユーザーが提供する
• Figmaから取得できる情報を用いて判断の上、必要なチェック項目を作成する
• 対象のJiraチケットに記載されたスコープで作成する
• 作成したチェックリストは対象のJiraチケットにサブタスクとして追加する
• コントラスト比はデザイナーが責任を持つ
• 具体的な実装方法はエンジニアが責任を持つ

できたもの

/a11y-qc-check <Figma URL> <Jira ticket key>

1. チケット情報を取得

Atlassian MCPでサマリー、受け入れ基準、親課題IDなどの情報を取得

2. デザインから要素を分類

FigmaMCPより取得したデザインデータから要素を抽出し分類

• インタラクティブ要素（button, input, dropdown, link, toggle等）
• 静的表示項目（ラベル、説明文）
• 装飾的アイコン（テキストと併記）
• 動的コンテンツ（modal, toast, dialog）

3. チェックリスト生成

• ガイドライン（要件をもとに作成）に基づいて生成

4. Jiraサブタスク作成

• Atlassian MCPでサブタスクを作成
• 作成されたサブタスクのキーとURLを報告

これだけチェックしておけば完璧になるというリストではないので、他のツールを合わせて利用したり、最終的な判断は人間が下す必要はありますが、これをベースに考えていくという使い方ができると良いと思っています。

早速使ってもらった

作成したコマンドは、開発者全体へ共有し、ツールさえ使えれば誰でも使えるようにしました。

早速、アクセシビリティの改善に一緒に取り組んでいるチームメンバーに作成したチェックリストを使いながら実際にテストしてもらったところ、

前提知識やスクリーンリーダーの操作方法などで戸惑う場面はあったものの、チェックリストがあることで「何を確認すればよいか」が明確になり、作業を進めることができた。
チェックリストに沿って作業することで知識が身についていくので、2回目以降はよりスムーズに実施できそう

とのフィードバックをいただきました。

カスタムコマンド作成の目的だった「誰でも始められる」という目標は達成できたと言えそうです🙌

また、自分でも使ってみて「何をチェックすべきか」の最初の判断をAIに任せることができるようになったので、これから「どうしたらもっと使いやすくなるか」を考えることにより時間を割けるようになることを期待しています。

さいごに

アクセシビリティの改善は継続していくことこそが重要だと思っています。
一人よりみんなで取り組み、続けていくための手段として、今回の記事が参考になるとうれしいです。

もちろん、カスタムコマンドも作って終わりではないので、これからもっと改善していきたいと思っています。

• Chrome MCPと組み合わせて、フォーカス可否などの機械的チェックできる部分をAIに任せる
• Skills化してトークン効率の向上と出力の安定化を目指す

など、いろいろと試していく予定です！