画像が自動チェックに合格したからといって、スクリーンリーダーに依存するユーザーにとって、その画像に関連付けられた代替テキストが役立つとは限りません。これは、2026年8月24日付でTaarik AshenafiとKeenan Zhouが執筆した技術記事でGitHubが示した主な結論です。両氏はGitHub Accessibility Scanner向けに、代替テキストの拡張機能を開発しました。
この記事は、Web上で最も人気のある100万サイトのトップページを調査したWebAIM Million 2026の報告書に基づいています。同報告書では、画像の16.2%で代替テキストが欠落していることが判明しました。代替テキストがある画像のうち、10.8%は、image、生のファイル名、隣接する画像から繰り返された説明など、役に立たない説明を提供していました。問題は、ほとんどの自動チェックツールが、説明の品質や文脈への適合性ではなく、画像に利用可能な名前が存在するかどうかを確認していることです。
証明できることと判断が必要なことを分ける
GitHubは、alt属性が存在することはツールで証明できる客観的な事実である一方、テキストが画像を説明するのに適しているかどうかは、多くの場合、文脈に依存する問題だと考えています。そこで、この拡張機能では、AIモデルの認証情報やネットワーク接続なしで、デフォルトで動作する5つの決定論的ルールを採用しました。
- 属性が存在しない、または空白だけが含まれている。ただし、通常は画像が装飾目的であることを示すalt=""とは区別します。
- hero.pngやIMG_2847.jpgのようなファイル名を使用している。
- TODOやtbdのような仮の値を残している。
- image、logo、chartのように、メディアの種類を表す一般的な単語を1つだけ使用している。
- 隣接する画像間で同じテキストを繰り返している。
曖昧な説明を検出するルールは、より複雑な推測ではなく、選別されたリストとの文字列の完全一致に基づいています。そのため、alt="image"は報告しますが、「シングルサインオンボタンを強調したログイン画面の画像」のような長い説明を、自動的に曖昧とは見なしません。GitHubは、開発者がツールを無効にする原因となる誤警告を大量に生成するよりも、一部のケースを見逃すほうがよいと説明しています。
HTMLの順序よりも視覚的な近接性が重要
重複テキストの処理によって、DOM内の要素の順序が、ユーザーが画面上で見る内容を必ずしも反映していないことが明らかになりました。たとえば、GitHubのロゴがヘッダーとフッターに表示されていても、抽出されたリストでは視覚的に離れているにもかかわらず隣り合っている場合があります。そこで拡張機能は、画像の位置を境界ボックスで調べ、画像間の距離が画像の寸法に比べて小さい場合にのみ、同じグループ内でテキストが重複していると判定します。
このしきい値は公式標準に基づく数値ではなく、実際のページで調整が必要な推定値です。測定可能な境界ボックスが利用できない場合、ルールは警告を出さないことを選びます。検出されないケースよりも、誤警告のほうが開発者にとって明確な問題になるためです。
視覚モデルは最終判定ではなく提案
オプションのルールは、ページの文脈を代替テキストと画像に追加します。これには、最も近い見出し、ページタイトル、figcaptionの有無、画像がリンクまたはボタン内にあるかどうか、周囲のテキスト最大600文字が含まれます。画像がリンクの唯一のコンテンツである場合、リンクの存在は特に重要です。そのとき代替テキストは単なる視覚的な説明ではなく、リンク先を説明する利用可能な名前になるためです。
これらのデータは、GitHub Modelsを介して視覚モデルに送信されます。GitHubによれば、最初の問題は、モデルが画像を誤解することよりも、テキストが十分に良い場合でも改善を提案しがちなことでした。これを抑えるため、該当する最初のケースで停止する優先順位付きの判定メカニズム、過剰なチェックを防ぐルール、結果を選択する前に理由の構造化を強制する出力形式が使用されました。ケースには、装飾画像、キャプションによって説明が冗長になっている画像、機能的な画像、情報を伝える画像が含まれます。
プライバシー、コスト、実務上の限界
モデルベースのルールはデフォルトで無効になっており、明示的に有効化し、GitHub Modelsへのアクセストークンを提供する必要があります。また、画像とリンクのURLからクエリパラメーターとフラグメント部分が削除され、HTMLをモデルに送信する前にsrcとsrcsetの値が(omitted)に置き換えられます。ただし、問題の位置を特定して修正する必要があるため、ページのURLと元のHTMLは通常のスキャナーのレポートに引き続き含まれます。Azure AI Visionの認証情報が設定されている場合は、オプションのOCR処理を実行するため、画像のバイナリデータが別のサービスに送信されることもあります。
モデルの呼び出しは、各スキャンで画像1枚ごとに1回発生する可能性があるため、画像の多いサイトほどコストが高くなります。そのため、この実験では、すべてのコミットに追加するのではなく、スケジュールに従ってチェックを実行するのが適していると示されています。
現在、この拡張機能が対象とするのはimgタイプのHTML要素だけです。また、認証で保護された画像は、ブラウザーセッション外で再取得される際に読み込みに失敗する可能性があります。さらに、スキャンでは計算済みの利用可能な名前ではなくalt属性そのものを読み取るため、aria-labelの誤りが見逃される場合があります。提案された結果は人による確認が必要な下書きであり、組み込みスキャナーのチェックと一部の警告が重複する可能性もあります。
実際に何が変わるのか
GitHubの実験は、チェックツールを構築する際に一般化できる原則を示しています。明確な誤りを証明するテストは、低コストで予測可能なものにし、デフォルトで有効にします。一方、文脈上の問題を疑うテストはオプションにし、判定ではなく提案として提示します。重要なのは、ユーザー体験の評価をDOMの内容や視覚モデルの意見だけに還元できないことです。ここでの自動化はレビューの範囲を広げますが、支援技術を使用する人々とサイトをテストすることに取って代わるものではありません。