アクセシビリティ検査がCIで緑になっても、alt="IMG_2847.png"のような説明は利用者の助けになりません。属性があるかどうかと、画像の役割を伝えられているかは、別の問題だからです。

GitHubは2026年8月24日、GitHub Accessibility Scanner向けのaltテキスト検査プラグインを紹介しました。興味深いのは、AIですべてを採点するのではなく、機械が証明できる欠陥と、文脈から疑いを提示する判定を分けたところです。

では、CIにはどこまで任せ、どこから人が見直すべきなのでしょうか。プラグインの仕組みを追いながら、「合格」を品質保証にしない運用まで整理します。

alt属性が存在しても画像の役割に合う説明とは限らない

altテキストは、画像に見えるものを一律に書き起こす欄ではありません。W3CのImages Tutorialでは、情報を伝える画像、装飾画像、リンクやボタンとして働く機能画像、複雑な図などを分け、用途・文脈・内容に応じて代替テキストを決めるよう案内しています。

たとえば、装飾だけの画像ならalt=""が適切です。情報画像なら要点を短く伝え、画像だけのリンクなら見た目ではなく移動先や操作を表す必要があります。WCAG 2.2の達成基準1.1.1の解説も、非テキストコンテンツの情報や目的をテキストで利用できるようにする考え方を示しています。

つまり、属性の有無は機械的に判定できますが、その文が画像の役割に十分かはページ全体の意味に左右されます。ここが従来の存在チェックと、今回の品質チェックを分ける境目です。

この差は小さくありません。WebAIM Million 2026では、上位100万ホームページの画像の16.2%で代替テキストが欠け、代替テキストがある画像の10.8%にも疑わしい表現や反復が見つかりました。欠落率は2025年の18.5%から下がりましたが、「属性を付ける」だけでは残る問題が見えてきます。

5つの既定ルールは文字列だけで証明できる欠陥を狙う

altテキストプラグインの公式リポジトリでは、次の5ルールが既定で有効です。

• alt属性がない、または空白だけになっている
• imageやlogoのような曖昧な語だけになっている
• IMG_2847.jpgのようなファイル名になっている
• TODOやtbdのような仮置きが残っている
• 画面上で隣接する画像に同じaltテキストが繰り返されている

これらは画像の意味を推測しなくても、文字列や配置から不備を指摘できます。曖昧語のルールは文字列を正規化して閉じた語彙へ完全一致させるため、alt="image"は検出しても、alt="image of the login screen with the SSO button highlighted"までは止めません。取りこぼしを許容して誤検知を抑える設計ですね。

対象画像の抽出にも意図があります。プラグインはPlaywrightのロールベースの探索を使い、支援技術に公開される要素から実際の<img>だけへ絞ります。装飾を明示するalt=""や非表示ツリー内の画像は、ルールへ渡しません。

同じaltテキストの反復も、DOM順だけでは判定しません。ヘッダーとフッターのロゴが抽出結果では隣り合っても、利用者には一つの画像群として提示されないためです。そこで画像の境界ボックス同士の距離を見て、画面上で近い反復だけを対象にします。DOMの形ではなく、利用者が受け取る配置へ寄せた判断だと分かります。

文脈が必要な判定だけをモデルへ分ける

alt="笑顔の人物"が十分かどうかは、その画像だけでは決まりません。雰囲気を添える写真なら足りるかもしれませんが、直前の見出しで人物名を紹介しているなら、誰なのかを伝えられていない可能性があります。

任意のalt-text-qualityルールは、画像とaltテキストに加えて、ページタイトル、最寄りの見出し、figcaption、リンクやボタンの内側かどうか、周辺テキスト最大600文字をGitHub Modelsへ送ります。決定的ルールでは扱えない、もっともらしいけれど不正確・不十分な説明や、SEO目的のキーワード詰め込みをレビュー候補として拾うためです。

ただし、モデルの役割は採点者ではありません。初期の実装では「もっと良くできるか」と尋ねると、適切なaltテキストにも別案を出し続け、すべてが指摘になったと説明されています。そこで装飾、キャプションとの重複、機能画像、情報画像という順序付きの判断手順を与え、細かな言い換えを求めない規則と構造化出力を組み合わせました。

この分離があるからこそ、誤検知しにくい検査を常時動かし、判断が揺れる部分だけを別のレビュー工程へ置けます。

公開プレビューでは既定ルールから小さく組み込む

