データ表とグラフのアクセシビリティでは、見た目を整えるだけでなく、数値、見出しとの関係、傾向、操作方法を別の手段でも受け取れるようにします。
スクリーンリーダーを使う人、画面を拡大する人、色の違いを判別しにくい人、キーボードで操作する人も、同じ判断材料へ到達できる設計が必要です。
この記事では、HTMLテーブルの基本から、狭い画面への対応、グラフの代替説明、SVGとCanvasの扱い、公開前後の検証までを実装例とともに整理します。
個々の手法を採用しただけで「WCAG 2.2のAAに準拠した」とは判断できないため、記事内の基準値は確認項目として扱い、最終的にはページ全体を試験してください。
最初に押さえる四つの原則
- 表の関係をHTMLで示す:見た目の太字ではなく、
caption、th、scopeなどで表題と見出しを表します。 - グラフの結論と数値をテキストでも示す:短い説明、本文の要約、必要に応じたデータ表を組み合わせます。
- 色だけに意味を持たせない:線種、形、ラベル、模様などを併用します。
- 実際の利用条件で確かめる:キーボード、スクリーンリーダー、拡大表示、狭い画面で情報や操作が失われないかを確認します。
Webアクセシビリティは、年齢や障害、利用環境にかかわらず、Web上の情報や機能を利用できる状態を目指す考え方です。
基準の全体像を先に確認したい場合は、WCAG 2.2で追加された達成基準の実務解説も参照してください。
データ表は見出しとの関係から設計する
データ表は、行と列の交点にある値を、行見出しと列見出しの組み合わせで読むものです。
その関係がHTMLに記述されていれば、支援技術はセルを移動するときに対応する見出しを伝えられます。
単純な表に必要な要素
caption- 表の題名です。
何を、どの時点や単位で示す表なのかを簡潔に書きます。 th- 見出しセルです。
装飾のためではなく、その行や列を説明するセルに使います。 scope- 見出しが列に対応するのか、行に対応するのかを示します。
単純な表ではcolとrowを使い分けます。 - 近接する注記
- 単位、集計期間、欠損値の表記、出典など、値の解釈に必要な情報です。
表から離れた場所に置かず、題名または表の直後で確認できるようにします。
次の例では、最上段を列見出し、左端を行見出しとして関連付けています。
<table>
<caption>四半期別売上の例(単位:百万円)</caption>
<thead>
<tr>
<th scope="col">製品</th>
<th scope="col">第1四半期</th>
<th scope="col">第2四半期</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">製品A</th>
<td>120</td>
<td>140</td>
</tr>
</tbody>
</table>
aria-labelで表に名前を付ける方法もありますが、画面上で読める表題が必要ならcaptionを優先します。
見える題名と読み上げ名を別々に管理すると、更新時に内容が食い違うおそれがあるためです。
複雑な表は分割できないかを先に考える
多段見出しや結合セルが多い表では、一つのデータセルに複数の見出しが対応します。
この場合は、表を目的別に分ける、見出しを繰り返す、詳細を別表へ移すといった単純化を先に検討します。
分割すると比較の意味が失われる場合は、各見出しセルに一意のidを付け、データセルのheaders属性から必要な見出しを列挙します。
ただし、属性の追加だけで正しさは保証されないため、想定するブラウザとスクリーンリーダーで読み上げ順を確認します。
<th id="store" scope="col">店舗</th>
<th id="current-food" scope="col">現在の食品在庫</th>
...
<th id="tokyo" scope="row">東京</th>
<td headers="tokyo current-food">120</td>
単位、欠損、並び順を明記する
「120」という値だけでは、金額、人数、割合のどれか判断できません。
単位と集計期間を表題または見出しに置き、税込みか税抜きか、速報値か確定値かなど、解釈を変える条件も近くに記載します。
欠損値とゼロも区別します。
たとえば「未取得」はデータがない状態であり、「0」は測定した結果がゼロだった状態なので、同じ記号で表すと判断を誤らせます。
レスポンシブ表は情報を消さずに扱う
列の多い表を狭い画面へ収めるとき、文字を極端に小さくしたり、補助列をCSSだけで非表示にしたりすると、比較に必要な情報を失います。
表の用途と列同士の関係を確かめ、次の方法から選びます。
| 方法 | 向いている表 | 注意点 |
|---|---|---|
| 表だけを横スクロール | 列を並べたまま比較する必要がある表 | スクロールできることを見た目と操作の両方で分かるようにする |
| 重要列と詳細表示 | 一覧では要点を確認し、詳細画面で全項目を見る表 | 隠した値へキーボードでも到達できる明示的な操作を用意する |
| カード表示 | 行ごとに独立して読める一覧 | 列を横断する比較には向かず、DOMの順序と見出しの対応を再設計する必要がある |
横スクロールを基本形にする
列の比較が主目的なら、表を専用のスクロール領域に収める方法が扱いやすい選択です。
ページ全体ではなく表だけが横へ動くため、表以外の本文は狭い画面でも一方向に読み進められます。
<div class="table-scroll" role="region"
aria-label="四半期別売上表"
tabindex="0">
<table>...</table>
</div>
.table-scroll {
max-width: 100%;
overflow-x: auto;
}
.table-scroll:focus-visible {
outline: 3px solid currentColor;
outline-offset: 2px;
}
tabindex="0"を付けるとスクロール領域へキーボードで移動できますが、ページ内のフォーカス停止位置も増えます。
実装後は、キーボードで実際に横移動できるか、領域名が過不足なく伝わるか、フォーカス表示が見えるかを確認します。
カード表示へ変換する場合は、CSSでtheadを隠して各セルに疑似要素のラベルを足すだけで終えません。
支援技術によって表のセマンティクスの扱いが変わる可能性があるため、列を横断する比較が不要かを判断したうえで、実際の読み上げを検証します。
拡大とリフローを含むモバイル対応は、モバイルWebアクセシビリティの実践手順で詳しく解説しています。
グラフは要点、詳細、元データを分けて伝える
グラフは、値の推移や差を短時間で把握するための視覚的な要約です。
一方、正確な値の比較や任意の項目の検索には表が向いています。
どちらか一方を常に正解とせず、読者が行う作業に合わせて次の三層を用意します。
- 短い名前:何を示すグラフかを代替テキストやアクセシブルネームで伝えます。
- 本文の要約:増減、最大値、例外など、グラフを掲載した理由に直結する傾向を書きます。
- 詳細な値:正確な数値が判断に必要なら、同じページのデータ表または明確なリンク先で提供します。
複雑なグラフのalt属性へ全データを詰め込むと、構造をたどれない長い読み上げになります。
短い説明で画像を識別し、見出しや表を使える本文側に詳細を置くと、視覚的に読む人にも同じ補足が届きます。
画像や非テキスト情報全般の考え方は、非テキスト情報の代替手段設計も参考になります。
<figure>
<img src="sales-chart.png"
alt="製品Aと製品Bの四半期別売上を比較した折れ線グラフ。詳細は直後に記載">
<figcaption>四半期別売上の推移(単位:百万円)</figcaption>
</figure>
<h3>グラフの要点</h3>
<p>製品Aと製品Bはいずれも期間を通じて増加しています。正確な値は次の表で確認できます。</p>
<table>...</table>
色以外の手掛かりを重ねる
系列を赤と緑だけで区別すると、色の見え方や表示環境によって判別できない場合があります。
実線と破線、丸と三角、直接ラベル、塗りの模様など、色以外の手掛かりを少なくとも一つ組み合わせます。
コントラストは、色同士が違って見えるかではなく、隣接する色との明るさの差を数値で確認します。
WCAG 2.2のAAでは、通常サイズの文字は背景に対して4.5対1以上、理解に必要なグラフの線や形などの非テキスト要素は隣接色に対して3対1以上が確認の基準です。
大きな文字や例外の扱いを含め、対象となる達成基準を分けて評価してください。
色の選び方と検証方法は、色覚多様性に配慮したWeb配色ガイドで確認できます。
SVGとCanvasは表示方式に合わせて補う
SVGは図形がDOM要素として存在し、Canvasは描画結果が主にピクセルとして表示されます。
ただし、「SVGなら自動的にアクセシブル」「Canvasなら利用できない」と単純には分けられません。
どちらも、グラフの名前、説明、元データ、操作手段を設計する必要があります。
静的なSVGには名前と見える説明を用意する
一枚の画像として扱う静的なSVGでは、role="img"、aria-labelledby、aria-describedbyで名前と短い説明を関連付けられます。
ブラウザと支援技術の組み合わせによってSVG内の情報の伝わり方は異なるため、重要な結論や数値はSVGの外にも表示します。
<figure>
<svg viewBox="0 0 400 220" role="img"
aria-labelledby="chart-title" aria-describedby="chart-desc">
<title id="chart-title">四半期別売上の推移</title>
<desc id="chart-desc">製品Aと製品Bの売上を比較する折れ線グラフ</desc>
<!-- 軸、線、データ点 -->
</svg>
<figcaption>傾向の説明とデータ表をこの後に掲載します。</figcaption>
</figure>
すべてのデータ点をTabキーの停止先にすると、点数の多いグラフでは操作回数が増えます。
データ点そのものを操作する必要がなければ、グラフは一つの画像として説明し、詳細は表で検索できるようにします。
系列の表示切り替えや期間変更が必要なら、ネイティブのbuttonや選択項目をグラフの外に置き、操作結果を視覚表示とテキストの両方で更新します。
Canvasの外に情報と操作を置く
Canvasへ描いた線や棒は、そのままではHTMLの見出しや表として探索できません。
Canvasの前後にグラフの名称と要約を置き、正確な値が必要な場合はHTMLのデータ表を併設します。
<figure aria-labelledby="canvas-caption">
<canvas id="sales-chart" width="640" height="360"
role="img" aria-labelledby="canvas-caption" aria-describedby="canvas-summary"></canvas>
<figcaption id="canvas-caption">四半期別売上の推移</figcaption>
</figure>
<p id="canvas-summary">両製品とも期間を通じて増加しています。正確な値は次の表に示します。</p>
<table>...</table>
ホバーでしか値を表示しないツールチップは、タッチ操作やキーボード操作では利用できないことがあります。
フォーカス、クリック、タップでも同じ情報を取得できるようにし、動的に変わる説明を通知する場合は、更新のたびに読み上げが過剰にならないかも確認します。
地図、ヒートマップ、ダッシュボードの補足
地図、ヒートマップ、ネットワーク図は位置や色の関係に多くの意味を持たせるため、一文の代替テキストだけでは説明しきれません。
図の目的に合わせ、地点一覧、地域別の値、上位項目、隣接関係などを見出し、文章、表で示します。
- 地図:選択地点を色だけで示さず、境界線、マーカー形状、ラベルも変えます。
- ヒートマップ:色の範囲を数値付きの凡例で説明し、必要なら各セルに値を表示します。
- ネットワーク図:ノードと接続関係を、検索可能な一覧や詳細表示でも確認できるようにします。
- ダッシュボード:カードごとに具体的な見出しを付け、単位、対象期間、更新時点を同じ位置で示します。
ダッシュボードの並び順は、固定された個数ではなく、利用者の判断手順に合わせます。
全体状況を確認してから内訳や例外を見る作業なら、その順序で見出しとカードを配置し、キーボードの移動順も見た目と一致させます。
公開前に行う手動テスト
自動検査は属性の欠落や一部のコントラスト問題を見つける助けになりますが、表が理解できるか、グラフの説明が十分かまでは判断できません。
少なくとも次の操作を人が確認します。
- 見出し構造:ページ内の見出し一覧だけを読んでも、表とグラフの位置や目的を把握できるか確認します。
- スクリーンリーダー:表の各セルで対応する行見出しと列見出しが伝わるか、読み上げ順が自然か確認します。
- キーボード:すべての操作へ到達でき、フォーカス位置が見え、横スクロール領域を操作できるか確認します。
- 拡大と狭い画面:幅320 CSSピクセル相当でも、表以外の本文にページ全体の横スクロールが生じず、情報や機能が消えないか確認します。
- 色とコントラスト:色を使わなくても系列、選択状態、増減を区別でき、必要な文字と図形が基準を満たすか測定します。
- 代替説明:画像を見なくても、グラフを掲載した理由、主要な傾向、判断に必要な値を確認できるか読み直します。
検証は一つのブラウザや支援技術だけで完結させず、実際の利用環境と対象範囲を決めて記録します。
ライブラリやCSSを更新した後も同じ手順を回せるようにすると、回帰を見つけやすくなります。
制作と運用に組み込む方法
記事や画面ごとに対処すると、同じ問題が繰り返されます。
表とグラフを共通部品として管理し、設計、実装、入稿、検証の担当者が同じ受け入れ条件を参照できるようにします。
- 表の仕様:表題、見出し、単位、欠損値、レスポンシブ方式を定義します。
- グラフの仕様:本文要約、詳細データ、系列ラベル、色以外の手掛かりを定義します。
- データの仕様:列名、単位、集計期間、更新時点、注記を表示側へ渡します。
- 受け入れ条件:キーボード、読み上げ、拡大、コントラストの確認結果を記録します。
表やグラフの内容が頻繁に変わる場合は、表示だけでなく代替説明も同時に更新される仕組みが必要です。
数値が差し替わっても本文の要約だけが古いまま残ると、視覚表示とテキスト説明が矛盾します。
よくある問題と修正方針
| 問題 | 読者への影響 | 修正方針 |
|---|---|---|
| 表を画像として掲載する | 文字の拡大、検索、セル単位の読み上げができない | HTMLの表を用意し、必要なら画像は補助として使う |
| 見た目だけを太字にする | どのセルが見出しか支援技術へ伝わらない | thとscopeで関係を記述する |
| 狭い画面で列を消す | 判断に必要な値へ到達できない | 横スクロールまたは操作可能な詳細表示へ切り替える |
| 系列を色だけで区別する | 線や領域を対応付けられない場合がある | 線種、形、模様、直接ラベルを併用する |
| altを「グラフ」とだけ書く | 図の目的も結論も分からない | 短い識別説明と、本文の要約やデータ表を組み合わせる |
| ホバーだけで値を表示する | キーボードやタッチ操作で同じ情報を取得できない | フォーカス、クリック、タップとHTMLのデータ表を用意する |
よくある質問
グラフとデータ表は必ず両方必要ですか
常に同じ形で併設する必要があるとは限りません。
ただし、グラフから正確な値を読み取ることが読者の作業に含まれるなら、HTMLのデータ表や同等に利用できる詳細表示を用意します。
複雑な表にはheaders属性を付ければ十分ですか
headers属性は見出しとの関係を明示する手段ですが、複雑さそのものは減りません。
先に表を分割できないかを検討し、採用する場合も支援技術で対応関係を検証します。
SVGを使えばCanvasよりアクセシブルになりますか
表示方式だけでは決まりません。
SVGでも名前や説明がなく、色だけに依存し、キーボードで操作できなければ情報は届きません。
Canvasでも、見える要約、HTMLのデータ表、操作可能なコントロールを組み合わせれば、必要な情報へ到達する手段を用意できます。
チェックリストを通ればAA準拠と表記できますか
この記事のチェック項目だけでは判断できません。
適合表記には、対象ページ、適用するWCAGの版とレベル、ページ全体の達成基準、依存する技術などを定めた評価が必要です。
表とグラフを公開するときの確認事項
- 表に内容を特定できる
captionがある - 行見出しと列見出しが
thとscopeで示されている - 単位、期間、欠損値、注記が値の近くにある
- 狭い画面でも列や操作が失われない
- グラフの目的と主要な傾向を本文で確認できる
- 正確な値が必要な場合はデータ表または詳細表示がある
- 色以外の手掛かりで系列や状態を区別できる
- 理解に必要な文字と図形のコントラストを測定した
- キーボード、スクリーンリーダー、拡大表示で手動確認した
- データ更新時に代替説明も更新される
表は数値同士の関係を、グラフは傾向や差を伝える表現です。
見える図だけを完成品とせず、構造化した表、本文の要約、色以外の手掛かり、操作可能なコントロールを同じ設計に含めることで、読者は必要な方法で判断材料を確かめられます。
この記事に関連する株式会社greedenの取り組み
表やグラフは、構造、代替説明、操作方法を一体で設計してこそ情報が届きます。
株式会社greedenは、Webアクセシビリティの診断から改善提案、実装支援まで、公開後の運用も見据えて伴走します。
