セマンティックHTMLの重要性と書き方｜アクセシビリティ向上の第一歩

はじめに

Webサイトを作っていて、「とりあえず div で囲んでおけば見た目は整うから」と感じたことはありませんか。たしかにブラウザで見る限り、画面の見た目はどちらでも変わりません。しかし、画面の向こう側で読み上げソフトを使っている人や、検索エンジンのクローラーから見ると、その差は決定的です。

この記事では、セマンティックHTMLの基本的な考え方から、アクセシビリティを高めるための具体的なタグの使い分け、現場で陥りやすい落とし穴までを順を追って解説します。読み終える頃には、「なぜ div だけではいけないのか」を自信を持って説明できるようになっているはずです。

セマンティックHTMLとは何か

セマンティックHTMLとは、それぞれの要素が持つ「意味」に従ってタグを使い分けるマークアップのことです。

「意味のあるタグ」を使うという考え方

家を建てるときの設計図を思い浮かべてみてください。同じ広さの空間でも、「リビング」「寝室」「キッチン」とラベルが書かれていれば、誰でも一目で部屋の役割がわかります。逆に、すべての部屋が「部屋A」「部屋B」と書かれていたら、家具を運び込む人は途方に暮れてしまうでしょう。

HTMLも同じです。<header> <nav> <main> <article> といったタグは、その部分がどんな役割を持っているかを明示するラベルの役目を果たします。ブラウザはもちろん、スクリーンリーダーや検索エンジンも、このラベルを手がかりにページの構造を理解しているのです。

div・spanとの違い

<div> と <span> は、何の意味も持たない「無色透明」なタグです。たとえるなら、ラベルの貼られていない真っ白なダンボール箱のようなもの。中身を確認するまで何が入っているかわかりません。

一方、セマンティックタグはあらかじめラベルが貼られた収納ボックスです。<nav> であれば「ここはナビゲーションです」、<article> であれば「ここは独立した記事です」と、開く前から中身が伝わります。div を全否定するわけではありませんが、適切なセマンティックタグがあるならそちらを優先する、というのが基本姿勢です。

なぜアクセシビリティに直結するのか

セマンティックHTMLは、見た目ではなく「情報の伝わり方」に影響します。とりわけアクセシビリティとの関係は深く、ここを理解するとマークアップの判断が一段とクリアになります。

スクリーンリーダーはタグを「読み上げる」

視覚に障害のある方がWebを利用するとき、画面のテキストを音声で読み上げる「スクリーンリーダー」というソフトを使います。このソフトは、ページのHTML構造を解析し、「ここはナビゲーションです」「ここから本文です」とユーザーに案内します。

もしページ全体が div だらけだったらどうなるでしょうか。スクリーンリーダーはどこが本文でどこがメニューなのか判別できず、利用者は最初から最後までテキストを順に聞かされることになります。これは、目次のない分厚い本を最初のページから読み続けるのと同じ苦痛です。適切なセマンティックタグがあれば、利用者は「本文に飛ぶ」「ナビゲーションを読み上げる」といったショートカット操作が可能になります。

キーボード操作との関係

マウスを使えず、キーボードだけでWebを操作する利用者も少なくありません。手に障害のある方や、一時的なケガ、あるいはパワーユーザーまで含めると、対象は意外と広いものです。

<button> や <a> といったタグは、最初からキーボードでフォーカスできる仕組みが備わっています。Tabキーで移動し、Enterキーで実行できる。一方、div にクリックイベントを仕込んだだけのボタン風要素は、キーボード利用者からは存在しないも同然です。「ネイティブのHTMLタグを使うだけで、無料でアクセシビリティが手に入る」と言われるのは、こうした標準機能のおかげなのです。

セマンティックHTMLがもたらす3つのメリット

セマンティックHTMLの恩恵は、アクセシビリティだけにとどまりません。

アクセシビリティ向上

