mcpField
D
deer-sense

deer-sense

github.com/autumnsgroveテスト・品質671 回インストール5 日前に更新
リポジトリ

deer-sense について

deer-senseは、UIを構築・レビューするチーム向けのアクセシビリティ監査スキルです。ニーズの整理、自動スキャン、手動テスト、修正、回帰防止の手順で監査を進めます。

主な機能

  1. 01障壁とWCAG目標の整理
  2. 02axe-coreとコンポーネントのスキャン
  3. 03キーボードとスクリーンリーダーの手動テスト
  4. 04セマンティックHTMLとARIAの修正案
  5. 05CIでのアクセシビリティ回帰チェック

活用シーン

  1. 01リリース前の新しいUIの監査
  2. 02新規UIコンポーネントのアクセシビリティ確認
  3. 03アクセシビリティの苦情調査と問題修正

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/autumnsgrove/lattice --skill deer-sense

インストール後、Claude Code で/deer-senseを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
automated-scanning.md
grove-a11y-patterns.md
keyboard-testing.md
screen-reader-testing.md

詳細

Deer Sense

鹿は研ぎ澄まされた感覚で森を進みます。ほかの者が聞き逃す音――足元で折れる小枝や、鳥の警告の鳴き声――を聞き取ります。進路をふさぐものにも気づきます。鹿は群れを危険から避けさせ、皆が安全に進めるよう導きます。デジタルの森では、鹿は一部の旅人が道を見つけられなくする障壁を察知します。

有効にするタイミング

  • ユーザーが「アクセシビリティをチェックして」または「a11y audit」と依頼したとき
  • ユーザーが「これをアクセシブルにして」または「スクリーンリーダーのテスト」と言ったとき
  • ユーザーが /deer-sense を呼び出す、または鹿／アクセシビリティに言及したとき
  • 新しい UI コンポーネントを構築するとき
  • 既存のインターフェースをレビューするとき
  • ビジュアルデザインを刷新した後
  • 大規模なリリースの前
  • アクセシビリティに関する苦情が寄せられたとき

組み合わせるもの： アクセシブルな UI の実装には chameleon-adapt

感覚

LISTEN --> SCAN --> TEST --> GUIDE --> PROTECT
   |         |        |        |          |
 Hear     Look for  Validate  Fix      Prevent
 Needs    Barriers   Paths   Issues   Regression
フェーズ 1：LISTEN

鹿の耳がぴくりと動き、危険が訪れる前に、ほかの者が聞き逃す音を聞き取ります……

誰のために構築するのか、どのような障壁があるのかを理解します。障害の種類と支援技術を対応付けます。このプロジェクトの WCAG 適合レベルの目標を設定します。

  • 該当する障害の種類（視覚、運動、認知、聴覚）と、利用する支援技術を特定します
  • WCAG の目標を確認します。Grove の標準は WCAG 2.1 AA 以上です
  • このインターフェースに特有の一般的な障壁を整理します。色のコントラスト、代替テキストの欠落、キーボードトラップ、小さなタッチターゲット、フォームラベルの欠落、分かりにくいナビゲーションなどです
  • Grove 固有の考慮事項を記録します。GroveTerm コンポーネント、ガラス面、季節ごとのアニメーション、動きの抑制などです

参考： 障害／支援技術の一覧表と WCAG レベルガイドについては references/automated-scanning.md を、Grove 固有の障壁パターンについては references/grove-a11y-patterns.md を読み込みます

フェーズ 2：SCAN

鹿の目が森の地面を見渡し、ひづめを踏み出す前に進路をふさぐものを見つけます……

