Figma での色アクセシビリティテスト：プラグインとワークフロー

Figma でのアクセシビリティテストは、デザイン後のチェックリストではなく、色の決定を行うと同時に、ワークフローに継続的に埋め込まれるべきものです。Figma 内（およびそのすぐ隣）で利用可能なツールは、これを実際にしています。コントラストチェック、色覚異常シミュレーション、バッチアクセシビリティ監査のすべてが、デザイン環境を離れることなく可能です。

このガイドは、主なプラグイン、そのワークフロー、それぞれが何をよくしているのか、どこで不足しているのか、トークン定義から開発者への引き継ぎまで、アクセシブルな色ワークフローを構築する方法をカバーしています。

Stark プラグインでのコントラストチェック

Stark は、Figma エコシステムで最も広く採用されているアクセシビリティプラグインです。無料ティアでは WCAG 2.1 コントラストチェック；有料ティアではバッチチェック、色覚異常シミュレーション、インタラクティブ要素の注釈、および完全なキャンバスのビジョンシミュレーターを追加します。

Stark をインストールして有効化する

Figma コミュニティから Stark をインストールします（プラグイン → コミュニティを参照 → 「Stark」を検索）。インストール後、任意の Figma ファイルのプラグインメニューからアクセスします。

Stark でのコントラストチェック

Stark の主要な機能：2つのレイヤー（または1つのテキストレイヤーを背景の上に）を選択して、Stark を実行し、コントラスト比と WCAG 適合状況を報告します。

ステップバイステップのワークフロー：

1. デザイン内のテキストレイヤーを選択
2. Stark を開く（プラグイン → Stark → コントラストをチェック）
3. Stark はテキストレイヤーの塗りつぶし色と、それの後ろの背景色を検出します
4. 結果は以下を示します：
5. 正確なコントラスト比（例：6.2:1）
6. 通常テキスト（≥ 4.5:1）と大きいテキスト（≥ 3:1）の WCAG AA 合格/不合格
7. 通常テキスト（≥ 7:1）と大きいテキスト（≥ 4.5:1）の WCAG AAA 合格/不合格

結果が失敗する場合、Stark は提案を提供します。ターゲット比に合格するテキストまたは背景の代替値。

Stark コントラストチェックの長所

Stark は、複雑な背景上にあるテキストを正しく処理します。テキストレイヤーがグラデーションまたは画像と重なる場合、Stark はレイヤーの直接の親塗りつぶしを使用するのではなく、テキスト位置で実際にレンダリングされた背景をサンプリングします。これにより、直接の親の色のみをチェックするツールよりも正確な結果が得られます。

Stark のコントラストの制限

Stark はレイヤーレベルでコントラストをチェックし、設計トークンレベルではチェックしません。テキストレイヤーが text/primary 変数にバインドされていることを認識しません。解決された 16 進値を確認するだけです。これは以下を意味します：

• プリミティブ変数の値を変更すると、既存フレーム上の Stark の結果が古くなります。古い値を反映し、再チェックするまで新しい値を反映しません
• Stark は、ライトモードで合格しているがダークモードで失敗するトークンペアに、各モードを個別にチェックしない限りフラグを付けません

これが、Stark とトークンレベルのコントラスト検証（トークン定義段階で生のプリミティブ値を互いに照合するチェック）を組み合わせることが重要な理由です。ColorFYI の コントラスト チェッカーを使用して、コンポーネントが作成される前の定義段階でトークンペアを検証します。

A11y カラーコントラストプラグイン

いくつかのプラグインは、完全な Stark 機能セットなしにアクセシビリティに特に焦点を当てています。注目すべき代替案：

A11y — カラーコントラストチェッカー

この無料プラグイン（Figma コミュニティで入手可能）は、シンプルで高速なコントラストチェックインターフェースを提供します。フレームを選択してプラグインを実行します。すべてのテキストレイヤーを反復処理し、スクロール可能なリストにコントラスト比を報告します。各項目はテキストコンテンツ、前景色、背景色、比率、合格/不合格状況を示します。

最良の使用例： 引き継ぎ前に1つのフレームまたはコンポーネントセットの迅速な監査。Stark より一括レビュー用に高速ですが、機能が少ないです。

制限事項： 重なったレイヤーまたはグラデーションを Stark ほど正確には検出しません。直接の親レイヤーの背景色をチェックします。テキストが視覚的に複雑な背景上にある場合、誤った結果が得られる可能性があります。

