画像の alt・サイズ・読み込み・失敗時の表示を一緒に設計する理由

作品画像の URL が正しくても、それだけでは決まらないことがあります。画像が表示されないときに読者に何が伝わるのか、読み込み前にどれだけの領域を確保するのか、そして画像そのものがどの情報を担っているのか、という点です。

このサイトの画像には、それぞれ異なる役割があります。作品カードにはサムネイルがあり、デザイン作品は外部アルバムへリンクしています。プロフィールページには拡大できるアバターがあり、記事の著者名のそばにも著者紹介を開くための画像があります。すべてに同じ alt や loading の設定を当てはめるのは適切ではありません。

私はまず、その場所で画像が何を担うのかを確認してから、サイズ、読み込み、失敗時の表示をまとめて考えます。どの選択も、読者が実際に受け取るページの一部になるためです。

alt はファイル名の言い換えではなく、用途に合わせて書きます

このサイトでは、作品サムネイルの alt に各言語の作品タイトルを使い、デザイン画像には作品データの説明文を使っています。表示中の作品を識別する手がかりにはなりますが、それぞれの画像の詳細まで十分に説明できているとは限りません。「EDM」のような短いラベルで足りるかどうかも、実際の内容に照らして判断する必要があります。

著者紹介を開く操作要素は扱いが異なります。中国語版では操作要素自体に「認識林予晴」（林予晴について知る）という読み取れる名前があり、画像のそばにも著者を示すテキストがあります。その中のアバターには alt="" と aria-hidden="true" を使い、同じ識別情報をここで繰り返さないようにしています。

W3C の画像チュートリアルでは、内容に情報を加えない装飾画像には、alt 属性を省略するのではなく、空の alt を指定するよう説明しています。[3] ただし、装飾かどうかは使用状況によって決まります。小さい画像だから、あるいはボタンの中にあるからという理由だけで、一律に代替テキストを空にすることはできません。

画像そのものに、読者が理解すべき手順や数値が含まれるなら、作品名だけで済ませることはできません。これは内容を校正するときに判断することで、HTML 属性を一つ加えれば自動的に解決する問題ではありません。

サイズの指定は、画像が表示される前の領域を確保します

MDN は、width と height によって画像の固有サイズの情報を伝え、読み込み前にブラウザーが領域を確保できると説明しています。これはレイアウトのずれを減らすための方法の一つです。[2]

このサイトの作品サムネイルは、サイズ属性、アスペクト比を固定したコンテナー、object-cover を組み合わせています。プロフィールページのアバターにはインポートした画像のサイズ情報を使い、実際の切り抜き方はコンテナーと CSS で決めています。サイズ属性と、最終的に画面へ表示する大きさは同じものではありません。

デザインギャラリーの画像には width="300"、height="200" があり、表示スタイルは h-auto w-full です。これは実装上の設定であり、外部の元画像がすべて実際に 3:2 の比率であることや、ギャラリー全体にレイアウトのずれがないことを示すものではありません。外部画像の実際のサイズと、読み込み後のカードの高さは、別に確認する必要があります。

確認したいのは、確保する比率がその表示方法に合っているかどうかです。切り抜く画像では、重要な内容が欠けていないかを確認します。全体を見せる縦長画像に、見た目をそろえるためだけに別のサムネイルの比率を当てはめるべきではありません。

読み込みのタイミングは、画像が現れる場所に合わせます

作品一覧とデザインギャラリーでは loading="lazy" を使い、プロフィールページのメインのアバターでは loading="eager" と fetchpriority="high" を使っています。著者紹介のそばのアバターも eager です。これらは各使用箇所の設定であり、すべての画像が従うべき共通ルールではありません。

loading="lazy" は、表示領域からの距離などの条件に応じて、ブラウザーが読み込みを遅らせられるようにします。一方、decoding="async" はデコードと描画のタイミングに関するヒントです。二つの属性は、別のことを扱っています。[2]

