GitHub 正在測試一個實驗性的通用無障礙智能體，旨在幫助工程師更高效地解決數字無障礙問題。該項目有兩個核心目標：第一，在 GitHub Copilot 命令行和 VS Code 集成中為工程師提供即時的無障礙問題解答；第二，在代碼進入生產環境之前自動捕獲並修復簡單、客觀的無障礙缺陷。目前，該智能體已對 3535 個拉取請求進行了審查，解決率達到 68%。按出現頻率排序，最常見的五類問題依次是：確保結構與關係對輔助技術清晰可見；為交互控件提供明確且簡潔的名稱；確保用户能感知到重要通知；為非文本內容提供文本替代；以及按邏輯順序移動鍵盤焦點。每解決一個問題，就減少了一處可能阻礙使用輔助技術用户訪問 GitHub 的障礙。
構建過程中，團隊特別強調了心態的重要性。他們根據社會模型理解，無障礙障礙往往源於環境設計，因此智能體並非試圖獨自“解決”無障礙問題，而是增強開發者的能力，幫助他們消除因界面構建方式產生的障礙。智能體並非萬能藥，合理劃定其職責範圍有助於快速啓動項目並獲得更多支持。
GitHub 擁有成熟的無障礙問題記錄系統，包括結構化報告模板、復現步驟、嚴重級別、服務區域、WCAG 成功標準等元數據，以及與修復 PR 的交叉鏈接。這些高度結構化的問題數據為智能體提供了理想的參考內容。團隊指示智能體從歷史問題中學習，利用 LLM 的模糊匹配能力而非確定性匹配，從而找到關聯的代碼和語言片段。
為了提升效率，智能體採用了子智能體架構。最初是單一智能體，但很快因侷限性而改為兩個專用子智能體：一個負責被動審查和研究，另一個負責主動實施。兩者通過模板化輸出進行通信，由父智能體協調。這種設計提供了升級檢查點、基於複雜度的行為控制、過濾功能和可追溯性。指令按線性順序執行，鏡像人工審計、修復和報告的工作流程。
智能體還通過代碼複雜度腳本和高風險模式識別來管理侷限。當代碼複雜度超過閾值或涉及拖放、富文本編輯器等高風險模式時，智能體不會自動修改代碼，而是建議用户諮詢無障礙團隊。此外，團隊特意設置了反遊戲機制，防止 LLM 繞過不生成代碼的指令。
儘管智能體取得了顯著成果，但團隊也承認，程序可確定的問題並不能覆蓋所有無障礙需求。目前智能體只適用於約 25 個（共 55 個）WCAG A 級和 AA 級成功標準中的一部分。未來，GitHub 計劃繼續分享經驗，幫助其他團隊在無障礙之旅中少走彎路。