WCAG カラーコントラストチェッカー（Anuoluwapo Odunsi による）

別の軽量の無料オプション。A11y と同様の機能。選択されたフレーム内のテキストレイヤーを反復処理し、合格/不合格状況を報告します。UI は、緑（合格）と赤（不合格）のインジケーター付きの単純なリストで結果を提供します。

このプラグインは、単色背景で設計されたシンプルなレイアウトに対して信頼性があります。本番使用の場合、非単色背景上のレイヤーについて、その結果を Stark または外部ツールに対して検証します。

Stark と無料代替案の選択

ソロデザイナーを対象とした小規模プロジェクトでは、無料の Stark ティアと A11y プラグインが大部分のニーズを満たしています。共有ライブラリを保守するデザインシステムチームの場合、Stark Pro のバッチチェックとシミュレーションは投資する価値があります。

Figma での色覚異常シミュレーション

Figma には色覚異常シミュレーション機能はありません。オプションはプラグインベースのシミュレーションと外部ツールチェックです。

Stark のビジョンシミュレーター

Stark Pro には、Figma キャンバス全体に色覚異常シミュレーションをリアルタイムでオーバーレイするビジョンシミュレーターが含まれています。個別色シミュレーションツールとは異なり、これはすべてのコンポーネント、すべてのコンテキスト（特定の状態を持つ人に表示される完全なデザイン）を示します。

Stark Pro のシミュレーションタイプ： - 赤色弱視（赤色錐体なし — 赤は非常に暗く見える） - 緑色弱視（緑色錐体なし — 最も一般的、赤/緑の混同） - 青色弱視（青色錐体なし — 青/黄色の混同、稀） - 無色覚（完全な色覚異常、グレースケール） - ぼやけた視力（視敏度シミュレーション）

シミュレーターはレイヤーオーバーレイです。レビュー中に任意のフレームで有効/無効に切り替えることができます。これにより、調整を行う際にリアルタイム比較が可能になります。

ColorFYI を使用した色個別シミュレーション

デザイントークンシステム内の特定の色（レンダリングされたキャンバスではなく）をチェックするために、ColorFYI の Color Blindness Simulatorは、各シミュレーションタイプの下で与えられた 16 進値がどのように変換されるかを正確に示します。結果の 16 進コードを含みます。

これは特にトークン定義段階で価値があります。セマンティックトークンペア（例：status/error = #EF4444 と status/success = #22C55E）をコミットする前に、両方の値をシミュレーションします：

1. 緑色弱視の下で #EF4444をシミュレーション — 褐色のオリーブ色になります
2. 緑色弱視の下で #22C55Eをシミュレーション — 同様の褐色になります

両方の色は、最も一般的な色覚異常の形式の下で見分けがつかない値に収束します。このペアは、色の差だけで意味を伝える場合、使用するたびに問題があります。トークンレベルで解決する根本的な問題であり、ダースのコンポーネントに伝播するのを防ぎます。

ブラウザー DevTools シミュレーション（無料、プラグイン不要）

Chrome と Firefox DevTools には、アクセシビリティツール内の色覚異常シミュレーターが含まれています。Chrome では：

1. DevTools を開く（F12 または Cmd+Option+I）
2. レンダリングパネルを開く（3ドット メニュー → その他のツール → レンダリング）
3. 「ビジョン欠損をエミュレート」にスクロール
4. 任意の欠損タイプを選択

Figma の内側ではありませんが、このシミュレーションはステージングまたは本番環境に適用されます。デザインモックアップではなく、最終的にレンダリングされたインターフェースの QA テストに役立ちます。

フレーム全体をバッチチェック

バッチチェックは、アドホックなスポットチェックから体系的なアクセシビリティ監査を分離するワークフローです。個別レイヤーを選択する代わりに、コンポーネント全体またはページを一度に監査します。

Stark Pro バッチチェックワークフロー

1. 監査したいフレームまたはコンポーネントを選択（ページ全体または特定のセクション可能）
2. Stark を開く → コントラストをチェック（有料ティアがアクティブ）
3. Stark は選択内のすべてのテキストレイヤーを反復処理
4. 結果はスクロール可能なリストで表示：各行はテキストレイヤー名、コントラスト比、AA と AAA の合格/不合格状況を示します
5. 失敗した項目をクリックして、キャンバス内のそのレイヤーに直接移動

すべてのボタン、カード、入力、バッジコンポーネントバリアントを含むコンポーネントライブラリフレームの場合、バッチチェックは、1時間の手動チェックで実行されるタスクの中で、すべてのバリアント全体のすべてのコントラスト失敗を1つの操作で特定します。