自動スキャンを実行し、機械的な違反をすばやく洗い出します。自動ツールで検出できるのは実際の問題のおよそ 30% です。手動テストを始める前に、明らかな問題を解消するために使用します。

  • axe-core CLI をインストールして実行します：npx axe https://localhost:5173 --tags wcag2aa
  • Svelte コンパイラーに組み込まれた a11y 警告を確認します（代替テキストの欠落、ラベルのない入力、クリックイベントのある div）
  • よくある問題のチェックリストを確認します：画像、フォーム、ナビゲーション、色のコントラスト、ページ構造、言語属性
  • 違反を記録し、重大度ごとに分類します。ブロッカー（ラベルの欠落、キーボードトラップ）と警告（最適ではない代替テキスト）

Showroom によるコンポーネント単体の監査：

ページ全体をスキャンする前に、Showroom を使って個々のコンポーネントを単体で監査します。Showroom はコンポーネント単位でフォーカススタイル、見出し階層、インタラクティブ要素の適合性をチェックし、ページのコンテキストに隠れてしまう a11y の問題を検出します。

# Audit each component the deer is reviewing
uv run --project tools/glimpse glimpse showroom \
  libs/engine/src/lib/ui/components/[path-to-component].svelte

# The audit checks: focus styles on interactive elements, heading hierarchy,
# image alt text, color contrast via computed styles, spacing grid compliance

これはコンポーネント単位の a11y 作業に必須のゲートです。 フォーカスインジケーターがない、または見出し階層が壊れているコンポーネントは、ページレベルのスキャンに先送りせず、ここで検出する必要があります。

Glimpse によるビジュアルスキャン：

ページをキャプチャして、実際にレンダリングされた結果を確認します。コンソールログから、隠れた a11y の問題が見つかることもよくあります。

# Prerequisite: seed the database if not already done
uv run --project tools/glimpse glimpse seed --yes

# Capture with console logs — errors often reveal missing ARIA, broken refs
# Local routing uses ?subdomain= for tenant isolation; --auto starts the dev server
uv run --project tools/glimpse glimpse capture \
  "http://localhost:5173/[page]?subdomain=midnight-bloom" \
  --season autumn --theme dark --logs --auto

# Check dark mode contrast — capture both themes side by side
uv run --project tools/glimpse glimpse matrix \
  "http://localhost:5173/[page]?subdomain=midnight-bloom" \
  --themes light,dark --logs --auto

# Browse interactively — does tab order make visual sense?
uv run --project tools/glimpse glimpse browse \
  "http://localhost:5173/[page]?subdomain=midnight-bloom" \
  --do "click first interactive element, press Tab, press Tab, press Tab" \
  --screenshot-each --auto

スクリーンショットを確認します。フォーカスインジケーターは見えますか？ ガラス面は十分なコントラストを保っていますか？ タッチターゲットは視覚的に十分な大きさですか？

参考： axe-core コマンド、Lighthouse CI のセットアップ、ESLint プラグインの設定、CI 統合用 YAML、問題の完全なチェックリストについては references/automated-scanning.md を読み込みます

フェーズ 3：テスト

シカは、それぞれの道を自らテストします。地図を知っていることと、実際に道を歩くことは同じではないからです……

手動テストでは、自動化で見落とされる問題を発見できます。キーボード操作、スクリーンリーダーの出力、動きの軽減、ズームをテストします。このインターフェースに関連するテストシナリオを確認してください。

  • キーボードテスト：Tab の順序、Enter／Space による有効化、フォーカスインジケーター、Escape キー、スキップリンク、フォーカストラップがないこと
  • スクリーンリーダーテスト（VoiceOver または NVDA）：ページタイトル、見出しナビゲーション、ランドマーク、画像、ボタン、フォーム、ライブリージョン
  • 200％のズームテスト：横スクロールがないこと、すべてのコンテンツが表示されること、要素が重ならないこと
  • 動きの軽減：すべてのアニメーションが prefers-reduced-motion に応じて切り替わることを確認します

リファレンス： キーボードのチェックリスト、フォーカストラップのパターン、モーダルのテスト、タッチターゲットの要件、条件付きフィールドのテストシナリオについては、references/keyboard-testing.md を読み込んでください。スクリーンリーダーのツール、ARIA のパターン、セマンティック HTML の修正、ARIA のチェックリストについては、references/screen-reader-testing.md を読み込んでください。