前述のとおり、スクリーンリーダーやキーボード操作との相性が良くなります。総務省が2024年に公表した「ウェブアクセシビリティ確保のためのガイドライン」でも、適切な構造化マークアップは基本要件として位置付けられています。今後、官公庁や大手企業の案件では、ますます必須要件となっていく流れです。

SEO効果

検索エンジンのクローラーも、セマンティックタグを手がかりにページの内容を理解します。「ここが見出し」「ここが本文」「ここは補足情報」と明示されていれば、検索エンジンは適切なキーワードと結びつけて評価できます。アクセシビリティ対応をしておくと、結果としてSEOにも有利に働く。一石二鳥の対策なのです。

保守性・可読性アップ

3か月後の自分や、新しくチームに加わった人が見たときに、ソースコードがすぐ理解できるかどうか。これは保守コストに直結します。<header> <aside> といったタグはコメントを書かなくても役割が伝わるため、コードレビューや引き継ぎがスムーズになります。店舗の在庫管理で、すべての段ボールに中身がラベリングされている状態を想像してください。それと同じ効果が、コードベースにももたらされるのです。

よく使うセマンティックタグと使い分け

ここからは現場で頻出するタグを整理しておきましょう。

構造を示すタグ（header, nav, main, footer など）

ページ全体のレイアウトを担う、いわば「家の骨組み」にあたるタグです。

これらは多くの場合、ページの大枠を組み立てるときに最初に登場します。

コンテンツを示すタグ（article, section, aside）

骨組みの内側に配置する、コンテンツの種類を示すタグです。

似たような役割に見えますが、<article> は「切り出して別の場所に置いても成立するか」が判断基準になります。

迷ったときの判断フロー

実務でタグ選びに迷ったら、次の順序で考えるとスッキリ整理できます。

「div ありき」ではなく、「役割ありき」で考える。この順序を守るだけで、マークアップの質はぐっと上がります。

実装時に陥りやすい3つの落とし穴

最後に、セマンティックHTMLを意識し始めた人がつまずきやすいポイントを紹介します。

見出しレベルの飛ばし

h1 の次にいきなり h3 が来る、というケースをよく見かけます。デザイン上のフォントサイズを優先してしまうのが原因ですが、スクリーンリーダーの利用者は見出しレベルを目次のように使うため、階層が飛ぶと混乱します。本の章立てで、第1章の次にいきなり1-1-1節が来るような状態だと考えてください。見た目のサイズはCSSで調整し、HTMLでは論理的な階層を保つのが原則です。

clickイベント付きdiv問題

JavaScriptで <div onClick="..."> のようにボタン風の要素を作るのは、典型的なアンチパターンです。前述のとおり、キーボードでフォーカスできず、スクリーンリーダーからもボタンとして認識されません。クリックできる要素は、原則として <button> か <a> を使う。これだけで、フォーカス管理もキー操作も無料でついてきます。

ARIA属性の乱用

「アクセシビリティ対応」と聞くと、ARIA属性をたくさん追加すれば良いと考えてしまいがちです。しかしW3Cも公式に「No ARIA is better than bad ARIA（誤ったARIAを使うくらいなら何もない方がマシ）」と注意喚起しています。

ARIAは、ネイティブHTMLでは表現できない場合の補助手段です。まずは適切なセマンティックタグで組み、それでも足りない情報を補うときだけARIAを足す。この順番を守らないと、かえって支援技術を混乱させる結果になります。

まとめ

セマンティックHTMLは、ただの「キレイな書き方」ではありません。スクリーンリーダー利用者にとっては道案内になり、キーボード利用者には標準機能を提供し、検索エンジンには内容理解の手がかりを与え、開発チームには可読性の高いコードを残します。

明日からできる第一歩は、自分が書いているHTMLを見直し、「div で囲んでいるけれど、本当はもっと適切なタグがあるのでは？」と一度問い直してみることです。判断に迷ったら、「役割ありきで考える」順序を思い出してください。小さな積み重ねが、誰にとっても使いやすいWebをつくっていきます。