HTML

Living Standard — Last Updated 1 September 2026

1. 1. 1. 4.8.4 画像
         1. 4.8.4.1 導入
            1. 4.8.4.1.1 アダプティブ画像
         2. 4.8.4.2 source、imgおよびlink 要素の共通属性
            1. 4.8.4.2.1 srcset共通属性
            2. 4.8.4.2.2 size属性
         3. 4.8.4.3 Processing model
            1. 4.8.4.3.1 When to obtain images
            2. 4.8.4.3.2 Reacting to DOM mutations
            3. 4.8.4.3.3 The list of available images
            4. 4.8.4.3.4 Decoding images
            5. 4.8.4.3.5 Updating the image data
            6. 4.8.4.3.6 Preparing an image for presentation
            7. 4.8.4.3.7 Selecting an image source
            8. 4.8.4.3.8 Creating a source set from attributes
            9. 4.8.4.3.9 Updating the source set
            10. 4.8.4.3.10 Parsing a srcset attribute
            11. 4.8.4.3.11 Parsing a sizes attribute
            12. 4.8.4.3.12 Normalizing the source densities
            13. 4.8.4.3.13 Reacting to environment changes
         4. 4.8.4.4 画像に対して代替として動作するテキストを提供に対する要件
            1. 4.8.4.4.1 一般的なガイドライン
            2. 4.8.4.4.2 画像のみを含むリンクまたはボタン
            3. 4.8.4.4.3 代替グラフィカル表現をもつフレーズまたは段落：チャート、図、グラフ、マップ、イラスト
            4. 4.8.4.4.4 代替グラフィカル表現をもつ短いフレーズまたはラベル：アイコン、ロゴ
            5. 4.8.4.4.5 印刷効果のためにグラフィックにレンダリングされたテキスト
            6. 4.8.4.4.6 周囲のテキストの一部をグラフィカルに表現
            7. 4.8.4.4.7 補助画像
            8. 4.8.4.4.8 情報を追加しない、純粋に装飾的な画像
            9. 4.8.4.4.9 リンクのない単一の大きな画像を形成する画像のグループ
            10. 4.8.4.4.10 リンクのある単一の大きな画像を形成する画像のグループ
            11. 4.8.4.4.11 コンテンツのキーパート
            12. 4.8.4.4.12 ユーザーを意図しない画像
            13. 4.8.4.4.13 画像を閲覧できることが知られている特定の人のために意図された電子メールまたは私的文書における画像
            14. 4.8.4.4.14 Guidance for markup generators
            15. 4.8.4.4.15 Guidance for conformance checkers

4.8.4 画像

4.8.4.1 導入

この節は非規範的である。

単独の画像リソースのみが存在する場合、HTMLにおいて画像を埋め込むために、img要素およびsrc属性を使用する。

<h2>From today's featured article</h2>
<img src="/uploads/100-marie-lloyd.jpg" alt="" width="100" height="150">
<p><b><a href="/wiki/Marie_Lloyd">Marie Lloyd</a></b> (1870–1922)
was an English <a href="/wiki/Music_hall">music hall</a> singer, ...

しかし、ユーザーエージェントが選択することができる複数の画像リソースを用いることを著者が望むかもしれない多数の状況が存在する：

• 異なるユーザーが異なる環境特性を持つかもしれない：

  • ユーザーの物理スクリーンサイズは他のものと異なるかもしれない。

    ラップトップのスクリーンは14インチ型であるかもしれない一方で、携帯電話のスクリーンは4インチ型であるかもしれない。

    画像のレンダリングサイズがビューポートに依存する場合、これは単に関連するだけである。

  • ユーザーのスクリーンピクセル密度は、別のスクリーンと異なるかもしれない。

    携帯電話のスクリーンは、物理スクリーンサイズに関わらず、別の携帯電話のスクリーンと比較してインチあたり物理ピクセルとして3倍になるかもしれない。

  • ユーザーのズームレベルは別のものと異なるかもしれず、時間とともに単独のユーザーに対して変化するかもしれない。

    ユーザーは、特定の画像の詳細を見るためにズームするかもしれない。

    ズームレベルおよびスクリーンピクセル密度（前のポイント）は、CSSピクセル密度あたり多数の物理スクリーンピクセルに影響を与えることができる。この比率は、一般にデバイスピクセル比として参照される。

  • ユーザーのスクリーン方向は別のものと異なるかもしれず、時間とともに単独のユーザーに対して変化するかもしれない。

    タブレットは縦型または90度回転して固定されることができ、その結果スクリーンは、"縦長"（portrait）または"横長"（landscape）のいずれかとなる。

  • ユーザーのネットワーク速度、ネットワークレイテンシおよび帯域幅コストは異なるかもしれず、時間とともに単独のユーザーに対して変化するかもしれない。

    ユーザーは、仕事で低レイテンシおよび一定コスト接続の高速かもしれないし、家で低レイテンシおよび一定コスト接続の低速かもしれないし、他の場所で高レイテンシおよび可変コスト接続の速度変化かもしれない。

• 著者は、ビューポートの幅に依存して、同じ画像だが異なるレンダリングサイズを表示したいかもしれない。これは通常ビューポートベースの選択として参照される。

  ウェブページは、常に全体のビューポート幅に及ぶ、一番上のバナーを持つかもしれない。この場合、画像のレンダリングサイズはスクリーンの物理サイズに依存する（最大化されたブラウザーウィンドウを仮定する）。

  別のウェブページは、小さな物理サイズをもつスクリーンに対する列、中程度の物理サイズをもつスクリーンに対する列、大きな物理サイズをもつスクリーンに対する列をともない、ビューポートを埋める各ケースにおいてレンダリングサイズの変化する画像をもつ、列における画像を持つかもしれない。この場合、画像のレンダリングサイズは、スクリーンがより小さくにもかかわらず、2列レイアウトと比較して1列レイアウトでより大きくなるかもしれない。

• 著者は、画像のレンダリングサイズ次第で異なる画像コンテンツを表示したいかもしれない。これは通常art directionとして参照される。

  ウェブページが大きな物理サイズ（最大化されたブラウザーウィンドウと仮定する）をもつスクリーンで見られる場合、著者は画像の重要な部分を囲むあまり関連しない部分を含むことを望むかもしれない。ウェブページが小さなな物理サイズをもつスクリーンで見られる場合、著者は画像の重要な部分のみを表示することを望むかもしれない。

• 著者は、ユーザーエージェントがサポートする画像フォーマットに応じて、同じ画像コンテンツだが異なる画像フォーマットを表示したいかもしれない。これは通常画像フォーマットベースの選択として参照される。

  ウェブページは、JPEG、JPEGと比較してより圧縮能力のよいWebPおよびJPEG XRフォーマットで画像を持つかもしれない。異なるユーザーエージェントは、よりよい圧縮比を提供するフォーマットをもつ、異なる画像フォーマットをサポートすることができるため、サポートしないユーザーエージェントに対してJPEGフォールバックを提供する一方で、著者はフォーマットをサポートするユーザーエージェントに対してよりよいフォーマットを配信したいだろう。

上記の状況は、相互に排他的ではない。たとえば、art directionに対する異なるリソースをもつ異なるデバイスピクセル比が異なるリソースを組み合わせることは理にかなっている。

スクリプトを使用することでこれら問題を解決することは可能である間、そのようにすることは他の問題を導入する：

