最初の問いは「この画像を説明するなら何と書くか」ではなく、「この画像を見られないと、何が分からなくなるか」です。設備紹介の写真なら、設備の特徴が失われるかもしれません。問い合わせボタンなら、操作の目的が失われます。本文と同じ内容を繰り返す飾りなら、伝達上の情報は失われない場合があります。この違いを整理してから、代替テキストの要否や内容を決めます。

W3Cの画像に関する判断フローは、画像内の文字、操作の機能、文脈上の意味、装飾としての用途を順に検討する考え方を示しています。[1]

ただし、すべての画像を自動分類できる規則ではありません。同じ写真でも、会社紹介の雰囲気づくりに使う場合と、安全設備の配置を説明する場合とでは、必要な代替情報が変わります。

運用担当者は、原稿の段階で各画像の掲載理由を一文にしてみると判断しやすくなります。「利用者が入口の位置を確認するため」「資料請求ページへ進むため」「余白を装飾するため」のように具体化します。説明できない場合は、制作者や依頼部署に意図を確認します。画像だけを見て推測で書くより、誤った情報を入れる危険を減らせます。

この確認は、自動生成された画像説明を採用するときにも必要です。画像認識で対象物の名前が正しく分かっても、そのページで伝えたい内容やリンクの目的まで一致するとは限りません。人物の役職、設備の型式、撮影場所など、画像だけでは確認できない情報は推定で補わず、確認済みの原稿や管理情報を根拠にします。

WCAG 2.2の達成基準1.1.1「非テキストコンテンツ」はレベルAで、非テキストの情報について、同等の目的を果たす代替テキストを求めています。装飾などには例外条件があり、支援技術が無視できるよう実装する考え方も含まれます。[2] したがって、画像というだけで必ず説明文を読み上げさせる、という要求ではありません。

一方、「確認表を作る」「公開前に別の担当者が読み直す」「同じ画像でも使用箇所ごとに確認する」といった本記事の手順は、要求を実務へ落とし込むための提案です。WCAG本文がその業務様式を指定しているわけではありません。WAIのチュートリアルやUnderstanding文書も、規範となる達成基準本文とは役割が異なる解説資料です。

altの点検だけで、ページ全体やサイト全体のアクセシビリティ対応が完了するわけではありません。リンクの目的、操作部品の名前、文字画像の利用などには関連する別の観点もあります。ここで扱う手順は法令適合や検索順位を保証するものではなく、自社の方針や確認対象に合わせて使う運用上の手がかりです。

画像だけで構成されるリンクでは、その画像が何を描いているかより、リンクの目的が伝わることが重要です。例えば、資料請求ページへ進むバナーに「青い長方形」と書いても、利用者は次に何が起こるか判断できません。「製品カタログの資料請求」のように、実際の移動先と合う説明を検討します。WAIは機能を持つ画像について、見た目ではなく実行される操作や目的を伝えるよう説明しています。[3]

企業ロゴが単独でトップページへのリンクになっている場合も同様です。会社名だけで十分か、ホームへの移動を含めたほうが分かりやすいかを、そのリンクの文脈で確認します。ロゴの形や色を長く説明しても、ナビゲーションとしての役割は伝わりません。一方、ブランドの変遷を説明する記事では、同じロゴの視覚的特徴そのものが情報になる可能性があります。

入稿前に確認するのは、画像内の表示とリンク先が一致しているかです。「見積もり依頼」と書かれた画像が一般の問い合わせページへ進むなら、代替テキストだけを都合よく直すのではなく、表示文言、リンク先、受け付ける内容の整合性を見直します。見えている人と読み上げで利用する人に異なる案内を出さないことが基本です。

ダウンロード画像では、資料名を明確にすることが役立ちます。ファイル形式や容量を案内するかは、利用者の判断に必要かを踏まえて決めます。ただし、実際の形式や容量を確認せずに書かないようにします。資料差し替え時には画像、リンク先、補足情報をひとまとまりで更新し、古いファイルへの導線を残していないか確かめましょう。

カード型の一覧では、サムネイル画像と記事タイトルが一つのリンクに含まれることがあります。その画像がタイトル以上の情報を持たず、リンクの目的がテキストから分かるなら、画像のaltを空にして重複を避ける実装を検討できます。[3] タイトルが読まれた直後に同じ文が画像の説明として繰り返されると、一覧を確認する負担が増えます。

ただし、画面で画像と文字が隣り合っているだけでは、同じリンクとは限りません。画像と見出しに別々のリンクが設定されていれば、画像側だけを空のaltにすると、名前を持たないリンクになる場合があります。編集画面の見た目で判断せず、制作担当者にリンクの構造と最終的なアクセシブルな名前を確認してもらいます。

