HTML・CSS・JavaScriptの役割
このページで学ぶこと
Section titled “このページで学ぶこと”- HTML・CSS・JavaScriptがそれぞれ何を担当するか
- 見た目が同じでも、HTMLの作り方によって品質が変わる理由
- JavaScriptが増えると、表現力だけでなく障害点や保守対象も増えること
- デザイン、SEO、アクセシビリティ、性能とフロントエンド実装の関係
- PMが実装詳細を知らなくても確認できる事項
Webページは、主にHTML、CSS、JavaScriptの三つを組み合わせて作られます。
flowchart LR
H[HTML<br/>意味と構造] --> P[Webページ]
C[CSS<br/>見た目とレイアウト] --> P
J[JavaScript<br/>動作と状態変化] --> P
単純化すると、HTMLは「何が書かれているか」、CSSは「どう見せるか」、JavaScriptは「操作に応じてどう変わるか」を担当します。
ただし、実務では完全に独立しているわけではありません。HTMLの構造がCSSの設計やアクセシビリティへ影響し、JavaScriptの実装が表示速度やSEOへ影響します。
HTMLは「文章の意味と構造」を表す
Section titled “HTMLは「文章の意味と構造」を表す”HTMLは、ページ内の情報を構造化するための言語です。
たとえば、同じ大きさ・太さで表示されていても、次の情報は意味が異なります。
- ページの見出し
- 段落
- 箇条書き
- ナビゲーション
- 本文
- 補足情報
- ボタン
- 入力フォーム
- 表
- 画像
HTMLでは、見た目ではなく役割に合った要素を使います。
flowchart TD
PAGE[ページ]
PAGE --> HEADER[ヘッダー・ナビゲーション]
PAGE --> MAIN[主要コンテンツ]
PAGE --> FOOTER[フッター]
MAIN --> H1[ページ見出し]
MAIN --> SECTION[内容のまとまり]
SECTION --> H2[小見出し]
SECTION --> TEXT[段落・リスト・画像]
この構造は、ブラウザ、検索エンジン、スクリーンリーダー、自動翻訳、AIによる情報抽出などに利用されます。HTMLは単なる「画面を作るコード」ではなく、情報設計を機械が理解できる形へ変換する役割を持ちます。
見た目が合っていてもHTML品質は異なる
Section titled “見た目が合っていてもHTML品質は異なる”デザインカンプ通りに見えるページでも、次のような問題があり得ます。
- 見出しが単なる大きな文字になっている
- リンクとボタンの役割が逆になっている
- 表が画像として貼られている
- 入力欄と項目名が関連づけられていない
- クリックできる要素がキーボードで操作できない
- 画像に代替テキストがない
- 本文の順番と読み上げ順が異なる
これらは、見た目だけのレビューでは発見しにくい問題です。
PMは実装コードを読まなくても、見出し構造、キーボード操作、フォームラベル、画像の代替テキスト、リンク・ボタンの用途、表のテキスト化などを成果物・テスト項目として確認できます。
CSSは「見た目とレイアウト」を制御する
Section titled “CSSは「見た目とレイアウト」を制御する”CSSは、HTMLで構造化した内容の表示方法を指定します。
- 色
- 文字サイズ
- 余白
- 配置
- 幅・高さ
- アニメーション
- 画面幅ごとのレイアウト
- 印刷時の表示
- ダークモード等の環境設定
flowchart LR
H[同じHTML] --> D[デスクトップ表示]
H --> M[モバイル表示]
H --> P[印刷表示]
H --> A[拡大・高コントラスト表示]
レスポンシブWebデザインでは、同じHTMLをさまざまな画面幅で見せます。そのため、デザインレビューでは単一の画面サイズだけでなく、文字拡大、長い見出し、多言語、縦長・横長端末、キーボードフォーカス等も確認します。
CSS設計も保守性へ影響する
Section titled “CSS設計も保守性へ影響する”ページ数や担当者が増えると、スタイルの再利用やルールが必要になります。
- 基本色・余白・文字サイズ
- ボタン・カード・見出し等の部品
- ページ共通レイアウト
- 状態別表示
- ブレークポイント
- デザインシステム
部品ごとのルールが曖昧だと、似ているが少しずつ異なるボタンや余白が増え、改修コストが高くなります。
Figma上でコンポーネントが整理されていても、実装側の部品と対応していなければ、保守性は自動的に高くなりません。
JavaScriptは「操作と状態変化」を担当する
Section titled “JavaScriptは「操作と状態変化」を担当する”JavaScriptは、ページを操作可能にしたり、表示内容を動的に変更したりするために使われます。
- メニューの開閉
- モーダル
- カルーセル
- タブ
- 入力チェック
- APIからのデータ取得
- 検索・絞り込み
- 地図
- グラフ
- ログイン後の表示
- 計測タグ
sequenceDiagram
participant U as 利用者
participant B as ブラウザ
participant J as JavaScript
participant A as API
U->>B: ボタンを押す
B->>J: 操作イベントを渡す
J->>A: データを要求
A-->>J: データを返す
J-->>B: 画面を書き換える
JavaScriptにより、ページ遷移をせずに表示を変えたり、外部データを取得したりできます。
一方、量や複雑さが増えるほど、読み込み時間、実行時間、エラー、ブラウザ差異、ライブラリ更新、セキュリティ、アクセシビリティ、テスト範囲への影響が大きくなります。
JavaScriptを使えばよいとは限らない
Section titled “JavaScriptを使えばよいとは限らない”同じ機能をHTMLやCSSだけで実現できる場合があります。
たとえば、通常のページ遷移をJavaScriptだけで再現したり、標準のボタンを独自のクリック要素で作ったりすると、実装・テスト・アクセシビリティの負担が増える場合があります。
PMが「JavaScriptを使わないように」と指示する必要はありません。確認したいのは、なぜ必要か、失敗した場合に何が起こるか、標準機能で代替できないか、対象ブラウザで動くかです。
HTML・CSS・JavaScriptとSEO
Section titled “HTML・CSS・JavaScriptとSEO”検索エンジンは、ページの内容・構造・リンク等を読み取ります。
HTMLの意味構造が不適切だったり、主要な内容がJavaScript実行後にしか現れなかったりすると、クロール・インデックス・共有時のメタ情報へ影響する場合があります。
ただし、「JavaScriptを使うとSEOに悪い」と一律には言えません。主要内容がどの時点でHTMLとして利用可能か、URLごとに内容が識別できるか、リンクをたどれるか、適切なステータスを返すか等を総合的に確認します。
HTML・CSS・JavaScriptとアクセシビリティ
Section titled “HTML・CSS・JavaScriptとアクセシビリティ”アクセシビリティは、三つすべてにまたがります。
| 技術 | 主に関係する項目 |
|---|---|
| HTML | 見出し、ランドマーク、ボタン、リンク、フォーム、表、代替テキスト |
| CSS | コントラスト、拡大、フォーカス、動き、レスポンシブ |
| JavaScript | キーボード操作、モーダル、動的更新、エラー、カルーセル |
公開前の「追加対応」にすると、構造・デザイン・動作を作り直すことがあります。要件・設計段階から扱います。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”デザイン制作時
Section titled “デザイン制作時”- 見出し階層が情報設計と一致しているか
- リンクとボタンの使い分けが明確か
- エラー、空データ、長文、多言語の状態があるか
- キーボードフォーカスが設計されているか
実装レビュー時
Section titled “実装レビュー時”- コンポーネント単位がデザインと一致しているか
- JavaScriptが必要以上に増えていないか
- 主要内容がJavaScriptエラーで消えないか
- レスポンシブ、拡大、実機で確認しているか
- 画像、フォント、外部タグが性能へ影響していないか
共通部品を変更すると、多数のページへ影響します。一方、似た部品が別々に実装されていると、一括変更できません。改修見積では、見た目だけでなく実装の共通化状況を確認します。
PMチェックリスト
Section titled “PMチェックリスト”- HTML・CSS・JavaScriptの役割を区別して説明できる
- 見た目だけでなく意味構造を確認する工程がある
- 見出し・リンク・ボタン・フォームの役割が整理されている
- モバイル、拡大、多言語、長文等の表示条件を決めている
- JavaScriptが必要な機能と理由を把握している
- JavaScriptエラー時の影響範囲を確認している
- 外部タグやライブラリを一覧化している
- デザイン部品と実装コンポーネントの対応を確認している
- SEO・アクセシビリティ・性能を上流工程から考慮している
- 対象ブラウザ・端末と実機確認範囲を決めている
よくある誤解・失敗
Section titled “よくある誤解・失敗”「HTMLは見た目が合えばよい」
Section titled “「HTMLは見た目が合えばよい」”HTMLは内容の意味と構造を表します。見た目が同じでも、検索・読み上げ・キーボード操作等の品質は異なります。
「CSSはデザインを再現するだけ」
Section titled “「CSSはデザインを再現するだけ」”CSSはレスポンシブ、拡大、印刷、フォーカス、アニメーション等にも関わります。
「JavaScriptを使うほどモダンになる」
Section titled “「JavaScriptを使うほどモダンになる」”JavaScriptは表現力を高めますが、性能・障害・テスト・保守対象も増やします。必要性と効果で判断します。
「Figmaでコンポーネント化したので実装も共通化される」
Section titled “「Figmaでコンポーネント化したので実装も共通化される」”デザイン側と実装側は別の成果物です。命名、状態、粒度、仕様を合わせる必要があります。
「アクセシビリティはHTMLコーダーが最後に対応する」
Section titled “「アクセシビリティはHTMLコーダーが最後に対応する」”情報設計、原稿、デザイン、動作、テストにまたがるため、最後だけでは解決できないことがあります。
理解度チェック
Section titled “理解度チェック”Q1. HTML・CSS・JavaScriptを一言ずつ説明してください。
Section titled “Q1. HTML・CSS・JavaScriptを一言ずつ説明してください。”回答と解説
HTMLは情報の意味と構造、CSSは見た目とレイアウト、JavaScriptは操作や状態変化を主に担当します。実際には相互に影響します。Q2. 見た目がデザイン通りでも、HTML品質に問題がある例を挙げてください。
Section titled “Q2. 見た目がデザイン通りでも、HTML品質に問題がある例を挙げてください。”回答と解説
見出しが単なる太字、ボタンが操作不能な要素、表が画像、入力欄にラベルがない、読み上げ順が不自然等が挙げられます。Q3. JavaScriptを多く使うことで、どのような確認項目が増えますか。
Section titled “Q3. JavaScriptを多く使うことで、どのような確認項目が増えますか。”回答と解説
読み込み・実行性能、エラー時の表示、ブラウザ対応、ライブラリ更新、アクセシビリティ、セキュリティ、テスト範囲等が増えます。Q4. デザインシステムを導入すれば、実装の保守性は自動的に高くなるでしょうか。
Section titled “Q4. デザインシステムを導入すれば、実装の保守性は自動的に高くなるでしょうか。”回答と解説
自動的には高くなりません。Figma上の部品と実装コンポーネントの粒度・状態・仕様・命名を合わせ、運用ルールを持つ必要があります。Q5. 新しいカルーセルを導入するとき、PMは見た目以外に何を確認しますか。
Section titled “Q5. 新しいカルーセルを導入するとき、PMは見た目以外に何を確認しますか。”回答と解説
キーボード・タッチ操作、自動再生停止、読み上げ、画像読み込み、JavaScriptエラー時、モバイル表示、性能、外部ライブラリ更新等を確認します。- MDN「HTML」
https://developer.mozilla.org/ja/docs/Web/HTML
HTMLがWebコンテンツの意味と構造を定義することを確認するための公式リファレンス。 - MDN「CSS」
https://developer.mozilla.org/ja/docs/Web/CSS - MDN「JavaScript」
https://developer.mozilla.org/ja/docs/Web/JavaScript - MDN Curriculum
https://developer.mozilla.org/en-US/curriculum/