効率的なバッチチェック用の整理

バッチチェックをアクション可能にするために、Figma ファイルを構造化します：

• コンポーネントページ ：すべてのコンポーネントバリアントを1つの「コンポーネント」ページに保持し、フレームをコンポーネントタイプ別に整理します。ライブラリアップデートを公開する前に、コンポーネントフレームごとにバッチチェックを実行します。
• スクリーンページ ：完全なスクリーンモックアップを別々のページに保持します。デザインレビュー会議またはクライアントプレゼンテーション前に、スクリーンごとにバッチチェックを実行します。
• アクセシビリティレビューフレーム ：デザインシステム内のすべてのテキスト/背景の色組み合わせを含む専用フレーム（「コントラストマトリックス」）を作成します。このフレームでバッチチェックを実行して、コンポーネント構成に関係なく、トークンシステム自体を監査します。

コントラストマトリックスを構築

コントラストマトリックスは、デザインシステム内のすべてのテキスト/背景組み合わせを表示するシステマティックグリッドで、事前計算されたコントラスト比です。特にダークモードドキュメントに役立ちます。

構造：

ColorFYI の コントラスト チェッカーを使用して、各モードの比率を入力します。合格しない組み合わせは、公開される前にプリミティブレベルで修正されます。マトリックスは生きているドキュメント—プリミティブ値が変わるときに更新します。

開発者への引き継ぎのためにアクセシビリティに注釈を付ける

Figma のアクセシビリティ注釈は、使用されたどの色を開発者に伝えるだけでなく、その色の実装においてそれらが満たす必要があるアクセシビリティ要件も通信します。

注釈を付ける内容

コントラスト比注釈 ：必須の最小コントラスト比を持つすべてのテキスト/背景ペア（特に AA に合格しているが AAA に合格していないペア）について、コンポーネントに比率と対象基準を注釈してください。

ボタンコンポーネントへの注釈例：

ボタンラベル / ボタン背景：4.7:1（WCAG AA ✓）
無効なボタンラベル / 無効な背景：2.1:1（意図的—無効状態）
フォーカスリング / ページ背景：3.2:1（UI コンポーネントの WCAG AA ✓）

非色インジケーター注釈 ：色を使用して意味を伝える要素については、その要素に付属する必要がある非色同等物を注釈してください。

エラー状態：赤いボーダー（#DC2626）+ ⚠ エラーアイコン + フィールドの下の「エラー：[メッセージ]」テキスト
成功状態：緑のボーダー（#16A34A）+ ✓ チェックアイコン + 成功テキスト
必須フィールド：赤いアスタリスク（*）+ 「必須」ラベル（色のみではない）

フォーカスインジケーター注釈 ：フォーカスリングの色、オフセット、最小サイズを文書化します。これは開発者への引き継ぎでしばしば見落とされていますが、WCAG 2.2 適合に必要です：

フォーカスインジケーター：
  色：border/focus（#3B82F6 ライト / #60A5FA ダーク）
  オフセット：2px
  幅：2px
  最小領域：2px × コンポーネントの周囲
  隣接する色に対して3:1 のコントラストを確保

Figma の注釈ツールを使用

Figma は組み込みの注釈ツールを提供します（検査 → 注釈またはデブ引き継ぎのマークアップモード）。これらはアクセシビリティ固有のフィールドを持っていませんが、スティッキーノート（異なる色のテキストフレーム）を、コンポーネントの近くに配置された注釈吹き出しとして使用できます。

頻繁に引き継ぎを行うチームの場合、Figma Tokens Annotation または A11y Annotation Kit（コミュニティファイル）などのコミュニティプラグインは、開発者がすぐに認識する標準化された注釈形式を提供します。

アクセシビリティ仕様ドキュメント

重要なコンポーネントリリースまたはデザインシステム v2 の立ち上げについて、Figma デザインに加えて別のアクセシビリティ仕様を作成します：

1. WCAG 成功基準 ：各コンポーネントに適用される SC をリストアップします（例：テキストの場合は 1.4.3 コントラスト、UI コンポーネントの場合は 1.4.11 テキスト以外コントラスト）
2. コントラスト比テーブル ：コンポーネント内で使用されるすべての色ペアのコントラストマトリックス値
3. 色覚異常互換性 ：主要な色ペアのシミュレーション結果—コンポーネントが色のみのテストに合格するかどうかを指摘
4. テストの指示 ：開発者が実装の色アクセシビリティを検証する方法（ブラウザー DevTools シミュレーション、自動 axe チェック、手動スクリーンリーダー レビュー）

