https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/#impact-in-numbers/?wt.mc_id=3reg_webpage_reactor
作者：Carie Fisher
排版：Alan Wang
AI 自动化处理无障碍反馈的分类工作，使我们能够专注于修复障碍——将混乱的积压转变为持续、快速的解决方案。

多年来，在 GitHub 上，无障碍反馈一直没有一个明确的去处。

与典型的产品反馈不同，无障碍问题不属于任何一个单一团队——它们横跨整个生态系统。例如，一位屏幕阅读器用户可能会报告一个涉及导航、身份验证和设置的工作流程中断的问题。一位仅使用键盘的用户可能会在一个被数十个页面复用的共享组件中遇到卡住的问题。一位低视力用户可能会指出一个影响所有使用共享设计元素界面的颜色对比度问题。这些问题没有任何一个单一团队负责——但每一个都阻碍着一个真实的人。

这些报告需要进行协调，而我们现有的流程在最初设计时并未考虑到这一点。反馈常常分散在各个待办事项中，缺陷在没有负责人的情况下长期存在，而用户的跟进却石沉大海。改进往往被承诺在一个神话般的“第二阶段”，但很少真正实现。

我们知道我们需要改变这一点。但在我们能够构建更好的东西之前，我们必须打好基础——集中分散的报告、创建模板，并对多年的积压进行分类整理。只有在我们建立了这个基础之后，我们才能问：AI 如何让这一切变得更简单？

答案是一个内部工作流，由 GitHub Actions、GitHub Copilot 和 GitHub Models 提供支持，确保每一条用户和客户反馈都成为一个被跟踪、被优先排序的问题。当有人报告一个无障碍使用方面的障碍时，他们的反馈会被捕获、审查，并持续跟进直到被解决。我们不希望 AI 取代人类判断——我们希望它处理重复性工作，让人类能够专注于修复软件。

这就是我们如何从混乱走向一个系统，在这个系统中，每一条无障碍反馈都被跟踪、优先排序并付诸行动——不是最终某一天，而是持续不断地进行。

无障碍作为一个动态系统

面向无障碍的持续 AI 将包容性编织进软件开发的结构之中。它不是一个单一产品，也不是一次性的审计——它是一种活的方法论，将自动化、人工智能和人类专业知识结合在一起。

这一理念与我们对 2025 年全球无障碍意识日（GAAD）承诺的支持直接相关：通过确保用户和客户反馈被路由到正确的团队，并转化为有意义的平台改进，从而加强整个开源生态系统的无障碍能力。

最重要的突破很少来自代码扫描器——它们来自倾听真实的人。但大规模倾听并非易事，这就是为什么我们需要技术来帮助放大这些声音。我们构建了一个反馈工作流，它不像一个静态的工单系统，更像一个动态引擎——利用 GitHub 产品来澄清、结构化和跟踪用户与客户反馈，将其转化为可实施的解决方案。

以人为本的设计

在跳入解决方案之前，我们先退一步来理解这个系统需要服务于谁：

• 问题提交者：社区经理、支持人员和销售代表代表用户和客户提交问题。他们不总是无障碍专家，因此他们需要一个能够引导他们并在工作流程中教授无障碍概念的系统。

• 无障碍与服务团队：负责修复的工程师和设计师需要结构化、可执行的数据——可复现步骤、WCAG 映射、严重性评分，以及明确的责任归属。

• 项目与产品经理：管理层需要按类别、趋势以及随时间变化的进展来了解痛点，从而进行战略性资源分配。

基于这些角色，我们知道我们希望做到：

1. 将反馈视为通过管道流动的数据

2. 构建一个能够随我们一起演进的系统

反馈如何流动

在这个基础之上，我们围绕事件驱动模式构建了一个架构，其中每一步都会触发一个 GitHub Action 来编排下一步——无论反馈来自哪里，都确保一致的处理方式。我们从 2024 年年中开始主要通过手动构建这个系统。如今，像 Agentic Workflows 这样的工具让你可以使用自然语言创建 GitHub Actions——这意味着这种系统可以在更短的时间内构建完成。

