WCAG見出しチェッカー

WCAG見出しチェッカーとは何か?

WCAG見出しチェッカーは、ウェブページ上の見出し要素(h1、h2、h3、h4、h5、h6)がスクリーンリーダーやその他の支援技術がナビゲートできる論理的な階層を形成していることを検証します。見出しは盲目および弱視ユーザーがページをスキミングする方法です。彼らはスクリーンリーダーのショートカットを使用して見出しから見出しへジャンプし、数秒で頭の中で目次を構築します。見出しが欠落している、順序が違う、または装飾的に使用されている場合、そのナビゲーションは崩壊します。WCAG 2.2の達成基準1.3.1(情報と関係)と2.4.6(見出しとラベル)は、見出しが構造を正しく伝達することを要求しています。

ルールは述べるのが簡単で違反するのが簡単です。ページごとに正確に1つのh1(ページタイトル)があるべきです。後続の各見出しは、その親より最大で1レベル深いはずです(h2の後に別のh2またはh3が続くことができますが、直接h4が続くことはできません)。見出しは空であってはなりません。見出しレベルはドキュメント構造を記述すべきであり、視覚的なサイズを記述すべきではありません(より小さなテキストが欲しいというだけでh4を使用しないでください)。ほとんどのアクセシビリティ監査は、見出し階層の問題を最初に修正すべきものとして指摘します。なぜなら、それらは一般的で、検証しやすく、スクリーンリーダーユーザーに対して影響が大きいからです。

このツールは、貼り付けたHTML(アップロードなし、サーバーラウンドトリップなし)を解析し、ドキュメント順に見出し要素を歩き、問題を報告します。h1の欠落、複数のh1、レベルのスキップ、空の見出し、およびページ構造のアウトラインです。出力は各問題を記述するプレーンテキストです。開発中、立ち上げ前、または定期的なアクセシビリティ監査サイクルの一部として、任意のページで実行します。出力は平易な言葉で、数値スコアではありません。目標は追いかける合格点ではなく、修正すべき具体的な問題を提供することです。

ツールの中身

ページの上部はHTMLを貼り付けるテキストエリアです。完全なドキュメント(DOCTYPE、html、head、body)またはフラグメント(bodyコンテンツのみ)を貼り付けることができます。ツールは標準のブラウザDOMParserを使用してドキュメント順にh1からh6までのすべての要素を抽出するので、解析は実際のブラウザが行うことと一致します。テキストエリアは任意のサイズの入力を処理します。非常に大きなドキュメント(数万行)は機能しますが、解析に数分の1秒長くかかります。

見出しを確認をクリックすると、結果が下に表示されます。最初のセクションは見出しアウトラインです。順番にすべての見出しが、レベルでインデントされているので、目次として構造を読むことができます。2番目のセクションは問題リストです。各問題はその具体的な場所、何が間違っているか、そしてなぜ重要かの簡単な説明とともに記載されます。問題は重大度別に分類されます。エラー(WCAG準拠のために修正必須)と警告(ベストプラクティスだが厳格な失敗ではない)です。

出力はブラウザに留まります。アップロードはされません。同じHTMLを編集を加えて何度も貼り付けて、修正を反復することができます。ツールは意図的に見出し構造以外を何もチェックしません(alt テキスト、コントラスト、フォーカス順序、ARIA、その他のWCAG基準を確認しません)。それらについては、axe DevTools、Lighthouse、WAVEのような包括的な監査ツールと一緒にこのツールを使用してください。

歴史と背景

HTML見出しは始まり(1991)から

Tim Berners-Leeは1991年に元の18タグの一部としてh1からh6までの要素を備えたHTMLを導入しました。元の意味的意図は常にビジュアルスタイリングではなく、ドキュメント構造でした。Webの見出しの階層は、はるかに古い伝統に由来します。印刷ドキュメント(書籍、論文、政府報告書)は構造を伝えるために何世紀にもわたって番号付きセクションレベルを使用してきました。HTMLはそのモデルを直接受け継ぎました。35年にわたる安定したセマンティクスにもかかわらず、見出しの誤用は最新のウェブで最も一般的なアクセシビリティバグの1つです。なぜなら、デザイナーはしばしばビジュアルサイズで最初にスタイルを設定し、構造を後でチェックするからです。

