J1.12.2accessibility feedback mechanism设计研究
声明需提供反馈渠道供用户报告新发现的障碍
别名: 反馈渠道 · 报告障碍 · 联系方式
概念解释
清单写于过去某一天，新的失败会在明天出现。声明因此必须给出一条反馈渠道（accessibility feedback mechanism）：人可以报告刚撞上的障碍，并且这条通道本身走得通。邮箱、在线表格、电话，选什么介质次要；要能用键盘提交、有可读的时限、有升级路径（平等机构、监管投诉）。渠道若藏在正要被抱怨的那页里、还套一层图形验证码，就不是渠道。
机制
符合性快照会过期，组织自己的测试覆盖不全。反馈是把用户当成持续抽样。第二层是渠道的可达性决定样本是谁：只有视力良好、能过验证码的人能寄信，报告就会重复已经看得见的问题，真正被挡住的人进不来。无人值守的别名邮箱等于没有渠道——压力机制需要回执和时限，否则投诉停在发出那一刻。声明里的渠道也是执法链条的入口：许多模板要求写清下一步向谁升级，缺这一句，用户被留在公司内部流程里。
怎么研究
用阅读器、键盘、语音控制实际提交一次「报告障碍」，记录能否完成、回执是否带日期、时限内是否有人应答。统计渠道本身的失败（验证码、无名称字段、只在 App 内）。对照声明文本是否写了升级路径。
自变量：介质（邮件 / 表格 / 电话）、是否有验证码、是否承诺时限。 因变量：辅助技术用户能否提交、回执率、从报告到清单更新的天数、渠道自身造成的放弃。
不要用「页面上有联系我们链接」当渠道存在——那条链接可能指向销售表。
边界
安全举报、滥用投诉走另一套入口，不要强行并进无障碍表单，但要在声明里指过去。大规模攻击下可以加限流，限流不能只剩图形挑战；准备电话或已登录用户的简化表。内部员工报缺陷用工单系统即可，对外声明仍要有公众入口。渠道不能替代自己的测试：零报告可能是渠道坏了，不是产品没问题。
怎么落地
- 声明在「如何报告」一节同时给出至少两种介质，其中一种不依赖图形验证码，并写应答时限与升级对象。
- 表格字段程序化关联可见标签，提交成功后给出可被阅读器读到的确认和案件号。
- 值班把报告写入缺陷队列，并在时限内回执；超时时限的，声明里的天数要改或加人。
- 验证：关掉显示器，用键盘把一份障碍报告走完。走不通就先修渠道再谈产品。两周后查该报告是否进入缺陷库、声明清单有没有新增对应项。