フェーズ 4：ガイド

シカは倒木を避けて群れを導き、頭をそっと向けて通りやすい道を示します……

適切な実装でアクセシビリティの問題を修正します。可能な場合は ARIA よりセマンティック HTML を優先してください。修正のたびに、すべての人にとってインターフェースがより明確になるようにします。

  • 色のコントラストの問題を修正します：コントラスト比の事前テスト済みの Grove パレットトークンを使用します
  • div だらけの構造をセマンティック HTML（article、button、nav、main）に置き換えます
  • フォーカス管理を追加します：openModal() は最初の要素にフォーカスを移し、closeModal() はトリガーにフォーカスを戻します
  • アイコンのみのボタンに ARIA ラベルを追加し、動的なステータス更新用にライブリージョンを追加します
  • フォームのアクセシビリティを修正します：for／id のペア、エラー用の aria-describedby、エラーメッセージへの role="alert" の設定
  • すべての操作可能な Grove 要素で、タッチターゲットの最小サイズ 44px を確保します

リファレンス： ARIA ラベルのパターン、セマンティック HTML の修正、フォームのアクセシビリティのコードについては、references/screen-reader-testing.md を読み込んでください。タッチターゲットのパターン、グラスカードのフォーカススタイル、GroveTerm の要件、動きの軽減用ストアの使用方法については、references/grove-a11y-patterns.md を読み込んでください。

フェーズ 5：保護

シカは見張りに立ち、この監査が終わった後も道が通れる状態に保たれていることを確認します……

今後アクセシビリティのリグレッションが起きないようにします。CI に自動チェックを追加し、ドキュメントを整備して、誰もが森を歩ける状態に保ちます。

  • axe-core を vitest／puppeteer のテストスイートに追加します：違反があればテストを失敗させます
  • 開発時の警告用に eslint-plugin-svelte-a11y を追加します
  • すべてのプルリクエストで axe-core を実行するよう CI を設定します
  • アクセシビリティのドキュメントを、標準、テストプロセス、ツールに関する情報で更新します
  • 最終監査レポートを作成します：テストしたページ、自動テストの結果、手動テストの結果、修正した問題、継続的な保護策

リファレンス： CI の YAML、ESLint プラグインのセットアップ、vitest での axe-core の使用方法、ドキュメントのテンプレートについては、references/automated-scanning.md を読み込んでください。最終監査レポートのテンプレートについては、references/screen-reader-testing.md を読み込んでください。

リファレンスのルーティング表

フェーズリファレンス読み込むタイミング
LISTENreferences/automated-scanning.md常に（障害の種類、WCAG レベル）
LISTEN (Grove)references/grove-a11y-patterns.mdGrove コンポーネントを監査するとき
SCANreferences/automated-scanning.md常に（axe-core、Lighthouse、チェックリスト）
TEST (keyboard)references/keyboard-testing.mdキーボードとズームの手動テスト
TEST (screen reader)references/screen-reader-testing.mdスクリーンリーダーのテストシナリオ
GUIDEreferences/screen-reader-testing.md + references/grove-a11y-patterns.md問題を修正するとき
PROTECTreferences/automated-scanning.md + references/screen-reader-testing.mdCI のセットアップ、最終レポート

Deer のルール

意識

ほかの人が見落とすことに気づきましょう。アクセシビリティの障壁は細部に潜んでいます。ガラス面の上で技術的には表示されていても見えないフォーカスリングや、44px ではなく 42px のタッチターゲットなどです。

包括性

すべての人のためにデザインしましょう。森はすべての旅人に開かれています。アクセシビリティはすべての人に役立ちます。キーボードショートカットはパワーユーザーに、字幕は騒がしい環境にいる人に、わかりやすいエラーメッセージはすべての人に役立ちます。

継続性

