WCAG 2.4.6: 見出しとラベル

WCAG 2.4.6 は、見出しやラベルが存在する場合、それらが説明的であり、導入または識別するコンテンツのトピックや目的を正確に伝えなければならないと求めています。この基準は、特に支援技術を使用しているユーザーが、コンテンツを効率的にナビゲートし、ページのセクションやフォームフィールドの構造と目的を理解するのに役立ちます。

このルールの意味

WCAG 2.4.6 にはこうあります。「見出しおよびラベルは、トピックまたは目的を説明している。」 本質的にはこの達成基準は、ページ上に現れるあらゆる見出し（<h1> から <h6>）やラベル（<label>、aria-label、aria-labelledby）が、それが導入するコンテンツの主題、またはそれが識別するコントロールの目的を伝えられる程度に十分記述的であることを求めています。

この達成基準は、見出しやラベルが存在すること自体を求めているわけではありません。その義務は 1.3.1（情報及び関係性）や 2.4.2（ページタイトル）といった他の達成基準が扱います。2.4.6 が規定しているのは、既に存在している見出しやラベルの質です。つまり、それらがある場合には意味のあるものでなければなりません。「Section 1」や「Field」といった見出しやラベルは、その後に続くコンテンツや説明している入力について、ユーザーに有用な情報を何も伝えません。これに対して「Your Shipping Address」や「Monthly Budget Summary」のような文言は、ユーザーにすぐに状況を把握させます。

ここでいうラベルには、フォームコントロールに関連付けられた HTML の <label> 要素だけでなく、あらゆるプログラム的なラベリングの仕組みが含まれます。すなわち、aria-label、aria-labelledby、アクセシブルネームとして使用される title 属性、そしてフィールドセットに対する legend 要素です。支援技術に公開されるこれらのいずれもが、関連付けられたコントロールの目的を明確に説明していなければなりません。

見出しやラベルがあまりに一般的すぎたり、曖昧だったり、情報量が乏しかったりして、周囲の文脈を読まなければそのセクションやコントロールが何についてのものかユーザーが判断できない場合、失敗となります。例えば、3 つの入力欄すべてに「Enter here」というラベルが付いているフォームや、すべての小見出しに「More Info」という見出しを繰り返し使っているページは、この達成基準に違反します。同様に、DOM 上には見出しが存在していても、ユーザーを完全に誤解させる場合 — たとえば問い合わせフォームのセクションに「News and Updates」という見出しを付けているような場合 — も失敗です。

重要な公式の例外が 1 つあります。WCAG 2.4.6 が適用されるのは、見出しやラベルが使用されている場合だけです。ページに正当な理由で見出しがまったくない（例えば、単一のトピックからなる非常に短い文書）場合や、可視またはプログラム的なラベルを持たないフォームコントロールがある場合（これは代わりに 1.3.1 によって検出されます）、2.4.6 自体は適用されません。この達成基準の範囲は、存在ではなく、あくまで記述性に限られます。

なぜ重要か

記述的な見出しやラベルは非常に幅広いユーザー層に利益をもたらしますが、その影響が最も大きいのは、ナビゲーションのために構造に依存している障害のある人々です。

スクリーンリーダー利用者 — 主に全盲または重度のロービジョンの人々 — は、ショートカットキー（NVDA/JAWS の H、VoiceOver の Rotor など）を使って見出しから見出しへとジャンプすることで、日常的にページをナビゲートしています。見出しが曖昧だったり誤解を招くものであったりすると、このナビゲーション戦略は完全に破綻します。例えば、政府のサービスポータルにアクセスした全盲のユーザーが、見出しとして「Section A」「Section B」「Section C」しか使われていない場合、必要な情報を見つけるために各セクションのすべての文言を順番に読まなければならず、本来見出しが提供すべき効率性が失われてしまいます。世界保健機関によれば、世界中で約 22 億人が何らかの視覚障害を抱えており、これは非常に大きな人口です。

