屏幕阅读器可将时间线作为列表进行导航
GitHub 让屏幕阅读器可以把 issue 和 pull request 时间线当作列表来导航，播报列表结构、条目数量与当前位置，并在“加载更多”后播报新加载的事件数。该改进覆盖 issue、PR、commit、secret scanning alert 与 license compliance alert 时间线，已在 github.com 和 GitHub Enterprise Server 3.23 上线。
原贴
查看原文原文
中文翻译
屏幕阅读器现在可以将 issue 和 pull request 时间线作为列表进行导航。
当你浏览时间线时，辅助技术可以播报列表结构、条目数量、当前位置以及如何在事件之间移动。
这让理解较长的历史记录、并跳转到相关更新变得更容易，而无需依赖视觉扫描。
当你选择“加载更多”或“全部加载”后，焦点移动到最新事件时，屏幕阅读器现在会播报加载了多少个事件（例如“已加载 11 个新条目”）。
此前，新事件加载后不会有任何播报。
本次更新不会改变时间线的外观或行为，但改善了它们与辅助技术的配合方式。
你可以在 issue、pull request、commit、secret scanning alert 和 license compliance alert 时间线上使用这些改进。
本次更新已在 github.com 和 GitHub Enterprise Server 3.23 上提供。
要试用它，请打开一个历史记录较长的 issue 或 pull request，并使用 VoiceOver、NVDA 或 JAWS 等屏幕阅读器翻看时间线。
屏幕阅读器会将时间线作为一个带数量和位置的列表进行播报，选择“加载更多”会报告加载的新事件数量。
要了解更多信息，请参阅我们的 issue 屏幕阅读器指南。
核心信息
GitHub 让屏幕阅读器可以把 issue 和 pull request 时间线当作列表来导航，播报列表结构、条目数量与当前位置，并在“加载更多”后播报新加载的事件数。该改进覆盖 issue、PR、commit、secret scanning alert 与 license compliance alert 时间线，已在 github.com 和 GitHub Enterprise Server 3.23 上线。
- GitHub 让屏幕阅读器可以把 issue 和 pull request 时间线当作列表来导航，播报列表结构、条目数量与当前位置，并在“加载更多”后播报新加载的事件数。该改进覆盖 issue、PR、commit、secret scanning alert 与 license compliance alert 时间线，已在 github.com 和 GitHub Enterprise Server 3.23 上线。
- 原贴提到：Screen readers can now navigate issue and pull request timelines as a li
- 来源：github.blog
详细解读
这是什么信号：GitHub 把 issue 和 PR 的时间线从“一串平铺的事件流”改造成了对辅助技术可识别的列表结构。屏幕阅读器现在能播报列表结构、条目总数、当前位置以及事件之间的移动方式；“加载更多/全部加载”触发的异步追加，也第一次有了明确的数量播报（原文示例为“11 new items loaded”）。这条 changelog 本身很小，但它反映的是一类正在发生的产品取向：无障碍不再是事后补丁，而是被纳入基础信息架构。
为什么重要：时间线是 GitHub 上信息密度最高的组件之一，一个长跑 issue 或 PR 往往累积几十上百条评论、提交引用、状态变更和机器人事件。对依赖屏幕阅读器的开发者来说，之前的痛点不是“读不到”，而是“读不出结构”——无法知道总共有多少事件、自己处在第几条、后面还有没有、点了“加载更多”到底发生了什么。列表语义 + 位置播报 + 加载结果播报，把“线性盲读”变成了“可定位导航”，这是可用性量级的变化，而不只是体验优化。
对谁有价值：最直接的是使用 VoiceOver、NVDA、JAWS 的盲人和低视力开发者，他们终于能在长历史里跳转而不是硬扛到底。其次是负责前端组件库或内部协作平台的团队——GitHub 给出了一个可参照的实现范式：列表语义、位置信息、异步加载后的实时播报三者要成套出现。第三类是面向企业客户交付、需要应对无障碍合规审查（如采购方的无障碍条款、政府与公共部门项目）的团队，这类改动会进入他们的评估清单。
可以怎么行动：第一，如果你的团队在用 GitHub Enterprise Server，检查目标版本是否达到 3.23，否则这些改进不会出现在自建实例上。第二，组织一次实测：找一个历史很长的 issue 或 PR，用 VoiceOver、NVDA 或 JAWS 走一遍时间线，确认列表结构、条目计数、当前位置和“加载更多”后的数量播报是否符合预期。第三，把这次的交互模式反向用到自己的产品上——凡是无限滚动、动态追加、事件流式的列表，都应该问三个问题：有没有列表语义？有没有总量与位置？异步追加后有没有播报？第四，把无障碍路径纳入常规回归测试，而不是等合规审计时才临时补。
风险与限制：这项改进只发生在 GitHub 自己的时间线组件上，第三方 GitHub App、自研的看板或评论面板不会自动获得同等能力；实际播报效果仍取决于屏幕阅读器本身的实现和用户的配置，不同读屏软件对“数量/位置”的表达可能不一致；官方明确说明时间线的外观与行为没有变化，因此这是纯辅助技术侧收益，不会改变依赖视觉浏览的用户的既有工作流；GitHub Enterprise Server 用户存在版本门槛，升级前无法受益。
信息差价值
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《屏幕阅读器可将时间线作为列表进行导航》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。
参考来源
TOPIC HUBS
延伸专题
AI SUMMARY
这篇文章回答了什么
屏幕阅读器可将时间线作为列表进行导航主要讲什么？
GitHub 让屏幕阅读器可以把 issue 和 pull request 时间线当作列表来导航，播报列表结构、条目数量与当前位置，并在“加载更多”后播报新加载的事件数。该改进覆盖 issue、PR、commit、secret scanning alert 与 license compliance alert 时间线，已在 github.com 和 Git…
这篇文章最值得关注的要点是什么？
GitHub 让屏幕阅读器可以把 issue 和 pull request 时间线当作列表来导航，播报列表结构、条目数量与当前位置，并在“加载更多”后播报新加载的事件数。该改进覆盖 issue、PR、commit、secret scann…；原贴提到：Screen readers can now navigate issue and pull request timelines as a li；来源：github.blog
这篇文章和哪些AI专题相关？
它适合放在AI日报、AI工具、Agent工作流专题里阅读。 关联原因：这篇内容命中「热点解读」等主题信号。；这篇内容来自该专题长期覆盖的栏目。；这篇内容来自该专题长期覆盖的栏目。
阅读这篇文章建议先理解哪些关键词？
建议先理解AI日报、每日AI日报、AI信号、热点解读、BuilderPulse这些关键词，再结合正文判断工具、机会或风险是否值得进入自己的工作流。