アクセシビリティは一度きりではなく、継続的に取り組むものです。新しいコンポーネントを追加するたびに、最初から正しく対応する機会があります。また、a11y チェックを行わない PR は、障壁を再び生み出す機会になりかねません。

コミュニケーション

感覚的な比喩を使いましょう。

  • 「障壁に耳を澄ませています……」（ニーズを理解する）
  • 「道をスキャンしています……」（自動テスト）
  • 「ルートをテストしています……」（手動での検証）
  • 「障害物を避ける道をご案内しています……」（問題の修正）
  • 「道が開けました。」（監査完了）

アンチパターン

deer が行わないこと：

  • 実際の支援技術を使ったテストを省略する
  • 自動ツールだけに頼る（実際の問題の約 30％しか検出できません）
  • 「アクセシビリティオーバーレイ」やサードパーティ製ウィジェットのパッチを使う（効果はありません）
  • 認知アクセシビリティを無視する。わかりにくいナビゲーションも障壁です
  • a11y を後回しにし、「デザインが完成してから」追加するものとして扱う
  • 視覚的な代替手段を用意せずにフォーカスのアウトラインを非表示にする
  • 意味を伝えるために色だけを使う

監査の例

ユーザー：「新しいダッシュボードのアクセシビリティを監査してください」

Deer の流れ：

  1. LISTEN — 「ダッシュボードには複雑なデータ、グラフ、テーブルがあります。ユーザーはスクリーンリーダー、キーボード、運動機能を利用します。目標は WCAG AA です。Grove のガラスカードにはカスタムフォーカスが必要です。」

  2. SCAN — 「axe-core：違反が 5 件あります。グラフの alt が不足し、指標のコントラストが低く、テーブルのヘッダーがありません。Svelte の警告：onclick を持つ div が 2 つあります。」

  3. TEST — 「キーボード：フィルターのドロップダウンに移動できません（日付ピッカー内でフォーカスがトラップされます）。スクリーンリーダー：テーブルを操作できません（scope がありません）。ズーム：200％でサイドバーがメインコンテンツに重なります。」

  4. GUIDE — 「グラフに aria-label を追加し、Grove のトークンを使って指標のコントラストを 4.5:1 まで高め、適切な <th scope> を使ったテーブルのマークアップを追加し、サイドバーをレスポンシブにして、日付ピッカーをキーボードで操作できるものに置き換えます。」

  5. PROTECT — 「axe-core を CI に追加し、eslint-plugin-svelte-a11y を有効にして、監査レポートを作成し、コンポーネントのドキュメントにアクセシビリティのセクションを追加しました。」

クイック判断ガイド

状況対応
新しいコンポーネントまずセマンティック HTML を使用し、リリース前にキーボード操作とスクリーンリーダーでテストします
色の選択コントラスト比を確認します（最低 4.5:1 — Grove のパレットトークンを使用してください）
インタラクティブな要素キーボードで操作できるようにし、視認可能な focus-visible スタイルを必須とします
画像説明的な代替テキストを設定します（装飾のみの場合は alt=""）
フォームラベルを関連付け、エラーメッセージには aria-describedby を指定し、必須項目を示します
アニメーション$reducedMotion ストアに応じて制御します — 例外はありません
GroveTerm/GroveText必須の ARIA 属性については references/grove-a11y-patterns.md を読み込みます
タッチターゲット最小 44px — 見た目のサイズを小さく保つ必要がある場合はパディングを使用します

他のスキルとの連携

センシング前：

  • chameleon-adapt — 新しい UI を構築する場合は、最初からアクセシビリティを考慮して設計します

センシング後：

  • chameleon-adapt — 修正内容をアクセシブルな UI として実装します
  • beaver-build — 問題の修正後に、アクセシビリティのリグレッションテストを追加します
  • owl-archive — プロジェクトのアクセシビリティ標準を文書化します

森は、そこを訪れるすべての人を歓迎します。障壁を取り除きましょう。

コメント

Markdown 対応