スクリーンリーダーが見出しでナビゲートすることを学ぶ(1996年以降)

JAWS(Job Access With Speech)は1989年にHenter-Joyceによってリリースされ、1990年代後半にWebが人気を博すにつれて、Webページ見出しナビゲーションを追加しました。JAWSでHキーを押すと次の見出しにジャンプします。番号付きキー1から6は、その特定の見出しレベルにジャンプします。それ以来のすべての主要なスクリーンリーダー(2006年のNVDA、2005年のVoiceOver、AndroidのTalkBack)はこのショートカットをコピーしています。WebAIMの年次Screen Reader User Surveyは、スクリーンリーダーユーザーの67から70パーセントが、ページを理解するための主要な方法として見出しでナビゲートしていることを一貫して見出しています。したがって、壊れた見出し階層は美観の問題ではありません。

WCAG 1.0とアクセシビリティ標準の台頭(1999)

Web Content Accessibility Guidelines 1.0は、Webアクセシビリティのための最初の国際標準として、1999年5月にW3Cによって公開されました。WCAG 1.0は、見出しがドキュメント構造に使用されることを明示的に要求しました(チェックポイント3.5)。WCAG 2.0(2008)はこれを達成基準1.3.1(情報と関係、レベルA)および2.4.6(見出しとラベル、レベルAA)に洗練しました。WCAG 2.1(2018)および2.2(2023)は、基礎となる要件が健全であるため、これらの基準を変更せずに維持しました。世界中のほとんどのアクセシビリティ法(米国のADA、ヨーロッパのEAA、オンタリオのAODA)は、現在WCAG 2.1 AAを法的基準として引用しています。

HTML5セクション化とドキュメントアウトライン(2014)

HTML5(W3C勧告2014)はセクション要素(article、section、nav、aside)と、ネスト深度から見出し階層を導出するはずだったアウトラインアルゴリズムを導入しました。アルゴリズムはブラウザやスクリーンリーダーでは決して実装されず、2022年に正式に非推奨化されました。実用的なガイダンスは: 明示的な見出しレベル(h1からh6)を使用し、セクション要素を見出し深度の代わりではなく意味的グループ化として扱うことです。HTML Living Standardは現在、見出しレベルを明示的に設定する必要があることを明確に述べています。

ARIAロールとaria-level(2014年以降)

WAI-ARIA 1.1(W3C勧告2017)はrole="heading"をaria-level="N"で見出しをマークする代替方法として提供します。これはネイティブのh1-h6要素を使用できない場合に役立ちます(例えば、異なるコンテキストで異なる見出しレベルをレンダリングする必要があるフレームワークコンポーネント内で)。スクリーンリーダーはrole="heading"をネイティブ要素と同一に扱います。ベストプラクティスは可能な限りネイティブ要素を使用することです。ネイティブセマンティクスが利用できない場合にのみARIAを使用してください。このツールはネイティブ見出し要素とrole="heading"を持つ要素の両方をチェックします。

アクセシビリティ訴訟とビジネスケース(2017年以降)

Domino's Pizza v. Robles(米国最高裁2019)は、Americans with Disabilities Act(ADA、1990)が商用ウェブサイトに適用されることを確立しました。何百もの同様の訴訟が毎年続いています(2024年だけで4,000件以上のADAウェブ訴訟が提起されました)。European Accessibility Act(EAA、2025年6月施行)は、WCAG相当のアクセシビリティをEU全体のほとんどの消費者向けウェブサイトに対して法的要件にします。失敗した見出し構造は原告が特定して文書化するのが最も簡単な問題の1つで、これにより基本的な見出しチェックは高レバレッジのコンプライアンスステップになります。

実用的なワークフロー

新しいページとテンプレートでの立ち上げ前チェック

新しいページやテンプレートが出荷される前に、HTMLをこのチェッカーに通します。見出し構造の問題は最も簡単に導入できるアクセシビリティバグです(特にCMS駆動のコンテンツでは、編集者がビジュアルサイズに基づいて見出しレベルを選択します)し、最も簡単に修正できます。立ち上げ前にそれらを捕まえることは、コンテンツ所有者との調整が必要となる立ち上げ後よりもはるかに安価です。エージェンシーの場合は、このチェックをQAチェックリストに組み込みます。社内チームの場合は、コードレビューの一部としてまたはメインにマージする前に実行します。