また、近くに説明文があるだけで、常に空のaltが適切になるわけでもありません。写真が製品の付属品や接続端子などの追加情報を示しているなら、その意味をどう伝えるか検討が必要です。重複を減らす判断と、情報を省略する判断を混同しないようにしましょう。

運用ルールには「一覧画像はすべて空にする」ではなく、成立条件を書きます。例えば「同一リンク内に目的を表すテキストがあり、画像に追加情報がない場合は空のaltを使用する」とすれば、別テンプレートへ横展開するときにも確認点が残ります。実装が変わった後は、この条件が引き続き満たされるかを再確認します。

純粋な装飾や、必要な内容がすでにテキストで伝わっている画像では、空のaltを用いることがあります。HTMLのimg要素なら、alt=""という空の値を指定する方法です。alt属性そのものを付けない状態とは異なり、属性がない画像ではファイル名などが読み上げられる場合があります。WAIの装飾画像の解説でも、この違いが示されています。[4]

CMSの入力欄を空欄にしたとき、出力が空のaltになるのか、属性自体が消えるのかは製品や設定によって変わります。「入力していないから装飾扱いになる」と思い込まず、公開されたHTMLまたはアクセシビリティ情報で確認します。「装飾として扱う」という専用設定がある場合は、その挙動も制作担当者と共有しておきます。

装飾と判断しやすいのは、意味を持たない背景模様や区切りの飾りなどです。一方、受付時間、所在地、対象者、割引条件を画像で伝えている場合は、見た目が飾りのようでも重要な情報が含まれます。「デザイン画像」という制作上の呼び名だけでは判断できません。画像を外した状態でも、利用者の理解や判断に必要な情報が残るかを見ます。

CSSの背景画像も確認対象です。背景だから情報が不要なのではなく、情報が不要な装飾として適切に使われているかが問題です。必要な案内を背景画像だけに入れているなら、本文へテキストを追加するなどの方法を検討します。imgのalt欄を埋める作業だけでは、こうした情報欠落を拾えません。

工程図、組織図、比較グラフなどは、短いaltだけにすべての内容を詰め込むと理解しづらくなります。WAIの複雑な画像の解説は、画像を識別する短い説明に加え、重要な情報を文章などで伝える詳しい説明の考え方を示しています。[5] 実務では図の近くに説明文やデータ表を用意し、どこを読めば内容が分かるかを明確にします。

例えば、三つの申込方法を比較する図なら、代替情報には方法名だけでなく、利用条件、手順、違いを含めます。「申込方法の比較図」というaltだけでは、図があることは分かっても比較の内容は分かりません。逆に、図のすべての枠線や色を順番に説明しても、利用者が知りたい条件を探しづらくなることがあります。

グラフなら、対象期間、単位、系列の名称、値、読み取ってほしい傾向を確認します。単純なデータなら表を添える方法もありますが、表を置いただけで説明が十分とは限りません。グラフが示す比較や変化の意味が本文で説明されているか、欠測や集計条件が隠れていないかも確認します。図にない結論を代替説明の中だけで付け足すことは避けます。

フロー図では、分岐の条件と各条件の行き先が重要です。図中の文を上から並べただけでは、「該当する場合」と「該当しない場合」の違いが失われることがあります。文章で読み進めたときに正しい手順へ到達できるか、業務担当者に検証してもらいます。図と説明のどちらを読む場合でも、案内する手続きが一致する状態を目指します。

詳しい代替情報は、読める場所にあるだけでなく、該当する図から見つけられる必要があります。図の直後に説明を置く場合は、見出しや文頭でどの図について述べているか示します。別ページへ移す場合は、リンクの目的が分かる文言を使い、公開時にリンク先も確認します。「詳細はこちら」が複数並ぶ構成は、対応関係が分かりにくくなるので見直します。

説明が長い場合でも、altへ何百文字も押し込むことを第一の選択にしないようにします。利用者が見出しや表を使って必要な部分へ移動できるよう、本文として構造を持たせるほうが適したケースがあります。どの方法を使うかは実装によって異なるため、属性名だけを指定するのではなく、利用者が情報へ到達できる結果を制作担当者と共有します。

更新の責任も明確にします。図版を差し替えた担当者と本文を更新する担当者が別の場合、説明が古いまま残りやすくなります。「図の更新依頼には、代替テキストと詳細説明の更新要否を記載する」という欄を設ければ、画像だけの差し替えで作業を閉じることを防げます。図の元データが変わった場合は、公開中の表や注記も点検対象です。