注意欠如障害、記憶障害、学習障害などを含む認知障害のある人々は、認知負荷を減らすために、明確で予測可能なラベルや見出しに大きく依存しています。企業名と担当者名の両方を収集するページで、フォームフィールドが単に「Name」とだけラベリングされている場合、認知障害のあるユーザーは文脈だけからその曖昧さを解消できないかもしれず、エラーやフラストレーションにつながります。

スイッチアクセス、視線追跡ソフトウェア、Dragon NaturallySpeaking のような音声コントロールに依存している運動障害のあるユーザーは、記述的なラベルから恩恵を受けます。なぜなら、ラベル名を発話することで特定のフォームフィールドをアクティブにできるからです。複数のフィールドが同じラベルテキストを共有していると、音声コントロールソフトウェアはそれらを区別できず、ユーザーにとって身体的負担の大きい追加ステップを強いることになります。

現実のシナリオを考えてみましょう。スクリーンリーダーを使用している人が、EC サイトのチェックアウトページを訪れます。ページには請求先住所、配送先住所、ギフト受取人住所の 3 つの住所セクションがありますが、それぞれのセクションは同じ汎用的な見出し「Address」を使用し、各入力セットも「Street」「City」「Postal Code」といった同じラベルを使っています。固有で記述的な見出しやラベルがなければ、スクリーンリーダーユーザーはどのフィールド群に入力しているのか判断できず、注文ミスのリスクが大幅に高まり、購入自体を断念してしまう可能性も高くなります。

アクセシビリティを超えて、記述的な見出しは SEO にも大きな価値をもたらします。検索エンジンはページコンテンツを理解し、ユーザーのクエリとマッチさせるための強いシグナルとして見出し構造を利用します。意味のある見出しは、検索エンジンがページをより正確にインデックスし、検索結果で見出しがプレビュー文として表示される場面でクリック率を向上させることができます。これはビジネス上のインセンティブとアクセシビリティ要件を直接一致させるものです。

テスト方法

まず自動スキャンを実行する: axe DevTools（ブラウザ拡張）や Chrome DevTools の Lighthouse を使用して、自動ツールが検出できる構造上の見出しやラベルの問題（ラベルの欠如、見出しレベルの飛び、空の見出し要素など）を特定します。これらは直接の 2.4.6 違反ではありませんが、手動レビューの際により注意深く精査すべき領域を示します。レポートでフラグ付けされた、または特定されたすべての見出しとラベル付きコントロールを記録します。
見出しリストを抽出する: HeadingsMap（Firefox と Chrome で利用可能）や WAVE ツールなどのブラウザ拡張を使用して、ページ上のすべての見出しを周囲のコンテンツを取り除いたフラットなリストとして生成します。このリストを目次のように読んでください。本文を読まずに、見出しだけからこのページの構造と主なトピックをユーザーが理解できるかどうかを自問します。単独では曖昧または情報量が乏しい見出しがあれば、それは 2.4.6 の失敗です。
NVDA と Firefox でテストする: ページを開き、H キーを押して見出しごとにナビゲートします。各見出しの読み上げを聞き、その後に続くコンテンツを説明しているかどうかを評価します。次に F キーを押してフォームフィールドを順に移動し、各入力欄に対して読み上げられるラベルを聞きます。トピックや目的を明確に説明していない見出しやラベルをすべて記録します。
VoiceOver と Safari（macOS/iOS）でテストする: Web Rotor（VO+U）を使用して見出しリストとフォームコントロールリストを開きます。各リストをナビゲートし、ページ文脈から切り離して各項目の記述性を評価します。iOS では、Rotor で見出し単位に移動するために 3 本指スワイプを使用します。
JAWS と Chrome でテストする: H キーで見出しをナビゲートし、Forms Mode（F）を使ってフォームコントロール間を移動します。JAWS の List of Headings ダイアログ（Insert+F6）を使用して、すべての見出しをフラットなリストで表示します。これはスクリーンリーダーユーザーがページ構造をざっと確認する方法を再現します。
フォームラベルを単独で評価する: すべてのフォームコントロールについて、周囲の文脈をすべて隠すか無視し、プログラム的ラベル（可視ラベルテキスト、aria-label、aria-labelledby のターゲット）だけを読みます。ラベルだけで、どのような情報を入力すべきか、またはそのコントロールがどのような動作を行うのかを理解できることを確認します。
重複した見出しやラベルテキストを確認する: ページ内で繰り返されている見出しテキスト（複数の「Read More」見出しや複数の「Learn More」セクションなど）を検索します。同じテキストが、異なるトピックやコントロールを指す見出しやラベルに使われている場合、それは 2.4.6 の失敗です。