• ウェブページがすぐに読み込み完了するように、スクリプトが実行する機会を持つ前に、一部のユーザーエージェントは、HTMLマークアップで指定される画像を積極的にダウンロードする。スクリプトがダウンロードする画像を変更する場合、より悪いページ読み込みパフォーマンスを引き起こすことができるダウンロードの代わりに、ユーザーエージェントはダウンロードを分離する2つを潜在的に開始するだろう。

• 著者がHTMLマークアップで任意の画像の指定を避け、かつスクリプトから単一のダウンロードを代わりに実例を示す場合、それは上記の2回のダウンロード問題を回避するが、無効にされるスクリプトをもつユーザーに対して画像を一切ダウンロードせず、かつ積極的な画像ダウンロード最適化も無効にされる。

このことを考慮して、この仕様は宣言する方法で上記の問題を申し立てるための多数の機能を導入する。

画像のレンダリングサイズが固定される場合でデバイスピクセル比ベースの選択

img要素のsrcおよびsrcsetは、（より小さいサイズがより大きい画像のスケールダウンバージョンとなる）画像サイズで変化するのみの複数の画像を提供するためにx記述子を用いて使用することができる。

画像のレンダリングサイズがビューポート幅に依存する場合（ビューポートベースの選択）、x記述子は適さないが、art directionと一緒に使用することができる。

<h2>From today's featured article</h2>
<img src="/uploads/100-marie-lloyd.jpg"
     srcset="/uploads/150-marie-lloyd.jpg 1.5x, /uploads/200-marie-lloyd.jpg 2x"
     alt="" width="100" height="150">
<p><b><a href="/wiki/Marie_Lloyd">Marie Lloyd</a></b> (1870–1922)
was an English <a href="/wiki/Music_hall">music hall</a> singer, ...

ユーザーエージェントは、ユーザーのスクリーンのピクセル密度、ズームレベルおよびユーザーのネットワーク状態のような可能性のあるその他の要素に依存する与えられたリソースのどれでも選択することができる。

srcset属性を解釈しない古いユーザーエージェントの後方互換性のために、URLの1つは、img要素のsrc属性で指定される。これは（ユーザーが好むよりももしかすると低い解像度だけれども）古いユーザーエージェントにおいてさえも表示されるという何かしら役に立つ結果になるだろう。新しいユーザーエージェントに対して、あたかも属性が1x記述子とともにsrcsetで指定されたかのように、src属性はリソース選択に参加する。

画像のレンダリングサイズは、画像がダウンロードされる前に画像に対する空間を割り当てることがユーザーエージェントにできるwidthおよびheight属性で与えられる。

ビューポートベースの選択

srcsetおよびsizesは、（より小さいサイズがより大きい画像のスケールダウンバージョンとなる）画像サイズで変化するのみの複数の画像を提供するためにw記述子を用いて使用することができる。

この例において、バナー画像は（適切なCSSを用いて）ビューポート幅全体を取る。

<h1><img sizes="100vw" srcset="wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w"
     src="wolf-400.jpg" alt="The rad wolf"></h1>

ユーザーエージェントは、指定されるw記述子およびsizes属性で指定されるレンダリングサイズから各画像の効果的なピクセル密度を算出するだろう。 ユーザーエージェントは、ユーザーのスクリーンのピクセル密度、ズームレベルおよびユーザーのネットワーク状態のような可能性のあるその他の要素に依存する与えられたリソースのどれでも選択することができる。

ユーザーのスクリーンが320 CSSピクセル幅である場合、これはwolf-400.jpg 1.25x, wolf-800.jpg 2.5x, wolf-1600.jpg 5xに指定するのと等価である。言い換えると、ユーザーのスクリーン1200 CSSピクセル幅である場合、これはwolf-400.jpg 0.33x, wolf-800.jpg 0.67x, wolf-1600.jpg 1.33xに指定するのと等価である。w記述子およびsizes属性を使用することによって、ユーザーエージェントはユーザーのデバイスの大きさにかかわらず、ダウンロードする正確な画像リソースを選択することができる。

後方互換性のために、URLの1つはimg要素のsrc属性で指定される。新しいユーザーエージェントにおいて、srcset属性がw記述子を使用する場合、src属性は無視される。

この例において、ウェブページはビューポートの幅に依存する3つのレイアウトを持つ。狭いレイアウトは1列目の画像（各画像の幅が約100%）、中程度のレイアウトは2列目の画像（各画像の幅が約50%）、広いレイアウトは3列目の画像（各画像の幅が約33%）、およびページマージンを持つ。ビューポートがそれぞれ幅30emおよび幅50emである場合、これらのレイアウトを壊す。

<img sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
     srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
     src="swing-400.jpg" alt="Kettlebell Swing">

sizes属性は、30emおよび50emでレイアウトのブレークポイントを設定し、これらブレークポイントの間で 100vw、50vwまたはcalc(33vw - 100px)に画像サイズを宣言する。これらサイズは、CSSで指定されたように実際の画像幅と厳密にマッチする必要が必然的にない。

ユーザーエージェントは、trueに評価する<media-condition>（丸括弧の一部）をもつ最初の項目を用いる、またはそれらがfalseにすべて評価する場合、最後の項目（calc(33vw - 100px)）を用いて、sizes属性から幅を選ぶだろう。

たとえば、ビューポート幅が29emである場合、(max-width: 30em)がtrueに評価し100vwが使用され結果として、リソース選択の目的で画像サイズは29emである。ビューポート幅が代わりに32emである場合、(max-width: 30em)はfalseに評価するが、(max-width: 50em)はtrueに評価し、50vwが使用され結果として、リソース選択の目的で画像のサイズは16em（ビューポート幅の半分）となる。異なるレイアウトのため、わずかにより幅の広いビューポートがより小さい画像をもたらすことに注目する。

ユーザーエージェントは、効果的なピクセル密度を選択し、前の例と似た適切なリソースを選択することができる。

この例は前の例と同じであるが、画像がlazy-loadedである点が異なる。この場合、sizes属性はautoキーワードを使用でき、ユーザーエージェントはsource sizeにwidth属性（またはCSSで指定された幅）を使用する。

<img loading="lazy" width="200" height="200" sizes="auto"
     srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
     src="swing-400.jpg" alt="Kettlebell Swing">

autoキーワードをサポートしていないレガシーユーザエージェントとの後方互換性を向上させるために、必要に応じてフォールバックサイズを指定できる。

<img loading="lazy" width="200" height="200"
     sizes="auto, (max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
     srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
     src="swing-400.jpg" alt="Kettlebell Swing">

Art direction-ベースの選択

media属性と共にpicture要素およびsource要素は、（たとえばより小さい画像がより大きい画像の収穫されたバージョンかもしれない）画像コンテンツを変化させる複数の画像を提供するために使用することができる。

<picture>
  <source media="(min-width: 45em)" srcset="large.jpg">
  <source media="(min-width: 32em)" srcset="med.jpg">
  <img src="small.jpg" alt="The wolf runs through the snow.">
</picture>

ユーザーエージェントがmedia属性におけるメディアクエリーがマッチする最初のsource要素を選択し、要素のsrcset属性から適切なURLを選択する。

画像のレンダリングサイズは、ソースが選択されるものに依存して変化する。ダウンロードされた画像を持つ前にユーザーエージェントが使用することができる次元を指定するために、CSSは使用することができる。

img { width: 300px; height: 300px }
@media (min-width: 32em) { img { width: 500px; height:300px } }
@media (min-width: 45em) { img { width: 700px; height:400px } }

この例は、art directionおよびデバイスピクセル比ベースの選択を組み合わせる。ビューポートの半分を取るバナーは、1つは広いスクリーンに対して、1つは狭いスクリーンに対しての、2つのバージョンで提供される。