プラグインの現在のREADMEは、GitHub Accessibility Scanner v3以降を要件とし、GitHub Actionsのscans入力にnpmパッケージを追加する構成を案内しています。スキャナー自体も公開プレビューで、検出結果からGitHub Issueを作り、必要に応じてCopilotによる修正提案へつなぐツールです。

READMEの例は、既存のAxe検査を残したままプラグインをバージョン固定で追加します。

scans: |
  ["axe", {"name": "alt-text-scan", "package": "@github/accessibility-scanner-alt-text-plugin", "version": "1.1.0"}]

ここで"axe"を残すのは、プラグインを指定するとスキャナー既定のAxeだけが自動で走るわけではないためです。一方、Axeのimage-altとプラグインのmissing-alt-textは検出範囲が重なり、同じ画像が二重に報告される場合があります。導入直後はIssue件数だけで品質を測らず、どのルールが何を見つけたかを切り分けたいところです。

モデル判定を使わない段階でも、ファイル名、曖昧語、仮置き、近接した反復をCIへ持ち込めます。まず既定ルールの指摘がチームのコンテンツやUIに合うかを確認し、その後にモデル判定の必要性を決める順番が自然です。

モデル判定を有効にするとデータフローと実行コストが変わる

モデル判定は.github/scanner-plugins/alt-text-scan/config.jsonで明示的に有効化し、models:read権限を持つトークンをGITHUB_MODELS_TOKENへ渡します。READMEでは、スキャナーのサブアクションへ環境変数が届くよう、ジョブ単位で設定する構成が示されています。

{
  "$schema": "https://raw.githubusercontent.com/github/accessibility-scanner-alt-text-plugin/main/schema/config.schema.json",
  "rules": {
    "alt-text-quality": true
  }
}

この切り替えは、単なるルール追加ではありません。一般的には画像ごと・スキャンごとに1回のモデル呼び出しが発生するため、画像が多いサイトではコストと所要時間を支配し得ます。毎コミットではなく定期実行にする判断も出てきます。

送信前には画像URLやリンク先URLのクエリとフラグメントが除かれ、モデルへ渡すマークアップではsrcとsrcsetが省略されます。ただし、スキャナーが作る通常の指摘には実ページURLと元のHTMLが残ります。さらにAzure AI Visionの資格情報を設定すると、任意のOCR前処理で画像が別の送信先にも渡るため、レビュー対象はGitHub Modelsだけではありません。

ページタイトルや周辺本文も外部入力です。構造化出力は返答形式を制限できますが、ページ内の文がモデルの判断を誘導する可能性までは消せません。機密ページを対象にする前に、送信先、保存先、実行頻度、Issueを閲覧できる人をデータフローとして確認する必要があります。

「問題なし」と「評価できなかった」をログで分ける

静かなスキャン結果が、すべての画像を評価できた証拠とは限りません。モデル判定はブラウザーセッションの外から画像を再取得するため、認証の背後にある画像を読み込めない場合があります。取得エラーやモデルエラーはログへ記録して処理を飛ばすので、指摘ゼロと評価完了を同じ意味にしないことが大切です。

対象もHTMLの<img>に限られ、SVG、role="img"を持つコンテナ、CSS背景、canvasは含まれません。また、決定的ルールはalt属性そのものを読む一方、ブラウザーが計算するimgのアクセシブルネームではaria-labelやaria-labelledbyが先に使われます。HTML Accessibility API Mappingsと検査対象の差があるため、属性だけを見る指摘と実際の読み上げが食い違うケースも残ります。

公開プレビューかつ実環境からのフィードバックがまだ限られる段階なので、モデルの指摘は判決ではなくレビュー依頼、提案されたaltテキストは下書きとして扱います。Issueだけでなく、取得・スキップのログ、対象外の画像形式、二重報告も合わせて見ることで、検査の空白を把握できます。

自動化の役割は合否判定ではなく再確認の優先順位づけ

このプラグインが示す答えは明快です。未記入やファイル名のように証明できる欠陥は、安価で予測可能な既定ルールへ任せます。画像の目的や周辺文脈が必要な品質判断は任意のモデルで候補を絞り、最後は人が決めます。

CIの緑は「すべて良い」ではなく、「有効なルールが指摘を出さなかった」という状態です。スキップや対象外をログで分け、モデルへ渡るデータを理解し、支援技術を使う人による確認へつなげる。そこまで運用に含めて初めて、altテキスト検査は合格印ではなく、見るべき画像を人へ返す仕組みになります。

出典

• Title: Your alt text passes automated checks. That doesn’t mean it’s any good.
• URL: https://github.blog/engineering/user-experience/your-alt-text-passes-automated-checks-that-doesnt-mean-its-any-good/