修正方法

汎用的なセクション見出し — 不適切な例

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

汎用的なセクション見出し — 適切な例

<!-- 各見出しがセクションの実際のトピックを説明するようになり、
     スクリーンリーダーユーザーが必要な箇所へ直接ジャンプできる -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

曖昧なフォームラベル — 不適切な例

<!-- 2 つの住所ブロックがあり、どちらも同じラベルを使用しているチェックアウトフォーム -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

曖昧なフォームラベル — 適切な例

<!-- legend によって 2 つの fieldset が区別されるようになり、
     legend がプログラム的に区別のための文脈を提供するためラベルは短いままでよい -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

アイコンボタンに対する非記述的な ARIA ラベル — 不適切な例

<!-- aria-label はラベルを提供しているが、ボタンの目的を説明していない -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

アイコンボタンに対する非記述的な ARIA ラベル — 適切な例

<!-- aria-label が、ボタンを押すと何が起こるかを明確に伝えるようになった -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

「Read More」の見出しやリンクの繰り返し — 不適切な例

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

「Read More」の見出しやリンクの繰り返し — 適切な例

<!-- 各記事がトピックを特定できる固有で記述的な見出しを持つ -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

よくある間違い

「Step 1」「Step 2」「Section A」のような位置や順序だけを示す見出しを記述的なテキストなしで使用すること。これらの見出しは、ユーザーにシーケンス上の位置しか伝えず、そのセクションが何についてのものかは伝えません。常に「Step 2: Verify Your Email Address」のように、順序を示す表現と記述的な名詞句を組み合わせてください。
一覧ページ上のすべてのカードや記事コンポーネントに同じ見出しテキストを与えること（例えば、すべての商品カードの <h3> が単に「Product」となっている場合）。各カードの見出しは、その特定の商品、ブログ記事、アイテムを固有に識別しなければなりません。
フォーム入力のアクセシブルラベルとしてプレースホルダーテキストを使用すること（<label> 要素や aria-label の代わりに placeholder 属性に依存すること）。プレースホルダーは入力時に消え、すべてのスクリーンリーダーがアクセシブルネームとして確実に読み上げるわけではありません。プレースホルダーが存在する場合でも、別途記述的なラベルが必要です。
要素の種類を言い換えただけの aria-label を書くこと（テキストフィールドに aria-label='input'、ボタンに aria-label='button' など）。ラベルは、要素の種類ではなく、そのコントロールが何を行うのか、またはどのような値を収集するのかを説明しなければなりません。
フォームコントロールの唯一のラベルとしてツールチップテキストや title 属性を使用し、これで 2.4.6 を満たしているとみなすこと。title ベースのラベルはキーボードのみのユーザーにはしばしばアクセスできず、スクリーンリーダーによって一貫して読み上げられるわけでもありません。代わりに可視の <label> 要素や aria-label に依存してください。
複数の検索スコープが存在するページで、検索入力に単に「Search」とだけラベリングすること（サイト全体検索とデータテーブル内検索がある場合など）。2 つのコントロールが異なる検索を行う場合、それぞれのラベルは「Search all products」「Search within order history」のようにスコープを明示しなければなりません。
モーダルダイアログの見出しに、ページのメイン見出しと同じテキストを適用すること。モーダルの見出しは、「Confirm Your Cancellation」のように、そのダイアログの具体的なタスクやコンテンツを説明すべきであり、ページタイトルをそのまま引き継ぐと、モーダル内をナビゲートするスクリーンリーダーユーザーを混乱させます。
ラジオボタンやチェックボックスグループに対して記述的な <legend> を省略し、個々のオプションラベルだけを提供すること。<legend> は、各個別ラベルに意味を与えるための重要な文脈を提供します。「Yes」と「No」というオプションラベルだけでは、「Do you agree to the terms and conditions?」のような legend がなければ情報として不十分です。
ビジュアルデザイン上の理由から DOM 内の見出しテキストを切り詰めること（完全なテキストが隣接する視覚要素にあり、見出し自体はアイコンや 1 語だけになっている場合など）。スクリーンリーダーユーザーは周囲のレイアウトを見ずに見出しを聞くため、プログラム的な見出しはそれだけで十分に記述的でなければなりません。
ラベルが視覚ユーザーに見えているからといって、すべてのユーザーにとって十分に記述的であると仮定すること。位置関係に依存するラベル（カスタムグリッドの列見出しなどで、ラベルの意味が周囲のセルとの関係を視覚的に見ることで初めて分かる場合）は、視覚的には明確でも、同じ情報をプログラム的に伝えられないことがあります。アクセシブルネームだけで十分な情報が得られることを常に確認してください。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、トルコで事業を行う幅広い公的・民間主体に対して、デジタルアクセシビリティに関する義務を定めています。この通達は、適合のための技術標準として WCAG 2.1 レベル AA を明示的に参照しており、WCAG 2.2 のレベル AA 要件 — レベル AA において WCAG 2.1 と後方互換性があります — は強く推奨されるとともに、家族・社会サービス省（Aile ve Sosyal Hizmetler Bakanlığı）が発行する公式のアクセシビリティロゴ（Erişilebilirlik Logosu）を取得しようとする主体には必須とされています。

