HTMLの「main要素」を使いこなす:唯一性と制約、そして現場のリアリティ
フロントエンド開発の現場で、マークアップの設計は地味に見えて、実はプロダクトの堅牢性を左右する重要な局面だ。特にセマンティックなHTMLの構築において、`main`要素の扱いは、アクセシビリティやSEO、そしてブラウザのレンダリング挙動に直結する。
今日は、中級エンジニアが意外と曖昧にしがちな「`main`要素の唯一性」と、実務で遭遇する「例外的なユースケース」について、現場の知見を交えて深掘りしていく。
—
1. なぜ「main」はページに一つでなければならないのか
仕様書(HTML Living Standard)には、「`main`要素は文書の主要なコンテンツを表す」とあり、「ページ内に一つしか配置してはならない」という制約がある。
なぜか? それは、スクリーンリーダーや検索エンジンが「このページのメインディッシュはどこだ?」と判断するためのランドマーク(目印)として機能しているからだ。
もしページ内に複数の`main`が存在すると、ブラウザや支援技術はどれを優先すべきか迷子になる。結果として、`main`が持つ「メインコンテンツへのスキップリンク(スキップナビゲーション)」という強力なアクセシビリティ機能が正しく動作しなくなるリスクがある。
実務的な落とし穴:SPAでの「唯一性」
ReactやVueといったシングルページアプリケーション(SPA)で、レイアウトコンポーネント内に`main`を配置する場合、ページ遷移ごとにDOMが書き換わることを忘れてはならない。ルーティングごとに「コンテンツの本質」が入れ替わることを意識し、常に「そのページにおけるメインコンテンツはここだ」と宣言する設計を心がけよう。
—
2. hidden属性との併用:裏側の挙動を理解する
ここで一つ、現場で使えるテクニックを紹介しよう。`main`要素には`hidden`属性を付与できる。
「一つしか置けないはずなのに、`hidden`で隠す?」と疑問に思うかもしれないが、これは「条件によってメインコンテンツが切り替わるUI」を構築する際に非常に有効だ。
ブラウザのレンダリングエンジンは、`hidden`属性がついた要素を「表示せず、かつアクセシビリティツリーからも除外する」という挙動をとる。つまり、複数の`main`が存在していても、そのうち1つだけが可視状態であれば、仕様上の「唯一性」を損なわずに実装が可能というわけだ。
—
3. 実践:セマンティックかつ堅牢な実装サンプル
では、これらを踏まえた「現場でそのまま使える」マークアップ例を見てみよう。
サイトタイトル
記事タイトル
ここが文書の本質的なメインコンテンツ。
何らかの条件で切り替わる代替メインコンテンツ。
このコードのポイント
1. ARIAロールの省略: `main`タグ自体が強力なセマンティック要素であるため、`role=”main”`と書く必要はない。DRY(Don’t Repeat Yourself)の原則に倣い、書かなくていいものは書かないのがプロの作法だ。
2. id属性の付与: スキップリンク(「本文へスキップ」ボタン)の実装用に、`main`には必ず`id`を振っておこう。これはアクセシビリティ改善の第一歩だ。
3. 論理的な分離: `header`や`footer`を`main`の中に含めるのはアンチパターンだ。あくまで`main`は「固有のコンテンツ」に集中させる。
—
最後に:綺麗なマークアップは「愛」である
「動けばいい」というコードは、数ヶ月後の自分やチームメンバーに技術的負債として跳ね返ってくる。`main`要素を正しく扱うことは、ブラウザに対する敬意であり、エンドユーザーに対する誠実さだ。
次に実装する際は、CSSのクラス名に頭を悩ませる前に、まずはDOMの構造が「誰が見てもメインコンテンツがどこか分かる」ようになっているか、一度立ち止まって確認してみてほしい。
技術は常に進化しているが、こうしたHTMLの基礎的なセマンティクスは、どんなフレームワークを使おうとも変わらない「地図」のようなものだ。この地図を正しく描くことこそが、優れたフロントエンドエンジニアへの近道だと、私は信じている。

コメント