better-accessibility について
better-accessibilityは、アクセシブルなインターフェースコードの構築とレビューに使うデザインスキルです。プラットフォームのセマンティクス、キーボードやスクリーンリーダー、フォーム、動き、ズームを扱います。
主な機能
- 01ネイティブ要素とセマンティクス
- 02キーボード操作とフォーカス
- 03アクセシブルなフォームとエラー
- 04スクリーンリーダーへの通知
- 05ヒット領域、動き、ズーム
活用シーン
- 01キーボードのみで操作できるかの確認
- 02アクセシブルな名前とフォームエラーの点検
- 03ズームと視差効果の軽減への対応
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ boraoztunc/ skills --skill better-accessibilityインストール後、Claude Code で/better-accessibilityを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
focus-and-keyboard.mdforms.mdhit-areas.mdmotion-and-zoom.mdreview-output.mdscreen-readers.mdsemantics-and-aria.md詳細
技術とともに身につけるアクセシビリティ
アクセシビリティは、最後に付け足すコンプライアンスのチェック項目ではなく、インターフェースづくりの土台です。プラットフォームを活用すれば、その多くは追加コストなしで実現できます。ネイティブ要素にはキーボード操作への対応が組み込まれており、正しいラベルは読み上げられ、フォーカスリングの表示には CSS ルールを1つ設定するだけです。UI コードを構築またはレビューするときは、これらの原則を適用し、修正はすべてプロジェクト独自の作法で記述してください。既存のスタイリングシステムを使い、別のシステムを併用しないでください。
レビューでは、まずキーボードだけを使うユーザーとしてインターフェースを操作してください(すべてのフローをマウスなしで完了できる必要があります)。次に、スクリーンリーダーのユーザーとして確認します。各コントロールでは、名前、ロール、状態がそれぞれ読み上げられますか?判断に迷った場合は、カスタムで作り直すよりプラットフォームのデフォルトを優先し、ARIA は追加するより削除してください。
レンダリングされたペアのコントラスト測定と色の修正については better-colors スキル、視覚的なテキストサイズと iOS の入力時ズームについては better-typography、空間的な RTL レイアウトについては better-layout で扱います。
クイックリファレンス
| カテゴリー | 使用する場面 |
|---|---|
| フォーカスとキーボード | フォーカスリング、スキップリンク、tabindex、フォーカストラップ、APG のキーボード操作パターン |
| セマンティクスと ARIA | まずネイティブ要素を使う、ボタンとリンクの使い分け、ランドマーク、アクセシブルな名前、無効状態 |
| フォーム | ラベル、自動補完、エラーメッセージ、入力タイプ |
| スクリーンリーダー | 視覚的に隠したコンテンツ、ライブリージョン、トースト、代替テキスト、SVG |
| ヒット領域 | ターゲットサイズ、ヒット領域の拡張、重なりのルール |
| モーションとズーム | prefers-reduced-motion、自動再生と時間制限のある UI、200% ズーム、リフロー、rem と px |
| レビュー出力形式 | 重要度の尺度、指摘事項の表、検証、判定 |
基本原則
1. まずネイティブ要素を使う
ARIA の第一のルールは、ネイティブ要素がある場合は ARIA を使わないことです。操作には <button>、ナビゲーションには <a href> を使います(Cmd/Ctrl/中クリックに対応する必要があります)。<div onClick> は決して使わないでください。不適切な ARIA より、ARIA を使わないほうが優れています。
2. フォーカスリングを表示する
:focus 単体ではなく :focus-visible をスタイル指定し、キーボードユーザーにはフォーカスリングを表示し、マウスユーザーには通常表示されないようにします。ブラウザーの変更されていないフォーカスインジケーターを優先してください。デザイン上、カスタムのリングが必要な場合は、プロジェクトのフォーカストークンか、別の明示的な色を使い、インジケーター全体がまたぐすべての隣接色に対して確認してください。currentColor は、同じ確認を済ませた場合に限り使用できます。少なくとも 2px の実線の外周、またはそれと同等の視認可能な面積を確保してください。検証済みの代替手段なしに outline: none を使わず、強制カラーモードではシステムカラーを保持してください。
3. キーボード操作に完全対応する
ポインターによる操作すべてに、ARIA APG のパターンに沿ったキーボード操作を用意してください。オーバーレイは Escape で閉じ、複合ウィジェット(タブ、メニュー、リストボックス)内では矢印キーで移動し、ウィジェット間は Tab で移動し、Enter と Space で操作を実行します。tabindex="0"(通常のタブ順序に含める)と tabindex="-1"(プログラムによるフォーカス)のみを使ってください。自然な順序を崩す正の値は使用しないでください。複合ウィジェットではロービング tabindex を使い、アクティブな項目を 0、それ以外をすべて -1 にします。
4. フォーカスをトラップして復元する
モーダルでは背景コンテンツに inert を設定し、開いたときに内部へフォーカスを移し、閉じたときに起動元へフォーカスを戻します。背景コンテンツがスクロールしないよう、overscroll-behavior: contain を追加してください。
5. ヒット領域の最小サイズ
WCAG 2.5.8 のレベル AA の基準は、24×24 CSS ピクセルのターゲット、または同規格で定義されている間隔、同等のコントロール、インライン、ユーザーエージェント、必須の例外のいずれかです。操作しやすさを高めるため、密度が許す場合はタッチ環境では 44×44px、デスクトップインターフェースでは 40×40px を目指してください。表示要素を小さいままにする必要がある場合は、疑似要素で領域を広げてください。拡張したヒット領域を重ねてはならず、装飾レイヤーには pointer-events: none を設定してください。これにより、グローやグラデーションが下にあるコントロールを操作するためのクリックを遮らないようにします。
6. すべてのコントロールにラベルと型を設定する
すべての入力には <label for> またはラップする <label> を設定します。プレースホルダーはラベルの代わりにはなりません。また、ラベルとコントロールのクリック領域は共通にし、チェックボックスとそのテキストの間に反応しない領域を作らないでください。意味のある name を指定したうえで autocomplete を追加し、キーボードに適した type と inputmode を設定します。貼り付けは決してブロックしないでください。ユーザーはパスワードやワンタイムコードを貼り付けます。
7. エラーを確実に通知する
リクエストの開始までは送信ボタンを有効にしておき、開始後は元のラベルを保持したまま、スピナーを表示して無効にします。送信時に検証を行い、失敗したフィールドに aria-invalid="true" を設定し、aria-describedby でインラインエラーテキストを指定して、最初の無効なフィールドにフォーカスを移します。ネイティブコントロールが本当に利用できない場合は、ネイティブの disabled を使用します。フォーカス可能性や見つけやすさを意図的に維持する場合に限り、aria-disabled="true" を使用してください。その場合は、コードでポインター操作、キーボード操作、フォームの動作を無効にし、状態を明示的にスタイリングします。
8. すべての要素にアクセシブルな名前を付ける
アイコンのみのボタンには、内容を説明する aria-label が必要です。表示されているラベルのテキストは、アクセシブルな名前にも含めてください。装飾要素には aria-hidden="true" を設定します。フォーカス可能な要素には決して設定しないでください。
9. 色だけに頼らない
ステータスは、色に加えてアイコン、テキスト、または下線など、重複した手がかりで示します。コンテンツと状態に基づいて適用される WCAG のコントラスト要件を特定し、better-colors を使って、描画された前景色と背景色の組み合わせを測定します。コントラストが不十分な場合は、その色の組み合わせと満たしていない要件を報告します。依頼がない限り、プロジェクトの色は変更しないでください。
10. prefers-reduced-motion を尊重する
動きは @media (prefers-reduced-motion: no-preference) で囲み、オプトインにします。動きを抑える設定では、スライドや拡大・縮小を不透明度のクロスフェードに置き換え、視差効果と自動再生を完全に無効にします。この設定にかかわらず、自動再生されるメディアには見える一時停止コントロールが必要です。また、アクションやエラーを含むトーストは、閉じられるまで表示し続けます。
11. 動的コンテンツを通知する
フィールド固有の検証には aria-describedby を使用します。トーストや結果件数など、コントロールに関連付けられていない緊急性のない更新には、丁寧なライブリージョン(role="status")を使用します。role="alert" は、コントロールに関連付けられていない緊急のエラーに限って使用してください。丁寧な通知を繰り返し確実に行うには、テキストを更新する前に、安定した空のリージョンを描画します。動的に挿入されたアラートはサポート状況が異なるため、対象のスクリーンリーダーでテストする必要があります。
12. 目的に応じた代替テキストを設定する
装飾画像には alt="" を設定し、情報を伝える画像には意味を説明するテキストを設定します。機能を持つ画像にはそのアクションを説明するテキストを設定します。たとえば、検索アイコンのボタンには alt="magnifying glass" ではなく、alt="Search" を設定します。
13. 構造はナビゲーション
各セクションの内容を示す見出しを使用し、一貫性のあるアウトラインを構成します。ページごとに <h1> を1つ設け、見出しレベルを適切に入れ子にすることが推奨されるデフォルトです。ただし、これは単独で WCAG の適合・不適合を決める規則ではありません。表示されている主要な <main> ランドマークを1つ設けます。繰り返し表示されるナビゲーションやクロームがその前にある場合は、「コンテンツへスキップ」リンクを最初のフォーカス可能な要素にします。アンカー先の見出しには scroll-margin-top を設定します。
14. ズームとテキストサイズの変更に対応する
ページはズーム率200%で動作し、幅320pxで横スクロールなしにリフローする必要があります。テキストコンテナーには固定の height ではなく min-height を使用し、コードベースの慣習に合う場合は rem のブレークポイントを優先します。また、読者がズームできる範囲を制限するビューポートメタ設定は使用しないでください。
よくある間違い
| 間違い | 修正方法 |
|---|---|
フォーカスリングを消すために outline: none を使う | 代わりに :focus-visible のスタイルを設定します。マウスクリックでは表示されません |
| カスタムのフォーカス色がどこでも機能すると想定する | 隣接するすべての色とのコントラスト、および強制カラーモードでインジケーター全体を確認します |
ボタンやリンクに <div onClick> を使う | 操作には <button>、ナビゲーションには <a href> を使います |
| プレースホルダーだけをラベルとして使う | 視認できる <label for> を追加します。プレースホルダーは入力すると消えます |
フォーカス順を修正するために正の tabindex を使う | DOM の順序を修正します。0 と -1 だけを使ってください |
| 繰り返される丁寧な通知の告知が一貫しない | 空のステータス領域を安定して維持し、テキストを更新します。対象のスクリーンリーダーでテストしてください |
通常のトースト通知に assertive ライブ領域を使う | polite を使い、assertive はエラー用にします |
フォーカス可能な要素に aria-hidden="true" を設定する | これを削除するか、要素をフォーカス不可にします |
| 機能を持つアイコンの代替テキストで画像を説明する | alt="magnifying glass" ではなく、alt="Search" のように操作を説明します |
| フォームが有効になるまで送信ボタンを無効にする | 有効なままにし、送信時に検証して最初のエラーにフォーカスします |
| 装飾的な光彩やグラデーションがクリックを妨げる | レイヤーに pointer-events: none と aria-hidden="true" を設定します |
| タッチ操作後にホバーのスタイルが残る | @media (hover: hover) でホバーのスタイルを適用するようにします |
ネイティブの disabled コントロールにツールチップを付ける | 横に常時表示されるテキストを置くか、フォーカス可能なままにするため aria-disabled を使います |
報告
単独のアクセシビリティレビューは、確認されたすべての指摘事項を review-output.md に記載された形式で、検証結果と判定を添えて報告した時点で完了です。better-interface では、そちらの形式が優先されます。