该工作流会对关键事件作出反应：问题创建会通过 GitHub Models API 启动 GitHub Copilot 分析，状态变化会在团队之间发起交接，而解决会触发提交者与用户的后续跟进。每个 Action 也可以根据需要手动触发或重新运行——自动化覆盖常见路径，而人类可以在任何时候介入。

反馈不仅被捕获——它会持续流经正确的渠道，在每一个阶段提供可见性、结构和可执行性。

1. 处理接收

反馈可以来自任何地方——支持工单、社交媒体帖子、电子邮件、直接联系——但大多数用户选择 GitHub 无障碍讨论版块。在那里，他们可以协作并围绕共同的体验建立社区。如今，90% 的无障碍反馈通过这个单一渠道流入。由于帖子是公开的，其他用户可以确认 issue、补充上下文或提出变通方法——因此 issue 通常比支持工单拥有更丰富的细节。无论来源如何，每一条反馈都会在五个工作日内得到确认，即使是我们无法采取行动的反馈，也会得到指向有用资源的回复。

当反馈需要内部团队采取行动时，团队成员会使用我们自定义的无障碍反馈 issue 模板手动创建一个跟踪 issue。issue 模板是在创建新 issue 时用于标准化信息收集的预定义表单。该模板捕获初始上下文——用户报告了什么、来自哪里以及涉及哪些组件——从而确保在接收与分类之间不会丢失任何信息。

这就是自动化开始发挥作用的地方。创建 issue 会触发一个 GitHub Action 来调用 GitHub Copilot，第二个 Action 会将问题添加到项目看板中，从而提供当前状态的集中视图、揭示趋势并帮助识别新出现的需求。

2. GitHub Copilot 分析

在创建跟踪 issue 之后，一个 GitHub Action 工作流通过编程方式调用 GitHub Models API 来分析报告。我们选择使用存储的提示而不是模型微调，这样团队中的任何人都可以通过 pull request 更新 AI 的行为——无需重新训练流程，也不需要专业的机器学习知识。

我们使用由无障碍领域专家开发的自定义指令配置了 GitHub Copilot。我们的提示承担两个角色：分类分析（根据 WCAG 违规、严重性和受影响用户群体对 issue 进行分类）以及无障碍辅导（GitHub Copilot 作为领域专家帮助团队编写和审查无障碍代码）。

这些指令文件指向我们的无障碍策略、组件库以及内部文档，这些文档详细说明了我们如何解释和应用 WCAG 成功标准。当我们的标准演进时，团队通过 pull request 更新 markdown 和指令文件——AI 的行为会在下一次运行时改变，而不是下一次训练周期。有关这种方法的详细演练，请参阅我们关于优化 GitHub Copilot 自定义指令以实现无障碍的指南。

自动化分为两个步骤。首先，一个 Action 在 issue 创建时触发，并启动 GitHub Copilot 来分析报告。GitHub Copilot 会自动填充问题约 80% 的元数据——超过 40 个数据点，包括 issue 类型、用户细分、原始来源、受影响组件，以及足以理解用户体验的上下文。剩余 20% 需要团队成员手动输入。随后 GitHub Copilot 会在问题中发布一条评论，内容包括：

• 问题及用户影响的摘要

• 建议的 WCAG 成功标准（用于潜在违规）

• 严重性级别（sev1 至 sev4，其中 sev1 为严重）

• 受影响的用户群体（屏幕阅读器用户、键盘用户、低视力用户等）

• 建议的团队分配（设计、工程或两者）

• 一份低门槛的无障碍测试清单，供提交者验证问题

然后第二个 Action 会在该评论发布后触发，解析响应，根据 GitHub Copilot 分配的严重性应用标签，更新项目看板上的 issue 状态，并将其分配给提交者进行审核。

如果 GitHub Copilot 的分析看起来不准确，任何人都可以通过创建一个 issue 来标记它，描述它哪里出错以及应该如何表述——这将直接反馈到我们的持续改进流程中。

3. 提交者审核