そのため、async を lazy の代わりにはしませんし、すべての画像を high priority にもしません。ページを開いた直後に必要な画像かどうかを先に判断するほうが、同じ属性をサイト全体へコピーするよりも、読み込みのヒントを選ぶ根拠になります。

ここには変更前後の性能測定はありません。属性の選択だけから、どれだけ速くなったかを結論づけることはできません。

失敗時の案内でも、画像が担っていた用途を残します

このサイトの外部デザイン画像には、エラー処理の対象を示す専用のマークがあります。共通のブラウザースクリプトが error を監視し、失敗時には画像を非表示にして、作品の説明を含む読み込み失敗のテキストを表示します。初期化時には、読み込みが完了しているのに有効な幅がない画像も確認します。

ギャラリーのスクリプトは、それとは別に load または error の後でカードの読み込み状態を解除し、配置の再計算を予約します。画像が利用できないことを伝える処理と、カードの状態やレイアウトを扱う処理には、それぞれの責任があります。

画像を囲んでいた外部リンクは残るため、画像の読み込みに失敗しても、作品アルバムへ進む入口は HTML に残ります。ただし、アルバムのリンク先が利用できるかどうかは別の問題です。画像のエラー処理で、その到達先まで保証することはできません。

この独自の失敗時の案内は、対応するマークのある画像だけが対象です。通常の作品サムネイルや各所のアバターにも同じ案内が自動で付くわけではなく、自動再試行の機能もありません。一つのギャラリーの処理を、サイト内のすべての画像をカバーしているかのように書くべきではありません。

JavaScript がないときに残る基本機能も明確にします

alt、サイズ、標準のリンクは HTML に残ります。一方、独自のエラーテキストやギャラリーの動的な状態は JavaScript が扱います。スクリプトが動かなければ、独自の失敗時の案内はテンプレートに書かれているだけでは表示されず、非表示のままです。

このサイトのデザイン作品の外部リンクには読み取れる名前もありますが、それだけで、スクリプトがない場合の表示を画像ごとに確認したことにはなりません。標準の HTML は土台になりますが、すべての読み込み状態に同じような代替表示があるとは限りません。

この分担を明確にすると、何をテストすべきかも決めやすくなります。まずページが受け取る内容を確認し、その後にスクリプトが加える動作を確認します。ネットワークが正常で、画像がすべて読み込まれた状態だけで画面を確認しても十分ではありません。

画像の校正は、具体的な問いから始めます

以下は確認の提案であり、今回すべてを実施した結果ではありません。

• 画像が表示されなくても、読者は何の項目かを理解でき、操作要素にも名前が残っていますか？
• サイズと CSS の比率は実際の画像に合っていて、切り抜きによって重要な内容が欠けていませんか？
• ページを開いた直後に必要な画像の読み込みが、不適切なタイミングまで遅れていませんか？
• 画像のリクエストを意図的に失敗させたとき、読み込み状態は終了し、案内とリンク先は引き続き役割を果たしますか？
• JavaScript を無効にしても、主要な内容、代替テキスト、標準のリンクを理解できますか？

答えが「画像が表示された」だけなら、失敗時の表示や代替コンテンツまではまだ確認できていません。

この記録の範囲

この記事は、このサイトの現在の作品ページ、デザイン画像のデータ、プロフィールページ、記事の著者コンポーネント、共通スクリプトとギャラリーのスクリプトをもとに整理しています。外部画像の比率、スクリーンリーダーでの動作、ネットワーク切断時の挙動、すべての画像の失敗経路を、今回一つずつ実測したわけではありません。読み込み速度やレイアウトのずれについても、新しい測定はしていません。

ソースコードから確認できるのは、これらの責任をどう分担し、どの画像にどの設定を使っているかです。表示が適切かを判断するには、画像の内容と実際の使用状況に立ち戻る必要があります。

出典

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img [3] https://www.w3.org/WAI/tutorials/images/decorative