アクセシビリティ準拠のための既存サイトの監査

アクセシビリティ監査(訴訟前、EAA準拠、契約要件)のために、最もトラフィックの多いページをステップ実行し、それぞれのHTMLをこのチェッカーに通します。調査結果を文書化します: どのページに見出しの問題があるか、どのタイプか、どのように修正するか。他のWCAG基準についてはaxe DevToolsまたはLighthouseと組み合わせます。見出し構造の調査結果は通常、修復が最も簡単で、監査レポートの確実な早期勝利セクションを形成します。

CMS編集者のトレーニングとテンプレート化

CMS駆動のコンテンツ(WordPress、Drupal、Contentful、Sanity)は、しばしば編集者にH1からH6のオプションを持つ見出しドロップダウンを提供します。ルールを知らない編集者はビジュアルサイズでレベルを選択します。編集者に自分の見出し選択が何を生成するかを見せるためにこのチェッカーをデモします。テンプレートの場合、各デザイン変更後にレンダリングされた出力をチェッカーに通して、編集者の見出し選択が依然として有効な階層を生成することを確認します。多くのCMSプラグインは執筆時に編集者に警告します。このツールは検証ステップを果たします。

電子メールテンプレートとHTMLニュースレターの検証

スクリーンリーダーで読まれるHTML電子メールは、ウェブページと同じ見出し階層に従うべきです。大きなリストに送信する前に、電子メールテンプレートのHTMLをこのチェッカーに通します。一般的な電子メールテンプレートの問題: 複数のh1(各セクションに独自の見出しがある場合)、h1の欠落(レイアウトが直接h2で始まる場合)、小さな見出しに純粋に使用される装飾的なh4。送信前にこれらを修正してください。リスト上の支援技術ユーザーは気づくでしょう。

PDFからHTMLへの変換の検証

アクセシビリティのためにPDFをHTMLに変換するとき(見出しナビゲーションでスクリーンリーダーが読むことができるように)、コンバーターはPDF構造タグをHTML見出しレベルにマッピングする必要があります。結果はしばしば壊れています: 適切なタグ付けがないPDFは見出しがまったくないフラットなHTMLを生成し、タグ付きPDFでさえ時にはすべてh1またはすべてh2の出力を生成します。変換されたHTMLをこのチェッカーに通して、変換されたページを公開する前に問題を発見してください。

新しい開発者とデザイナーのオンボーディング

ジュニアフロントエンド開発者とデザイナーは、壊れた見出し階層と結果として生じるスクリーンリーダー体験の具体的な例を見ることで利益を得ます。このツールをスクリーンリーダーデモ(WindowsのNVDAは無料、MacのVoiceOverは組み込み)とペアにして、見出しがスクリーンリーダーナビゲーションをどのように駆動するかを示します。抽象的な見出しルールと具体的なユーザー体験の関連性は、しばしばレッスンが定着する理由となります。

よくある落とし穴

ビジュアルサイズで見出しレベルを選択する

最も一般的な間違い: 小さなテキストが欲しいのでh4を使用する、またはデザインに正しいサイズのh3がないのでh2からh4にスキップする。見出しレベルは構造的であり、視覚的ではありません。CSSを使用してサイズを制御し、ドキュメント階層に一致するレベルを使用します。デザインシステムに必要なすべてのレベルのビジュアルスタイルがない場合、間違ったレベルを選ぶ代わりに、追加(またはクラス名で上書き)します。

ページごとに複数のh1

ページにはページタイトルを表す正確に1つのh1があるべきです。一般的なバグ: h1でラップされたサイトロゴと、h1の記事タイトル(2つのh1)、各ヒーローセクションがh1を使用するホームページ(複数のh1)、またはレイアウトがh2で始まるためにh1がまったくない。修正は構造的です: ページ上の最も重要なコンテンツを単一のh1として選択し、その他すべてをh2以下に降格します。axeとLighthouseのようなツールはこの理由で複数のh1を警告します。

見出しレベルをスキップする