WCAG 2.4.6 はレベル AA の達成基準であり、対象主体が完全な適合を達成するために対処しなければならない範囲に明確に含まれます。大統領通達の対象となる主体の種類には、公共機関および政府機関、EC プラットフォーム、銀行および金融機関、病院および医療提供者、20 万人以上の加入者を有する通信事業者、旅行代理店、民間の交通事業者、そして国民教育省（Millî Eğitim Bakanlığı）に認可された私立学校が含まれます。

これらの主体にとって、記述的な見出しやラベルを提供しないことは、具体的な規制上のリスクを伴います。曖昧なセクション見出しを持つ政府ポータルは、障害のある市民が公共サービスにアクセスすることを妨げ、平等なアクセスを確保するという通達の明示的な目的と直接矛盾します。チェックアウトフローで曖昧なフォームラベルを使用している EC サイトは、視覚障害や認知障害のあるユーザーが購入を完了できない原因となり得ますが、これは通達が解消しようとしている経済参加への障壁に該当します。

Erişilebilirlik Logosu を取得しようとする主体は、アクセシビリティ監査を通じて適合を実証しなければならず、2.4.6 は監査人が手動で評価する達成基準の 1 つです。この達成基準は人間の判断を必要とし — 自動ツールでは記述性を評価できないため — 組織は、すべての見出しとフォームラベルの構造化された手動レビューを、アクセシビリティ監査プロセスの標準的な一部として組み込むべきです。これを一度きりの監査タスクとしてではなく、コンテンツが時間とともに変化しても継続的なコンプライアンスを維持するために、コンテンツ管理ワークフローやデザインシステムに組み込むことが、最も効果的な戦略です。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）