アクセシブルなデザインシステム実践ガイド：コンポーネント仕様・トークン設計・WCAG 2.1 AAの受け入れ基準・運用とガバナンスまで
概要サマリー（先に要点）
- アクセシビリティは“頑張る人”ではなく、“仕組み”で守るほうが強いですの。デザインシステム化は、その最短ルートです。
- 成功の鍵は ①デザイントークン（色・余白・文字・フォーカス）→ ②コンポーネント仕様（操作・状態・文言）→ ③受け入れ基準（テスト）→ ④運用（ガバナンス） の順で整えること。
- すべてを一気にAAAへ、は疲弊します。まずは WCAG 2.1 AA の“事故が起きやすい箇所”（フォーム、モーダル、タブ、メニュー、表、動画）を標準コンポーネントに落とし込みます。
- この記事には、コンポーネント仕様テンプレ、トークン例、アクセシビリティ受け入れ基準（書き方の型）、運用ルール、5分スモークテストを収録しました。
対象読者（具体）：UI/UXデザイナー、フロントエンドエンジニア、PM/ディレクター、QA、アクセシビリティ担当、制作会社の標準化担当、複数プロダクト運用チーム
アクセシビリティレベル：WCAG 2.1 AA 準拠を目標（継続的改善の運用を含む）
1. はじめに：アクセシビリティは“標準化”すると、やさしく続く
アクセシビリティ対応は、丁寧にやろうとするほど、個人の気合いや経験に依存しやすい領域ですの。
「このフォームのエラーはどう通知する？」「モーダルのフォーカスはどこへ戻す？」「色の意味はどう重ねる？」——毎回ゼロから考えると、時間もコストも増え、しかも担当者が変わるたびに品質が揺れてしまいます。
そこで力を発揮するのが、アクセシブルなデザインシステムです。
トークン（色・余白・フォーカス）とコンポーネント（ボタン・フォーム・モーダル）に、アクセシビリティの要件を最初から組み込む。そうすると、プロダクトが増えても、ページが増えても、更新があっても、やさしさが崩れにくくなります。
本記事は、単なる理想論ではなく、実務で“回る形”として、設計から運用までを丁寧にまとめますね。
2. 全体像：アクセシブルなデザインシステムは4層で作る
アクセシビリティの標準化は、次の順に積み上げると迷いません。
2.1 層1：デザイントークン（Design Tokens）
- 色（背景・本文・リンク・境界・フォーカス）
- 文字（サイズ・行間・太さ）
- 余白（スペーシング）
- 角丸、影、境界線
- アニメーション（動きの強さ、減らす設定）
狙い：見た目の一貫性だけでなく、コントラスト・フォーカス可視・ターゲットサイズの土台を固定すること。
2.2 層2：コンポーネント仕様（Component Specs）
- 構造（HTML/ARIAの基本）
- 操作（キーボード、フォーカス遷移）
- 状態（hover/focus/disabled/error/selected）
- 文言（ラベル、ヘルプ、エラー）
- 例外（ローディング、空状態、0件）
狙い：実装者が変わっても、体験が同じになること。
2.3 層3：受け入れ基準（Acceptance Criteria）
- “WCAG番号”ではなく、操作結果で定義
例：
「Tabのみで購入完了できる」「エラー要約にフォーカスが移動する」「Escで閉じ、トリガへ戻る」
狙い：レビューが主観にならず、QAと開発が同じ言葉で話せること。
2.4 層4：運用とガバナンス（Governance）
- 変更管理（Breaking changes、バージョン）
- 監査（四半期ごとの代表画面チェック）
- 問い合わせ対応（アクセシビリティ窓口）
- 教育（オンボーディング、チェックリスト）
狙い：“一回だけ頑張る”から“ずっと守れる”へ。
3. デザイントークン設計：アクセシビリティ要件を最初から埋め込む
3.1 色トークン：コントラストを「個別確認」から「仕組み」へ
色は、デザインの自由度が高いぶん事故も起きやすいです。そこでおすすめは、色を「用途」で分けることですの。
--color-bg（背景）--color-fg（本文）--color-muted（補助）--color-link（リンク）--color-border（境界線）--color-focus（フォーカス）--color-danger（エラー）--color-success（成功）
そして、次の方針をトークンの“前提”として明文化します。
- 本文は 4.5:1 以上（通常文字）
- 大きい文字は 3:1 以上
- 非テキスト（境界、アイコン、フォーカス）は 3:1 以上
- リンクは「色だけ」にしない（下線などで重ねる）
3.2 フォーカストークン：見える輪郭を標準装備に
フォーカスリングを“各プロダクトの好み”にすると、すぐに消されますの。
だから最初からトークンにして固定します。
:root{
--focus-color: #FF9900;
--focus-width: 3px;
--focus-offset: 3px;
}
:focus-visible{
outline: var(--focus-width) solid var(--focus-color);
outline-offset: var(--focus-offset);
}
@media (prefers-contrast: more){
:focus-visible{ outline-width: 4px; }
}
3.3 スペーシングとターゲットサイズ：押しやすさは余白で作る
ボタンやチェックボックスは、見た目よりも“押せる面積”が大切です。
- 目安：高さ44px相当（モバイルで特に重要）
- クリック対象は余白込みで確保（テキストだけにしない）
3.4 モーション：動きは“弱め”をデフォルトに
スケルトンやローディングなど、動きが多い領域は、認知負荷や酔いにつながりやすいですの。
- 既定：ゆっくり、低コントラスト、点滅しない
prefers-reduced-motion: reduceで止める
4. コンポーネント仕様：アクセシビリティを「設計図」にする
ここからは、仕様の“型”をご紹介します。どのコンポーネントにも共通するテンプレを先に置きますね。
4.1 仕様テンプレ（おすすめの章立て）
- 目的：何のためのコンポーネントか
- 構造：HTML要素の基本、ARIAを使う場合の前提
- 状態：default / hover / focus / disabled / error / selected
- キーボード操作：Tab、矢印、Enter/Space、Esc、Home/End
- フォーカス管理：初期フォーカス、復帰、トラップの有無
- 文言ルール：ラベル、ヘルプ、エラー文の書き方
- レスポンシブ：狭幅時の挙動
- 禁止事項：事故が起きるパターン
- 受け入れ基準：テスト可能な文章で
- サンプル：最小実装例、良い例・悪い例
この型で揃えると、レビューがとても楽になりますの。
5. 重点コンポーネントの“標準仕様”例（実務で一番効くところ）
5.1 ボタン（Button）
構造
- 基本は
<button>を使う（クリックできるdivを作らない） - アイコンボタンは
aria-labelを必ず付ける
キーボード
- Tabでフォーカス
- Enter/Spaceで発火
受け入れ基準（例）
- ボタンはキーボードで実行できる
- フォーカスが視認できる（ライト/ダーク両方）
- 無効状態は
disabledを使い、見た目だけにしない
サンプル
<button type="button">保存</button>
<button type="button" aria-label="閉じる">
<img src="close.svg" alt="">
</button>
5.2 フォームフィールド（TextField / Select / Checkbox）
（フォームは事故率が高いので、標準化の効果が最大です）
構造
labelとforを必ず結ぶ- ヒントは
aria-describedbyで関連付け - エラーは
aria-invalid="true"＋エラーテキスト関連付け
文言ルール
- エラーは「どこで・なぜ・どう直す」
- 必須/任意はラベルで明示（色だけで伝えない）
受け入れ基準（例）
- ラベルが可視で存在し、読み上げで項目名が分かる
- エラー発生時、エラー要約が表示され、最初のエラーへフォーカス移動できる
autocompleteが適切（メール、住所、氏名など）
サンプル
<div class="field">
<label for="email">メールアドレス（必須）</label>
<input id="email" type="email" autocomplete="email" aria-describedby="email-hint email-err" aria-invalid="true">
<p id="email-hint">例：example@example.com</p>
<p id="email-err" class="error" role="alert">形式が正しくありません。</p>
</div>
5.3 モーダル（Dialog）
構造
- 可能ならネイティブ
<dialog>、難しければrole="dialog"で実装 - 背景は
inert（対応外は代替）で操作不能に
フォーカス管理
- 開いたら最初の操作要素へ
- Tabはモーダル内で循環（トラップ）
- Escで閉じる
- 閉じたらトリガに戻す
受け入れ基準（例）
- モーダル表示中、背景の要素へフォーカスが移動しない
- Escで閉じ、元のボタンへ戻る
- タイトルが読み上げられる（名前の提供）
5.4 タブ（Tabs）とメニュー（Menu）
標準ルール
- Tab：領域間移動、矢印：領域内移動（ロービングTabIndex）
- Home/Endで先頭/末尾
- 選択状態は
aria-selectedなどで露出
受け入れ基準（例）
- 矢印で隣のタブへ移動できる
- 選択中のタブが読み上げで分かる
- パネルの内容が表示/非表示で破綻しない
5.5 テーブル（Table）
（以前の記事とつながる“標準部品”として強いです）
構造
- 見出しセルは
th scopeを基本、複雑表はheaders/idまたは分割captionで表の目的を示す
受け入れ基準（例）
- スクリーンリーダーでセル移動したとき、見出しが分かる
- モバイルで情報欠落が起きない（横スクロール等）
5.6 ローディング（Loading）と通知（Status/Alert）
標準ルール
- 重要なエラーは
role="alert" - 成功や完了は
role="status"（割り込みすぎない） - スピナーは
aria-hidden="true"、テキストで「読み込み中」を表示
受け入れ基準（例）
- 読み込み状態がテキストで分かる
prefers-reduced-motionでアニメーションが止まる（または弱まる）
6. 受け入れ基準の書き方：WCAG番号より“操作結果”で
受け入れ基準は、チームの合意をつくる言葉です。
WCAG番号の羅列だけだと「で、何を確認すれば？」となりやすいので、次の型が効きますの。
6.1 受け入れ基準の型（おすすめ）
- 前提：どの画面・どのコンポーネントか
- 操作：何をするか（Tab、矢印、Enter、Escなど）
- 期待：どうなるべきか（フォーカス、読み上げ、状態表示）
- 例外：例外があれば明記（外部埋め込みなど）
例（モーダル）
- 操作：設定ボタンをEnterで押しモーダルを開く
- 期待：モーダル内の最初の操作要素へフォーカスが移動する
- 操作：Esc
- 期待：モーダルが閉じ、設定ボタンへフォーカスが戻る
この形にすると、QAもデザイナーも同じ言葉で話せます。
7. デザインレビューと実装レビュー：どこで何を見るか
7.1 デザインレビュー（Figmaなど）の観点
- コントラスト（本文/リンク/非テキスト）
- フォーカスリングの見え方（背景の上でも）
- 状態（hover/focus/disabled/error/selected）
- タッチターゲット（44px相当）
- 文章（ラベル、ヘルプ、エラーの言い回し）
- 色だけで意味を伝えていないか（アイコン・テキスト併用）
7.2 実装レビューの観点
- ネイティブ要素優先（button、a、input）
- ランドマークと見出し階層
- キーボードで完遂できるか
aria-*の過不足（付けすぎも事故）- フォーカス遷移（モーダル、メニュー、エラー時）
8. 5分スモークテスト：デザインシステム側に“儀式”を置く
デザインシステムに、コンポーネント共通の最小テストを“儀式”として固定すると強いです。
- Tabのみで主要操作が完遂できる
- フォーカス可視（ライト/ダーク）
- モーダル：開く→操作→Esc→復帰
- フォーム：ラベル・必須明示・エラー要約・個別エラー関連付け
- 色だけに依存しない（リンク、エラー、状態）
- 200%拡大で破綻しない（表・コード除く）
prefers-reduced-motionで動きが抑制される- スクリーンリーダーで名前・役割・状態が把握できる（最低限）
9. 運用とガバナンス：デザインシステムを“使われ続ける”状態へ
9.1 変更管理（バージョニング）
- 破壊的変更（例：モーダルAPI変更）はメジャーアップ
- 小変更（文言追加、軽微改善）はマイナー/パッチ
- 変更点は「何が良くなったか」を先に書く（採用されやすいですの）
9.2 例外処理（どうしても守れない時）
例外はゼロにできません。大切なのは“例外の扱いを標準化”すること。
- 例外申請（理由、影響、代替手段、改善予定）
- 期限を付ける（永遠の例外にしない）
- アクセシビリティ声明や窓口と連携（置き去り防止）
9.3 役割分担（最小の体制）
- オーナー：方針と優先度の決定
- メンテナー：コンポーネントとドキュメント更新
- レビュー担当：受け入れ基準のチェック
- 窓口：利用者の困りごとを拾い、改善に繋ぐ
小さく始めても構いません。役割がゼロだと、必ず腐りますの。
10. 対象読者にとっての価値（具体）
- デザイナー：状態・フォーカス・文言の型があり、迷いが減って制作が早くなる。
- エンジニア：ARIAやフォーカス管理の“定石”が標準化され、回帰バグが減る。
- QA：受け入れ基準が操作結果で定義され、検証が再現可能になる。
- PM/運用：プロダクトが増えても品質が揺れにくく、説明責任と信頼が積み上がる。
- 利用者：どの画面でも操作が一貫し、困ったときの導線も確保され、安心して使える。
11. アクセシビリティレベルの評価（本記事の到達点）
- **WCAG 2.1 AAを“継続的に満たすための設計と運用”**を中心に構成しています。主に次の達成基準と結びつきます。
- 1.1.1 非テキストコンテンツ：アイコン・画像の扱いを標準化
- 1.3.1 情報及び関係性：フォーム、表、見出し、ランドマークの構造化
- 1.4.1 色の使用 / 1.4.3 コントラスト / 1.4.11 非テキストコントラスト：トークンで担保
- 1.4.10 リフロー：レスポンシブ方針を仕様へ
- 2.1.1 キーボード：コンポーネント操作の標準化
- 2.4.3 フォーカス順序 / 2.4.7 フォーカス可視：フォーカストークン＋仕様で固定
- 3.3.x 入力支援：エラー通知・提案・誤入力防止の標準化
- 4.1.2 名前・役割・値：ARIAの最小正確運用
- さらに、テストとガバナンスを含めることで、**“一度の準拠”ではなく“維持できる準拠”**に近づける内容です。
12. まとめ：やさしさを“部品”にして、チームの力にする
- アクセシビリティは、トークンとコンポーネントに埋め込むと強い。
- 仕様は「構造・操作・状態・文言・受け入れ基準」をセットで書く。
- 受け入れ基準はWCAG番号より、操作結果の文章で定義する。
- 5分スモークテストを“儀式”にして回帰を防ぐ。
- 例外は申請と期限で管理し、置き去りを作らない。
- 運用とガバナンスがあると、アクセシビリティは続き、信頼が積み上がる。
アクセシビリティは、特別な機能ではなく、日々の標準の中にあるほうが美しいですわ。
あなたのチームの“やさしさ”が、プロダクトの成長と一緒に、ずっと自然に続いていきますように。心を込めて応援しますね。