「2024年のWebデザイン」を振り返るときは、当時の作品の見た目、技術の公式発表、今の自社の改修を分けて考えます。本稿は2024年の技術紹介を確認する記事で、2026年の採用率や業界全体の流行を調査した結果ではありません。

Google I/O 2024の公式紹介では、スクロールに応じた動き、画面の切り替えをつなぐView Transitions、補足を開くPopoverなどが説明されました。これらは画面を作る選択肢です。採用するだけで問い合わせや売上が増えるとは説明できません。

まず自社で困っている画面を一つ選びます。架空の点検会社なら、サービス一覧で自分の設備に合う項目がわからない場面を考えます。この場合は、項目ごとの対象説明を加えることが先の候補です。新しい動きを足しても、違いの説明がなければ選べません。

技術名を見る前に「初めて来た人が何を読んで何を選ぶか」を書きます。問題が説明の不足なのか、画面の切り替えがわかりにくいのか、操作の反応が遅いのかで、試す要素は違います。過去の紹介をそのまま作業リストにせず、問題と候補を対応させてください。

この章の根拠：出典1出典2

シンプルな画面は、文章をすべて減らした画面とは限りません。点検会社なら、対応設備、対象外、相談前の準備は残す必要があります。重要な答えを見出しで示し、詳しい条件へ進めるように分けることで、説明を失わずに整理できます。

写真や図は、何を頼めるか、どの部分を確認するかを示すために使います。大きな写真で最初の画面を埋める場合も、狭い画面で必要な対象が切れないか、説明を待たずに読めるかを確かめます。高画質という理由だけで重いファイルを採用しません。

画像の代替テキストは、画像の役割から決めます。対象設備の写真なら識別に必要な説明、工程図なら図が答える内容を本文にも残します。装飾だけなら空のaltが適切な場合があります。すべてに検索語を詰めるという方法は採りません。

カード型の並び、大きな文字、余白を参考にするときも、自社の実際の原稿を入れて比較します。「点検」という短い語と、「契約前の設備状態の確認」という長い語では必要な幅が違います。見出しを小さくして収める前に、配置や区切りを変える案を試します。

この章の根拠：出典5

スクロールに応じたアニメーションは、ページを動かす位置に合わせて表現を変える仕組みです。工程の位置を伝える目的なら候補になり得ますが、説明を演出が終わるまで読めなくする必要はありません。対応しない環境でも通常の文章や図が残る案を求めます。

View Transitionsは画面や状態の切り替えを動きでつなぐ仕組みです。一つの画面内の更新と、別ページへの移動では実装条件が違います。担当者には何から何へ切り替わるのか、対象のブラウザと環境、使えない場合の普通の移動を確認します。

Popoverはボタン等から補足を表示する仕組みです。重要な受付条件を補足の中だけへ隠すと、読まずに進む訪問者もいます。補足としてよい内容か、見出しやボタン名が明確か、キーボードで開閉できるかを確かめます。ダイアログと同じ制約や意味を自動で持つものではありません。

2024年の紹介ページの現在の互換性表示が更新されている場合もあります。当時の本文と今の対応状況を混同せず、現行の仕様資料と実際の対象ブラウザで確認します。ブラウザ名だけでなく版も記録し、動作を試せていない環境を「対応済み」としないでください。

この章の根拠：出典1

操作に伴う不要な動きを止められることは、WCAG 2.2のAAA基準で扱われています。自動で始まる動きの停止とは別の条件です。本稿の例で基準全体への適合を証明することはできませんが、動きを追加する前に考えるべき点になります。

以下の例は、index.htmlとstyle.cssを同じ練習フォルダーに保存して使います。受付条件へのリンクは通常のHTMLとして使え、動きを減らす希望がない場合だけ、ポインターやフォーカスで少し位置が変わります。新しい技術そのものの実装ではなく、通常表示を残して動きを加える考え方の最小例です。

ブラウザでリンクを押して条件へ移動し、Tabキーでリンクへ移動します。期待する結果は、どちらの操作でも内容を読めることです。端末の動き軽減設定を有効にした場合は、位置の変化がなくてもリンクの文字とフォーカスの枠が残ります。設定名は端末と版で変わります。

動きが残る場合は、別のCSSが同じ要素に適用されていないかを開発者ツールで確認します。内容が消える場合は、動きの完了を前提に表示を隠す設定がないかを調べます。WordPress等へ使うときはテーマのCSSと干渉し得るため、変更前のCSSを保管し、作業環境の限定した要素で試してから適用を判断します。

この章の根拠：出典3出典4

2024年3月12日にCore Web Vitalsの応答性指標はFIDからINPへ置き換わりました。INPは利用中の操作に対する画面の応答を扱います。古い資料のFIDだけを現在の判定として使わず、現行の計測画面と説明を確認します。

PageSpeed Insights等では、実際の利用から得るデータと、試験環境の結果を分けて見ます。実利用のデータが表示されないサイトもあり、データがないことを良好と判断できません。同じページの同じ操作で困りごとを再現し、担当者がスクリプトや画像等の原因を調べます。

画面が速く反応しても、サービスの説明が不足すれば相談を準備できません。計測値と、対象を選べるか、受付条件を読めるかという利用の確認を別に残します。改修の前後で同じ操作を試すと、何を直したかを説明できます。

AIのおすすめ表示やノーコード製品も、目的、使用するデータ、現行の製品機能、更新担当の確認が必要です。この歴史記事から未確認の製品機能を断定せず、必要な役割が決まっていない場合は今回の改修で保留とする判断ができます。

この章の根拠：出典2

点検会社の例なら、対象説明は採用候補、用途が決まらない大きなスクロール演出は保留、画面切替は対象環境と通常の移動を確認してから判断、と書けます。技術が新しいかだけで採用を決めないことが大切です。

改修メモには、困る画面、参考にした2024年の記録、使う目的、通常表示、対象環境、動き軽減、測定と操作確認を残します。未確認の項目を担当者へ渡せば、過去の紹介を現在の実装相談に使えます。

この章の根拠：出典1出典3出典2