GitHub在仓库首页突出无障碍声明：入口更容易找到，承诺仍要写明版本与已知限制

GitHub于2026年10月1日更新仓库概览，对根目录、.github目录或docs目录中的ACCESSIBILITY.md提供突出展示。公开仓库的Community Standards页面也可用于添加或提议无障碍声明。github.com所有套餐已支持，Enterprise Server将于3.24加入。

声明首先帮助使用者判断自己能否完成任务

以下为本文的文档建议。对于准备使用一款工具的人，“我们重视无障碍”提供的信息很有限。更有用的是说明哪些核心操作已经检查、采用什么版本与使用方式，以及还有哪些限制。用户据此判断是否适合自己的任务，维护者也能减少重复回答。

例如一款文件整理工具可以说明：选择文件、修改名称和确认结果这条流程是否能仅用键盘完成，出错信息能否被读屏软件读到，放大文字后是否仍能找到操作按钮。这些只是本文给出的写作方向，不代表任何特定项目已经完成测试。

AI模型生成的概念示意图，以清楚的入口与平缓路径表现可访问的信息，并非产品截图或真实设施照片。

把结论限定到实际检查过的范围

一次在某种浏览器和辅助工具组合上的检查，不能覆盖所有设备与使用情境。声明可以写明项目版本、最近核验日期、覆盖的主要流程和测试条件。没有完成评估的部分也应直接说明，让阅读者知道结论在哪里停止。

已知限制适合用用户能够理解的语言描述。例如“弹窗关闭后，键盘焦点可能无法回到原按钮”，比“存在焦点问题”更容易判断影响。若有可行的临时办法，也可以提供明确步骤，并把它与正式修复计划区分开，避免用户以为限制已经解决。

在首页显示文档，只改变发现入口，不构成认证，也不会自动修复产品问题。维护者若要引用某项标准或评估结果，应保证声明能够连到相应依据；不应因为文件已经出现，就把整个项目标成全面符合某种要求。

反馈入口要能把问题交到维护流程里

用户报告困难时，通常需要说明正在完成什么任务、停在哪一步，以及使用了什么环境。反馈说明可以帮助收集这些必要信息，同时避免要求与排查无关的个人情况。公开Issue、私下联系和项目已有支持渠道各有适用情境，文档应告诉用户怎样选择。

收到反馈之后，将问题关联到对应版本与页面，能够帮助维护者确认修复范围。如果后来界面重做，旧声明也应跟着复查。最容易过期的往往不是“支持什么”这句话，而是它指向的操作步骤、截图或已知限制是否仍符合当前软件。

可以把声明复查放进现有发布检查：本次是否改了导航、弹窗、表单或键盘操作，是否引入新的限制，是否已经关闭一个旧问题。这样文档随着产品变化积累具体证据，而不会在第一次创建后就成为无人维护的承诺页。

这项小更新的意义，在于让项目更容易把使用条件主动展示出来。真正有帮助的声明不需要写得宏大，只要让使用者找到可靠的当前信息，并知道遇到障碍时如何获得回应。

来源与核验

GitHub无障碍声明展示公告发布于2026年10月1日，本文于北京时间2026年10月2日核验。文档结构与示例为原创建议，未对具体项目作合规判断。