把无障碍声明当工程资产管理：ACCESSIBILITY.md 的版本、责任人与失效率

把无障碍声明当工程资产管，就是要求它满足三个条件：能被追溯（版本）、能被问责（责任人）、能被判定过期（失效率）。GitHub 在 2026 年 11 月 5 日的博客中说明，平台会高亮仓库中的 ACCESSIBILITY.md 文件，并帮助维护者记录无障碍目标、已知障碍、支持环境、贡献者期望和报告流程（GitHub Blog）。这解决的是“声明放在哪里”；“放进去之后怎么不失效”仍要由项目自己设计。下文的字段与流程都是管理建议，并非 GitHub 规定的格式；高亮的具体展示规则、是否对文件结构有要求，本次材料未提供，待核实。

版本：让声明和代码使用同一条时间线#

把文件放在仓库根目录，与 README、LICENSE 同级，让它的每次修改都经过 PR 评审、进入 commit 历史。“这句话是什么时候写的、谁改的、为什么改”可以直接从版本历史回答，不需要额外的文档系统。

• 写入两类时间：核对日期（最近一次重新验证的时间）和适用范围（覆盖哪条发布线，例如“2.x”）。
• 避免“当前版本”“最新浏览器”这类会随时间偏移的措辞，改成可判定的表述。
• 版本化不是给文件加编号，而是让每次修改都能 diff、能回滚、能追到评审记录。

责任人：单一 owner 加一条升级路径#

用 CODEOWNERS 指定声明的评审人只是第一步。owner 还必须具备修复能力，或者能明确把问题转给能修复的人。建议在文件中写清四个字段：负责人、备份负责人、报告渠道、响应目标（例如“5 个工作日内确认收到”）。

常见的反模式是只写“如有问题请联系维护者”。这既没有指定人，也没有时限，无法判定是否履约。

失效率：把陈述变成可核对的断言#

这里的失效率指：声明中的断言在抽查时不再成立的比例。它值得记录，是因为一份写着“支持某屏幕阅读器”但实际已不支持的声明，比没有声明更糟——用户会按错误预期使用产品，然后把失败归因于自己。

做法是把每条陈述拆成可验证的条目，标注核对方式和上次核对结果。下表是结构示例，其中的数值均为占位，不代表任何真实项目：

核对频率应按发布节奏定，而不是按自然年。若某条断言连续多次核对失败，应把它从“支持”移到“已知障碍”，而不是让它留在原地。公开失效率会带来压力，但只有公开才可能被外部用户纠正。

一个最小文本模板#

下面是 Markdown 文本模板，不是可执行代码，未运行任何校验工具；字段按上文建议组织，可按项目裁剪。

# 无障碍声明

适用范围：2.x 发布线
最近核对：YYYY-MM-DD
负责人：@maintainer-a（备份：@maintainer-b）
报告渠道：issue 模板「无障碍问题」
响应目标：5 个工作日内确认收到

## 目标
- （本发布线承诺做到的事）

## 已知障碍
- （当前不满足、且用户可感知的问题，附 issue 链接）

## 支持环境
- （经过核对的操作系统、浏览器、辅助技术组合）

## 贡献者期望
- （提交 UI 变更时需要附带的无障碍检查）

## 核对记录
- YYYY-MM-DD：核对人，结论，变更

边界：声明不能替代什么#

声明不能替代实际修复，也不能替代法律或采购场景下的合规文件。它的作用是让外部用户知道当前状态和反馈路径，让内部知道哪些承诺正在被跟踪。把这三件事分开写，比在一份文件里同时承担所有职能更可持续。