トピックを検索
写真の要点を外したり読み違えたりするAI生成の代替テキスト
ショップのメディアライブラリーがアップロードのたびにAIの説明を代替テキストへ書き込み、誰も読まないまま公開されるため、4色で売っている手帳が3色だと読み上げられてしまう
photo.alt = await describeImage(photo.url); 問題
スクリーンリーダー利用者には、AIが商品写真から推測した文が読み上げられるため、写真で伝えたいことが届かないか、事実と違う内容を聞かされてしまう
ある文具店が、2027年の週間手帳を4色で売っています。商品ページの写真は、セージ色の表紙、1週間のページを開いたところ、4色を並べたところの3枚です。ショップのメディアライブラリーには、AIで代替テキストを付けるアドオンが入っています。写真をアップロードすると、アドオンは写真を画像説明サービスに送り、返ってきた文をそのまま写真の代替テキストに書き込みます。その欄を開く人はいないまま、ページが公開されます。
スクリーンリーダーの利用者が写真を順に移動すると、「白いテーブルの上の緑色のノート、画像」「罫線のあるページを開いたノート、画像」「緑、青、ピンクの3冊のノート、画像」と聞こえます。ファイル名でも「画像」の一語でもなく、どれも丁寧な説明に聞こえます。しかし最初の2枚は、写っているものを挙げるだけで、写真がそこにある理由を伝えていません。伝えるべきだったのは、2027年版の手帳であること、見開きで1週間を見渡せて、メモ欄も付いた作りであることです。3枚目は間違っています。手帳は4冊で、色はセージ、ネイビー、テラコッタ、サンドです。テラコッタが欲しい買い手はピンクがあると聞かされ、サンドという色があることは最後まで知りません。
達成基準1.1.1「非テキストコンテンツ」は、情報を伝える画像に、同じ目的を果たすテキストの代替を求めています。この写真の目的は手帳を売ること、つまり表紙、中の作り、色を見せることです。この画像説明サービスが受け取るのは画素だけです。商品も、ページも、3枚目が色を選ぶ写真であることも知らないため、見分けられた物の名前を並べるだけで、写真を読み違えれば、写真にないことまで代替テキストに書いてしまいます。どれほど自然な文でも、画像で伝えたいことを抜かしたり取り違えたりしていれば、同じ目的は果たせません。
サービス自体は頼まれたとおりに動いています。問題は、返ってきた文の扱い方です。文はそのまま alt 属性に入ってページに公開され、商品を知っている人が読む段階がどこにもありません。Microsoftは、Officeの自動代替テキストについて、生成された文を確認して編集し、「高信頼で生成された説明」のような注記を削除するよう案内しています。アップロードの時点で代替テキストの欄に書き込むアドオンでは、この確認が抜け落ちます。
代替テキストは、写真が読み込めなかったときに表示される文でもあり、読み上げや翻訳のツールが受け取る文でもあります。ショップでは、お金を払う前に商品の見た目を知る唯一の手段であることも少なくありません。
10グループ中2グループに影響
axe は alt 属性のない画像を、ANDI はファイル名を含む代替テキストを探します。この代替テキストは文章になっているため、どちらにも引っかかりません。文と写真を見比べることも、ショップが何色を売っているかを知ることも、チェックツールにはできません。この診断は、生成ツールの注記(「高信頼で生成された説明」など)が残った代替テキストを、確認の手がかりとして報告します。注記は人が確認する際に削除するものなので、残っていれば、読まれないまま公開された可能性が高いと言えます。注記のない生成された文は、ほかの代替テキストと見分けが付きません。写真だけを渡して別のAIに確認させても、見るのは同じ画素で、商品について知っていることも変わりません。
試してみる
手帳の写真をアップロードして、代替テキストに何が入るか見てみましょう
エディターの下の欄に、AIが各写真の代替テキストに書き込んだ内容が出ます。エディターの中で、それを読んだり直したりできますか?次に修正を適用し、写真と見比べて説明を直してから、チェックを入れてください。
問題あり 修正できますか?
週間手帳 2027(A5)
写真
各写真の代替テキスト(商品ページでスクリーンリーダーが読む内容):
(写真をアップロードしてください)
修正方法
AIの説明は、公開する前に人が確かめる
// メディアライブラリーに写真がアップロードされたときmedia.on('upload', async (photo) => { photo.alt = await describeImage(photo.url); await photo.save();}); // 編集画面の「公開」ボタンが押されたときapp.post('/products/:id/publish', async (req, res) => { const product = await products.get(req.params.id); await product.publish(); res.redirect(product.url);});問題点4点
- アップロードの処理がサービスの返した文をそのまま代替テキストに書き込むため、商品を公開した時点で説明も公開される。
- 編集画面は写真を表示するだけで説明は表示しないため、「公開」を押す前に誰も読まない。
- 表紙と中のページの写真は写っているものだけで説明され、年号も、ページの作りも、メモ欄も伝わらない。
- 色の写真は説明が間違っている。4冊ではなく3冊、テラコッタではなくピンクと言っている。
// メディアライブラリーに写真がアップロードされたときmedia.on('upload', async (photo) => { // 人が確認するための下書き。確認されるまで、写真に代替テキストはない photo.altDraft = await describeImage(photo.url); photo.alt = null; await photo.save();}); // 編集画面の「公開」ボタンが押されたときapp.post('/products/:id/publish', async (req, res) => { const product = await products.get(req.params.id); for (const photo of product.photos) { if (!req.body[`checked-${photo.id}`]) return res.sendStatus(422); photo.alt = req.body[`alt-${photo.id}`].trim(); await photo.save(); } await product.publish(); res.redirect(product.url);});修正の手順5ステップ
- サービスが返した文は専用の欄に下書きとして保存し、代替テキストはまだ設定しない。AIが書いた文が、そのままページに出ることはなくなる。
- 編集画面で、各下書きを写真の隣のテキスト欄に表示し、説明が答えるべき問いを欄のラベルにする。
- 欄に短いヒントを結び付け、AIの下書きなので写真と見比べる必要があることを伝える。
- 写真ごとに、必須のチェックボックスを加える。すべての写真を確認するまでブラウザーはフォームを送らず、サーバーも確認のない公開を受け付けない。
- 「公開」のときに、人が確認した文か書き直した文を代替テキストにする。空のまま確認した欄は
alt=""になり、何も加えない写真に使える。
これで修正前の例は直り、確認する人が写真を見られて商品を知っている限り、1.1.1を満たします。下書きは入力の手間を省いてくれますが、テキストの代替と言えるのは、写真がそのページにある理由を知っている人が読んでからです。
生成された文が入ってくるすべての経路。 下書きの欄は、アップロードのボタンだけでなく、画像説明サービスの文が代替テキストに届くすべての経路を受け止める必要があります。
- メディアライブラリー全体への一括処理。代替テキストを付けるプラグインの多くが、代替テキストのない画像に向けて用意している。WordPressでは装飾画像の代替テキストの欄を空にするため、付け忘れと見分けが付かず、一括処理は区切り線や背景の画像まで説明してしまう。
- 「すべて承認」ボタンのある確認画面。確認とは名ばかりで、1回のクリックで、読まれていない下書きがすべて公開される。
- 商品フィード、表計算のファイル、ほかのショップからの取り込み。説明が別の場所で生成されていることがある。
- 写真1枚の説明を生成し直すボタン。上書きしてよいのは下書きだけで、人が確認した代替テキストを上書きしてはいけない。
文脈を渡すと下書きは良くなるが、確認済みにはならない。 商品名やページのキーワードを写真と一緒に受け取るサービスもあり、下書きは実物に近づきます。それでも、ショップが売っている色や、買い手が何を比べているかは分からず、写真を読み違えることもあるため、下書きは下書きのままです。
複数の場所で使う1枚の写真。 メディアライブラリーは多くの場合、画像1枚に代替テキストを一つしか持ちません。しかし同じ写真が、あるページでは商品の色の一覧になり、別のページでは飾りのバナーになることがあります。W3Cの画像のチュートリアルが説明するとおり、ふさわしい文はそのページに画像がある理由で決まるため、写真を置く場所で説明を設定するか、そこで上書きできるようにします。
装飾かどうかは人が選ぶ。 本文にない情報を何も加えない写真には、空の代替テキストが正解で、それを決められるのは人だけです。区切り線に付いた生成された説明は雑音になり、色の写真が空の代替テキストになれば色が伝わりません。ファイル名や同じ言葉が読まれる装飾画像も参照してください。
写真の中の文字やデータ。 サイズ表やラベルの写真は、その文字を代替テキストに入れるか、できればページの本文に書きます。画像の文字を読み取るサービスも、色と同じように数字を読み違えることがあります。実際のテキストの代わりに使われた文字画像も参照してください。
修正の確認
4項目、マウス不要
確認方法: スクリーンリーダー
OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。画像説明サービスやその設定、写真を加える方法を変更した際は、再度確認します。
スクリーンリーダーでの aria-describedbyの読まれ方
制限
このサンプルは、どのアプリケーションでも同じ結果になることを保証するものではありません。describeImage、media、products は、実際のサービスに置き換えてください。このガイドは、生成された説明が読まれないまま公開される場合を扱います。代替テキストがない画像や、ファイル名が入った画像は代替テキストがない、情報を伝える画像で、説明を一度も尋ねないアップロードは代替テキストを尋ねない画像のアップロードで扱います。グラフや図表は1文の代替テキストでは足りず、別のトピックで扱います。Microsoft Edgeのように、代替テキストのない画像をブラウザー自身が説明する機能は、利用者側の道具であって、ページのテキストの代替ではありません。代替テキストのない画像が、それで合格になることはありません。このページで実際に買い物をする人と一緒に確認してください。
よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。
参考資料
- WCAG Understanding: non-text-content(新しいタブで開きます)
- WAI Tutorial: images/decision-tree(新しいタブで開きます)
- WAI Tutorial: images/informative(新しいタブで開きます)
- support.microsoft.com: everything-you-need-to-know-to-write-effective-alt-text-df98f884-ca3d-456c-807b-1a1fa82f5dc2(新しいタブで開きます)
- developer.mozilla.org: img(新しいタブで開きます)
EaseWebのサービス
修正した問題を、次のリリースで再発させない
このガイドのような修正方法を、コーディングエージェントが従うルールと、CIのチェックに組み込みます。あわせて定期的に、キーボードとスクリーンリーダーで手動の再テストを行います。