题干与适用场景
请讲一次你发现产品存在无障碍问题、已经影响用户或上线风险的经历。你如何确认影响、推动修复、与团队沟通，并防止同类问题再次发生？
高质量回答要讲清一个真实的失败或险情，而不是背诵 WCAG 条款。WCAG 2.2 提供可测试的成功准则；GOV.UK Service Manual 同时建议自动测试、人工测试和辅助技术测试。你可以用这些资料解释判断依据，但不要把一次自动扫描结果包装成完整合规结论。
面试官考察点
面试官关注你是否把受影响用户放在中心，能否迅速确认事实、承认责任、协调跨职能修复，并用结果证明改进。还会观察你如何处理发布压力、不同优先级和不完整证据，以及是否把个人补救升级为团队机制。
回答前需要澄清的问题
- 问题影响哪类用户、哪条关键任务和哪些设备或辅助技术？
- 你是通过用户反馈、人工测试、自动化检查还是生产指标发现的？
- 当时是否已经上线，是否存在替代路径或紧急缓解措施？
- 哪些团队拥有设计、代码、内容、测试和发布决策权？
- 你能分享哪些时间、成功率、阻塞步骤或回归数据？
- 你亲自负责的行动是什么，哪些事情由其他人完成？
30 秒回答框架
“我会选一个能说明影响和改变的具体案例：先用受影响用户的任务和证据界定问题，立即提供可用的临时路径并同步风险；然后与设计、工程、测试和产品共同排出修复优先级，用辅助技术和真实用户复测。修复上线后，我把检查点、责任人和回归指标加入日常流程。结果不仅是缺陷关闭，还要证明关键任务成功率、投诉或回归率发生了什么变化；如果仍有残留风险，我会明确说出来。”
分步骤深入解答
第一步：描述影响而不是贴标签
说明用户在什么任务、设备和辅助技术组合下被阻塞。把“按钮不友好”改成“使用屏幕阅读器无法识别提交按钮，结账任务无法完成”，并给出复现步骤、样本量或用户原话。避免在没有证据时判断严重等级或法律责任。
第二步：快速确认并止损
复现问题，记录页面版本、浏览器、辅助技术、成功与失败路径。若风险正在扩大，提出暂时关闭受影响流程、提供电话或人工替代、暂停发布或加明显提示等方案。说明你如何让受影响用户知道变化，而不是只在内部工单中标记。
第三步：用共同语言协调团队
把问题拆成设计、语义结构、键盘操作、焦点管理、内容、测试和发布环节，邀请真正使用辅助技术的同事或用户参与。用任务和证据讨论优先级，避免把无障碍变成某个专家的个人责任，也不要用“先做功能以后再补”结束对话。
第四步：制定可验证的修复计划
明确最小修复、负责人、截止时间、依赖和停止线。组合自动化规则、人工键盘检查、屏幕阅读器测试和真实用户测试；自动工具只能发现部分问题。若存在多个受影响流程，先修复高频或不可替代的任务，再安排后续批次。
第五步：在压力下沟通取舍
向发布负责人说明用户影响、风险、缓解方案和延期成本。若无法在发布前彻底修复，给出范围受限的替代路径、公开说明和明确期限，而不是隐藏问题。记录谁批准了什么，确保团队理解“未完成”与“已接受风险”的差别。
第六步：与用户共同验证结果
让受影响用户按原任务完成操作，覆盖键盘、屏幕阅读器、放大或语音输入等真实组合。记录任务成功率、完成时间、错误、求助次数和主观反馈。修复后仍失败时，承认结果并继续迭代，不用一次绿色扫描掩盖体验问题。
第七步：把教训写入流程
在设计评审、组件库、验收标准、CI 检查、发布清单和回归测试中加入具体规则。为每条规则指定维护人和例外处理方式，建立缺陷趋势与用户反馈入口。流程改进必须能被下一位同事执行，而不是只依赖你的记忆。
第八步：用结果和反思收尾
用修复前后数据说明变化，并指出哪些指标仍不理想。反思你的判断、沟通或预防机制哪里不足；若你误估了影响，直接说明如何修正。最后说清下一步：扩大测试覆盖、更新组件、培训团队或安排再次用户研究。
设计取舍与边界
速度与完整修复
紧急缓解可以保护用户，但不能替代根因修复。回答应同时给出立即止损和长期计划，并说明如何防止临时方案变成永久状态。
自动化与人工验证
自动检查适合快速回归，人工键盘和辅助技术测试能发现上下文、焦点、顺序和实际可用性问题。两者不能互相冒充，覆盖范围和证据应分别记录。
标准与真实体验
WCAG 成功准则提供共同语言，但一次通过不代表所有用户任务都顺畅。把标准条款连接到具体任务、设备和用户反馈，避免只展示合规分数。
失败演练与演进计划
修复后仍有用户无法完成任务
重新观察完整任务链，邀请用户说明卡点，检查内容、焦点和错误恢复，而不是只重新运行扫描。扩大样本并更新验收标准。
团队把问题归咎于旧组件
先承认组件约束，再提出短期封装或替代路径和长期组件修复。记录影响范围，安排拥有者和截止时间，避免责任在团队之间来回转移。
发布压力再次出现
使用预先约定的停止线、风险记录和替代路径。若需要带风险发布，明确批准人、用户告知、监控指标和回滚条件，并在事后复盘是否需要提高门槛。
常见误区与追问
误区一：只说“我修了一个 aria 属性”
追问：哪个用户任务被阻塞？修复前后如何验证？候选人应讲清任务、辅助技术和结果。
误区二：把自动扫描分数当成用户证据
追问：你做了哪些人工和真实用户测试？哪些问题自动工具无法发现？
误区三：把无障碍交给 QA 或某位专家
追问：设计、工程、内容和产品各自改变了什么？候选人应说明共同责任和流程护栏。
误区四：只讲团队冲突，不讲个人行动
追问：你具体提出、推动或改变了什么？如果没有你的行动，结果会怎样？
延伸追问与参考答案
你如何在证据不足时决定是否阻止发布？
先说明已知影响、未知部分和临时缓解，再按关键任务、受影响规模、是否有替代路径和修复时间提出建议。由有权限的负责人批准，并留下监控、用户告知和回滚条件，不能用猜测冒充确定性。
如何证明流程改进真的有效？
比较后续版本的缺陷回归率、关键任务成功率、辅助技术测试覆盖、用户反馈和修复周期。定期抽样人工验证，确保指标没有因为减少报告而“变好”。
如果你当初判断错了，怎么回答？
明确错误判断、造成的影响和新证据，说明你如何向团队和受影响用户沟通，并把修正写入流程或检查项。承担责任比把错误归给工具更能体现学习能力。