前回の続き——書き方の分かれ道
前回のG-02では、HTMLがブラウザの中でDOMという木構造になり、そこをJavaScriptが書き換えると学びました。今回はそのDOMの一つ手前、元のHTMLをどう書くかに話を戻します。G-01で見た見出しや段落といった部品には、実は意味を持つものと、意味を持たない無色のものがあります。どちらを使っても見た目は作れてしまう、その選び方が今日の中心です。
このスライドのポイント
- G-02: HTMLはブラウザ内でDOMになり、そこをJavaScriptが書き換える
- 今回はDOMの一つ手前、元のHTMLを「どう書くか」に戻る
- G-01の部品には「意味を持つもの」と「無色のもの」がある
意味に合った要素を選ぶ
セマンティックHTMLとは、内容の意味に合った要素を選んで書く書き方のことです。たとえばheaderは頭部、navは案内、mainは主内容、buttonは押して動くものを表します。これに対してdivやspanは、意味を持たない汎用の入れ物です。意味のある要素を選ぶと、その情報は検索エンジンや読み上げソフト、そして後からコードを読む人、つまり未来の自分やAIへの手がかりになります。見た目を作るだけなら、どちらの要素でも同じことができてしまう。だからこそ、意味で選ぶという発想が大切になります。
このスライドのポイント
- セマンティックHTML＝内容の意味に合った要素を選ぶ書き方
- header（頭部）・nav（案内）・main（主内容）・button（押して動くもの）
- div・spanは意味を持たない汎用の入れ物
- 意味のある要素は、検索エンジン・読み上げソフト・後から読む人（未来の自分やAI）への情報になる
なぜ必要か——「divだらけ」の落とし穴
意味を意識しないと、AIが生成しがちな「divだらけのHTML」を見ても、その良し悪しを判断できません。たとえば「クリックできるdiv」は、見た目こそボタンでも、キーボードだけでは押せません。こうした書き方は、カテゴリGの最終回で扱うアクセシビリティ、つまり誰かが使えない画面を生む温床になります。そして構造の乱れは、後から直すほどコストが大きくなります。作った直後、まだ小さいうちに気づけるかどうかが分かれ目です。
このスライドのポイント
- AIは「divだらけのHTML」を生成しがち
- 「クリックできるdiv」はキーボードで押せない
- カテゴリG最終回のアクセシビリティ問題の温床になる
- 構造の質は、早い段階ほど直すコストが小さい
同じ見た目・違う中身
全体像を対比で見てみます。同じ見た目のページを2枚用意します。片方はdivだけで組んだもの、もう片方はheader・nav・mainで組んだものです。人間の目には、この2枚はまったく同じに見えます。しかし検索エンジンや読み上げソフトといった機械にとっては、中身に大きな違いがあります。片方は「ここが案内、ここが主内容」と伝わり、もう片方はただの入れ物の集まりにしか見えません。見た目が同じでも、伝わる情報量がまったく違うのです。
このスライドのポイント
- 同じ見た目のページを2枚並べて比較する
- 片方はdivだけ、もう片方はheader・nav・mainで構成
- 人間の目には同じ、機械と支援技術には大違い
- 見た目が同じでも、伝わる情報量が違う
ボタンに見えるdivと、button要素
具体例として、ボタンを考えます。見た目上のボタンは、divでも作れますし、button要素でも作れます。CSSを当てれば、見た目はどちらも区別がつかないほど同じにできます。ところがbutton要素には、キーボードでの操作や読み上げソフトへの対応が、最初から備わっています。意味に合った要素を選ぶだけで、こうした品質が後から自然に付いてくるのです。逆にdivでボタンを作ると、その機能を一つずつ手作業で足していくことになり、抜けや不具合の原因になります。
このスライドのポイント
- 見た目上のボタンはdivでもbutton要素でも作れる
- CSSを当てれば見た目はどちらも同じにできる
- buttonはキーボード操作・読み上げ対応が最初から備わる
- 意味を選ぶだけで品質が付いてくる
技術サンプル: divと意味のある要素
サンプルを見ます。上の書き方は、見出しをdivで、送信をdivで表しています。下の書き方は、見出しをh1、送信をbutton要素で表しています。下の書き方なら、機械にも「これは見出し」「これは押せるもの」と伝わります。上は、人間が見た目から推測するしかありません。AIに画面を作らせたときは、「divで書かれているが意味のある要素に置き換えるべき箇所を指摘してください」と聞くと、こうした差を早い段階で洗い出せます。
このスライドのポイント
- 種別: code
- 目的: 「意味が伝わらない書き方」と「意味が伝わる書き方」を見比べる
- サンプル本体:
見た目が正しい vs 意味が正しい
混同しやすいのは、「見た目が正しい」ことと「意味が正しい」ことです。CSSを使えば、見た目はどんな要素からでも作り込めます。ですから、見た目が整っていることは、意味が正しいことの証明にはなりません。この2つはまったく別の軸だと覚えておいてください。見た目が完成していても、中身がdivだらけということは、十分に起こり得ます。
このスライドのポイント
- CSSを使えば、見た目はどんな要素からでも作り込める
- だから「見た目が整っている」は「意味が正しい」の証明にならない
- この2つは別の軸
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが生成した画面には、「buttonであるべきなのにdivになっている箇所、h1であるべきなのにdivになっている箇所はありませんか」と聞きましょう。こうした指摘は、修正コストが低い早い段階でこそ効きます。意味の正しさは後回しにせず、構造ができた時点で一度確認する習慣をつけてください。ここで整えておくと、後のCSSやアクセシビリティの作業がずっと楽になります。
このスライドのポイント
- AIの生成画面に「buttonであるべきdiv・h1であるべきdivはないか」を確認
- 修正コストが低い早い段階で直す
- 意味の正しさは後回しにせず、構造ができた時点で一度確認する
まとめと次回
最後に一問一答です。押して動作するUIに使うべき要素は何でしょうか。……答えは、button要素です。clickできるdivではなく、buttonを選びます。30秒でまとめます。意味に合った要素を選ぶセマンティックHTMLは、検索・支援技術・保守性を同時に高め、見た目だけでは代えられない品質を生みます。だからこそ、構造ができた早い段階で意味の正しさを確認しておきましょう。次回は、入力を受け取るフォーム要素へ進みます。関連資料は「UI改善プロンプト50」と「画面設計チェックリスト100」です。
このスライドのポイント
- 一問一答: 押して動作するUIに使うべき要素は？ → button（clickできるdivではなく）
- 30秒まとめ: 意味に合った要素を選ぶと、検索・支援技術・保守性が同時に上がる
- 次回: 入力を受け取るフォーム要素へ
- 関連資料: 「UI改善プロンプト50」「画面設計チェックリスト100」