在我们根据 GitHub Copilot 的建议采取行动之前，会进行两层审核——首先是 issue 提交者。

提交者尝试复现用户报告的问题。GitHub Copilot 在其评论中提供的清单引导我们的社区经理、支持人员和销售代表完成专家级测试流程——无需无障碍专业知识。每一项都包含通俗语言解释、逐步说明以及工具和文档链接。

示例问题包括：

• **你是否可以仅使用键盘导航页面？**按“Tab”键在交互元素之间移动。你是否可以访问所有按钮、链接和表单字段？你是否始终可以看到焦点位置？

• **图像是否具有描述性的 alt 文本？**右键单击图像并选择“检查”以查看标记。alt 属性是否描述了图像的用途，还是只是一个通用文件名？

• **交互元素是否有清晰的标签？**使用屏幕阅读器导航到按钮或链接。其用途是否被清晰地朗读？或者，查看浏览器开发者工具中的无障碍树，以检查元素如何暴露给辅助技术。

如果提交者能够复现问题，他们会将问题标记为已审核，这会触发下一个 GitHub Action。如果他们无法复现，他们会联系用户获取更多细节。一旦新信息到达，提交者可以重新运行 GitHub Copilot 分析——要么通过 Actions 标签手动触发 Action，要么通过移除并重新添加相关标签来自动触发。AI 提供草稿，但人类提供验证。

4. 无障碍团队审核

一旦提交者将 issue 标记为已审核，一个 GitHub Action 会更新其在工作流项目看板上的状态，并将其添加到一个单独的无障碍首响应看板中。这会通知无障碍团队——工程师、设计师、倡导者、测试供应商和管理人员——GitHub Copilot 的分析已准备好供他们审核。

团队会验证 GitHub Copilot 的分析——检查严重性级别、WCAG 映射和类别标签，并纠正 AI 出错的任何内容。当出现差异时，我们假设人类是正确的。我们记录这些更正，并使用它们来改进提示文件，从而提高未来的准确性。

一旦验证完成，团队会确定解决路径：

• 文档或设置更新：直接向用户提供解决方案。

• 由无障碍团队进行代码修复：直接创建 pull request。

• 需要服务团队：将 issue 分配给相应的服务团队并跟踪其解决过程。

确定前进路径后，团队将 issue 标记为已分类。随后一个 Action 会将其重新分配给提交者，由提交者将计划传达给用户——让他们知道正在做什么以及可以期待什么。

5. 关联审计

作为审核流程的一部分，团队将用户和客户反馈与我们的正式无障碍审计系统连接起来。

大约 75–80% 的情况下，报告的 issue 对应于我们在内部审计中已经知道的内容。我们不会创建重复项，而是找到现有的内部审计 issue 并添加一个客户报告标签。这使我们能够根据真实世界影响进行优先排序——一个 sev2 问题在技术上可能不如 sev1 严重，但如果有多个用户报告，我们会提高其优先级。

如果反馈揭示了新的问题，我们会创建一个新的审计 issue 并将其与跟踪 issue 关联。

6. 闭环

这是建立信任最关键的一步。花时间报告无障碍使用方面障碍的用户理应知道他们的反馈带来了行动。

一旦确定了解决路径，提交者会联系最初的用户，告知计划——将修复什么，以及可以期待什么。当修复上线后，提交者会再次跟进，并请用户进行测试。由于大多数 issue 源自社区讨论版块，我们会在那里发布确认信息供所有人查看。

如果用户确认修复有效，我们会关闭跟踪 issue。如果修复未完全解决问题，提交者会收集更多细节，流程会回到无障碍团队审核。我们不会在用户确认修复对他们有效之前关闭 issue。

7. 持续改进

当 issue 关闭时，工作流并不会结束——它会反馈回自身。

当提交者或无障碍团队成员发现 GitHub Copilot 输出中的不准确之处时，他们会创建一个新 issue，请求审查结果。每一条 GitHub Copilot 分析评论的底部都包含一个创建该 issue 的链接，因此反馈回路被构建在工作流本身中。团队会审查不准确之处，并将更正作为 pull request 提交到前面描述的自定义指令和提示文件中。

