仓库里的 ACCESSIBILITY.md：该写什么、由谁维护
可访问性声明（ACCESSIBILITY.md）服务于三类读者：使用辅助技术的用户、集成方和维护者本身。它应写明适用范围、可核验的符合性状态、已知限制、反馈渠道、责任角色与更新记录；维护上要有单一所有者，并把声明更新挂到组件与功能变更的评审流程里，而不是靠定期重读。
仓库里的 ACCESSIBILITY.md，作用是把“这个项目对残障用户意味着什么”写成一份可核对的说明：哪些能用、哪些不能用、遇到问题找谁。它既不是合规证书，也不是对外的宣传材料。判断它写得好不好，标准很简单：一个使用屏幕阅读器或键盘操作的人读完，能不能知道自己会碰到什么，以及下一步做什么。
需要先说明边界：本次材料只给出主题，没有 ACCESSIBILITY.md 的正文。因此下文不描述该仓库当前写了什么，也不评价它是否符合任何标准；以下内容是从“声明文件要被读者用来做决定”这一功能出发的通用建议，属于建议与示例，不是对现有文件的核验结论。具体司法辖区对可访问性的法定义务、以及适用的标准版本与等级，待核实。
先确定读者，再决定写什么#
可访问性声明通常有三类读者，各自需要的东西不一样：
- 使用者：想知道自己常用的辅助技术能不能完成主要任务，坏了怎么反馈。
- 集成方：把项目接进自己产品前，想知道边界在哪里、有没有已知障碍。
- 维护者：改版之后想知道这份文件哪一段已经过时。
三者的交集是“范围 + 状态 + 渠道”。只在文件里写一句“我们重视可访问性”，对任何一类读者都不成立。
建议包含的字段#
| 字段 | 建议写什么 | 由谁提供 |
|---|---|---|
| 适用范围 | 哪些页面、组件、接口、版本在声明内；哪些明确不在 | 项目负责人 |
| 符合性状态 | 做到哪一步：已核对 / 部分核对 / 未核对。没有可核验的审计记录时，不要写“完全符合” | 技术核对人 |
| 已知限制 | 具体且可复现的障碍，例如某组件不支持键盘操作，而不是“存在一些不足” | 开发与测试 |
| 反馈渠道 | 可用的邮箱或 issue 模板，并说明需要提供哪些信息（页面、辅助技术、浏览器） | 维护者 |
| 响应预期 | 只写团队能稳定兑现的时间窗；兑现不了就不写数字 | 维护者 |
| 责任角色 | 写角色而不是个人，人员变动后文件仍可维护 | 项目负责人 |
| 更新记录 | 最近一次核对日期与变更摘要 | 维护者 |
其中“响应预期”最容易变成空头承诺：一旦写进声明，读者会按它衡量。没有明确排期时，写清“收到反馈后会确认并回复，具体时长未定”即可，不必填一个好看的数字。
谁来维护#
声明本身没有复杂度，失效通常来自所有权缺失：改版上线，文件没人动，几个月后它描述的是已经不存在的界面。可行的做法是把责任拆成两层——
- 内容所有者：对文件中所有对外承诺负责，通常是项目负责人；决定哪些内容可以公开写。
- 技术核对人：对事实负责，确认“已知限制”是否仍然成立、核对日期是否真实。
个人可以兼任，但角色要在文件里写清楚，否则新人接手时不知道谁能批准修改。
把更新挂到触发条件上
比“每季度复核一次”更可靠的是让变更自己触发更新。建议至少覆盖：
- 新增或删除面向用户的功能、页面；
- 更换导航、表单、媒体播放器一类交互组件；
- 反馈处理完毕，把结果回写到“已知限制”；
- 到达约定的复核日期——写具体日期，不写“定期”。
更实际的做法是在代码评审清单里加一行：涉及界面交互的改动，检查 ACCESSIBILITY.md 是否需要同步修改。这样文件跟着代码走，而不是靠某个人记得。
几种应当避免的写法#
- 没有审计记录就声明“完全符合 WCAG（Web Content Accessibility Guidelines，Web 内容可访问性指南）”；版本与等级待核实，无记录时不宜作为结论。
- 只留一个投诉邮箱，不写适用范围，读者无法判断问题是否在声明覆盖范围内。
- 把标准条款原文抄一遍当作声明，读者仍然不知道自己会遇到什么。
- 承诺无法兑现的修复时间。
模板示意
下面是一份最小骨架，仅用于说明结构，未在任何仓库中执行或验证，字段可按项目增删：
# 可访问性声明
## 适用范围
本声明适用于 <产品名> <版本/模块>。<其他模块> 不在范围内。
## 当前状态
- 已核对：<范围与核对方式>
- 未核对：<范围>
## 已知限制
- <具体障碍>：影响 <操作>，临时替代方案 <...>
## 反馈
- 渠道：<邮箱或 issue 模板>
- 请提供：页面地址、使用的辅助技术、浏览器与版本
## 责任与更新
- 内容所有者：<角色>
- 技术核对人：<角色>
- 最近核对日期：<YYYY-MM-DD>
一个最小起点#
- 确定声明覆盖哪些模块与版本，把“不在范围内”的部分写出来。
- 列出目前真实知道的问题，宁可短，也不要写没有依据的“基本无障碍”。
- 给出一个能收到信息的反馈渠道，并写明需要哪些复现信息。
- 指定内容所有者与技术核对人两个角色，把核对日期写进文件。
做到这四步，文件就已经可以被读者使用。剩下的部分——更细的符合性说明、更完整的限制清单——应该随着实际核对推进，而不是一次写满。