h2から直接h4に行くと、ドキュメントアウトラインが壊れます。見出しから見出しへ移動するスクリーンリーダーユーザーは、各h4がh3の下にネストされていることを期待し、欠落したh3は構造を混乱させます。修正は欠落した中間レベルを挿入するか、h4をh3に降格することです。最も一般的な原因は、ビジュアル階層が3つのサイズを使用するモックアップからデザインをコピーすることですが、デザインシステムは4つの見出しレベルを使用します。すべてのコンポーネント更新後に再チェックしてください。

空の見出し

テキストコンテンツのないh2(しばしばJavaScriptウィジェットがテキストを削除したが要素を保持したため)は、スクリーンリーダーの見出しリストにラベルのない見出しとして表示され、これは混乱を招き役に立ちません。見出しにテキストを入力するか、見出し要素全体を削除します。これはデータがロードされる前にプレースホルダー要素がレンダリングされる単一ページアプリで一般的です。中に入れるコンテンツがあるときのみ見出しをレンダリングします。

非セマンティックラッパー内の見出し

role="presentation"またはaria-hidden="true"を持つdivでラップされた見出しはアクセシビリティツリーから削除され、それ以外は正しい見出しをスクリーンリーダーから隠す可能性があります。すべての見出しの親要素を監査して、見出しをアクセシビリティツリーから取り除かないことを確認します。CSS display:noneとvisibility:hiddenも見出しを削除します。意図的にのみ使用し、スクリーンリーダーが見えるべきコンテンツには決して使用しないでください。

ネイティブHTMLで済むときにARIAを使用する

h2要素を使用する代わりにdivにrole="heading" aria-level="2"を追加することはアクセシビリティのために機能しますが、不必要な複雑さです。ネイティブh1-h6要素は見出しセマンティクスを無料で取得し、デフォルトのブラウザスタイルで正しくレンダリングされ、ARIAオーバーライドよりもスクリーンリーダーのバグによりよく耐えます。ARIAの最初のルール(WAI-ARIA Authoring Practicesによる)は: ネイティブHTMLが同じセマンティクスを提供する場合はARIAを使用しないことです。フレームワークの制約が本当にARIAを強制しない限り、ネイティブの見出し要素を使用してください。

プライバシーとデータ処理

貼り付けたHTMLはチェック中ずっとあなたのブラウザに留まります。見出しを抽出するDOMParserはあなたのマシン上でJavaScriptで動作します。結果はテキストエリアの下のページにレンダリングされます。アップロードステップはなく、リモート処理はなく、貼り付けたHTMLについてのテレメトリもありません。これは重要です。なぜなら、最もチェックしたいHTML(立ち上げ前のテンプレート、NDA下のクライアントサイト、内部管理ページ)は、まさにサードパーティのSaaSバリデーターに貼り付けるべきでないものだからです。

ページがロードされると、ツールはオフラインで動作します。インターネットから切断し、HTMLを貼り付け、チェックを実行し、マークアップが別のマシンに触れることなく結果を確認できます。ほとんどのクラウドアクセシビリティチェッカー(PowerMapper、Tenon、Site Improve)はページURLまたはHTMLのアップロードを必要とします。機密ページの場合、それはまさに避けるべき失敗モードです。

このツールを使用しない場合

完全なWCAG監査の場合(包括的なツールを使用)

見出し構造はWCAG基準の数十のうちの1つです。完全な監査には、axe DevTools(DequeからのChrome/Firefoxの無料拡張機能)、Lighthouse(Chromeに組み込み)、WAVE(WebAIMの無料ツール)、またはTenonやPowerMapperのような有料ソリューションを使用します。これらは色のコントラスト、altテキスト、ARIAの使用、フォームラベル、フォーカス順序などをチェックします。包括的なものの代わりではなく、それと一緒にこのツールを実行してください。

動的コンテンツの場合(レンダリングされたDOMをテスト)

見出しがJavaScript(React、Vue、Svelte、Angular)によって生成される場合、静的なHTMLソースには最終的な見出しが含まれません。JavaScriptが実行された後にレンダリングされたDOMを貼り付ける必要があります。ブラウザDevToolsを使用します: ページを開き、DevToolsを開き、Elementsタブ、bodyまたはmainを右クリック、Copy outerHTML、その後それをこのチェッカーに貼り付けます。またはライブDOMを直接歩くブラウザ拡張機能を使用します。

自動化されたCI/CDパイプラインの場合(Nodeライブラリを使用)

