アクセシブルなグラフ設計ガイド｜色、代替テキスト、表、操作をWCAG 2.2で確認

アクセシブルなグラフとは、見た目だけでなく、文章、データ表、キーボード操作など複数の方法で内容を理解できるグラフです。
色の見分けにくさ、弱視、スクリーンリーダーの利用、拡大表示、小さな画面、マウスを使わない操作を想定すると、読み手が情報へ到達する方法を一つに限定せずに済みます。

設計の出発点は「きれいに描くこと」ではなく、「何を比較し、どの変化や例外を伝えるか」を文章で定めることです。
結論を短い要約で示し、正確な値を表で確認できるようにし、その理解をグラフで助ける順序なら、描画や操作に問題が起きても情報が失われにくくなります。

アクセシブルなデータ可視化の三つの層

グラフのアクセシビリティは、代替テキストを一つ追加するだけでは整いません。
読み手が欲しい情報の粒度に合わせて、要約、データ、視覚表現の三つを用意します。

1. 要約：結論、傾向、最大値や最小値、例外を短い文章で伝えます。
2. データ：比較に必要な値を、見出しのあるHTMLの表やダウンロード可能なファイルで提供します。
3. 視覚表現：棒、線、点、面積などを使い、値の関係を短時間で把握できるようにします。

要約はすべての値を読み上げる場所ではなく、グラフから読み取ってほしい内容を示す場所です。
一方、データ表は正確な値を調べたり、行と列を比較したりするために使います。
この役割分担があると、長すぎる代替テキストや、視覚情報だけに依存した説明を避けられます。

グラフを作る前に決めること

まず、利用者の問いを一文にします。
「月別の売上はいくらか」と「売上が落ち込んだ月はいつか」では、必要な表現が異なるためです。

グラフの種類は、見栄えではなく問いに合わせて選びます。
値の意味、単位、対象期間、集計条件も、タイトル、軸ラベル、キャプションのいずれかで確認できるようにします。

色だけに頼らない系列の区別

WCAG 2.2の達成基準1.4.1「色の使用」は、情報を伝える唯一の視覚的手段として色を使わないよう求めています。
色を使わないという意味ではなく、色を見分けられなくても同じ情報を得られる手掛かりを加えるという意味です。

• 折れ線グラフ：実線と破線、丸と三角のマーカー、線の終点に置く系列名を組み合わせます。
• 棒グラフ：塗り色に加えて、斜線や点のパターン、棒の近くに置く値や項目名を使います。
• 状態表示：「正常」「要確認」などの文字やアイコンを添え、緑と赤だけで意味を分けません。
• 凡例：グラフ本体と同じ線種やパターンを使い、対応する対象の近くに置きます。

配色そのものの決め方は、既存記事の色覚多様性に配慮したWeb配色の実践手順でも確認できます。

文字とグラフィックのコントラストを分けて確認する

コントラストの基準は、文字とグラフィックで扱いが異なります。
WCAG 2.2のレベルAAでは、通常の文字は背景に対して4.5対1以上、大きな文字は3対1以上が基準です。

軸、線、マーカーなど、内容を理解するために必要なグラフィック部分は、隣接する色に対して3対1以上を確認します。
装飾的なグリッド線まで一律に強くすると主データが埋もれるため、その線が理解に必要かを先に判断します。

代替テキスト、長い説明、データ表の使い分け

画像として掲載するグラフには、画像の種類と目的が分かる短い代替テキストを付けます。
複雑なグラフでは、すべての値をalt属性へ詰め込まず、本文の要約や構造化されたデータ表へ案内します。

• 短い代替テキスト：何のグラフか、どの期間や対象か、どこに詳しい説明があるかを示します。
• 本文の要約：伝えたい傾向、最大値や最小値、例外を説明します。
• データ表：値、単位、行と列の関係をHTMLの構造で示します。
• ダウンロード：再利用が必要なデータにはCSVなどを用意し、ファイルの内容と形式をリンク文で伝えます。

aria-describedbyで長い説明を関連付ける方法もありますが、参照先に表や見出しがある場合、その構造が支援技術へ期待どおり伝わるとは限りません。
構造を保つ必要がある説明は、同じページで普通に読める見出し、文章、表として提供します。

画像ごとのalt属性の判断は、代替テキストの基本と書き方も参考になります。

架空データを使ったHTML例

次の例では、短い代替テキストの後に要約とデータ表を置きます。
グラフを見られない場合も、3月が最大で1月が最小だと分かり、各月の値も表から確認できます。

<figure>
  <img
    src="orders.png"
    alt="2025年上期の月別注文数を示す棒グラフ。要約とデータ表が続きます。"
    aria-describedby="orders-summary">
  <figcaption>月別注文数（架空の例）</figcaption>
</figure>

<p id="orders-summary">
  3月が1,240件で最大、1月が780件で最小です。
  4月以降は1,180件から1,210件の範囲で推移しています。
</p>

<table>
  <caption>2025年上期の月別注文数（架空の例）</caption>
  <thead>
    <tr>
      <th scope="col">月</th>
      <th scope="col">注文数</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">1月</th><td>780件</td></tr>
    <tr><th scope="row">2月</th><td>920件</td></tr>
    <tr><th scope="row">3月</th><td>1,240件</td></tr>
    <tr><th scope="row">4月</th><td>1,180件</td></tr>
    <tr><th scope="row">5月</th><td>1,210件</td></tr>
    <tr><th scope="row">6月</th><td>1,190件</td></tr>
  </tbody>
