把无障碍声明放进仓库：ACCESSIBILITY.md 该写目标、已知障碍还是支持渠道
一句话回答
ACCESSIBILITY.md 不应在三项中三选一；建议先保证真实可达的支持渠道，再列经核实的已知障碍，最后写目标与范围，并保留复核记录。没有测试或规范依据时，不写合规或已完成的结论。
直接回答：不是三选一。本文建议的顺序是支持渠道 → 已知障碍 → 目标与范围；如果维护能力只够保留一项，先保证支持渠道真实可达。目标说明承诺边界，但不能帮用户绕过障碍；已知障碍能减少重复试错；支持渠道给无法自助的人一个出口。
本次写作没有可引用的规范原文、审计报告或 API.PLUS 的无障碍测试记录，因此下面只讨论仓库文档的结构，不判断任何页面是否合规，也不把建议写成实测结论。
三部分各自解决什么#
无障碍声明是面向使用者的说明文件，不等同于正式合规报告或审计报告。对开发者读者来说，最有用的信息通常是：我遇到的障碍是否已知、有没有替代路径、该向谁报告。
| 内容 | 回答的问题 | 维护难点 | 缺失后的风险 |
|---|---|---|---|
| 目标与范围 | 覆盖文档、控制台还是示例代码？是承诺还是现状？ | 容易写成营销话术 | 读者不知道声明是否适用于自己 |
| 已知障碍 | 哪些操作受影响、有无替代方案、是否已修复？ | 需要核实并定期复查 | 用户重复踩坑，支持成本上升 |
| 支持渠道 | 新问题去哪里反馈、是否有人处理？ | 渠道必须有人值守 | 声明看起来完整，但无法行动 |
这张表是比较建议，不是规范要求。三者的优先级来自可操作性，而不是篇幅：目标可以很短，支持和障碍必须能落地。
推荐的最小结构#
- 适用范围与最后复核日期。写清覆盖哪些产品面、不覆盖什么。日期只写真实复核日，不写“即将更新”。
- 支持渠道。给出真实邮箱、表单或 issue 模板；示例地址要明确标为占位。只承诺能兑现的响应方式。
- 已知障碍。逐条写影响范围、现象、影响、临时替代方案和状态；未核实的不要写成已确认。
- 目标与当前状态。目标可以写方向，但当前状态必须有证据；没有评估就写“未评估”。
- 维护触发条件。界面改版、修复上线、重复反馈出现时更新，比固定“每月检查”更可执行。
示例骨架#
下面是未执行的 Markdown 模板，只用于展示字段；邮箱域名和日期均为占位，不能当作 API.PLUS 的当前声明。
# 无障碍支持说明
最后复核：YYYY-MM-DD（占位）
## 适用范围
- 覆盖：开发者文档、控制台（按实际填写）
- 不覆盖：第三方站点与嵌入内容（按实际填写）
## 支持渠道
- 邮箱：accessibility@example.com（占位）
- 反馈时请说明页面或操作、使用的辅助技术（如适用）
- 响应时限：按实际可承诺内容填写
## 已知障碍
| 范围 | 现象 | 影响 | 临时替代方案 | 状态 |
| --- | --- | --- | --- | --- |
| 示例页面 | 键盘焦点顺序异常 | 难以完成某操作 | 使用站内搜索或联系支持 | 待核实 |
## 目标与当前状态
- 目标：改善文档站键盘可操作性
- 当前状态：未评估（有测试记录后再改）
## 维护
- 触发更新：界面改版、修复上线、收到重复反馈哪些写法要避免#
- 只写“我们致力于无障碍”，却没有范围和渠道。
- 把目标写成“已完全无障碍”，除非有可核验记录。
- 公布无人处理的邮箱或 issue 模板。
- 把已知障碍写成模糊的“部分页面可能有问题”，读者无法判断替代路径。
- 把内部路线图当成公开时间承诺。
边界条件#
如果涉及法规、采购合同或正式合规声明，格式、措辞和审查流程应另行确认；本文不替代法律意见或无障碍审计。对 API.PLUS 的具体现状，本次材料不足以判断，相关项应标“待核实”。在没有测试记录时，更稳妥的做法是缩小声明范围：写清覆盖什么、哪里可能受阻、如何找到人。