見出しチェックを各コミットまたはプルリクエストで自動的に実行したい場合は、axe-core、Pa11y、jest-axeをテストスイートに統合します。それらは見出しチェック(およびその他の多くのWCAGチェック)をCIでヘッドレスに実行します。このブラウザツールは開発とレビュー中の対話的な使用のためのものであり、自動化のためのものではありません。両方には場所があります。ワンオフ監査にはブラウザツールを使用し、継続的検証にはCIライブラリを使用します。

PDFまたはWord文書のアクセシビリティの場合

PDFとWord文書には独自のアクセシビリティタグ付けシステム(PDF/UA、Wordの見出しスタイル)があります。HTML見出しを使用しないので、このツールは適用されません。PDFアクセシビリティについては、Adobe Acrobat ProのAccessibility CheckerまたはPAC 2024(無料、PDF/UAに焦点を当てている)を使用します。Wordについては、組み込みのAccessibility Checker(Reviewタブ)を使用します。このツールを使用したい場合は最初にHTMLに変換しますが、変換自体が見出しの問題を導入する可能性があります。

その他の質問

見出しレベルをスキップしても大丈夫ですか?

ストレートなドキュメントコンテンツでは違います。WCAG 2.2 SC 1.3.1は、見出しが階層的なシーケンスを形成すべきであることを示唆しています。スキップに見える1つの一般的なケースは、ページアウトラインがh1で始まり、メインコンテンツ領域内でh2、そしてサイドバーまたはナビゲーションもh2を持つ場合です。それは問題ありません。なぜなら、両方ともページのh1の下の兄弟だからです。実際のルールは: 連続的なコンテンツフロー内でレベルをスキップしないことです。チェッカーは真のスキップのみを報告します。

私のフレームワークが1つの見出しレベルのみをサポートする場合は?

一部のコンポーネントライブラリは、固定レベル(ネストに関係なく常にh2)で見出しをレンダリングします。修正は見出しコンポーネント(h2、h3など)にlevelプロップを公開し、親に適切な値を渡させることです。Reactのようなフレームワークは一般的にこれを行います。あなたのものがそうでない場合は、コンポーネントにaria-levelを追加し、リファクタリングできるまで一時的な回避策としてrole="heading"を使用します。長期的には、すべての再利用可能な見出しコンポーネントはlevelプロップを受け入れるべきです。

ツールはrole="heading"のようなARIAロールをチェックしますか?

はい。role="heading"と有効なaria-level属性(1から6)を持つ任意の要素は、指定されたレベルで見出しとして扱われます。ネイティブh1-h6要素は常に好まれますが、ARIAでマークされた見出しはスクリーンリーダーにとって同等に有効で、ネイティブと一緒にチェックされます。

見出し階層は他のWCAG基準と比べてどれほど重要ですか?

とても。WebAIMの年次Screen Reader User Surveyは、スクリーンリーダーユーザーの67-70%が、ページを理解する主要な方法として見出しでナビゲートすることを一貫して見出しています。悪い見出しはアクセシビリティナビゲーション方法の主要な1つを事実上ブロックします。WebAIMの年次WebAIM Million分析では、見出しの問題はウェブ全体で最も一般的なアクセシビリティの失敗の上位5つに入ります。高いユーザー影響と簡単な検出の組み合わせにより、それらは最優先事項になります。

すべてのページにh1が必要ですか?

はい、まれな例外を除いて。完全なHTMLドキュメントには、ページタイトルを表す正確に1つのh1があるべきです。例外は、より大きなページに明示的に挿入されるフラグメント(電子メール署名、別のページに埋め込まれたウィジェット)です。ホストページがh1を提供し、フラグメントはh2以下から始まります。スタンドアロンページの場合、h1の欠落は明らかなアクセシビリティの失敗です。

法的コンプライアンス監査のためにこのツールを信頼できますか?

見出し構造に特に関しては、はい: ルールは正確で、ツールは正確に実装しています。全体的なWCAGコンプライアンスについては、単一の自動ツールでは不十分です。法的グレードの監査には、支援技術での手動テスト、専門家のレビュー、障害者ユーザーとのユーザーテストが必要です。このツールを監査への複数の入力の1つとして使用し、コンプライアンスの唯一の真実の源として使用しないでください。