</table>

インタラクティブなグラフの操作設計

表示切替、絞り込み、範囲変更、詳細表示などの機能がある場合は、マウスやタッチだけでなくキーボードでも同じ結果へ到達できるようにします。
ホバーだけで開くツールチップは避け、フォーカスや明示的なボタン操作でも内容を表示します。

• 系列の表示切替には、ラベルのあるネイティブのボタンやチェックボックスを優先します。
• 現在の表示状態を、見た目とプログラムの両方で判別できるようにします。
• フィルター後の件数や期間など、フォーカスを移さずに変わる結果は、適切なステータスメッセージとして伝えます。
• フォーカス位置を常に見える状態にし、グラフ内で迷わない操作順序を決めます。
• データ点を一つずつTabキーで移動させると停止回数が増えるため、点が多い場合は表を主要経路にするか、矢印キーで移動する複合的な操作方法を検討します。

独自のキー操作を採用する場合は、操作方法をグラフの前で説明し、実装するライブラリと支援技術の組み合わせで確認します。
キーボード操作とフォーカスの全体像は、キーボード操作とフォーカス表示の実務ガイドで詳しく解説しています。

SVGとCanvasで異なる確認点

SVGは要素を文書構造として扱えますが、要素へ役割や名前を付ければ自動的に使いやすくなるわけではありません。
読み上げ順、フォーカス数、支援技術での認識、代替の表や文章まで含めて検証します。

Canvasの描画内容は、そのままではHTMLの構造として伝わりません。
要約、データ表、操作用のHTML要素を別に用意し、Canvasだけを情報取得や操作の唯一の経路にしない設計が必要です。

拡大表示、リフロー、タップ領域

WCAG 2.2の達成基準1.4.10「リフロー」は、横書きコンテンツでは幅320 CSSピクセル相当まで狭めても、原則として情報や機能を失わず二方向のスクロールを求めないことを扱います。
ただし、意味を保つために二次元の配置が必要なデータ表や図には例外があります。

グラフ全体を無理に縮小してラベルを読めなくするのではなく、要約を先に表示し、グラフは必要に応じて横スクロールできる領域へ分離し、データ表は行見出しが追えるようにします。
文字、凡例、ツールチップが切れないことも、拡大率を変えて確認します。

操作対象は、WCAG 2.2の達成基準2.5.8が定める24×24 CSSピクセル以上、または規定の間隔や例外を確認します。
見た目のマーカーが小さい場合でも、ボタンのクリック可能領域や代替操作を十分に確保します。

WCAG 2.2で関係する主な達成基準

次の表は、グラフで確認しやすい項目を実務向けに対応付けたものです。
これらを実装しただけでページ全体の「WCAG 2.2 AA準拠」を宣言できるわけではなく、適合を示すには対象ページと一連の操作を含む試験が必要です。

WCAGの全体像と2.2で追加された項目は、WCAG 2.2の実務入門も参照してください。

公開前に行う手動テスト

1. 文章だけで確認：タイトル、要約、データ表を読み、グラフの結論と正確な値へ到達できるかを確かめます。
2. 色を外して確認：モノクロ表示などで、系列と状態を線種、形、パターン、文字から区別できるかを確かめます。
3. 拡大して確認：400％拡大や幅320 CSSピクセル相当で、説明、表、操作が欠けないかを確かめます。
4. キーボードで確認：表示切替、フィルター、詳細表示を操作し、フォーカスが見え、移動順が理解できるかを確かめます。
5. スクリーンリーダーで確認：グラフ名、要約、表の見出し、操作状態、更新結果が意味の通る順序で伝わるかを確かめます。
6. 複数の画面幅で確認：ラベルやツールチップの重なり、切れ、表の読みにくさがないかを確かめます。
7. 実データで確認：長い項目名、負の値、欠損値、系列の増加、最大値と最小値が近い場合も崩れないかを確かめます。

チームで品質を保つ方法

個別のグラフを毎回ゼロから直すと、同じ問題が繰り返されます。
デザインシステムやBIテンプレートに、色以外の手掛かり、要約欄、データ表、フォーカス表示、空データやエラーの文言を組み込みます。

レビューでは「色数」だけでなく、利用者の問い、要約、単位、代替経路、操作、更新通知を確認します。
公開後にデータや系列が変わるグラフは、データ更新時にも要約と代替テキストが整合する運用を決めておきます。

グラフを伝わる情報へ変える

グラフに必要なのは、色を減らすことだけではありません。
利用者の問いを定め、要約、データ表、視覚表現を役割分担させ、操作と更新結果まで複数の方法で伝える設計が必要です。

最初の改善では、既存のグラフに結論を示す一段落と、正確な値を確認できる表を追加してください。
次に、色以外の手掛かり、コントラスト、キーボード操作、拡大表示を順に確認すると、見た目を保ちながら情報への入口を増やせます。

参考資料

• W3C「Web Content Accessibility Guidelines (WCAG) 2.2」
• W3C WAI「Complex Images」
• W3C WAI「Understanding Success Criterion 1.4.1: Use of Color」
• W3C WAI「Understanding Success Criterion 1.4.11: Non-text Contrast」
• W3C WAI「Understanding Success Criterion 2.5.8: Target Size (Minimum)」