stakeholder-communication

利益相关方沟通

使用能引起对话对象共鸣的语言，传达无障碍决策——因为合适的论据取决于听众是谁。

核心原则

不同的利益相关方关注的事情各不相同。能打动首席财务官的无障碍论据，并不能打动工程师。根据他们的优先事项调整表达方式。

利益相关方视角

面向高管和领导层

他们关注：风险、收入、声誉、法律风险。

将无障碍描述为：

• 降低风险：“不合规会让我们面临法律诉讼。过去十年中，ADA 诉讼数量逐年增加。《欧洲无障碍法案》现已生效。”
• 市场规模：“全球有 15% 的人口有残障。这意味着我们目前排除在外的潜在用户超过 10 亿。”
• 品牌声誉：“无障碍问题很快就会公之于众。引领无障碍实践能成为差异化优势。”
• 避免成本：“在设计阶段修复无障碍问题的成本，比发布后修复低 10 倍，比遭遇诉讼后修复低 100 倍。”

面向产品经理

他们关注：用户满意度、完成率、范围、时间安排。

将无障碍描述为：

• 提高转化率：“无法完成流程的用户不会转化。每个无障碍障碍都会导致用户流失。”
• 用户满意度：“无障碍改进始终能提升所有用户的满意度评分，而不仅仅是残障用户。”
• 明确范围：“以下是具体的验收标准。这不是额外工作，而是完成标准的定义。”
• 竞争优势：“我们的竞争对手在这方面做得并不好。在采购决策中，无障碍确实能形成差异化优势。”

面向工程师

他们关注：清晰度、具体性、标准、实施成本。

将无障碍描述为：

• 明确的规格：“以下是需要实现的具体内容：明确的 WCAG 标准、明确的属性、明确的行为。”
• 代码质量信号：“无障碍代码就是结构良好的代码。语义化 HTML、合理的 DOM 顺序和恰当的状态管理，无论是否考虑无障碍，都是工程最佳实践。”
• 测试标准：“以下是测试方法：这些键盘操作序列、这些屏幕阅读器播报内容、这些对比度比例。”
• 预防优于修复：“现在就做好，比 QA 发现问题后再修复更快。”

面向设计师

他们关注：用户体验、工艺水准、专业标准。

将无障碍描述为：

• 设计质量：“无障碍设计就是更好的设计。清晰的层次结构、一致的模式、通俗易懂的语言和宽容的交互能改善所有人的体验。”
• 专业标准：“无障碍并非对创造力的限制，而是一项设计要求，就像响应式设计或性能一样。”
• 用户共情：“我们为真实情境中的真实用户设计。残障也是现实的一部分。”

对话结构

申请资源时

1. 说明具体的用户问题（而非技术要求）
2. 量化受影响的人数（提供具体数字，而不只是百分比）
3. 说明解决方案及其范围（具体、明确、可实现）
4. 联系到对方已经关心的事项（法律、收入、品牌）

反对削减时

1. 明确指出削减会排除哪些人
2. 说明问题的严重程度（完全无法使用，还是使用不便）
3. 提出不会牺牲无障碍的替代性范围缩减方案
4. 如果决定被否决，则记录该决定（这能保护所有人）

汇报进展时

• 先讲成果：“现在又有 3 个用户群体可以完成结账了”
• 展示前后对比：具体的改进，而非抽象的合规情况
• 联系他们跟踪的指标：完成率、支持工单、满意度评分
• 避免行话：说“看不到屏幕的用户”，而不是“JAWS 用户遇到 ARIA 违规问题”

反面做法

• 只强调合规（听起来像是在走过场，而非创造价值）
• 诉诸内疚（“残障人士无法使用我们的产品”）
• 表述含糊（“我们需要改善无障碍体验”）
• 将其说成可有可无（“如果能……就好了”）
• 把无障碍视为独立项目，而非质量的一部分

评估问题

1. 你能否用各利益相关方关心的方式阐述无障碍方面的理由？
2. 无障碍要求是否以具体的验收标准呈现，而非含糊的愿景？
3. 进展是否以用户成果而非技术合规情况来汇报？
4. 当无障碍工作被降低优先级时，是否记录了相关决定及其影响？