<h1>
 <picture>
  <source media="(max-width: 500px)" srcset="banner-phone.jpeg, banner-phone-HD.jpeg 2x">
  <img src="banner.jpeg" srcset="banner-HD.jpeg 2x" alt="The Breakfast Combo">
 </picture>
</h1>

画像フォーマットベースの選択

source要素のtype属性は、異なるフォーマットで複数の画像を提供するために使用することができる。

<h2>From today's featured article</h2>
<picture>
 <source srcset="/uploads/100-marie-lloyd.webp" type="image/webp">
 <source srcset="/uploads/100-marie-lloyd.jxr" type="image/vnd.ms-photo">
 <img src="/uploads/100-marie-lloyd.jpg" alt="" width="100" height="150">
</picture>
<p><b><a href="/wiki/Marie_Lloyd">Marie Lloyd</a></b> (1870–1922)
was an English <a href="/wiki/Music_hall">music hall</a> singer, ...

この例において、ユーザーエージェントは、サポートされるMIMEタイプをもつtype属性を持つ最初のリソースを選択する。ユーザーエージェントがWebP画像をサポートする場合、最初のsource要素が選択される。WebP画像をサポートしないが、ユーザーエージェントがJPEG XR画像をサポートする場合、2つ目のsource要素が選択される。これらのフォーマットがいずれもサポートされない場合、img要素が選択される。

4.8.4.1.1 アダプティブ画像

この節は非規範的である。

CSSおよびメディアクエリーは、具体的には異なるビューポートの次元および画素密度で、ユーザーの環境に動的に適応するグラフィカルなページレイアウトを構築するために使用することができる。しかしコンテンツに対して、CSSは助けにならない。代わりに、img要素のsrcset属性およびpicture要素がある。この節は、この機能を使用する方法を示すサンプル例を渡り歩く。

（600 CSSピクセルより広い）大きな画面でa-rectangle.pngという名前の300×150の画像が使用される一方で、（600 CSSピクセルより小さい）小さな画面でa-square.pngという名前の100×100の画像が使用される状況を考えてみよう。この場合のマークアップは次のようになる：

<figure>
 <picture>
  <source srcset="a-square.png" media="(max-width: 600px)">
  <img src="a-rectangle.png" alt="Barney Frank wears a suit and glasses.">
 </picture>
 <figcaption>Barney Frank, 2011</figcaption>
</figure>

alt属性の中に入れるものの詳細については、画像の代替として機能するテキストを提供するための要件の節を参照のこと。

これに伴う問題は、ユーザーエージェントが、画像が読み込まれるときに画像に使用する次元が何か必ずしも分からないということである。ページが読み込まれる最中に、複数回のリフローさせるレイアウトを回避するために、CSSおよびCSSメディアクエリーは、次元を提供するために使用することができる：

