WCAG 達成基準 · Level A
WCAG 1.3.1: 情報および関係
WCAG 1.3.1 は、視覚的な提示によって伝えられる情報、構造、および関係性が、プログラムによって判別できるか、またはテキストとして利用可能であることを求めており、支援技術の利用者が、視覚による利用者と同じ構造的な文脈を得られるようにしています。
- Level A
- Wcag
- Wcag 2 2 a
- 知覚可能
- アクセシビリティ
このルールの意味
WCAG 1.3.1「情報及び関係性」は、知覚可能（Perceivable）という原則の下にあるレベルAの達成基準です。その中核となる要件はシンプルですが影響範囲は広く、「視覚的に伝えられているあらゆる情報や関係性は、支援技術が検出しユーザーに伝達できる形でも表現されていなければならない」というものです。インデントでリストを示す、太字で必須項目を示す、色でエラーを示す、サイズで見出しを示すといった視覚的な手がかりをデザインで用いる場合、その同じ意味づけが基盤となるコードの中にも存在していなければなりません。
この達成基準は、Webコンテンツが見た目によって日常的に伝えている意味の3つのカテゴリに適用されます。
- 情報 — どのフォームフィールドが必須か、どの表セル同士が関係しているかといった、ページ上で伝達される事実やデータ。
- 構造 — 見出しの階層、順序付き・順序なしリスト、データテーブルなど、コンテンツの組織的な枠組み。
- 関係性 — ラベルとその入力欄、表のヘッダーとデータセル、用語とその定義など、要素同士の関連。
1.3.1に合格するページとは、視覚ユーザーが利用できるあらゆる構造的・関係的な情報が、有効でセマンティックなHTMLとして符号化されているか、あるいは支援技術が解釈できる正しいARIAロール・プロパティ・ステートとして公開されているページです。逆に、視覚的な構造がCSSや画像の中にしか存在しない場合や、ARIAマークアップが提示されているDOM構造と矛盾している、あるいは欠落している場合、そのページは不合格となります。
公式な例外は最小限です。この達成基準は、すべての視覚的な装飾に意味的な役割を持たせることを要求しているわけではありません。装飾的な枠線や背景色など、純粋に美的なフォーマットにはプログラム上の対応物は不要です。しかし、ユーザーが意味を伝えていると合理的に解釈しうるあらゆるフォーマット（必須を示すアスタリスク、用語集の太字の用語、番号付きの手順など）には、対応するプログラム上の表現が必要です。
なぜ重要か
情報と関係性は、ユーザーがWebページ上で行うほぼすべてのインタラクションの基盤です。その構造が視覚的なプレゼンテーションの中だけに閉じ込められていると、人口のかなりの割合がコンテンツをまったく理解できない状態に置かれてしまいます。
スクリーンリーダー利用者（典型的には全盲またはロービジョンの人々）は、セマンティックなHTMLとARIAから構築されるアクセシビリティツリーをたどってページを操作します。開発者が実際の<h2>ではなく、見出しのようにスタイルされた<div>を使った場合、Hキーで見出し間を移動するスクリーンリーダーユーザーはその見出しを完全に飛ばしてしまいます。そのセクションにたどり着けないかもしれません。世界保健機関（WHO）によれば、世界で約22億人が何らかの視覚障害を抱えており、そのうち数千万人が日常的にスクリーンリーダーに依存しています。
認知障害のあるユーザーも、明確な構造から同様に大きな恩恵を受けます。適切に入れ子になった見出し、意味のあるリストマークアップ、ラベル付きフォームコントロールは、予測可能なパターンを提供することで認知的負荷を軽減します。「見出しレベル2、Products」に続いて「見出しレベル3、Laptops」とスクリーンリーダーが読み上げることで、ページの認知的な地図が得られます。構造的なアンカーのない、スタイルだけが施されたテキストの壁は、誰にとっても分かりにくいものですが、とりわけ注意力や記憶に課題のあるユーザーにとっては混乱の元になります。
キーボード操作、スイッチアクセス、音声コントロールソフトウェアに依存する運動障害のあるユーザーも、プログラム上の構造に依存しています。Dragon NaturallySpeakingのような音声コントロールソフトウェアは、ラベルやロールから導出されるアクセシブルネームをもとにクリック可能なターゲットを生成します。ラベルが関連付けられていないフォーム入力は、音声コマンドで確実にターゲットにすることができません。
具体的なシナリオを考えてみましょう。ある病院の患者ポータルが、今後の予約の一覧表を表示しているとします。この表は、日付と医師を関連付けるために視覚的な配置と背景色を使っていますが、<th>要素にはscope属性がなく、データセルはヘッダーを参照していません。スクリーンリーダーを使う全盲のユーザーは、「9:00 AM」「Dr. Ayşe Kaya」「Cardiology」といった孤立したセルの値だけを聞くことになり、どの値がどの列に属しているのか分かりません。予約時間を誤解したり、誤った診療科に行ってしまうかもしれません。ヘッダーにscope='col'を正しく付与し、セルにheaders属性でヘッダーを参照させていれば、これらの関係性は音声で伝わっていたはずです。
アクセシビリティ以外にも、構造化されたHTMLには重要なSEO上の価値があります。検索エンジンのクローラーは、見出しの階層を使ってページのトピックを理解し、リストマークアップから列挙されたコンテンツを特定し、ラベルの関連付けからフォームの目的を理解します。1.3.1に合格しているページは、ほとんどの場合、検索エンジンがより正確に解析しランキングできるページでもあります。
関連するaxe-coreルール
次のaxe-coreルールは、WCAG 1.3.1の違反に直接対応しています。各ルールは、プログラム上の構造や関係性の特定の側面を対象としています。
- aria-required-children — 特定のARIAロールを持つ要素に、必要な子ロールが含まれているかをチェックします。例えば、
role='list'にはrole='listitem'を持つ子要素が含まれていなければなりません。正しい子構造がないと、コンテナとその項目との関係性が支援技術にとって失われます。 - aria-required-parent — 上記の逆で、特定の親コンテキストを必要とするロールを持つ要素に、実際にその親が存在するかをチェックします。
role='listitem'がrole='list'や<ul>/<ol>の内側にない場合、関係性のコンテキストが欠落しているためフラグが立てられます。 - aria-roles — すべての
role属性値が有効なARIAロールであることを検証します。無効またはスペルミスのあるロール（例えば、見出し要素の代わりにrole='heading'を使う、あるいは完全に架空のロールを使うなど）は、支援技術に有用な情報が届かず、その要素が完全に無視される可能性があります。 - definition-list —
<dl>要素に許可された子要素（<dt>、<dd>、<div>、<script>、<template>）のみが含まれているかを検証します。<dl>の直下に<p>などの他の要素を挿入すると、用語と定義の関係構造が無効になります。 - dlitem —
<dt>と<dd>要素が<dl>要素の内側でのみ使用されているかをチェックします。これらの要素を必要な親コンテキストの外で使うと、用語と定義のペアとしての意味が失われます。 - heading-order — 文書アウトラインの中で見出しレベルが飛ばされている箇所（例：
<h2>から<h4>へ飛ぶ）にフラグを立てます。必ずしも常に厳密な失敗とは限りませんが、レベルを飛ばすとページの階層構造について支援技術を誤解させ、見出しでナビゲートするユーザーを混乱させます。 - label — すべてのフォーム入力に、プログラム上関連付けられたラベルがあることを検証します。これは
<label for='...'>、aria-label、aria-labelledby、またはラッピングされた<label>要素のいずれかによって行われます。アクセシブルなラベルのない入力は、全盲ユーザーや音声コントロールユーザーに、何を入力すべきか理解するための情報を提供しません。 - list —
<ul>と<ol>要素の直下に、<li>要素（および<script>と<template>）だけが含まれていることを保証します。無効な子要素は、スクリーンリーダーが項目数や位置を読み上げるために利用するリスト構造を壊します。 - listitem —
<li>要素が<ul>、<ol>、またはrole='list'コンテナの内側でのみ使用されているかをチェックします。孤立したリスト項目は、その意味を完全に失います。 - scope-attr-valid —
<th>要素のscope属性が、許可された値（col、row、colgroup、rowgroup）のみを含んでいるかを検証します。複雑なデータテーブルでscope値が無効または欠落していると、スクリーンリーダーはどのヘッダーが特定のデータセルに適用されるのかを確実に読み上げることができません。 - td-headers-attr — データセルが
headers属性を使用している場合、その属性で参照されているすべてのIDが同じテーブル内に実在し、ヘッダーセルに属しているかをチェックします。参照が壊れている、または欠落していると、データとその説明的ヘッダーとのプログラム上の関係が断たれ、スクリーンリーダーユーザーは文脈を失います。
axe-coreのような自動ツールでは、1.3.1のすべての違反を検出できないことに注意してください。例えば、開発者が視覚的にスタイルされた<div>にrole='list'を付与し、その子要素を正しくrole='listitem'で構造化している場合、axeはこれを合格と判定します。しかし、人間のテスターが確認すると、視覚的なインデントがARIA構造には表現されていない入れ子のサブリストを暗示していることが判明するかもしれません。視覚的な階層が複雑な場合は常に、自動スキャンを補完するものとして、手動による確認とスクリーンリーダーテストが不可欠です。
テスト方法
- axe DevToolsまたはLighthouseによる自動スキャン：axe DevToolsブラウザ拡張機能（ChromeまたはFirefox）をインストールします。テスト対象のページを開き、DevToolsを開いてaxeタブに移動し、ページ全体のスキャンを実行します。結果をタグ
wcag131でフィルタリングするか、「Info and Relationships」にタグ付けされたすべての問題を確認します。上記11個のaxeルールの違反を特に探します。Lighthouse（Chrome DevToolsのAuditsパネル）では、アクセシビリティ監査を実行し、「Accessibility」カテゴリで見出し順序、ラベル、リスト関連の失敗を確認します。フラグが立てられたすべての要素とそのDOMセレクタを、修正のために記録します。 - 見出し構造の手動レビュー：HeadingsMapブラウザ拡張機能、またはaxe DevToolsの「Headings」パネルを使用して、ページの完全な見出しアウトラインを表示します。そのアウトラインが論理的かつ階層的であることを確認します — よく構造化された目次のように読めるはずです。見出しレベルが飛ばされていないこと、見出しテキストが意味のあるものであり、見出し要素ではない要素に視覚的なスタイルだけを適用したものではないことを確認します。
- フォームラベルの検証：ページ上のすべてのインタラクティブなフォーム要素をTabキーで順に移動します。各input、select、textareaについて、可視のラベルが存在し、プログラム上関連付けられていることを確認します（DevToolsで要素を確認し、一致する
for/idのペア、またはaria-label/aria-labelledbyを探します）。Chrome DevToolsのアクセシビリティツリー（Elementsパネル → Accessibilityタブ）を使用して、各コントロールの計算されたアクセシブルネームを確認します。 - NVDA + Firefoxによるスクリーンリーダーテスト：NVDAを起動し、Firefoxでページを開きます。Hキーで見出し間を移動し、読み上げられる見出しレベルが視覚的な階層と一致しているか確認します。Fキーでフォームフィールド間を移動し、各フィールドのラベルが読み上げられることを確認します。Tキーでテーブルに移動し、セル間を矢印キーで移動しながら、ヘッダーの読み上げを聞きます。Lキーでリスト間を移動し、項目数が読み上げられることを確認します。
- VoiceOver + Safari（macOS/iOS）によるスクリーンリーダーテスト：VoiceOverを有効にします（macOSではCmd+F5）。ローター（Ctrl+Option+U）を開き、Headings、Links、Form Controls、Tablesを確認します。すべての構造的要素がローターに表示され、その読み上げられる名前が意味があり正確であることを確認します。
- JAWS + Chromeによるスクリーンリーダーテスト：JAWSとChromeでページを開きます。JAWSの見出し一覧（Insert+F6）を使って見出しツリーを確認します。フォームフィールド一覧（Insert+F5）を使ってラベルの関連付けを検証します。テーブル内を矢印キーで移動し、各データセルについてJAWSが列ヘッダーと行ヘッダーを読み上げることを確認します。
- テーブルヘッダーの関係性チェック：ページ上のすべてのデータテーブルを特定します。単純なテーブルでは、
<th>要素に適切なscope属性が付与されていることを確認します。複数レベルのヘッダーを持つ複雑なテーブルでは、データセルが正しいid値を参照するheaders属性を使用していることを確認します。各セルから論理的な行ヘッダーと列ヘッダーへの経路を視覚的にたどり、その同じ経路がコード内にも表現されていることを確認します。
修正方法
スタイル付きdivで実装された視覚的見出し — 誤り
<!-- 見出しがCSSのfont-sizeとfont-weightだけで伝えられている -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>スタイル付きdivで実装された視覚的見出し — 正しい例
<!-- セマンティックな見出し要素が階層を支援技術に公開する -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>関連付けられたラベルのないフォーム入力 — 誤り
<!-- placeholderはラベルの代わりにはならない。入力時に消えてしまう -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />関連付けられたラベルのないフォーム入力 — 正しい例
<!-- for属性はidと一致させることでラベルと入力を結び付ける -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />scope属性のないデータテーブル — 誤り
<!-- ヘッダーにscopeがないため、スクリーンリーダーは列とデータを関連付けられない -->
<table>
<tr>
<th>Tarih</th>
<th>Doktor</th>
<th>Klinik</th>
</tr>
<tr>
<td>15 Temmuz 2025</td>
<td>Dr. Ayşe Kaya</td>
<td>Kardiyoloji</td>
</tr>
</table>scope属性のないデータテーブル — 正しい例
<!-- scope='col'は各thが列全体を説明することをスクリーンリーダーに伝える -->
<table>
<caption>Yaklaşan Randevular</caption>
<thead>
<tr>
<th scope='col'>Tarih</th>
<th scope='col'>Doktor</th>
<th scope='col'>Klinik</th>
</tr>
</thead>
<tbody>
<tr>
<td>15 Temmuz 2025</td>
<td>Dr. Ayşe Kaya</td>
<td>Kardiyoloji</td>
</tr>
</tbody>
</table>リストコンテナの外で使用されているリスト項目 — 誤り
<!-- 親となるulまたはolのないli要素には意味がない -->
<div class='features'>
<li>Fast performance</li>
<li>WCAG compliant</li>
<li>Mobile friendly</li>
</div>リストコンテナの外で使用されているリスト項目 — 正しい例
<!-- ulで囲むことで、スクリーンリーダーに項目数とナビゲーションの文脈を提供する -->
<ul class='features'>
<li>Fast performance</li>
<li>WCAG compliant</li>
<li>Mobile friendly</li>
</ul>よくある間違い
<div>や<span>要素に対して、CSSのfont-sizeとfont-weightだけで見出しの見た目を作り、role='heading'とaria-levelを追加しない、あるいは実際の<h1>〜<h6>要素に変換しないこと — スクリーンリーダーはこれらをナビゲート可能な見出しとして認識できません。- フォーム入力の唯一のラベルとして
placeholderテキストを使用し、ユーザーが入力を始めるとラベルが消えてしまい、入力中のフィールドがラベルなしの状態になること — 入力には必ず持続的な<label>要素を組み合わせてください。 - 必須フィールドを、フォーム上部の凡例で視覚的にだけ説明される赤いアスタリスク（*）で示し、
aria-required='true'を追加しない、またはプログラム上のラベルに「必須」であることを含めないこと — これではスクリーンリーダーユーザーに同じ情報が伝わりません。 <ul>に対してCSSでlist-style: noneを適用し、一部のスクリーンリーダー（特にSafari + VoiceOver）がその要素をリストとして読み上げなくなる可能性を理解していないこと — リストのセマンティクスが意味を持つ場合は、それを保持するために明示的にrole='list'を追加します。- 見出しレベルを飛ばすこと — 例えば、テキストを小さくしたいというデザイナーの意図から、
<h2>の直後に<h4>を配置するなど — 正しい見出しレベルを使用し、視覚的な見た目はCSSで制御すべきです。 colspan/rowspanでセルを結合した複雑なデータテーブルを構築しながら、データセルにheaders属性を追加せず、スクリーンリーダーユーザーが曖昧な結合セルにどのヘッダーが対応しているのか判断できない状態にしてしまうこと。- レイアウト目的で
<table>要素を使用し、その後role='presentation'を一貫性なく追加すること — 一部のセルにはヘッダーが残り、文脈から切り離された形で読み上げられ、テーブルが純粋に装飾目的であることを視覚的に確認できないユーザーを混乱させます。 <dl>の直下に<p>や<div>で<dt>/<dd>のペアをラップしながら、HTML5では<dl>内に許可されるラッパーは<div>だけであり、他のブロック要素を混在させると定義リスト構造が壊れることを理解していないこと。- DOM内に存在しないIDを参照する
aria-labelledbyを入力に追加したり、テキスト以外の要素のIDを参照したりすること — 計算されたアクセシブルネームが空になり、その入力は支援技術にとって事実上ラベルなしになります。 - ページが視覚的に正しく見え、Lighthouseのスコアが90以上であるからといって、1.3.1に準拠していると想定してしまうこと — 自動ツールでは、ARIAロール階層に反映されていない視覚的な入れ子関係など、すべての構造的な違反を検出できないため、手動およびスクリーンリーダーによる検証が必須です。
トルコのアクセシビリティ規制との関係
トルコの大統領通達2025/10は、2025年6月21日付官報（No. 32933）で公布され、トルコで事業を行う幅広い主体に対し、WCAG 2.2に整合したWebアクセシビリティ義務を課しています。WCAG 1.3.1はレベルAの達成基準であり、適合の基礎的な階層 — 最低限許容されるアクセシビリティレベル — に位置するため、この通達の対象となるすべての主体にとって完全に必須です。
通達は2つの遵守期限を定めています。中央政府機関、自治体、国立大学、公立病院などの公的機関は、通達の施行から1年以内にレベルAの完全な適合を達成しなければなりません。規制の対象となる民間部門の事業者には、遵守のための2年間の猶予があります。しかし、どちらのグループにとっても義務は任意ではありません。不遵守は、規制当局による監視や執行措置の対象となるリスクを伴います。
通達で明示的に対象とされている民間部門の事業者には、eコマースプラットフォーム、銀行および金融機関、民間病院および医療提供者、20万人以上の加入者を持つ通信会社、認可を受けた旅行代理店、民間の交通事業者、国民教育省（MoNE）の認可の下で運営される私立学校が含まれます。これらの事業者がパブリック向けのWebサイトやモバイルWebアプリケーションを運営する場合、そのデジタル資産全体で1.3.1が満たされていなければなりません。
実務的な遵守の観点から、1.3.1はページ構造を規定するため、レベルAの中でも最も影響力の大きい達成基準の1つです。商品カテゴリーページで見出しにスタイル付き<div>要素を使用し、チェックアウトフォームの入力にラベルの関連付けがなく、注文概要がscope属性のない非構造化テーブルになっているトルコのeコマースサイトは、1.3.1に包括的に不適合となります。是正は単なる法的義務ではなく、トルコで推定70万人以上とされる、買い物、銀行取引、医療アクセス、行政サービスのオンライン利用に支援技術を必要とする全盲・ロービジョンの人々の体験を直接的に改善するものです。
コンプライアンスを実証しようとする組織は、デジタルコンテンツ全体を対象に、axe-coreによる自動スキャンとスクリーンリーダーによる手動監査の両方を実施することが推奨されます。1.3.1が求める構造的アクセシビリティは、コンテンツが作成・更新される際に継続的に遵守されるよう、デザインシステムやコンポーネントライブラリに組み込まれるべきであり、一度限りの是正作業として扱うべきではありません。