第二章：法规与标准——无障碍设计的“硬约束”与“软指南”

做车载HMI无障碍设计，光有情怀可不够。你得懂法规，懂标准。

说白了，这些条文就是你的“护身符”和“紧箍咒”。我见过不少团队，产品做得花里胡哨，结果合规审查一查，全得推倒重来。嗯，咱们今天就把这些硬骨头啃一啃。

2.1 国际通用标准：ISO 9241-11 与 WCAG 2.1

先聊ISO 9241-11。这个标准讲的是“可用性”。它定义了三个核心维度：有效性（用户能不能完成任务）、效率（花多少资源）、满意度（用户爽不爽）。

我个人习惯，在项目初期就用这个框架去拆解需求。比如，一个视力障碍用户调节空调温度，他能不能通过语音完成？需要几步？他会不会觉得烦躁？这就是ISO 9241-11的落地。

所以我们要看WCAG 2.1。这是Web内容无障碍指南，但车载HMI现在越来越像“带轮子的平板”，所以它非常适用。WCAG 2.1 有四大原则：

• 可感知：信息必须能通过感官获取。比如，图标不能只有颜色区分，还得有文字标签。我在项目中遇到过，一个红色警告图标，色盲用户根本看不见。后来我们加了“！”符号和震动反馈。
• 可操作：交互组件必须能用。比如，触控按钮不能太小，至少得44x44像素。我曾经因为按钮做小了，被测试组骂了一周。
• 可理解：信息和操作必须易懂。比如，语音指令“打开空调”和“开启制冷”，用户得能猜到是同一个功能。
• 鲁棒性：兼容各种辅助技术。比如，屏幕阅读器（TalkBack、VoiceOver）能不能正确朗读你的界面？

2.2 汽车行业专属标准：SAE J3016 与 ISO 26262

SAE J3016 你可能不熟，但它定义了自动驾驶的等级（L0-L5）。为什么无障碍设计要关心这个？

你想想看，L2级辅助驾驶，驾驶员还得随时接管。这时候如果界面信息过载，或者操作延迟，对认知障碍用户就是灾难。到了L4、L5，用户可能完全脱离驾驶，这时候交互方式就得彻底改变——比如，允许更复杂的语音对话，或者更长的触控等待时间。

我建议，在做设计时，先明确你的目标自动驾驶等级。不同等级，对无障碍的要求天差地别。

再说ISO 26262，功能安全标准。它跟无障碍有什么关系？关系大了！

举个例子，一个肢体障碍用户，可能用头部控制或眼动追踪来操作。如果系统因为一个软件bug，误判了用户的意图，突然加速或刹车，那就是安全事故。ISO 26262要求我们考虑所有可能的“失效模式”，包括辅助技术带来的新风险。

2.3 企业合规要求：从“可以不做”到“必须做”

聊完国际标准，咱们看看企业层面。现在很多车企，尤其是出口欧洲、北美的，已经把无障碍纳入强制合规清单。

比如，欧盟的《欧洲无障碍法案》（EAA），2025年就要全面执行。不符合的车载系统，可能无法上市。美国也有《康复法案》第508条，政府采购的车载设备必须无障碍。

国内呢？虽然目前没有强制性的车载无障碍法规，但《无障碍环境建设法》已经实施，而且工信部也在推动智能网联汽车的标准体系。我个人判断，未来3-5年，国内一定会出细则。

企业怎么做？我建议分三步走：

1. 建立内部标准：别等法规逼你。把WCAG 2.1 AA级作为基线，再结合SAE J3016的等级，制定自己的设计规范。比如，我们团队就规定：所有触控目标最小尺寸48x48px，对比度不低于4.5:1。
2. 引入第三方审计：自己测容易有盲区。找专业的无障碍测试机构，用真实用户（视障、听障、肢体障碍）做测试。我曾经请过一位全盲用户来测我们的语音导航，他一句话就点醒了我们：“你们的语音反馈太啰嗦了，我只想知道下一个路口怎么走，不想听‘前方500米有测速’。”
3. 纳入开发流程：无障碍不是最后补的。在需求阶段就要写清楚“支持屏幕阅读器”、“支持语音控制所有核心功能”。在测试阶段，要有专门的“无障碍测试用例”。

好了，这一章就到这里。下一章，咱们聊聊具体的用户研究——怎么找到那些“沉默的用户”，听听他们真正的痛点。