多言語ページでは、日本語版で確認が終わっても、他言語版の意味が一致するとは限りません。図内の言語、alt、詳細説明、リンク先を同じ言語の組として確認します。翻訳者には画像ファイルだけでなく、掲載ページの文脈と説明の目的を渡すと、必要な情報を落としにくくなります。

イベント告知やキャンペーンでは、日時や条件まで一枚の画像にまとめたくなることがあります。画像の代替情報を用意することは重要ですが、それだけで小さい文字の読みにくさや拡大時の問題を解消できるわけではありません。主要な案内は通常のテキストでも掲載し、画像を読めるかどうかに手続きが左右されない構成を検討します。

WCAG 2.2の1.4.5「文字画像」はレベルAAで、所定の例外を除き、使用している技術で表現できる場合は文字画像よりテキストを使う要求です。[6] この観点と、1.1.1の代替テキストの観点は分けて考えます。altを追加したから文字画像に関する確認も済んだ、とまとめて判断しないようにします。

例えば、申込期間を画像と本文の両方に載せるなら、双方の日付が一致しているか確認します。公開後の延長が決まった際に本文だけ直すと、利用者が異なる案内に接する可能性があります。情報を複製する箇所を必要以上に増やさず、更新の基準になる原稿を決めることも、画像を安全に運用するための工夫です。

入稿前には、対象ページ、画像の位置、役割、altの案、詳細説明の場所、確認者を一覧にします。すべての画像に長い管理票を作る必要はありません。リンク画像と複雑な図、判断が分かれた装飾画像を優先して記録すれば、小規模なサイトでも始めやすくなります。重要なのは、空欄が作業漏れなのか意図した空のaltなのかを区別できることです。

CMSに同じ画像を再利用する場合は、メディア管理画面の値が全ページへ反映されるのか、挿入時にコピーされるのか、ページごとに上書きできるのかを調べます。一か所の修正が別の用途のページへ波及することもあります。使用箇所を確認せず、共有画像の説明を一括で変更しないようにしましょう。

公開前のプレビューでは、画像、周辺の本文、リンク先、代替情報を一組として確認します。自動チェックでaltの有無を調べるだけでは、内容の適切さは判定できません。「画像」「写真」「バナー」とだけ書かれた説明や、別製品の名前が残った説明は、人が文脈と照合して見つける必要があります。

公開後は実際のURLで確認します。プレビューと本番でテンプレートや画像出力が違う場合があるためです。必要に応じて読み上げ環境でも確認し、リンクが目的の分かる名前で案内されるか、装飾が不要に割り込まないか、詳細説明へたどり着けるかを確かめます。確認したブラウザーや支援技術、ページの範囲を記録し、一つの環境での結果を全環境の保証にしないことも大切です。

画像の確認記録には、判断した理由も短く添えておきます。「本文と同じ情報なので空のalt」「画像だけがリンクになっているため移動先を記載」などの記録があれば、後任が説明を追加・削除するときの手がかりになります。決まった文章を機械的に引き継ぐのではなく、ページの構成が変わったら理由も見直します。確認表を作る目的は入力作業を増やすことではなく、次の変更で同じ判断を最初からやり直さずに済むようにすることです。

制作担当者へは「altを改善してください」だけでなく、対象URL、画像の位置、現状、困ること、期待する状態を伝えます。例えば「一覧の画像リンクが名称なしになるため、記事名が分かるリンクにしたい」「工程図の分岐条件を本文でも読めるようにしたい」と書けば、原稿側と実装側のどちらを直すべきか検討しやすくなります。

確認が終わっていない図を急いで公開する場合も、不確かな説明で欄を埋めて完了扱いにはしません。必要情報を通常のテキストで正確に提供できるか、図の公開時期を調整するかを管理責任者と判断します。公開後に対応する場合は、対象と担当者を明記して残し、画像が表示されていることだけを完了条件にしないようにします。

画像のaltを運用するうえで大切なのは、説明文の量を増やすことではありません。リンクなら目的、装飾なら不要な読み上げを避ける実装、複雑な図なら内容へたどり着ける代替情報を用意することです。画像の用途を判断し、本文と実装を合わせて確認する流れをつくれば、日々の更新でも確認すべき点が明確になります。

画像SEOの基本｜alt属性・ファイル名・表示速度でホームページを改善する方法　

以下は2026年10月20日に確認したW3Cの一次資料です。本文の確認手順と管理方法は、これらを踏まえた実務上の提案です。
[1] W3C WAI An alt Decision Tre
[2] W3C Web Content Accessibility Guidelines 2.2 達成基準1.1.1
[3] W3C WAI Functional Images
[4] W3C WAI Decorative Images
[5] W3C WAI Complex Images
[6] W3C WAI Understanding Success Criterion 1.4.5 Images of Text