<style>
 #a { width: 300px; height: 150px; }
 @media (max-width: 600px) { #a { width: 100px; height: 100px; } }
</style>
<figure>
 <picture>
  <source srcset="a-square.png" media="(max-width: 600px)">
  <img src="a-rectangle.png" alt="Barney Frank wears a suit and glasses." id="a">
 </picture>
 <figcaption>Barney Frank, 2011</figcaption>
</figure>

また、source要素およびimg要素でwidthおよびheight属性を使用して、幅および高さを指定することもできる

<figure>
 <picture>
  <source srcset="a-square.png" media="(max-width: 600px)" width="100" height="100">
  <img src="a-rectangle.png" width="300" height="150"
  alt="Barney Frank wears a suit and glasses.">
 </picture>
 <figcaption>Barney Frank, 2011</figcaption>
</figure>

img要素は、picture要素をサポートしないレガシーユーザーエージェントに使用するために画像のURLを与えるsrc属性とともに使用される。これは、src属性で提供するためにその画像の質問につながる。

著者がレガシーユーザーエージェントで最大の画像を希望する場合、マークアップは次のようになる：

<picture>
 <source srcset="pear-mobile.jpeg" media="(max-width: 720px)">
 <source srcset="pear-tablet.jpeg" media="(max-width: 1280px)">
 <img src="pear-desktop.jpeg" alt="The pear is juicy.">
</picture>

しかし、レガシーモバイルユーザーエージェントがより重要である場合、完全にsrc属性を上書きする、source要素にすべての3つの画像を一覧表示することができる。

<picture>
 <source srcset="pear-mobile.jpeg" media="(max-width: 720px)">
 <source srcset="pear-tablet.jpeg" media="(max-width: 1280px)">
 <source srcset="pear-desktop.jpeg">
 <img src="pear-mobile.jpeg" alt="The pear is juicy.">
</picture>

この時点で、実際にsrc属性はpictureをサポートするユーザーエージェントによって完全に無視されるため、src属性は最小でも最大でもないものを含む、任意の画像をデフォルトにすることができる：

<picture>
 <source srcset="pear-mobile.jpeg" media="(max-width: 720px)">
 <source srcset="pear-tablet.jpeg" media="(max-width: 1280px)">
 <source srcset="pear-desktop.jpeg">
 <img src="pear-tablet.jpeg" alt="The pear is juicy.">
</picture>

max-widthメディア機能が使用される上記は、画像が意図される最大（ビューポート）次元を与える。代わりにmin-widthを使用することも可能である。

<picture>
 <source srcset="pear-desktop.jpeg" media="(min-width: 1281px)">
 <source srcset="pear-tablet.jpeg" media="(min-width: 721px)">
 <img src="pear-mobile.jpeg" alt="The pear is juicy.">
</picture>

4.8.4.2 source、imgおよびlink 要素の共通属性

4.8.4.2.1 srcset共通属性

srcset属性は、この節で定義された要件をもつ属性である。

属性が存在する場合、属性値は、U+002C COMMA文字（,）でそれぞれ分離される1つ以上の画像候補文字列から成らなければならない。画像候補文字列が記述子およびURLの後にASCII空白文字を一切含まない場合、次の画像候補文字列が存在するとき、1つ以上のASCII空白文字で開始しなければならない。

同じ要素に対して別の画像候補文字列の幅記述子値と同じ幅記述子値を持つ要素に対する画像候補文字列が存在してはならない。

同じ要素に対して別の画像候補文字列のピクセル密度記述子値と同じピクセル密度記述子値を持つ要素に対する画像候補文字列が存在してはならない。この要求の目的のために、記述子をもたない画像候補文字列は、1x記述子をもつ画像候補文字列と等価である。

要素に対する画像候補文字列が幅記述子を指定させる場合、その要素に対するすべての他の画像候補文字列も幅記述子を指定させなければならない。

画像候補文字列の幅記述子における指定される幅は、リソースが自然幅を持つ場合、画像候補文字列のURLによって指定されるリソースにおける自然幅にマッチしなければならない。

要素が存在するsizes属性を持つ場合、その要素に対するすべての画像候補文字列は幅記述子を指定させなければならない。

4.8.4.2.2 size属性

sizes属性は、この節で定義された要件をもつ属性である。

存在する場合、値は妥当なソースサイズのリストでなければならない。

<source-size-list> = <source-size>#? , <source-size-value>
<source-size> = <media-condition> <source-size-value> | auto
<source-size-value> = <length> | auto

キーワードautoは、 parse width attributeで計算される幅である。存在する場合、これは最初のエントリーでなければならず、値<source-size-list>全体は文字列"auto"（ASCII大文字・小文字不区別）である、または文字列"auto,"（ASCII大文字・小文字不区別）で始まらなければならない。

画像の読み込みを開始したimg要素（画像データの更新またはその要素の環境変化への対応アルゴリズムとともに）が自動サイズを許可し、かつレンダリングされている場合、 autoは実際のオブジェクト幅である。そうでなければ、 auto値は無視され、代わりに次のsource sizeが使用される（存在する場合）。

autoキーワードは、次の条件が満たされる場合、source要素のsizes属性およびimg要素のsizes属性に指定してもよい。そうでなければ、autoを指定してはならない。

• 要素は、後続の兄弟img 要素をもつsourceである。

• 要素はimgである。

• 上記のいずれかの条件で参照されるimg要素は、 自動サイズを可能にする。

さらに、widthおよびheight属性またはCSSで次元を指定することを強く勧める。サイズが指定されていない場合、画像は300×150の次元でレンダリングされる可能性がある。これは、sizes="auto" がcontain-intrinsic-size: 300px 150pxをレンダリングセクションで暗黙に指定しているためである。

<source-size-value>は、画像の意図するレイアウト幅を与える。著者は、<media-condition>をもつ異なる環境に対して異なる幅を指定してもよい。

何に相対するかについての混乱を避けるため、パーセンテージは<source-size-value>で許可されない。'vw'単位は、viewport幅に相対的な大きさに対して使用することができる。

4.8.4.3 Processing model

An img element has a current request and a pending request. The current request is initially set to a new image request. The pending request is initially set to null.

An image request has a state, current URL, and image data.

An image request's state is one of the following:

Unavailable

The user agent hasn't obtained any image data, or has obtained some or all of the image data but hasn't yet decoded enough of the image to get the image dimensions.

Partially available

The user agent has obtained some of the image data and at least the image dimensions are available.

Completely available

The user agent has obtained all of the image data and at least the image dimensions are available.

Broken

The user agent has obtained all of the image data that it can, but it cannot even decode the image enough to get the image dimensions (e.g. the image is corrupted, or the format is not supported, or no data could be obtained).

An image request's current URL is initially the empty string.

An image request's image data is the decoded image data.

An image request's state is initially unavailable.

When an img element's current request is available, the img element provides a paint source whose width is the image's density-corrected natural width (if any), whose height is the image's density-corrected natural height (if any), and whose appearance is the natural appearance of the image.

Each img element has a last selected source, which must initially be null.

Each image request has a current pixel density, which must initially be 1.

Each image request has preferred density-corrected dimensions, which is either a struct consisting of a width and a height or is null. It must initially be null.

For example, if the current pixel density is 3.125, that means that there are 300 device pixels per CSS inch, and thus if the image data is 300x600, it has density-corrected natural width and height of 96 CSS pixels by 192 CSS pixels.

All img and link elements are associated with a source set.

A source set is an ordered set of zero or more image sources and a source size.

An image source is a URL, and optionally either a pixel density descriptor, or a width descriptor.

A source size is a <source-size-value>. When a source size has a unit relative to the viewport, it must be interpreted relative to the img element's node document's viewport. Other units must be interpreted the same as in Media Queries. [MQ]

A parse error for algorithms in this section indicates a non-fatal mismatch between input and requirements. User agents are encouraged to expose parse errors somehow.

Whether the image is fetched successfully or not (e.g. whether the response status was an ok status) must be ignored when determining the image's type and whether it is a valid image.

This allows servers to return images with error responses, and have them displayed.

The user agent should apply the image sniffing rules to determine the type of the image, with the image's associated Content-Type headers giving the official type. If these rules are not applied, then the type of the image must be the type given by the image's associated Content-Type headers.

User agents must not support non-image resources with the img element (e.g. XML files whose document element is an HTML element). User agents must not run executable code (e.g. scripts) embedded in the image resource. User agents must only display the first page of a multipage resource (e.g. a PDF file). User agents must not allow the resource to act in an interactive fashion, but should honour any animation in the resource.

This specification does not specify which image types are to be supported.

4.8.4.3.1 When to obtain images

By default, images are obtained immediately. User agents may provide users with the option to instead obtain them on-demand. (The on-demand option might be used by bandwidth-constrained users, for example.)

4.8.4.3.2 Reacting to DOM mutations

4.8.4.3.3 The list of available images

Each Document object must have a list of available images. Each image in this list is identified by a tuple consisting of an absolute URL, a CORS settings attribute mode, and, if the mode is not No CORS, an origin. Each image furthermore has an ignore higher-layer caching flag. User agents may copy entries from one Document object's list of available images to another at any time (e.g. when the Document is created, user agents can add to it all the images that are loaded in other Documents), but must not change the keys of entries copied in this way when doing so, and must unset the ignore higher-layer caching flag for the copied entry. User agents may also remove images from such lists at any time (e.g. to save memory). User agents must remove entries in the list of available images as appropriate given higher-layer caching semantics for the resource (e.g. the HTTP `Cache-Control` response header) when the ignore higher-layer caching flag is unset.

The list of available images is intended to enable synchronous switching when changing the src attribute to a URL that has previously been loaded, and to avoid re-downloading images in the same document even when they don't allow caching per HTTP. It is not used to avoid re-downloading the same image while the previous image is still loading.

The user agent can also store the image data separately from the list of available images.

For example, if a resource has the HTTP response header `Cache-Control: must-revalidate`, and its ignore higher-layer caching flag is unset, the user agent would remove it from the list of available images but could keep the image data separately, and use that if the server responds with a 304 Not Modified status.

4.8.4.3.4 Decoding images

Image data is usually encoded in order to reduce file size. This means that in order for the user agent to present the image to the screen, the data needs to be decoded. Decoding is the process which converts an image's media data into a bitmap form, suitable for presentation to the screen. Note that this process can be slow relative to other processes involved in presenting content. Thus, the user agent can choose when to perform decoding, in order to create the best user experience.

Image decoding is said to be synchronous if it prevents presentation of other content until it is finished. Typically, this has an effect of atomically presenting the image and any other content at the same time. However, this presentation is delayed by the amount of time it takes to perform the decode.

Image decoding is said to be asynchronous if it does not prevent presentation of other content. This has an effect of presenting non-image content faster. However, the image content is missing on screen until the decode finishes. Once the decode is finished, the screen is updated with the image.

In both synchronous and asynchronous decoding modes, the final content is presented to screen after the same amount of time has elapsed. The main difference is whether the user agent presents non-image content ahead of presenting the final content.

In order to aid the user agent in deciding whether to perform synchronous or asynchronous decode, the decoding attribute can be set on img elements. The possible values of the decoding attribute are the following image decoding hint keywords:

When decoding an image, the user agent should respect the preference indicated by the decoding attribute's state. If the state indicated is Auto, then the user agent is free to choose any decoding behavior.

It is also possible to control the decoding behavior using the decode() method. Since the decode() method performs decoding independently from the process responsible for presenting content to screen, it is unaffected by the decoding attribute.

4.8.4.3.5 Updating the image data

This algorithm cannot be called from steps running in parallel. If a user agent needs to call this algorithm from steps running in parallel, it needs to queue a task to do so.

4.8.4.3.6 Preparing an image for presentation

Resolution in EXIF is equivalent to CSS points per inch, therefore 72 is the base for computing size from resolution.

It is not yet specified what would be the case if EXIF arrives after the image is already presented. See issue #4929.

4.8.4.3.7 Selecting an image source

4.8.4.3.8 Creating a source set from attributes

4.8.4.3.9 Updating the source set

Each img element independently considers its previous sibling source elements plus the img element itself for selecting an image source, ignoring any other (invalid) elements, including other img elements in the same picture element, or source elements that are following siblings of the relevant img element.

4.8.4.3.10 Parsing a srcset attribute

4.8.4.3.11 Parsing a sizes attribute

It is invalid to use a bare <source-size-value> that is a <length> (without an accompanying <media-condition>) as an entry in the <source-size-list> that is not the last entry. However, the parsing algorithm allows it at any point in the <source-size-list>, and will accept it immediately as the size if the preceding entries in the list weren't used. This is to enable future extensions, and protect against simple author errors such as a final trailing comma. A bare auto keyword is allowed to have other entries following it to provide a fallback for legacy user agents.

4.8.4.3.12 Normalizing the source densities

An image source can have a pixel density descriptor, a width descriptor, or no descriptor at all accompanying its URL. Normalizing a source set gives every image source a pixel density descriptor.

4.8.4.3.13 Reacting to environment changes

4.8.4.4 画像に対して代替として動作するテキストを提供に対する要件

4.8.4.4.1 一般的なガイドライン

特に指定されている場合を除き、alt属性を指定しなければならず、その値は空であってはならない。値は画像に対して適切な代用品でなければならない。alt属性に対する具体的な要件は、次の節で説明するように、画像が表現しようとするものによって異なる。

代替テキストを記述する場合に考慮すべき最も一般的な規則は次のとおりである：すべての画像をその画像のalt属性のテキストと置換してもページの意味を変えないことを意図する。

よって、一般に、代替テキストは、もし画像を含めることができなかったならば、何が書かれていただろうかを考慮することで記述することができる。

この帰結は、alt属性の値が画像のキャプション、タイトル、凡例とみなすことができるテキストを含めるべきではないということである。ユーザーが画像の代わりに使用できる代用テキストを含むはずである。画像を補完することを意図しない。title属性は、補足情報のために使用することができる。

もう1つの帰結は、alt属性の値は既に画像隣接する文で提供される情報を繰り返すべきではないということである。

代替テキストを考える1つの方法は、画像の存在があることを言及することなく、電話で誰かに画像を含むページをどのように読むかを考えることである。通常、画像の代わりにいうものは何でも、代替テキストを記述するための良いスタートである。

4.8.4.4.2 画像のみを含むリンクまたはボタン

ハイパーリンクを作成するa要素、またはbutton要素が、テキストコンテンツを持たないが1つ以上の画像を含む場合、alt属性はリンクまたはボタンの目的を併せて伝えるテキストを含まなければならない。

<h1>Pick your color</h1>
<ul>
 <li><a href="green.html"><img src="green.jpeg" alt="Green"></a></li>
 <li><a href="blue.html"><img src="blue.jpeg" alt="Blue"></a></li>
 <li><a href="red.html"><img src="red.jpeg" alt="Red"></a></li>
</ul>

<button name="rgb"><img src="red" alt="RGB"><img src="green" alt=""><img src="blue" alt=""></button>
<button name="cmyk"><img src="cyan" alt="CMYK"><img src="magenta" alt=""><img src="yellow" alt=""><img src="black" alt=""></button>

<button name="rgb"><img src="red" alt="R"><img src="green" alt="G"><img src="blue" alt="B"></button>
<button name="cmyk"><img src="cyan" alt="C"><img src="magenta" alt="M"><img src="yellow" alt="Y"><img src="black" alt="K"></button>

<button name="rgb"><img src="red" alt="sRGB profile"><img src="green" alt=""><img src="blue" alt=""></button>
<button name="cmyk"><img src="cyan" alt="CMYK profile"><img src="magenta" alt=""><img src="yellow" alt=""><img src="black" alt=""></button>

4.8.4.4.3 代替グラフィカル表現をもつフレーズまたは段落：チャート、図、グラフ、マップ、イラスト

たとえばフローチャート、図、グラフ、または道順を示す簡単な地図など、意味ある物を視覚的な形式で時により明確に記述することができる。そのような場合、画像はimg要素を使って指定することができるが、より少ないテキスト版が依然として与えられなければならず、そのため画像を表示できない（たとえば、非常に低速な接続である、またはテキストのみのブラウザーを使用している、またはハンズフリーの自動車用音声ウェブブラウザーによって読み出されているページを聞いている、または単に目が見えないため）ユーザーは依然としてメッセージが搬送されて理解できる。

テキストはalt属性で指定されなければならず、かつsrc属性で指定される画像と同じメッセージを伝えなければならない。

代替テキストが画像の説明でなく、画像の代用品であることを認識することが重要である。

<p>In the common case, the data handled by the tokenization stage
comes from the network, but it can also come from script.</p>
<p><img src="images/parsing-model-overview.svg" alt="The Network
passes data to the Input Stream Preprocessor, which passes it to the
Tokenizer, which passes it to the Tree Construction stage. From there,
data goes to both the DOM and to Script Execution. Script Execution is
linked to the DOM, and, using document.write(), passes data to the
Tokenizer."></p>

<!-- This is the correct way to do things. -->
<p>
 You are standing in an open field west of a house.
 <img src="house.jpeg" alt="The house is white, with a boarded front door.">
 There is a small mailbox here.
</p>

<!-- This is the wrong way to do things. -->
<p>
 You are standing in an open field west of a house.
 <img src="house.jpeg" alt="A white house, with a boarded front door.">
 There is a small mailbox here.
</p>

4.8.4.4.4 代替グラフィカル表現をもつ短いフレーズまたはラベル：アイコン、ロゴ

文書は、アイコン形式で情報を含むことができる。アイコンは、視覚ブラウザーのユーザーに一目で機能を認識するのを助けることを意図する。

ある場合、アイコンは同じ意味を伝えるテキストラベルを補足する。これらの場合において、alt属性は存在しなければならないが、空でなければならない。

<nav>
 <p><a href="/help/"><img src="/icons/help.png" alt=""> Help</a></p>
 <p><a href="/configure/"><img src="/icons/configuration.png" alt="">
 Configuration Tools</a></p>
</nav>

他の場合において、アイコンは何かを意味する記述をもつ横のテキストを持たない。アイコンは自明であると仮定される。この場合において、同等のテキストラベルはalt属性で指定しなければならない。

<body>
 <article>
  <header>
   <h1>Ratatouille wins <i>Best Movie of the Year</i> award</h1>
   <p><img src="movies.png" alt="Movies"></p>
  </header>
  <p>Pixar has won yet another <i>Best Movie of the Year</i> award,
  making this its 8th win in the last 12 years.</p>
 </article>
 <article>
  <header>
   <h1>Latest TWiT episode is online</h1>
   <p><img src="podcasts.png" alt="Podcasts"></p>
  </header>
  <p>The latest TWiT episode has been posted, in which we hear
  several tech news stories as well as learning much more about the
  iPhone. This week, the panelists compare how reflective their
  iPhones' Apple logos are.</p>
 </article>
</body>

多くのページは、会社、組織、プロジェクト、バンド、ソフトウェアパッケージ、国、またはその他団体を表すロゴ、記号、旗、またはエンブレムを含む。

たとえばページの見出しのように、ロゴが団体を表すために使用されている場合、alt属性はロゴによって表されるその団体の名前を含まなければならない。alt属性は、伝えられているロゴであるという事実はないので、単語"ロゴ"のようなテキストを含んではならない。団体そのものである。

ロゴが表すものの名前の横にロゴが使用される場合、そのロゴは補足であり、そのalt属性は空でなければならない。

ロゴが単なる装飾材料（ブランディングとして、たとえば、ロゴが所属する実体を言及する記事でサイドイメージ）として使用される場合、純粋に装飾的な画像で下記のエントリーが適用される。ロゴが実際に議論されている場合、それは代替グラフィック表現（ロゴ自体）、および適用される上記の最初のエントリーを持つ語句や段落（ロゴの説明）として使用されている。

<h1><img src="XYZ.gif" alt="The XYZ company"></h1>

<article>
 <h2>News</h2>
 <p>We have recently been looking at buying the <img src="alpha.gif"
 alt=""> ΑΒΓ company, a small Greek company
 specializing in our type of product.</p>

<aside><p><img src="alpha-large.gif" alt=""></p></aside>
 <p>The ΑΒΓ company has had a good quarter, and our
 pie chart studies of their accounts suggest a much bigger blue slice
 than its green and orange slices, which is always a good sign.</p>
</article>

<p>Consider for a moment their logo:</p>

<p><img src="/images/logo" alt="It consists of a green circle with a
green question mark centered inside it."></p>

<p>How unoriginal can you get? I mean, oooooh, a question mark, how
<em>revolutionary</em>, how utterly <em>ground-breaking</em>, I'm
sure everyone will rush to adopt those specifications now! They could
at least have tried for some sort of, I don't know, sequence of
rounded squares with varying shades of green and bold white outlines,
at least that would look good on the cover of a blue book.</p>

4.8.4.4.5 印刷効果のためにグラフィックにレンダリングされたテキスト

時に、画像がテキストだけで構成されており、画像の目的が、テキストをレンダリングするために使用される実際の印刷効果を強調するだけでなく、単にテキスト自体を伝えるもの。

このような場合、alt属性が存在しなければならないが、画像自身に書かれたものと同じテキストで構成されなければならない。

<h1><img src="earthdayheading.png" alt="Earth Day"></h1>

<p><img src="initials/o.svg" alt="O">nce upon a time and a long long time ago, late at
night, when it was dark, over the hills, through the woods, across a great ocean, in a land far
away, in a small house, on a hill, under a full moon...

画像がUnicodeで表現できない文字を表すために別の方法で使用される場合、たとえば外字、異体字、または新規の通貨記号のような新しい文字において、テキストによる代替は、たとえば、文字の発音を与えるために表音のひらがなやカタカナを使用するなど、同じものを記述するより伝統的な方法であるべきである。

<p>Only <img src="euro.png" alt="euro ">5.99!

文字が同じ目的を果たすならば画像を使用すべきでない。たとえば装飾のため、または適切な文字がないため（外字の場合のように）など、テキストをテキストで直接表現することができない場合にのみ、画像が適切だろう。

デフォルトのシステムフォントが指定された文字をサポートしないため、著者が画像を使用するように誘惑される場合、ウェブフォントは画像よりも優れた解決策である。

4.8.4.4.6 周囲のテキストの一部をグラフィカルに表現

多くの場合、画像は実際には単なる補足であり、その存在は単に周囲のテキストを強調するだけである。この場合、alt属性が存在しなければならないが、その値は空文字列でなければならない。

一般に画像は、画像を削除してもページの有用性が弱まるわけでない場合にこのカテゴリーに分類されるが、画像を含めることは、視覚ブラウザーのユーザーにとって概念を理解することがはるかに容易になる。

<p>The Network passes data to the Input Stream Preprocessor, which
passes it to the Tokenizer, which passes it to the Tree Construction
stage. From there, data goes to both the DOM and to Script Execution.
Script Execution is linked to the DOM, and, using document.write(),
passes data to the Tokenizer.</p>
<p><img src="images/parsing-model-overview.svg" alt=""></p>

<!-- Using the title="" attribute -->
<p>The Network passes data to the Input Stream Preprocessor, which
passes it to the Tokenizer, which passes it to the Tree Construction
stage. From there, data goes to both the DOM and to Script Execution.
Script Execution is linked to the DOM, and, using document.write(),
passes data to the Tokenizer.</p>
<p><img src="images/parsing-model-overview.svg" alt=""
        title="Flowchart representation of the parsing model."></p>

<!-- Using <figure> and <figcaption> -->
<p>The Network passes data to the Input Stream Preprocessor, which
passes it to the Tokenizer, which passes it to the Tree Construction
stage. From there, data goes to both the DOM and to Script Execution.
Script Execution is linked to the DOM, and, using document.write(),
passes data to the Tokenizer.</p>
<figure>
 <img src="images/parsing-model-overview.svg" alt="The Network leads to
 the Input Stream Preprocessor, which leads to the Tokenizer, which
 leads to the Tree Construction stage. The Tree Construction stage
 leads to two items. The first is Script Execution, which leads via
 document.write() back to the Tokenizer. The second item from which
 Tree Construction leads is the DOM. The DOM is related to the Script
 Execution.">
 <figcaption>Flowchart representation of the parsing model.</figcaption>
</figure>

<!-- This is WRONG. Do not do this. Instead, do what the above examples do. -->
<p>The Network passes data to the Input Stream Preprocessor, which
passes it to the Tokenizer, which passes it to the Tree Construction
stage. From there, data goes to both the DOM and to Script Execution.
Script Execution is linked to the DOM, and, using document.write(),
passes data to the Tokenizer.</p>
<p><img src="images/parsing-model-overview.svg"
        alt="Flowchart representation of the parsing model."></p>
<!-- Never put the image's caption in the alt="" attribute! -->

<p>According to a study covering several billion pages,
about 62% of documents on the web in 2007 triggered the Quirks
rendering mode of web browsers, about 30% triggered the Almost
Standards mode, and about 9% triggered the Standards mode.</p>
<p><img src="rendering-mode-pie-chart.png" alt=""></p>

4.8.4.4.7 補助画像

時には、画像はコンテンツに重要ではないが、それにもかかわらず、純粋に装飾的でもテキストと完全に冗長でもないことがある。この場合、alt属性は存在しなければならず、かつその値は空の文字列、または画像が伝える情報のテキスト表現のいずれかであるべきである。画像が画像のタイトルを与えるキャプションを持つ場合、（非視覚読者に相当な混乱を与えることになるので）alt属性の値は空であってはならない。

<p><img src="president.jpeg" alt=""> Ahead of today's referendum,
the President wrote an open letter to all registered voters. In it, she admitted that the country was
divided.</p>

<p><img src="president.jpeg" alt="The President is sad.">
Ahead of today's referendum, the President wrote an open letter to all
registered voters. In it, she admitted that the country was divided.
</p>

<p><img src="president.jpeg" alt="The President is happy!">
Ahead of today's referendum, the President wrote an open letter to all
registered voters. In it, she admitted that the country was divided.
</p>

<p>Ahead of today's referendum, the President wrote an open letter to
all registered voters. In it, she admitted that the country was divided.</p>
<figure>
 <img src="president.jpeg"
      alt="A high forehead, cheerful disposition, and dark hair round out the President's face.">
 <figcaption> The President of Ruritania. Photo © 2014 PolitiPhoto. </figcaption>
</figure>

4.8.4.4.8 情報を追加しない、純粋に装飾的な画像

画像が装飾的であるが特にページ固有でない場合―たとえばサイト全体のデザインスキームの一部を形成する画像のような―画像は、文書のマークアップでなく、サイトのCSSで指定すべきである。

しかし、周囲のテキストで議論されないが、依然として一部の関連性を持つ装飾的な画像はimg要素を使用して、ページに含めることが可能である。そのような画像は装飾的であるが、依然としてコンテンツの一部に由来する。この場合、alt属性が存在しなければならないが、その値は空文字列でなければならない。

<h1>The Lady of Shalott</h1>
<p><img src="shalott.jpeg" alt=""></p>
<p>On either side the river lie<br>
Long fields of barley and of rye,<br>
That clothe the wold and meet the sky;<br>
And through the field the road run by<br>
To many-tower'd Camelot;<br>
And up and down the people go,<br>
Gazing where the lilies blow<br>
Round an island there below,<br>
The island of Shalott.</p>

4.8.4.4.9 リンクのない単一の大きな画像を形成する画像のグループ

画像が小さな画像ファイルに分割されている場合、再度完全な画像を形成するために共に表示され、画像の1つは、全体としての絵に適するだろう関連規則に従って設定されたalt属性を持たなければならず、残りのすべての画像は、空のalt属性を持たなければならない。

<h1><img src="logo1.png" alt="XYZ Corp"><img src="logo2.png" alt=""></h1>

<p>Rating: <meter max=5 value=3><img src="1" alt="3 out of 5"
  ><img src="1" alt=""><img src="1" alt=""><img src="0" alt=""
  ><img src="0" alt=""></meter></p>

4.8.4.4.10 リンクのある単一の大きな画像を形成する画像のグループ

一般にイメージマップは、リンク用の画像をスライスする代わりに使用されるべきである。

画像が確かにスライスされ、スライスされた画像のコンポーネントのいずれかがリンクの唯一のコンテンツである場合、リンクあたりの1つの画像は、リンクの目的を表すalt属性で代替テキストを持たなければならない。

<h1>The Church</h1>
<p>You come across a flying spaghetti monster. Which side of His
Noodliness do you wish to reach out for?</p>
<p><a href="?go=left" ><img src="fsm-left.png"  alt="Left side. "></a
  ><img src="fsm-middle.png" alt=""
  ><a href="?go=right"><img src="fsm-right.png" alt="Right side."></a></p>

4.8.4.4.11 コンテンツのキーパート

場合によっては、画像はコンテンツの重要な部分である。たとえば、これは、フォトギャラリーの一部であるページに当てはまるかもしれない。画像はその画像を含むページの全体の要点である。

コンテンツの重要な部分である画像の代替テキストを提供する方法は、画像の出所に依存する。

一般的な場合

提供される詳細な代替テキストで可能な場合、たとえば、画像が雑誌のレビューでの一連のスクリーンショットや、漫画の一部、またはその写真に関するブログエントリーでの写真である場合、画像に対して適切に提供されるようなテキストがalt属性のコンテンツとして指定されなければならない。

代替テキストを伴う、新しいOSについてのギャラリーでのスクリーンショット：

<figure>
 <img src="KDE%20Light%20desktop.png"
      alt="The desktop is blue, with icons along the left hand side in
           two columns, reading System, Home, K-Mail, etc. A window is
           open showing that menus wrap to a second line if they
           cannot fit in the window. The window has a list of icons
           along the top, with an address bar below it, a list of
           icons for tabs along the left edge, a status bar on the
           bottom, and two panes in the middle. The desktop has a bar
           at the bottom of the screen with a few buttons, a pager, a
           list of open applications, and a clock.">
 <figcaption>Screenshot of a KDE desktop.</figcaption>
</figure>

財務レポートのグラフ：

<img src="sales.gif"
     title="Sales graph"
     alt="From 1998 to 2005, sales increased by the following percentages
     with each year: 624%, 75%, 138%, 40%, 35%, 9%, 21%">

"sales graph"は、売り上げグラフに対する代替テキストとして不十分であることに注意する。良いキャプションとされるテキストは、一般に置換テキストとしては適さない。

完全な記述を無視する画像

ある場合において、画像の性質は、徹底した代替テキストを提供することが現実的ではないかもしれない。たとえば、画像は不鮮明であったり、複雑なフラクタルかもしれず、詳細な地形図であるかもしれない。

この場合、alt属性は、適切な代替テキストが含まれなければならないが、それはやや短いかもしれない。

単に画像を正しく扱うことのできるテキストが存在しないのである。たとえば、ロールシャッハ・インクブロットテストを記述するための有用な言及はほとんどない。しかし、短い説明であっても、まだ何もないよりましである：

<figure>
 <img src="/commons/a/a7/Rorschach1.jpg" alt="A shape with left-right
 symmetry with indistinct edges, with a small gap in the center, two
 larger gaps offset slightly from the center, with two similar gaps
 under them. The outline is wider in the top half than the bottom
 half, with the sides extending upwards higher than the center, and
 the center extending below the sides.">
 <figcaption>A black outline of the first of the ten cards
 in the Rorschach inkblot test.</figcaption>
</figure>

以下は、代替テキストの非常に悪い用法であろうことに注意する：

<!-- This example is wrong. Do not copy it. -->
<figure>
 <img src="/commons/a/a7/Rorschach1.jpg" alt="A black outline
 of the first of the ten cards in the Rorschach inkblot test.">
 <figcaption>A black outline of the first of the ten cards
 in the Rorschach inkblot test.</figcaption>
</figure>

このような代替テキストのキャプションを含むことは、実用的でない。なぜなら、一度でもキャプションを読んだり聞いたことがあった場合、2回以上助けず、画像を持たないユーザーに対してキャプションを効果的に重複するためである。

完全な説明を覆す画像の別の例は、定義により、詳細で無限であるフラクタルである。

次の例は、マンデルブロ集合の画像の完全なビューの代替テキストを提供する1つの可能な方法を示す。

<img src="ms1.jpeg" alt="The Mandelbrot set appears as a cardioid with
its cusp on the real axis in the positive direction, with a smaller
bulb aligned along the same center line, touching it in the negative
direction, and with these two shapes being surrounded by smaller bulbs
of various sizes.">

同様に、人の顔の写真は、たとえば伝記において、コンテンツにかなり関連し、コンテンツの鍵と考えることができるが、テキストを完全に代替するのは困難である：

<section class="bio">
 <h1>A Biography of Isaac Asimov</h1>
 <p>Born <b>Isaak Yudovich Ozimov</b> in 1920, Isaac was a prolific author.</p>
 <p><img src="headpics/asimov.jpeg" alt="Isaac Asimov had dark hair, a tall forehead, and wore glasses.
 Later in life, he wore long white sideburns."></p>
 <p>Asimov was born in Russia, and moved to the US when he was three years old.</p>
 <p>...</p>
</section>

そのような場合、そのようなテキストは、画像の存在を報告するブラウザー自体に冗長になるため、代替テキストで画像自体の存在への参照を含むことは不必要である（実際に推奨されない）。たとえば、代替テキストが"アイザック・アシモフの写真"であった場合、適合するユーザーエージェントはより有用な"（画像）アイザック・アシモフは黒い髪、長い額で、眼鏡をかけ..."よりもむしろ"（画像）アイザック・アシモフの写真"として読み上げるかもしれない。

コンテンツが未知である画像

画像が任意の関連する代替テキストのない一部の自動化された方法で得られる（たとえばウェブカメラなど）、またはページが、ユーザーが適切なまたは有用な代替テキストを提供できない場所でのユーザーが提供する画像を使用するスクリプトによって生成されている（たとえば写真共有サイト）、または著者自身が、画像が何を表すのかを知らない（たとえばブログで画像を共有する視覚障害者の写真家）のいずれかなどの、一部の不幸な例において、使用可能な代替テキストがまったく存在しないかもしれない。

そのような場合、alt属性を省略してもよいが、次のいずれかの条件をさらに満たさなければならない：

• img要素は、figcaption要素とその子孫を無視して、要素間の空白文字以外のコンテンツを含むfigcaption要素を含むfigure要素であり、figure要素は、要素間の空白文字およびimg要素以外のフローコンテンツ子孫を持たない。

• title属性が存在しかつ空でない値を持つ。

  title属性に依存することは、多くのユーザーエージェントがこの仕様で要求されるようなアクセス可能な方法で属性を公開しないため、現在推奨されない（たとえば、ツールチップを出現させるマウスなどのポインティングデバイスが必要になり、これはモダンな携帯端末やタブレットをもつ人のような、キーボードのみのユーザーとタッチのみのユーザーを締め出す）。

そのような場合は最小限に保たれるべきである。実際の代替テキストを提供する能力を有する著者のわずかな可能性がある場合、alt属性の省略を許容しないだろう。

サイトがキャプション以外のメタデータを用いて画像を受信した場合、写真共有サイトの写真は、次のようにマークアップできる：

<figure>
 <img src="1100670787_6a7c664aef.jpg">
 <figcaption>Bubbles traveled everywhere with us.</figcaption>
</figure>

しかし、画像の重要部分の詳細な説明が、ユーザーから取得してページに含まれる場合、これはより良いだろう。

ユーザーが撮影した写真での視覚障害者ユーザーのブログを示す。最初に、ユーザーはショーを撮った写真の任意のアイデアを持たないかもしれない：

<article>
 <h1>I took a photo</h1>
 <p>I went out today and took a photo!</p>
 <figure>
  <img src="photo2.jpeg">
  <figcaption>A photograph taken blindly from my front porch.</figcaption>
 </figure>
</article>

しかし最終的に、ユーザーは友人による画像の説明を取得するかもしれず、その場合代替テキストを含めることができる：

<article>
 <h1>I took a photo</h1>
 <p>I went out today and took a photo!</p>
 <figure>
  <img src="photo2.jpeg" alt="The photograph shows my squirrel
  feeder hanging from the edge of my roof. It is half full, but there
  are no squirrels around. In the background, out-of-focus trees fill the
  shot. The feeder is made of wood with a metal grate, and it contains
  peanuts. The edge of the roof is wooden too, and is painted white
  with light blue streaks.">
  <figcaption>A photograph taken blindly from my front porch.</figcaption>
 </figure>
</article>

時として画像全体の要点は、テキストの説明が利用できず、ユーザーが説明を提供する。たとえば、CAPTCHA画像のポイントは、ユーザーが文字通りグラフィックを読むことができるかどうかを確認することにある。これはCAPTCHAをマークアップする1つの方法である（title属性に注目する）：

<p><label>What does this image say?
<img src="captcha.cgi?id=8934" title="CAPTCHA">
<input type=text name=captcha></label>
(If you cannot see the image, you can use an <a
href="?audio">audio</a> test instead.)</p>

もう1つの例は、画像を表示し、正しい代替テキストをもつページを書く目的に対して正確に代替テキストを求めるソフトウェアである。そのようなページは次のように、画像のテーブルを持つことができる：

<table>
 <thead>
  <tr> <th> Image <th> Description
 <tbody>
  <tr>
   <td> <img src="2421.png" title="Image 640 by 100, filename 'banner.gif'">
   <td> <input name="alt2421">
  <tr>
   <td> <img src="2422.png" title="Image 200 by 480, filename 'ad3.gif'">
   <td> <input name="alt2422">
</table>

この例ですら、できる限り多くの有用な情報が依然としてtitle属性に含まれることに注意する。

一部のユーザーは、まったく画像を使用できない（たとえば、非常に低速な接続である、テキストのみのブラウザーを使用している、ハンズフリーの自動車声ウェブブラウザーで読みあげてページを聞いている、または単に目が見えない）ので、alt属性は省略することが許可されるよりむしろ、上記の例のようにまったく代替テキストが利用できず、何も利用できない場合に、置換テキストを備えるのである。著者の一部による努力の欠如は、alt属性を省略するための許容可能な理由でない。

4.8.4.4.12 ユーザーを意図しない画像

一般に、著者は画像を表示する以外の目的でimg要素を使用することは避けるべきである。

img要素が画像を表示する以外の目的で使用されている場合、たとえば、ページビューをカウントするサービスの一部として用いる場合、alt属性は空文字列でなければならない。

このような場合、widthとheight属性は、両方とも0に設定すべきである。

4.8.4.4.13 画像を閲覧できることが知られている特定の人のために意図された電子メールまたは私的文書における画像

この節は、公にアクセス可能な、すなわち、ウェブサイト上の文書、公開メーリングリストに送信された電子メール、またはソフトウェアのドキュメントなど、対象となる読者が必ずしも個人的に著者に知られていない文書には適用されない。

画像が、画像を見ることができることが知られている特定の人に向けた私的通信（たとえばHTML形式の電子メールなど）に含まれる場合、alt属性は省略されてもよい。しかし、このようなケースでさえも、著者は、（上記のエントリーで説明したように、関連する画像の種類に応じて適切に）代替テキストを含めることを強く勧める。結果として、ユーザーが画像をサポートしないメールクライアントを使用する場合、または文書が画像を簡単に見ることのできないユーザーに転送される場合、電子メールは依然として有用である。

4.8.4.4.14 Guidance for markup generators

Markup generators (such as WYSIWYG authoring tools) should, wherever possible, obtain alternative text from their users. However, it is recognized that in many cases, this will not be possible.

For images that are the sole contents of links, markup generators should examine the link target to determine the title of the target, or the URL of the target, and use information obtained in this manner as the alternative text.

For images that have captions, markup generators should use the figure and figcaption elements, or the title attribute, to provide the image's caption.

As a last resort, implementers should either set the alt attribute to the empty string, under the assumption that the image is a purely decorative image that doesn't add any information but is still specific to the surrounding content, or omit the alt attribute altogether, under the assumption that the image is a key part of the content.

Markup generators may specify a generator-unable-to-provide-required-alt attribute on img elements for which they have been unable to obtain alternative text and for which they have therefore omitted the alt attribute. The value of this attribute must be the empty string. Documents containing such attributes are not conforming, but conformance checkers will silently ignore this error.

This is intended to avoid markup generators from being pressured into replacing the error of omitting the alt attribute with the even more egregious error of providing phony alternative text, because state-of-the-art automated conformance checkers cannot distinguish phony alternative text from correct alternative text.

Markup generators should generally avoid using the image's own filename as the alternative text. Similarly, markup generators should avoid generating alternative text from any content that will be equally available to presentation user agents (e.g., web browsers).

This is because once a page is generated, it will typically not be updated, whereas the browsers that later read the page can be updated by the user, therefore the browser is likely to have more up-to-date and finely-tuned heuristics than the markup generator did when generating the page.

4.8.4.4.15 Guidance for conformance checkers

A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:

• The img element is in a figure element that satisfies the conditions described above.

• The img element has a title attribute with a value that is not the empty string (also as described above).

• The conformance checker has been configured to assume that the document is an email or document intended for a specific person who is known to be able to view images.

• The img element has a (non-conforming) generator-unable-to-provide-required-alt attribute whose value is the empty string. A conformance checker that is not reporting the lack of an alt attribute as an error must also not report the presence of the empty generator-unable-to-provide-required-alt attribute as an error. (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are not required to show an error in this case, because such an error might encourage markup generators to include bogus alternative text purely in an attempt to silence validators. Naturally, conformance checkers may report the lack of an alt attribute as an error even in the presence of the generator-unable-to-provide-required-alt attribute; for example, there could be a user option to report all conformance errors even those that might be the more or less inevitable result of using a markup generator.)