J1.09.3accessibility in requirements设计研究
无障碍需求应进入需求清单而非验收清单
别名: 需求清单 · 验收清单 · definition of done
概念解释
写在验收清单末尾的无障碍，等到功能已经按指针路径做完才被打开。那时只剩两种动作：挡住发布，或记一笔债。无障碍需求应进入需求清单（accessibility in requirements）要求它在故事被接受之前就有可判定的验收条件——这条任务能用键盘做完、每个输入有名称、限时可关——而不是在 QA 的最后一栏打勾。验收仍然要做；它不是需求的替代品。
机制
团队优化被写明的东西。需求清单决定什么算「做完」，验收清单决定什么算「还过得去」。把无障碍放在后者，等于宣布它可以在范围谈判里被拿掉。第二层是门禁只会发现缺陷，不会长出语义：测试员可以报「没有标题」，却不能在已经定稿的信息结构里发明标题层级。缺陷来源统计里，若无障碍条目几乎全部标成「验收阶段发现」，说明它从未进入做功能的那几周。早期付费邀请障碍用户，若仍只挂在发布前的可用性场次，也是同一错位。
怎么研究
按发现阶段给无障碍缺陷编码：需求评审、设计评审、实现、验收、上线后。对照故事模板里有没有通道验收条件。看发布门禁挡住的是「缺功能」还是「缺无障碍」，以及后者被豁免的次数。
自变量：故事是否自带键盘 / 名称 / 时限等验收条件。 因变量：缺陷首次发现阶段、验收阶段占比、门禁豁免次数、从发现到修复跨越的迭代数。
问卷上「我们重视无障碍」不算证据；要看模板和门禁日志。
边界
需求写了仍然要测——写进清单不等于已经可用。不是每条成功标准都该贴在每个故事上：与本功能无关的项（没有视频就不要写字幕）会把清单变成仪式。监管审计、上线后的抽检仍在，它们补的是需求覆盖不到的漂移，不能反过来当唯一机制。紧急热修可以先走窄门禁，但必须在下一迭代把条件补回需求，否则热修会变成永久的验收主义。
怎么落地
- 故事模板固定三问：不用指针能否完成、每个可操作控件的名称从哪来、有没有不可关的时限。答不出不准开工。
- 完成定义包含通道，不把「无障碍」单列成最后一个可选框。
- 障碍用户测试排进设计前期的任务，而不是只出现在发布周。
- 验证：抽最近一个迭代的故事，看无障碍条件是写在验收栏末尾，还是写在功能描述里。再抽缺陷，看首次发现阶段。若八成以上来自验收或上线后，把模板改掉后再跑一个迭代对比。