このドキュメントは開発者の QA の受け入れ基準となり、各コンポーネントの「アクセシブル」が何を意味するかについての曖昧性を排除します。

アクセシブルな色ワークフローを構築

アクセシブルな色ワークフローは、デザインプロセスの終わりでのゲートシリーズではなく、すべてのステージで分散した習慣のセットです。

ステージ 1：トークン定義

コンポーネントが構築される前に： - すべての意図された色組み合わせのセマンティックトークンペア（背景/前景）を定義 - ColorFYI の コントラスト チェッカーを使用して WCAG AA に対して各ペアを検証 - ColorFYI の Color Blindness Simulatorを通じて、意図された各ペアの両方の色をシミュレート—両方の色が類似したシミュレート値に収束するペアにフラグを付ける - セマンティックトークン値にコミットする前に、プリミティブレベルで失敗するペアを修正

ステージ 2：コンポーネント設計

コンポーネントが構築される際： - 変数にバインドした後、すべてのテキストレイヤーで Stark のインラインコントラストチェックを使用 - バリアントが完了したときに、各コンポーネントフレームで Stark バッチチェックを実行 - Figma の変数モードスイッチャーを使用して、ライトとダークの両方のモードでコンポーネントをレビュー - インタラクティブ状態（ホバー、フォーカス、アクティブ、無効）を特に確認します。無効状態はデザイン上低コントラストを持つことがありますが、それは受け入れ可能です。明示的に文書化します

ステージ 3：スクリーン設計

スクリーンがアセンブルされる際： - メジャーレイアウト変更後、各フルスクリーンフレーム全体で Stark バッチチェックを実行 - すべてのステータスメッセージ（エラー、成功、警告、情報）をテストします。これらは色に大きく依存し、色覚異常失敗の高リスクです - すべてのフォーム検証状態が非色インジケーター（アイコン、テキスト、またはパターン）を含むことを確認

ステージ 4：引き継ぎ

開発に配信する前に： - デザイン内のすべての非明白な色ペアについて、コントラスト注釈を作成 - すべての色分けされた要素について、非色冗長性の要件を文書化 - 主要なステータス色ペアについて、色覚異常シミュレーション結果を含める - フォーカスインジケーターの色、幅、コントラスト要件を指定

ステージ 5：QA

開発実装後： - レンダリングされたアプリケーションで、ブラウザー DevTools 色覚異常シミュレーションを使用 - 本番ページで自動 axe または Deque コントラストアナライザースキャンを実行 - フォーカスインジケーターがライトとダークモードの両方で見え、コントラスト要件を満たしていることを確認 - 非標準背景色（カラフルなカードやステータスバナーなど）を使用するコンポーネントについて、テキストの読みやすさをスポットチェック

重要なポイント

• Stark は Figma 内で最も多機能のアクセシビリティプラグインです。無料ティアは個別のコントラストチェックを処理；有料ティアはフレーム全体のバッチチェックと完全なキャンバスの色覚異常シミュレーションを追加します。
• 無料代替案（A11y、WCAG カラーコントラストチェッカー）はクイックスポットチェックに役立ちますが、複雑な背景の精度は低いです。重要な発見については Stark または外部ツールで交差確認してください。
• トークンレベルでの色覚異常シミュレーション（生の 16 進値で ColorFYI の Color Blindness Simulatorを使用）は、コンポーネントが構築される前に行われるべきです—問題のある発見をプリミティブ段階で捕捉して、すべての場所に伝播するのを防ぎます。
• コントラストマトリックスを構築して、ライトとダークモードの両方で、すべてのトークンペアのコントラスト比を文書化—これは生きているドキュメントになり、ライブラリ公開チェックリストになります。
• バッチチェック（Stark Pro または A11y 無料プラグイン）は、一度に整数のコンポーネントフレームを監査します。プロジェクト完了時ではなく、ライブラリ公開の前にバッチチェックを実行してください。
• 開発者への引き継ぎでアクセシビリティを明示的に注釈 ：コントラスト比、非色冗長性の要件、フォーカスインジケーター仕様、各コンポーネントの WCAG 成功基準。
• アクセシブルなワークフローはステージ全体に分散している—トークン定義、コンポーネント設計、スクリーンアセンブリ、引き継ぎ、QA—最後の1つのパスではありません。