accessibility-testing について
accessibility-testingは、Webアクセシビリティを評価・実装する開発者向けスキルです。自動チェック、コンポーネント単位のWCAG 2.2 AAA審査、修正内容の記録、アクセシビリティ情報ページの作成指針を扱います。
主な機能
- 01pa11yとaxe-coreによる自動チェック
- 02コンポーネント単位のWCAG 2.2 AAA審査
- 03基準ごとの状態を表で記録
- 04問題と修正案の文書化
- 05アクセシビリティ情報ページの作成指針
活用シーン
- 01CIパイプラインへのアクセシビリティ検査追加
- 02WCAG基準に沿ったコンポーネント評価
- 03問題と修正内容の記録
- 04公開用アクセシビリティ情報ページの作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ kreerc/ accessibility.md --skill accessibility-testingインストール後、Claude Code で/accessibility-testingを入力して読み込まれたか確認します。
詳細
開発者を含むすべての人に質の高いウェブ体験を提供するには、アクセシビリティを適切に実装することが重要です。
ソフトウェア要件とプログラムによるテスト
アクセシビリティの不具合を迅速かつ確実に検出するには、自動化されたルールベースのアクセシビリティチェックを使用してください。そのために、pa11y/pa11y CLI ツールと axe-core runner を開発要件として設定し、新しい開発ビルドに対して実行してください。また、ページの他の部分から切り離して、個々の機能やコンポーネントもテストしてください。
これらのチェッカーツールを既存の CI パイプラインに組み込んでください。
手動チェック
コンポーネントごとに、WCAG 2.2 レベル AAA への完全な適合性を確認し、達成基準の番号、名称、簡単な説明、適合状況(合格、不合格、該当なし、未テスト)を記載した表を作成してください。
役立つ場合は、テンプレートを作成して再利用してもかまいません。
Playwright などのブラウザーベースのツールを使用し、従来は実際のユーザーによるテストが必要だったチェックを実行してもかまいません。判断できない場合や、結果の信頼性に懸念がある場合は、開発者が実施するための明確で簡潔な評価手順を添えて、TODO を記載してください。
成果物の作成
アクセシビリティについて評価または判断した場合は必ず、記録された問題と推奨される修正を簡潔にまとめてください。完全なアーキテクチャの見直しがより適切で正しい選択となる場合に、安易な応急処置や簡略化した修正を提案してはいけません。特に、応急処置として ARIA パターンを用いる場合は注意してください。
アクセシビリティ情報(欧州アクセシビリティ法の要件)
EU 法および各国の同等法令(ドイツの Barrierefreiheitsstärkungsgesetz/BFSG など)で定められているとおり、プロジェクトには、以下の内容を自然な言葉で記載した、一般公開のアクセシビリティ情報ページが必要です。
- サービス名
- サービスの概要
- 提供者のメールアドレスと電話番号、および公開可能な場合は所在地
- 適用される法律の名称
- アクセシビリティを確保するために使用しているツールとプロセス、および評価に使用するエージェントの名称
- 各達成基準のアクセシビリティに関する詳細(平易な言葉で記載し、合格、不合格、該当なしのいずれかを明記)
- 管轄機関の連絡先(ドイツの場合、たとえば Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen, MLBF AöR, Magdeburg)
- 最終評価日
- 不適合要件をすべて修正する日付
法律では、開発者が提供するサービスについて、管轄機関に事前に通知することも義務付けられています。そのためのメールを下書きし、該当するメールアドレスを調べてください。
このページは、プライバシーポリシーなどの他の法令関連リンクの近くに配置し、すべてのページからアクセスできるようにしてください。
サービスが法律の適用対象に直接該当しない可能性がある場合も含め、いずれの場合もこのページを実装してください。