用 ACCESSIBILITY.md 把无障碍目标写成可核查的仓库文件

简短回答：ACCESSIBILITY.md 是一个把无障碍声明放进版本库的入口，GitHub 会突出显示它；但“可核查”不是文件名带来的，而是内容写法决定的——每条声明都要能对应到一次别人可以重复执行的检查、一个可追踪的 issue 和一个复查日期。

GitHub 侧发生了什么#

据 GitHub 博客 2026 年 11 月 5 日的文章，ACCESSIBILITY.md 文件现在在 GitHub 上有了“家”：GitHub 会突出显示这类文件，并帮助维护者记录无障碍目标、已知障碍、支持环境、贡献者预期和报告流程（来源：Accessibility statements now have a home on GitHub，作者 Jan Maarten）。

需要划清边界：本次材料只提供了摘要与作者介绍片段。高亮出现在仓库页面的哪个位置、是否有文件位置或命名规则、是否纳入社区健康文件检查、是否影响检索，材料均未提供，待核实。因此下文的结构是写作建议，不是平台要求。

把目标写成可核查的句子#

博文摘要列出的五类内容——目标、已知障碍、支持环境、贡献者预期、报告流程——可以直接作为章节骨架。难点在于每一节都容易滑向口号。一个可操作的改写规则是：断言 → 对象 → 核对方式 → 追踪与复查。

表格右列的共同点：任何一位维护者拿着文件，都能判断“做到没做到”，而不需要先理解作者意图。

一份可直接改的占位骨架#

下面的内容是占位示例，未在真实仓库中执行或验证；尖括号与“待填写”处需要替换为团队实际信息，不要照抄数字。

# Accessibility

## 目标
- 键盘可完成：搜索 → 详情 → 提交（核对方式：手动走查，记录见 `a11y` 标签）
- 对比度：正文文本达到团队选定标准（标准名称与版本：待填写）

## 已知障碍
| 现象 | 影响 | 临时绕行 | 追踪 | 复查 |
| --- | --- | --- | --- | --- |
| 弹窗焦点未锁定 | 键盘用户可能移出对话框 | 使用页面内表单 | #<issue 编号> | 待填写 |

## 支持环境
- 已测试：<浏览器 + 版本>、<屏幕阅读器 + 版本>（测试日期：待填写）
- 未测试：待填写

## 报告问题
- 渠道：<issue 模板名称>
- 请附：辅助技术名称与版本、浏览器与版本、复现步骤、期望结果

## 贡献者预期
- 涉及交互组件的 PR，需说明键盘操作路径
- 新增动画需说明如何关闭

最容易写成空话的两节#

已知障碍

这一节的可信度取决于是否承认问题存在。建议每行都填“临时绕行”和“追踪链接”：前者让用户当下有路可走，后者让问题不会随文件一起被遗忘。若某条障碍没有修复计划，写清楚即可，比模糊表述更可核查。

报告流程

只写“欢迎反馈”没有信息量。应写清渠道、需要携带的材料，以及收到之后会发生什么。响应时限若无法承诺就不要写数字——占位示例里的任何时限都应先与团队确认再落笔，否则文件本身就成了无法兑现的承诺。

维护与边界#

• 加日期：目标和已测试环境标注核对日期，过期即可见。
• 能核实再写：标准名称、版本、测试工具都以官方文档为准，版本未定就写“待定”。
• 不越界：ACCESSIBILITY.md 是声明与协作入口，推断而言，它不能替代实际测试，也不构成合规结论；材料未提供合规相关说明。

最后一条现实提醒：文件写完之后，真正的检验是下一位贡献者能否只读这一个文件，就知道该做什么、该找谁、问题记在哪里。做不到，就说明还需要再改一版。