我们还自动化了新无障碍指南的集成。一个单独的 GitHub Action 每周扫描我们的内部无障碍指南仓库，并自动将更改纳入 GitHub Copilot 的自定义指令中。

目标不是完美——而是持续改进。每个季度，我们都会审查准确性指标并优化我们的指令。这些审查会进入季度和财年的报告中，跟踪解决时间、WCAG 失败模式以及反馈量趋势——为管理层提供对进展和持续差距的可见性。系统会随着时间变得更智能，而现在我们有数据来证明这一点。

影响数据

一年前，几乎一半的无障碍反馈在超过 300 天后仍未解决。如今，这一积压不仅变小了——而且已经消失。改进也不止于此。

• 89% 的 issue 现在在 90 天内关闭（从 21% 提升）

• 平均解决时间减少 62%（118 天 → 45 天）

• 人工管理时间减少 70%

• 30 天内解决的 issue 同比增长 1,150%（4 → 50）

• 关键 sev1 issue 减少 50%

• 在最近一个季度中，100% 的 issue 在 60 天内关闭

我们通过 GitHub Actions 自动生成的每周和季度报告来跟踪这些数据——揭示哪些 WCAG 标准最常失败以及解决时间如何随时间变化。

数据之外

一位名叫 James 的用户通过电子邮件向我们报告 GitHub Copilot CLI 无法访问。装饰性格式为屏幕阅读器带来了噪音，交互元素无法导航。

一位团队成员创建了一个跟踪问题。几乎在瞬间，GitHub Copilot 分析了该报告——将 James 的描述映射到具体的技术概念，链接到内部文档，并提供复现步骤，使提交者能够像 James 一样体验产品。

在这个上下文下，这位团队成员意识到我们的工程团队在今年早些时候已经发布了可访问的 CLI 更新——只是 James 并不知道。

他们立即回复。他的回应是？“感谢指出 --screen-reader 模式，我认为这会有极大的帮助。”

由于 AI 工作流正确识别了问题，我们在数小时内将挫折转化为解决方案。

但最有价值的结果不是速度——而是用户的反馈。不仅仅是我们做出了回应，而是这些修复对他们确实有效：

• “非常感谢团队在高对比主题中更新贡献图。在网格边缘添加边框是一个小但有意义的改进。继续加油！”

• “假设你想为你的 GitHub 工作流创建多个标签：bug、enhancement、dependency updates……但如果你是盲人呢？之前你只能看到随机的十六进制颜色代码……现在已经修复，这些颜色有了有意义的英文名称。做得好，GitHub！”

• “这可能听起来不太专业，但我真的刚刚尖叫了！这个修复真的改变了我的一天……在此之前，我一直让我的妻子帮我管理 GitHub issue，但现在我可以自己导航了！能够更独立对我来说意义重大，所以再次感谢。”

这种独立性正是关键。每一个工作流、每一个自动化、每一次审核——它们的存在都是为了让这样的时刻成为常态，而不是例外。

更大的图景

这样的故事提醒我们为什么基础很重要。设计标注、代码扫描器、无障碍倡导者以及与残障人士的测试——这些并不会被 AI 取代。它们正是让 AI 辅助工作流有效的原因。没有这种以人为本的基础，AI 只是更快地错过重点。

我们仍在学习，系统也在不断演进。但每一条反馈都会教会我们一些东西，而这些知识现在会持续回流到我们的团队、用户以及我们构建的工具中。

如果你在维护一个仓库——无论是大型企业项目还是周末的开源库——你今天就可以构建这样的系统。从小处开始。为无障碍创建一个 issue 模板。添加一个包含团队无障碍标准的 .github/copilot-instructions.md 文件。让 AI 处理分类和格式化，让你的团队专注于真正重要的事情：编写更具包容性的代码。

如果你在使用 GitHub 时遇到无障碍使用方面的障碍，请分享你的反馈。它不会消失在待办事项列表中。我们在倾听——现在我们也拥有了将其落实的系统。