HTML見出しの「深淵」：アウトラインアルゴリズムとセマンティックな設計の真実
フロントエンドのアーキテクトとして多くのコードベースをレビューしてきましたが、いまだに遭遇するのが「見た目のフォントサイズを基準に見出しタグを選定する」という悪癖です。
かつてHTML5策定時に鳴り物入りで登場した「アウトラインアルゴリズム（各セクションで見出しレベルをリセットできるという概念）」は、現在ではブラウザの実装状況やアクセシビリティの観点から、ほぼ「死んだ仕様」と化しています。今、私たちが信頼すべきは、HTML4時代から連綿と続く「h1からh6までの厳格なネスト構造」そのものです。
今日は、単なるマークアップの作法を超え、レンダリングエンジンやアクセシビリティツリー、そして大規模アプリケーションにおける型安全なコンポーネント設計の視点から、この「見出し」という原始的かつ根源的な要素を再定義します。
—
1. アウトラインの「崩壊」とブラウザの現実
HTML5仕様書が夢見た「`section`タグを使えば、その中ではまた`h1`から始められる」という夢は、主要なスクリーンリーダーや検索エンジンの解釈と乖離しました。
現実的なエンジニアリングにおいて、アウトラインは「ドキュメントツリー全体で一貫した深さを持つべき」です。これを無視すると、NVDAやVoiceOverのような支援技術において、階層が正しく認識されず、ユーザーのコンテキスト理解を著しく阻害します。
パフォーマンスへの小さな警告
不要なネストや、過度なDOMの深さは、ブラウザのスタイル計算（Recalculate Style）のコストを微増させます。特に大規模SPAで、動的に生成される見出しが深すぎる場合、レンダリングエンジンのレイアウト計算に余計な負荷がかかります。見出しは「ドキュメントの骨格」です。ここを簡潔に保つことは、SEOだけでなく、DOMノードの効率化にも繋がるのです。
—
2. TypeScriptによる「見出しの型安全」：コンポーネント設計の最適解
ReactやVueなどのコンポーネント指向フレームワークにおいて、見出しを盲目的にハードコーディングするのは避けるべきです。特に再利用性の高いカードコンポーネントなどでは、`h2`であるべきか`h3`であるべきかがコンテキストによって変わるからです。
以下は、TypeScriptで堅牢にこれを制御する設計例です。
type HeadingLevel = 1 | 2 | 3 | 4 | 5 | 6;
interface HeadingProps {
level: HeadingLevel;
children: React.ReactNode;
className?: string;
}
/
- 見出しの階層をプロパティで強制するコンポーネント
- 外部からの誤ったレベル指定をコンパイルタイムで防ぐ
/
export const Heading: React.FC
// 動的なタグ名生成
const Tag = `h${level}` as keyof JSX.IntrinsicElements;
// 適切なセマンティクスを維持しつつ、共通のスタイルを適用
return
};
このように、`level`を型定義で縛ることで、開発者が「なんとなく`h4`」といったタグ選択をする余地を排除し、チーム開発におけるセマンティクスの崩壊を防ぐことができます。
—
3. 非同期読み込みと見出しの競合
現代のWebアプリでは、コンテンツが非同期（SuspenseやSWRなど）で注入されることが一般的です。ここで陥りやすい重大なバグが「見出しレベルのスキップ」です。
- Bad: `h1`の直後に突然`h4`が出現する。
- Good: コンテンツが非同期であっても、DOM上では論理的な階層（1→2→3）を維持する。
特に、非同期で読み込まれるサイドバーやウィジェットが、親のドキュメントの階層を破壊しないよう、「見出しの深さをContext APIで管理する」という設計も、大規模アプリケーションでは検討に値します。コンポーネントの深さに応じて、自動的にレベルをインクリメントさせる仕組みを作れば、エンジニアが階層を意識するコストをゼロにできます。
—
4. エッジケース：`hr`タグの役割再考
最後に、見出しに関連して語られることの多い`hr`についても触れておきます。`hr`は単なる「横線」ではありません。「テーマ的な区切り（Thematic break）」です。
見出しのレベルを変えるほどではないが、トピックが明確に切り替わる場所には`hr`を置くべきです。これをCSSの`border-bottom`で代用してはいけません。アクセシビリティツリーにおける「区切り」としての情報が失われ、スクリーンリーダーのユーザーがトピックの切れ目を認識できなくなるからです。
—
結論：コードは「意味」を語るべき
ブラウザは賢いですが、私たちの意図を汲み取る魔法使いではありません。CSSでどう見せるかは二の次です。重要なのは、「HTMLの構造が、そのコンテンツの論理的な階層を正確に表現しているか」、ただ一点です。
堅牢なアプリケーションとは、DOMの構造がそのまま情報の骨格として機能しているものを指します。流行のフレームワークがどれほど進化しようとも、この「見出しの深さ」という原始的なルールを遵守することが、結果として最も高いパフォーマンスとアクセシビリティをもたらす最短ルートなのです。
次にコードを書くとき、その`h`タグは「フォントサイズのため」ではなく、「情報の階層を正しく伝えるため」にあることを思い出してください。エンジニアの矜持は、こうした細部へのこだわりの中にこそ宿ります。
コメント