継続的AIによるアクセシビリティ：GitHubがフィードバックをインクルージョンに変える方法
GitHubは散在するアクセシビリティフィードバックをActions、Copilot、Modelsを活用した内部ワークフローで一元管理し、AIによる定型業務の自動化と人間の修正作業を組み合わせる継続的インクルージョン体制を構築した。
キーポイント
フィードバックの一元化と構造化
スクリーンリーダーやキーボード操作など多様なユーザーからの散在する問題をテンプレート化し、バックログを整理して所有責任を明確化した。
AIを活用した継続的ワークフロー
GitHub Actions、Copilot、Modelsを組み合わせ、フィードバックのキャプチャから追跡・優先順位付けまでを自動化し、人間の開発者はソフトウェア修正に集中できる体制を整えた。
コードスキャナよりユーザー体験を重視
自動化された検査ツールだけでなく、実際のユーザーからの声をスケールして増幅し、インクルーシブな開発を「生きている方法论」として定着させた。
...
...
影響分析・編集コメントを表示
影響分析
本記事は、AIを単なる開発補助ツールではなく、組織横断的なプロセス改善のエンジンとして位置づけた実践例を示している。特にアクセシビリティという複合的な課題に対し、既存プラットフォームの機能を組み合わせることで運用コストを削減し、開発者の創造的作業への集中を可能にした点は、多くのテック企業におけるAI統合の参考モデルとなる。ただし自社ブログであるため実証データが限られるものの、プロセス革新とAI活用の方針は業界の標準化に寄与する可能性がある。
編集コメント
自社プラットフォームの機能紹介であるため客観性は限られるが、AIを「業務の肩代わり」から「人間の判断支援」へ再定義した運用設計は、実務導入の重要な指針となる。
長年にわたり、GitHub におけるアクセシビリティに関するフィードバックには明確な受け入れ先がありませんでした。
一般的な製品フィードバックとは異なり、アクセシビリティの問題は特定のチームに属するものではありません。それらはエコシステム全体に横断的に存在します。例えば、スクリーンリーダーユーザーが報告する破綻したワークフローは、ナビゲーション、認証、設定など複数の領域にまたがる可能性があります。キーボードのみで操作するユーザーは、数十ページにわたって共有されているコンポーネント内のトラップ（罠）に遭遇することがあります。低視力ユーザーは、共有デザイン要素を使用するすべての表面に影響を与える色コントラストの問題を指摘します。これらの問題のいずれも単一のチームが所有していませんが、すべてが実際のユーザーの行動を阻害しています。
これらの報告には、既存のプロセスでは当初想定されていなかった調整が必要です。フィードバックはしばばバックログに散在し、バグは所有者不明のまま放置され、ユーザーからの追跡連絡は無視される傾向がありました。改善策は、ほとんど実現しない神話的な「フェーズ 2」で約束されることが多かったです。
私たちはこの状況を変える必要があると知っていました。しかし、より良い仕組みを構築する前に、まず土台を築く必要がありました。散在する報告の一元化、テンプレートの作成、そして何年にもわたるバックログのトリアージです。その基盤が整って初めて、「AI はどのようにしてこれを容易にできるのか？」という問いを立てることが可能になります。
答えは、GitHub Actions、GitHub Copilot、そして GitHub Models を活用した社内ワークフローでした。これにより、ユーザーや顧客からのあらゆるフィードバックが追跡可能な優先度付きの課題として管理され、対応されるようになります。誰かがアクセシビリティの障壁を報告した場合、そのフィードバックは収集・レビューされ、解決されるまで追跡されます。私たちは AI が人間の判断を代替することを望んではいませんでした。むしろ、反復作業を AI に任せることで、人間がソフトウェアの修正に集中できる環境を作りたかったのです。
これが、混沌とした状態から、すべてのアクセシビリティに関するフィードバックが追跡され、優先順位付けされ、即座に対応されるシステムへと変化したプロセスです。最終的にではなく、継続的にです。
生きたシステムとしてのアクセシビリティ
アクセシビリティのための継続的 AI は、インクルージョンをソフトウェア開発の基盤に織り込みます。これは単一の製品や一度きりの監査ではありません。自動化、人工知能（AI: Artificial Intelligence）、そして人間の専門知識を組み合わせた、生きたメソドロジーなのです。
この哲学は、2025 年のグローバル・アクセシビリティ・アウェアネス・デー（GAAD）への誓約に対する私たちの支援と直接結びついています。それは、ユーザーや顧客からのフィードバックが適切なチームへルーティングされ、意味のあるプラットフォーム改善へと翻訳されることを通じて、オープンソース・エコシステム全体におけるアクセシビリティを強化するというものです。
最も重要なブレークスルーは、コードスキャナから来ることはめったにありません。それは、実際の人間に耳を傾けることから生まれます。しかし、大規模な範囲で耳を傾けるのは困難です。そのため、これらの声を増幅させるためにテクノロジーが必要でした。私たちは、静的なチケット管理システムというよりはむしろ動的なエンジンとして機能するフィードバックワークフローを構築しました。GitHub の製品を活用して、ユーザーや顧客からのフィードバックを明確化し、構造化し、追跡することで、実装可能なソリューションへと変換しています。
まず人々のために設計する
解決策に飛び込む前に、このシステムが誰のために機能すべきかを理解するために一歩引いて考えました。
課題提出者：コミュニティマネージャー、サポートエージェント、営業担当者がユーザーや顧客に代わって課題を提出します。彼らは必ずしもアクセシビリティの専門家ではないため、作業の流れの中で彼らを導き、アクセシビリティの概念を教えるシステムが必要です。
アクセシビリティおよびサービスチーム：修正を担当するエンジニアやデザイナーには、構造化された実用的なデータ—再現可能な手順、WCAG（Web Content Accessibility Guidelines）マッピング、深刻度スコア、明確な所有権—が必要です。
プログラムおよびプロダクトマネージャー：リーダーシップ層は、カテゴリ別、トレンド別、時間経過に伴う進捗状況における課題点を可視化し、戦略的にリソースを配分する必要があります。
これらのペルソナ（人物像）を念頭に置き、私たちは 1) フィードバックをパイプラインを通じて流れるデータとして扱うこと、2) 私たちと共に進化できるシステムを構築することを目指しました。
フィードバックの流れ
その基盤を確立した上で、イベント駆動型パターンを中心としたアーキテクチャを構築しました。各ステップは GitHub Action をトリガーして次の手順を調整し、フィードバックの発生源がどこであれ一貫した処理を実現します。このシステムは 2024 年半ばから主に手作業で構築されました。現在では Agentic Workflows のようなツールにより、自然言語を使って GitHub Actions を作成できるようになりました—つまり、同様のシステムを従来よりもはるかに短い時間で構築することが可能になっています。
ワークフローは主要なイベントに応じて反応します：Issue の作成は GitHub Models API を介して GitHub Copilot による分析を開始し、ステータスの変更はチーム間の引き継ぎをトリガーし、解決は利用者へのフォローアップを提出者に促します。すべての Action は必要に応じて手動でトリガーしたり再実行したりすることも可能です—自動化が一般的なフローをカバーする一方、人間はいつでも介入できます。
フィードバックは単に収集されるだけでなく、適切なチャネルを通じて継続的に流れ、各段階において可視性、構造化、そして実行可能性を提供します。
*画像をクリックして拡大してください。
- 受入アクション
フィードバックはあらゆる場所から寄せられます——サポートチケット、ソーシャルメディアの投稿、メール、直接の連絡など—but 多くのユーザーが GitHub のアクセシビリティディスカッションボードを選択します。そこでは、共通の経験に基づいて協力し、コミュニティを築くことができます。現在、アクセシビリティに関するフィードバックの 90% がこの単一のチャネルを通じて流れています。投稿は公開されているため、他のユーザーが問題を確認したり、文脈を追加したり、回避策を提案したりできます——そのため、問題にはサポートチケットでは決して得られないほど詳細な情報が付随して届くことが多いのです。出所に関わらず、すべてのフィードバックは 5 営業日以内にAcknowledged（承認）され、対応できないフィードバックについても、役立つリソースへの案内を含む回答が返されます。
フィードバックに内部チームによるアクションが必要な場合、メンバーが手動でカスタムアクセシビリティフィードバック用Issueテンプレートを使用して追跡用のIssueを作成します。Issueテンプレートは、新しいIssueを開く際に情報を収集する方法を標準化する事前定義されたフォームです。このテンプレートでは、初期の文脈——ユーザーが報告した内容、その出所、関与するコンポーネント——を記録するため、受付からトリアージまでの間に情報が失われることはありません。
ここから自動化が始まります。Issueを作成するとGitHub Actionがトリガーされ、GitHub Copilot が連携します。また、別のActionがそのIssueをプロジェクトボードに追加し、現在のステータスの一元化されたビューを提供し、トレンドを浮き彫りにし、新たなニーズの特定を支援します。
- GitHub Copilot の分析
追跡用イシューが作成されると、GitHub Action ワークフローがプログラムを通じて GitHub Models API を呼び出し、レポートを分析します。モデルのファインチューニングではなく保存されたプロンプトを採用したのは、チームの誰でもプルリクエストを通じて AI の動作を更新できるようにするためです。再トレーニングパイプラインは不要で、専門的な機械学習の知識も必要ありません。
GitHub Copilot は、アクセシビリティの専門家が策定したカスタム指示を使用して設定されています。私たちのプロンプトには 2 つの役割があります。1 つ目はトライアージ分析で、WCAG の違反内容、深刻度、影響を受けるユーザーグループに基づいてイシューを分類します。2 つ目はアクセシビティコーチングで、GitHub Copilot が専門家の役割を果たし、チームがアクセシブルなコードを書き、レビューするのを支援します。
これらの指示ファイルは、私たちのアクセシビリティポリシー、コンポーネントライブラリ、そして WCAG の成功基準をどのように解釈し適用するかを詳細に記した内部ドキュメントを参照しています。基準が進化した場合、チームはプルリクエストを通じて markdown ファイルと指示ファイルを更新します。AI の動作は次のトレーニングサイクルではなく、次の実行時に即座に変更されます。このアプローチの詳細な手順については、アクセシビリティのための GitHub Copilot カスタム指示の最適化に関するガイドをご覧ください。
自動化は2つのステップで行われます。まず、Issue が作成された際に Action が発火し、GitHub Copilot にレポートの分析をトリガーします。GitHub Copilot は、Issue のタイプ、ユーザーセグメント、元のソース、影響を受けるコンポーネント、およびユーザー体験を理解するための十分な文脈など、40 以上のデータポイントを含む Issue メタデータの約 80% を自動的に記入します。残りの 20% は、チームメンバーによる手動入力が必要です。その後、GitHub Copilot は以下の内容を含むコメントを Issue に投稿します。
問題とユーザーへの影響の要約
潜在的な違反に対する WCAG（Web Content Accessibility Guidelines）の成功基準の提案
深刻度レベル（sev1 から sev4 まで。sev1 が最優先事項）
影響を受けるユーザーグループ（スクリーンリーダー利用者、キーボード操作利用者、低視力利用者など）
推奨されるチームへの割り当て（デザイン、エンジニアリング、またはその両方）
提出者が Issue を検証できるようにするための、ハードルの低いアクセシビリティテストのチェックリスト
次に、そのコメントに対して第 2 の Action が発火し、回答を解析して、GitHub Copilot が割り当てた深刻度に基づいてラベルを付与し、プロジェクトボード上の Issue のステータスを更新し、レビューのために提出者に割り当てます。
GitHub Copilot の分析が不正確に見える場合、誰でも問題のある箇所とその修正内容を記述した Issue を作成してフラグを立てることができます。これは継続的な改善プロセスに直接フィードバックされます。
- 提出者のレビュー
GitHub Copilot の推奨事項を実行する前に、2 つの層のレビューが行われます。まず最初の段階は、問題を投稿した本人によるものです。
投稿者は、ユーザーが報告した問題を再現しようと試みます。GitHub Copilot がコメントで提供するチェックリストは、コミュニティマネージャー、サポートエージェント、営業担当者を専門レベルのテスト手順へと導きます。アクセシビリティに関する専門知識は不要です。各項目には平易な言葉による説明、ステップバイステップの手順、およびツールやドキュメントへのリンクが含まれています。
例として挙げられる質問は以下の通りです:
キーボードのみでページを操作できますか？「Tab」キーを押してインタラクティブな要素間を移動してください。すべてのボタン、リンク、フォームフィールドに到達できますか？常にフォーカスの位置を確認できますか？
画像には説明的な代替テキスト（alt text）がありますか？画像を右クリックして「Inspect（検証）」を選択し、マークアップを表示します。alt 属性は画像の目的を説明していますか、それとも一般的なファイル名ですか？
インタラクティブな要素は明確にラベル付けされていますか？スクリーンリーダーを使用して、ボタンまたはリンクへ移動します。その目的が明確に読み上げられますか？あるいは、ブラウザの開発者ツールにあるアクセシビリティツリー（accessibility tree）を確認し、要素が支援技術に対してどのように公開されているかを検査することもできます。
問題の再現が可能であれば、提出者はその課題をレビュー済みとしてマークし、次の GitHub Action がトリガーされます。再現できない場合は、ユーザーに連絡して詳細情報を求めます。新しい情報が届くと、提出者は手動で Actions タブからアクションを実行するか、関連するラベルを一時的に削除して再追加することで自動的に起動させることで、GitHub Copilot の分析を再度実行できます。AI が草案を作成しますが、検証は人間が行います。
- アクセシビリティチームによるレビュー
提出者が課題をレビュー済みとしてマークすると、GitHub Action がワークフロープロジェクトボード上のそのステータスを更新し、別のアクセシビリティファーストレスポンダーボードに追加します。これにより、エンジニア、デザイナー、チャンピオン、テストベンダー、マネージャーで構成されるアクセシビリティチームに対して、GitHub Copilot の分析がレビューの準備ができていることが通知されます。
チームは GitHub Copilot の分析を検証し、深刻度のレベル、WCAG（Web Content Accessibility Guidelines）のマッピング、およびカテゴリラベルを確認して、AI が誤った部分を修正します。不一致がある場合は、人間の判断を正解とみなします。これらの修正内容は記録され、プロンプトファイルの改善に活用されて、将来の精度が向上します。
検証が完了すると、チームは解決策の方針を決定します：
ドキュメントまたは設定の更新：ユーザーに対して直接解決策を提供する。
アクセシビリティチームによるコード修正：プルリクエストを直接作成する。
サービスチームの割り当て：該当するサービスチームに課題を割り当て、解決まで追跡します。
進捗経路が確定すると、チームは課題を「トリアージ済み」としてマークします。その後、アクションによって提出者に再割り当てされ、提出者がユーザーへ計画を伝達し、何が行われ、何を期待すべきかを知らせます。
- 監査へのリンク
レビュープロセスの一環として、チームはユーザーおよび顧客からのフィードバックを公式なアクセシビリティ監査システムに紐付けます。
約75〜80%のケースでは、報告された課題は内部監査ですでに把握している事象に対応しています。重複を作成するのではなく、既存の内部監査課題を見つけ、「顧客報告」ラベルを追加します。これにより、実際の影響に基づいて優先順位を決定できます。例えば、技術的には Sev1 よりも Sev2 の方が重要度が低いと見なされる場合でも、複数のユーザーから報告があれば、その優先度を上げます。
フィードバックによって新たな事象が明らかになった場合は、新しい監査課題を作成し、追跡用課題にリンクします。
- 情報のループ完了
これは信頼構築において最も重要なステップです。アクセシビリティの障壁を報告するために時間を割いてくれたユーザーには、そのフィードバックが具体的な行動につながったことを知る権利があります。
解決策の道筋が決まると、提出者は元のユーザーに連絡し、計画の内容（何が修正され、何を期待すべきか）を伝えます。修正がリリースされると、提出者は再度フォローアップを行い、ユーザーにテストを依頼します。ほとんどの問題はコミュニティディスカッションボードから発生するため、確認メッセージはそこで全員が見られるように投稿されます。
ユーザーが修正が機能していると確認すれば、追跡用イシューはクローズされます。しかし、修正が問題を完全に解決していない場合は、提出者がさらに詳細情報を収集し、プロセスはアクセシビリティチームによるレビューの段階に戻ります。ユーザーが自分にとって修正が機能すると確認するまで、イシューをクローズすることはありません。
- 継続的な改善
イシューがクローズされた時点でワークフローが終わるわけではありません。それは自己フィードバックする仕組みとなっています。
提出者やアクセシビリティチームのメンバーが、GitHub Copilot の出力に不正確な点を見つけた場合、結果の見直しを要求する新しいイシューを開きます。すべての GitHub Copilot 分析コメントには、このイシューを作成するためのリンクが下部に含まれており、フィードバックループはワークフローそのものに組み込まれています。チームはその不正確性をレビューし、修正内容は前述のカスタムインストラクションおよびプロンプトファイルへのプルリクエストとして反映されます。
また、新しいアクセシビリティガイダンスの統合も自動化されています。専用の GitHub Action が内部のアクセシビリティガイドリポジトリを毎週スキャンし、変更点を自動的に GitHub Copilot のカスタムインストラクションに取り込みます。
目標は完璧さではなく、継続的な改善です。四半期ごとに精度指標を見直し、指示を洗練させています。これらの見直しは、解決までの時間、WCAG（Web Content Accessibility Guidelines）の失敗パターン、およびフィードバック量の傾向を追跡する四半期報告書と年度報告書に反映され、リーダーシップに対して進捗と依然として残る課題の両方に対する可視性を提供します。このシステムは時間の経過とともに賢くなり、その成果を示すデータも既に揃っています。
数値で見るインパクト
1 年前、アクセシビリティに関するフィードバックのほぼ半分が 300 日以上未解決のまま放置されていました。現在では、その backlog（滞留分）は単に縮小しただけではなく、完全に解消されています。そして改善はこれだけで終わるものではありません。
89% の課題が 90 日以内にクローズされるようになりました（前年比 21% から上昇）
平均解決時間が 62% 短縮されました（118 日 → 45 日）
手動の管理業務に要する時間が 70% 削減されました
30 日以内に解決された課題が 1,150% 増加しました（前年比 4 件 → 50 件）
重大度レベル 1 のクリティカルな課題が 50% 減少しました
直近の四半期では、全課題が 60 日以内にクローズされました
これらの進捗は、GitHub Actions（GitHub Actions）によって生成された自動化された週次および四半期レポートを通じて追跡されており、最も頻繁に失敗する WCAG の基準や、解決時間の推移傾向を明確に示しています。
数値の向こう側で
James という名前のユーザーから、GitHub Copilot CLI（GitHub Copilot コマンドラインインターフェース）がアクセシビリティに対応していないとのメールが届きました。装飾的な書式設定がスクリーンリーダーにとってノイズとなり、対話型要素を操作することが不可能でした。
チームメンバーが追跡用イシューを作成しました。数分後、GitHub Copilot がそのレポートを分析し、ジェームズの説明を特定の技術概念にマッピングし、内部ドキュメントへのリンクを提供するとともに、提出者がジェームズと同じように製品を体験できる再現手順を示しました。
この文脈から、チームメンバーはエンジニアリングチームが今年早些にすでにアクセシビリティ対応の CLI 更新（CLI: コマンドラインインターフェース）をリリースしていたことに気づきました。ジェームズは単にその事実を知りませんでした。
彼らは即座に返信しました。その返答とは？「–screen-reader モード（スクリーンリーダーモード）に言及していただきありがとうございます。これは非常に役立つと確信しています。」
AI ワークフローが問題を正しく特定したおかげ、私たちは数時間で不満を解決へと転換できました。
しかし、最もやりがいを感じる結果は速度そのものではなく、ユーザーからのフィードバックです。単に私たちが対応したというだけでなく、修正が実際に彼らの役に立ったという点です：
「高コントラストテーマ（high contrast theme: 高コントラストテーマ）における貢献グラフの更新をチームに心から感謝します。グリッドエッジ周囲へのボーダー追加は小さな変更ですが、意味のある改善です。続けてください！」
「GitHub を活用したワークフローのために複数のラベルを作成したい場合を考えましょう：バグ、機能強化、依存関係の更新など…。しかし、もしあなたが視覚障害者ならどうでしょうか？以前はランダムに与えられた 16 進数コード（hex codes: 16 進数コード）しかありませんでした… しかし今は修正され、これらの色には意味のある英語名が付けられました。よくやった、GitHub！」
「これはあまりプロフェッショナルではないかもしれませんが、私は実際に叫んでしまいました！この修正のおかげで一日が明るくなりました… これまでは妻に GitHub のイシューを管理してもらっていましたが、今では自分でナビゲートできるようになりました。これにより少し自立できるようになったことは非常に意味があり、改めて感謝申し上げます。」
その自立こそが目的です。すべてのワークフロー、すべての自動化、すべてのレビューは、このような瞬間が例外ではなく当然の期待となるために存在しています。
より大きな視点
こうした物語は、なぜ基盤が重要なのかを思い出させてくれます。デザイン注釈、コードスキャナ、アクセシビティの推進者、障害を持つ人々とのテスト—これらは AI によって置き換えられるものではありません。むしろ、AI を活用したワークフローを効果的なものにする要素です。その人的な基盤がなければ、AI は単に要点を見失うためのより速い手段に過ぎません。
私たちはまだ学びの最中にあり、システムも進化し続けています。しかし、フィードバックのすべてから何かを学び、その知識は現在、私たちのチームやユーザー、そして構築するツールへと継続的に還元されています。
リポジトリを維持している方なら—大規模なエンタープライズプロジェクトでも週末に開発するオープンソースライブラリーでも—今日からこのようなシステムを構築できます。小さく始めてください。アクセシビティ用のイシューテンプレートを作成し、チームのアクセシビリティ基準を記した .github/copilot-instructions.md ファイルを追加してください。AI にトリアージとフォーマット処理を任せることで、チームは本当に重要なこと—より包括的なコードを書くことに集中できます。
GitHub を利用中にアクセシビリティの障壁に直面した場合は、ぜひフィードバックをお寄せください。その意見は単なるバックログとして埋もれることはありません。私たちは耳を傾けており、今やそれを実現するためのシステムを整えています。
「Continuous AI for accessibility: How GitHub transforms feedback into inclusion」という記事は、The GitHub Blog で最初に公開されました。
原文を表示
For years, accessibility feedback at GitHub didn’t have a clear place to go.
Unlike typical product feedback, accessibility issues don’t belong to any single team—they cut across the entire ecosystem. For example, a screen reader user might report a broken workflow that touches navigation, authentication, and settings. A keyboard-only user might hit a trap in a shared component used across dozens of pages. A low vision user might flag a color contrast issue that affects every surface using a shared design element. No single team owns any of these problems—but every one of them blocks a real person.
These reports require coordination that our existing processes weren’t originally built for. Feedback was often scattered across backlogs, bugs lingered without owners, and users followed up to silence. Improvements were often promised for a mythical “phase two” that rarely materialized.
We knew we needed to change this. But before we could build something better, we had to lay the groundwork—centralizing scattered reports, creating templates, and triaging years of backlog. Only once we had that foundation in place could we ask: How can AI make this easier?
The answer was an internal workflow, powered by GitHub Actions, GitHub Copilot, and GitHub Models, that ensures every piece of user and customer feedback becomes a tracked, prioritized issue. When someone reports an accessibility barrier, their feedback is captured, reviewed, and followed through until it’s addressed. We didn’t want AI to replace human judgment—we wanted it to handle repetitive work so humans could focus on fixing the software.
This is how we went from chaos to a system where every piece of accessibility feedback is tracked, prioritized, and acted on—not eventually, but continuously.
Accessibility as a living system
Continuous AI for accessibility weaves inclusion into the fabric of software development. It’s not a single product or a one-time audit—it’s a living methodology that combines automation, artificial intelligence, and human expertise.
This philosophy connects directly to our support for the 2025 Global Accessibility Awareness Day (GAAD) pledge: strengthening accessibility across the open source ecosystem by ensuring user and customer feedback is routed to the right teams and translated into meaningful platform improvements.
The most important breakthroughs rarely come from code scanners—they come from listening to real people. But listening at scale is hard, which is why we needed technology to help amplify those voices. We built a feedback workflow that functions less like a static ticketing system and more like a dynamic engine—leveraging GitHub products to clarify, structure, and track user and customer feedback, turning it into implementation-ready solutions.
Designing for people first
Before jumping into solutions, we stepped back to understand who this system needed to serve:
Issue submitters: Community managers, support agents, and sales reps submit issues on behalf of users and customers. They aren’t always accessibility experts, so they need a system that guides them and teaches accessibility concepts in the flow of work.
Accessibility and service teams: Engineers and designers responsible for fixes need structured, actionable data—reproducible steps, WCAG mapping, severity scores, and clear ownership.
Program and product managers: Leadership needs visibility into pain points by category, trends, and progress over time to allocate resources strategically.
With these personas in mind, we knew we wanted to 1) treat feedback as data flowing through a pipeline and 2) build a system able to evolve with us.
How feedback flows
With that foundation set, we built an architecture around an event-driven pattern, where each step triggers a GitHub Action that orchestrates what comes next—ensuring consistent handling no matter where the feedback originates. We built this system largely by hand starting in mid-2024. Today, tools like Agentic Workflows let you create GitHub Actions using natural language—meaning this kind of system could be built in a fraction of the time.
The workflow reacts to key events: Issue creation launches GitHub Copilot analysis via the GitHub Models API, status changes initiate hand-offs between teams, and resolution triggers submitter follow-up with the user. Every Action can also be triggered manually or re-run as needed—automation covers the common path, while humans can step in at any point.
Feedback isn’t just captured—it continuously flows through the right channels, providing visibility, structure, and actionability at every stage.
*Click images to enlarge.
- Actioning intake
Feedback can come from anywhere—support tickets, social media posts, email, direct outreach—but most users choose the GitHub accessibility discussion board. It’s where they can work together and build community around shared experiences. Today, 90% of the accessibility feedback flows through that single channel. Because posts are public, other users can confirm the problem, add context, or suggest workarounds—so issues often arrive with richer detail than a support ticket ever could. Regardless of the source, every piece of feedback gets acknowledged within five business days, and even feedback we can’t act on gets a response pointing to helpful resources.
When feedback requires action from internal teams, a team member manually creates a tracking issue using our custom accessibility feedback issue template. Issue templates are pre-defined forms that standardize how information is collected when opening a new issue. The template captures the initial context—what the user reported, where it came from, and which components are involved—so nothing is lost between intake and triage.
This is where automation kicks in. Creating the issue triggers a GitHub Action that engages GitHub Copilot, and a second Action adds the issue to a project board, providing a centralized view of current status, surfacing trends, and helping identify emerging needs.
- GitHub Copilot analysis
With the tracking issue created, a GitHub Action workflow programmatically calls the GitHub Models API to analyze the report. We chose stored prompts over model fine-tuning so that anyone on the team can update the AI’s behavior through a pull request—no retraining pipeline, no specialized ML knowledge required.
We configured GitHub Copilot using custom instructions developed by our accessibility subject matter experts. Our prompt serves two roles: triage analysis, which classifies issues by WCAG violation, severity, and affected user group, and accessibility coaching, where GitHub Copilot acts as a subject-matter expert to help teams write and review accessible code.
These instruction files point to our accessibility policies, component library, and internal documentation that details how we interpret and apply WCAG success criteria. When our standards evolve, the team updates the markdown and instruction files via pull request—the AI’s behavior changes with the next run, not the next training cycle. For a detailed walkthrough of this approach, see our guide on optimizing GitHub Copilot custom instructions for accessibility.
The automation works in two steps. First, an Action fires on issue creation and triggers GitHub Copilot to analyze the report. GitHub Copilot populates approximately 80% of the issue’s metadata automatically—over 40 data points including issue type, user segment, original source, affected components, and enough context to understand the user’s experience. The remaining 20% requires manual input from the team member. GitHub Copilot then posts a comment on the issue containing:
A summary of the problem and user impact
Suggested WCAG success criteria for potential violations
Severity level (sev1 through sev4, where sev1 is critical)
Impacted user groups (screen reader users, keyboard users, low vision users, etc.)
Recommended team assignment (design, engineering, or both)
A checklist of low-barrier accessibility tests so the submitter can verify the issue
Then a second Action fires on that comment, parses the response, applies labels based on the severity GitHub Copilot assigned, updates the issue’s status on the project board, and assigns it to the submitter for review.
If GitHub Copilot’s analysis seems off, anyone can flag it by opening an issue describing what it got wrong and what it should have said—feeding directly into our continuous improvement process.
- Submitter review
Before we act on GitHub Copilot’s recommendations, two layers of review happen—starting with the issue submitter.
The submitter attempts to replicate the problem the user reported. The checklist GitHub Copilot provides in its comment guides our community managers, support agents, and sales reps through expert-level testing procedures—no accessibility expertise required. Each item includes plain-language explanations, step-by-step instructions, and links to tools and documentation.
Example questions include:
Can you navigate the page using only a keyboard? Press “Tab” to move through interactive elements. Can you reach all buttons, links, and form fields? Can you see where your focus is at all times?
Do images have descriptive alt text? Right-click an image and select “Inspect” to view the markup. Does the alt attribute describe the image’s purpose, or is it a generic file name?
Are interactive elements clearly labeled? Using a screen reader, navigate to a button or link. Is its purpose announced clearly? Alternatively, review the accessibility tree in your browser’s developer tools to inspect how elements are exposed to assistive technologies.
If the submitter can replicate the problem, they mark the issue as reviewed, which triggers the next GitHub Action. If they can’t reproduce it, they reach out to the user for more details. Once new information arrives, the submitter can re-run the GitHub Copilot analysis—either by manually triggering the Action from the Actions tab or by removing and re-adding the relevant label to kick it off automatically. AI provides the draft, but humans provide the verification.
- Accessibility team review
Once the submitter marks the issue as reviewed, a GitHub Action updates its status on the workflow project board and adds it to a separate accessibility first responder board. This alerts the accessibility team—engineers, designers, champions, testing vendors, and managers—that GitHub Copilot’s analysis is ready for their review.
The team validates GitHub Copilot’s analysis—checking the severity level, WCAG mapping, and category labels—and corrects anything the AI got wrong. When there’s a discrepancy, we assume the human is correct. We log these corrections and use them to refine the prompt files, improving future accuracy.
Once validated, the team determines the resolution approach:
Documentation or settings update: Provide the solution directly to the user.
Code fix by the accessibility team: Create a pull request directly.
Service team needed: Assign the issue to the appropriate service team and track it through resolution.
With a path forward set, the team marks the issue as triaged. An Action then reassigns it to the submitter, who communicates the plan to the user—letting them know what’s being done and what to expect.
- Linking to audits
As part of the review process, the team connects user and customer feedback to our formal accessibility audit system.
Roughly 75–80% of the time, reported issues correspond to something we already know about from internal audits. Instead of creating duplicates, we find the existing internal audit issue and add a customer-reported label. This lets us prioritize based on real-world impact—a sev2 issue might technically be less critical than a sev1, but if multiple users are reporting it, we bump up its priority.
If the feedback reveals something new, we create a new audit issue and link it to the tracking issue.
- Closing the loop
This is the most critical step for trust. Users who take the time to report accessibility barriers deserve to know their feedback led to action.
Once a resolution path is set, the submitter reaches out to the original user to let them know the plan—what’s being fixed, and what to expect. When the fix ships, the submitter follows up again and asks the user to test it. Because most issues originate from the community discussion board, we post confirmations there for everyone to see.
If the user confirms the fix works, we close the tracking issue. If the fix doesn’t fully address the problem, the submitter gathers more details and the process loops back to the accessibility team review. We don’t close issues until the user confirms the fix works for them.
- Continuous improvement
The workflow doesn’t end when an issue closes—it feeds back into itself.
When submitters or accessibility team members spot inaccuracies in GitHub Copilot’s output, they open a new issue requesting a review of the results. Every GitHub Copilot analysis comment includes a link to create this issue at the bottom, so the feedback loop is built into the workflow itself. The team reviews the inaccuracy, and the correction becomes a pull request to the custom instruction and prompt files described earlier.
We also automate the integration of new accessibility guidance. A separate GitHub Action scans our internal accessibility guide repository weekly and incorporates changes into GitHub Copilot’s custom instructions automatically.
The goal isn’t perfection—it’s continuous improvement. Each quarter, we review accuracy metrics and refine our instructions. These reviews feed into quarterly and fiscal year reports that track resolution times, WCAG failure patterns, and feedback volume trends—giving leadership visibility into both progress and persistent gaps. The system gets smarter over time, and now we have the data to show it.
Impact in numbers
A year ago, nearly half of accessibility feedback sat unresolved for over 300 days. Today, that backlog isn’t just smaller—it’s gone. And the improvements don’t stop there.
89% of issues now close within 90 days (up from 21%)
62% reduction in average resolution time (118 days → 45 days)
70% reduction in manual administrative time
1,150% increase in issues resolved within 30 days (4 → 50 year-over-year)
50% reduction in critical sev1 issues
100% of issues closed within 60 days in our most recent quarter
We track this through automated weekly and quarterly reports generated by GitHub Actions—surfacing which WCAG criteria fail most often and how resolution times trend over time.
Beyond the numbers
A user named James emailed us to report that the GitHub Copilot CLI was inaccessible. Decorative formatting created noise for screen readers, and interactive elements were impossible to navigate.
A team member created a tracking issue. Within moments, GitHub Copilot analyzed the report—mapping James’s description to specific technical concepts, linking to internal documentation, and providing reproduction steps so the submitter could experience the product exactly as James did.
With that context, the team member realized our engineering team had already shipped accessible CLI updates earlier in the year—James simply wasn’t aware.
They replied immediately. His response? “Thanks for pointing out the –screen-reader mode, which I think will help massively.”
Because the AI workflow identified the problem correctly, we turned a frustration into a resolution in hours.
But the most rewarding result isn’t the speed—it’s the feedback from users. Not just that we responded, but that the fixes actually worked for them:
“Huge thanks to the team for updating the contributions graph in the high contrast theme. The addition of borders around the grid edges is a small but meaningful improvement. Keep it up!”
“Let’s say you want to create several labels for your GitHub-powered workflow: bug, enhancement, dependency updates… But what if you are blind? Before you had only hex codes randomly thrown at you… now it’s fixed, and those colors have meaningful English names. Well done, GitHub!”
“This may not be very professional but I literally just screamed! This fix has actually made my day… Before this I was getting my wife to manage the GitHub issues but now I can actually navigate them by myself! It means a lot that I can now be a bit more independent so thank you again.”
That independence is the point. Every workflow, every automation, every review—it all exists so moments like these are the expectation, not the exception.
The bigger picture
Stories like these remind us why the foundation matters. Design annotations, code scanners, accessibility champions, and testing with people with disabilities—these aren’t replaced by AI. They are what make AI-assisted workflows effective. Without that human foundation, AI is just a faster way to miss the point.
We’re still learning, and the system is still evolving. But every piece of feedback teaches us something, and that knowledge now flows continuously back to our team, our users, and the tools we build.
If you maintain a repository—whether it’s a massive enterprise project or a weekend open-source library—you can build this kind of system today. Start small. Create an issue template for accessibility. Add a .github/copilot-instructions.md file with your team’s accessibility standards. Let AI handle the triage and formatting so your team can focus on what really matters: writing more inclusive code.
And if you hit an accessibility barrier while using GitHub, please share your feedback. It won’t disappear into a backlog. We’re listening—and now we have the system to follow through.
The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み