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