compliance
如何回应一份无障碍投诉
一份分步指南,教你如何回应网站无障碍投诉——从最初的确认收悉,到修复、沟通,以及防止同样的投诉再次发生。
为什么你的回应比投诉本身更重要
无障碍投诉——无论是通过联系表单提交、通过邮件发送、提交给监管机构,还是以正式法律函件的形式送达——很少会就此终结。你如何回应,决定了接下来会发生什么。
一个及时、真诚、以行动为导向的回应能够化解大多数投诉,而无需升级。回避、轻视或干脆不回应,往往正是让一个本可修复的用户投诉演变为正式调查或诉讼的原因。
本指南介绍了如何在每一个阶段处理无障碍投诉:从你收到投诉的那一刻起,直到修复、沟通,以及建立制度以防止同样的投诉再次出现。
弄清楚你收到的是哪种投诉
并非所有无障碍投诉都是一样的,恰当的回应方式取决于投诉的类型。
用户反馈
最常见的形式。一名残障人士在你的网站上遇到了障碍——一份无法用屏幕阅读器完成的表单、一个没有字幕的视频、一个键盘无法触及的按钮——他们通过你的联系页面、无障碍反馈机制或常规客服渠道直接向你反馈了这一问题。
这些投诉往往是你的团队所能获得的最有价值的反馈。它们揭示了自动化工具经常遗漏的、来自真实用户在真实情境中遇到的真实障碍。
监管或政府投诉
在英国,用户可能会向政府数字服务局(GDS)或平等与人权委员会(EHRC)举报问题。在美国,投诉可能提交给司法部(DOJ)、教育部民权办公室(OCR)或其他联邦机构。在欧盟,投诉会提交给根据《网络无障碍指令》指定的国家执法机构。
这些投诉遵循一个正式的流程。你通常会收到书面通知、关于所涉违规行为的描述,以及一个回应期限。
法律律师函
在美国,这通常是原告打算依据 ADA 第三章提起诉讼的第一个信号。函件描述所涉违规行为,通常还会提出和解条件。这是一个需要单独处理的法律事项——请参阅我们的ADA 律师函指南获取专门的详细说明。
无障碍声明反馈
如果你的网站发布了带有反馈机制的无障碍声明(英国 PSBAR 要求如此,其他地方也强烈建议这样做),你可能会通过它收到结构化的反馈。这些反馈往往详细而具体,应给予与其他任何投诉同等的重视。
第一步:及时确认收悉
当一份无障碍投诉到来时,你能做的最重要的一件事,就是迅速回复以确认已收到。
即使你无法立即着手调查问题,这一点依然重要。当天或次个工作日内的确认收悉,能传达出你认真对待这份投诉的态度。它也能防止投诉人以为自己的消息被忽视了——这是引发升级的常见诱因。
你的确认回复应该:
- 确认已收到该投诉
- 指明负责跟进的具体人员或团队
- 给出一个切实可行的完整回应时间表(见第三步)
- 感谢对方提出这个问题——他们正在帮助你发现一个同样影响其他用户的障碍
保持专业且真诚感激的语气。反馈无障碍障碍的人往往已经尝试过其他变通方法却一无所获。他们正在花费本不应由他们承担的时间。
模板:
感谢您与我们联系。我们已收到您的留言,正在审查您所描述的问题。我们团队的成员将在 [时间范围] 内与您联系并提供进展更新。我们高度重视无障碍问题,感谢您向我们反馈此事。
第二步:调查具体的障碍
确认收悉之后,调查投诉人所描述的具体问题。避免陷入一种诱惑:运行一次泛泛的无障碍审计,并把这当作对这份具体投诉的回应——这会拖延解决进程,也偏离了重点。
需要调查的内容:
- 你能否重现这个问题?在投诉人所描述的环境中进行测试:他们提到的浏览器、操作系统和辅助技术(如果有提及)。
- 这个障碍是出现在组件层面(某个具体的按钮、表单或模态框),还是页面层面?
- 这是一个代码问题、内容编写问题,还是第三方组件问题?
- 网站上其他地方是否存在同样的障碍?
- 它违反了哪一项 WCAG 成功标准(如果有)?
可使用的测试工具:
- 仅用键盘——你能否仅使用 Tab、Shift+Tab、Enter、空格键和方向键,到达并操作受影响的元素?
- 屏幕阅读器——使用 NVDA + Chrome、JAWS + Chrome,以及 macOS/iOS 上的 Safari + VoiceOver 进行测试。该元素是否有可访问名称?是否被正确播报?
- 自动化扫描工具——对受影响的 URL 运行一次针对性扫描,以发现同一位置的其他问题
- 放大到 200% 并重排到 320px 宽度——布局是否会崩坏?
记录你的调查结果。你需要清楚地记录这个障碍是什么、存在于何处,以及是什么导致的。
第三步:修复它——并设定切实可行的时间表
一旦你了解了这个障碍,就着手修复它。优先级和时间表应与严重程度相匹配:
| 严重程度 | 示例 | 目标修复时间 |
|---|---|---|
| 严重 | 结账表单无法用键盘触及、屏幕阅读器用户登录受阻 | 24–72 小时 |
| 重大 | 商品图片缺失替代文本、关键流程中的表单输入未加标签 | 一周以内 |
| 中等 | 次要内容的色彩对比度不足、缺失标题结构 | 本次或下次冲刺(两周)以内 |
| 轻微 | 博客文章中非描述性的链接、缺失 lang 属性 | 下一个计划中的维护窗口 |
如果修复需要时间——例如,需要第三方供应商更新其组件——请将这一情况告知投诉人。告诉他们:
- 这个障碍是什么
- 是什么原因造成的
- 你正在采取什么措施来修复它
- 预计何时能够解决
- 在此期间是否有其他方式可以完成该任务
替代访问途径很重要。如果一个人无法使用你的结账流程,在修复进行期间,可以提供通过电话或邮件下单的方式。仅仅说”我们正在处理”而没有提供替代方案,并不是一种合理的调整——这只是在告诉用户他们无法使用你的服务。
第四步:向投诉人给出具体的回应
当修复完成后(或者如果需要更长时间,当你有了一个具体计划时),向投诉人发出一份实质性的进展说明。这份回应应该:
- 描述所识别出的具体问题
- 说明你在调查中发现了什么
- 说明已经修复的内容,或详细说明带有时间表的修复计划
- 确认修复已经过验证(重新测试)
- 邀请他们体验更新后的效果,并在障碍仍然存在时反馈
- 提供一个直接联系方式,以便他们遇到进一步问题时使用
避免使用”我们已经改善了无障碍能力”之类含糊的安慰性说法。要具体。一位无法用屏幕阅读器登录的投诉人,应该确切地知道到底哪里出了问题,以及现在是否已经修复。
模板:
感谢您在我们调查您所反馈的问题期间的耐心等待。我们在 [具体页面/组件] 上发现了 [具体问题]。这一问题已经解决——[简要描述修复方案]。我们已经重新测试了更新后的 [页面/组件],确认 [元素] 现在 [可访问的行为表现]。如果您仍遇到任何问题,我们非常乐意听取您的反馈。您可以直接通过 [联系方式] 与我们联系。
第五步:记录一切
对于你收到并解决的每一份无障碍投诉,都要保留一份记录,包括:
- 收到日期和确认日期
- 所反馈障碍的描述
- 你的调查结果
- 所采取的修复措施及其部署日期
- 修复已经过测试的确认
- 与投诉人的所有往来记录
这份文档记录有三个作用。首先,它展示了善意——如果投诉升级为监管调查或法律行动,一份有记录的修复历程是你认真对待此事并采取了行动的有力证据。其次,它为你的无障碍声明提供了素材,声明中应列出已知问题及其修复状态。第三,它为你的代码库或内容工作流程中反复出现的失败模式积累了机构知识。
第六步:更新你的无障碍声明
你的无障碍声明应反映网站当前已知的状态。在解决一份投诉之后:
- 从已知问题列表中移除该障碍(如果它曾被列出)
- 更新”最后审查”日期
- 如果这份投诉揭示了一类你此前未曾识别出的问题,将其加入并注明其修复状态
一份准确反映已知问题——包括那些尚未修复、但带有切实可行时间表的问题——的无障碍声明,比一份宣称完全符合但用户明知并非如此的声明,更能建立信任。
处理无法立即解决的投诉
有时一个障碍无法迅速修复:该组件由尚未发布修复方案的第三方供应商所有,修复需要一次平台迁移,或者内容存在于需要大量工作才能更新的旧系统中。
在这些情况下:
提供替代访问途径。 在大多数司法辖区,这是法律要求的”合理调整”或同等义务。它必须是真正等效的——不能是打折的替代方案。如果一份 PDF 无法访问,可以提供通过邮件以无障碍格式提供该信息的方式。如果预订表单对屏幕阅读器用户无法使用,可以提供通过电话预订的方式。
对时间表保持诚实。 告诉投诉人”这将在第三季度修复”并不能真正满足他们的需求。要承诺具体的里程碑,并确实履行。
内部升级。 涉及核心流程(登录、结账、账户管理、关键表单)的投诉,应被视为高优先级的工程问题,而不是内容微调。确保正确的人员知晓这一情况。
回应监管投诉
如果一份投诉已升级到监管机构——英国的 GDS、美国的 DOJ 或 OCR,或欧盟的国家执法机构——处理流程会更加规范。
你通常会收到:
- 一份描述了指控内容的正式投诉通知
- 要求在规定期限内做出正式回应
- 在某些情况下,参与调解或非正式解决的邀请
不要错过截止日期。 一份未获回应或延迟回应的监管投诉,会传递出不配合的信号,并强化投诉人的立场。
针对具体指控作出回应。 监管机构期望的是针对所提出的具体问题的回应,而不是一份关于你对无障碍工作承诺的泛泛声明。
提供修复证据。 对于已修复的所反馈障碍,提供相应文档:截图、审计报告、部署日期确认。一位能够看到问题已经解决的监管人员,追究正式执法行动的理由会大大减少。
寻求法律建议。 对于正式的监管投诉,特别是在美国,DOJ 的调查范围可能很广,建议聘请熟悉数字无障碍领域的法律顾问。
防止下一份投诉
每一份无障碍投诉都是一个障碍已经触及真实用户的证据。目标不仅是解决个别投诉,更是建立能够防止新障碍出现的制度。
将无障碍嵌入你的开发流程。 CI/CD 流水线中的自动化无障碍检查能在问题到达生产环境之前——而不是在用户反馈之后——捕获可检测到的问题。我们的CI/CD 无障碍集成让这成为每一次构建的一部分。
安排定期审计。 自动化工具能捕获 30%–40% 的 WCAG 失败项。使用屏幕阅读器和纯键盘导航的人工审计能发现剩余的部分。每季度或每半年一次的审计,能在用户发现问题之前先发现它们。
培训你的团队。 理解无障碍的开发人员、设计师和内容作者会制造更少的障碍。一次性的培训,其效果不如将无障碍审查嵌入到设计评审、代码审查和内容发布工作流程中。
让你的反馈机制真正易于使用。 一份带有可用、无障碍联系方式的无障碍声明,为用户提供了一条直接联系你的途径,而不必求助于监管机构。许多投诉之所以会升级,恰恰是因为网站自身的反馈渠道本身就无法访问。
如果你想在下一份投诉到来之前了解你网站当前的无障碍状况,免费自动化扫描是最快的起点。要获得全面的图景,请联系我们讨论一次全面审计。