"我们的客服 Agent 上线了，但有个用户说用不了。"——面向公众的 Agent，把服务从"排队等人工"变成"随时可问"，看似更普惠；但如果它是纯图形界面、只认鼠标点击、错误提示只有一句"操作失败"，那它就把视障、听障、行动不便以及大量老年用户挡在了门外。无障碍（Accessibility，常缩写 A11Y）不是"给少数人做的额外功能"，而是面向公众服务的基本合规要求。
我国的《无障碍环境建设法》已于 2023 年施行，把信息无障碍从"倡议"变成"法定义务"；国家标准也给出了互联网内容无障碍的技术要求与测试方法。对面向公众的企业 Agent 来说，无障碍不再是"要不要做"的问题，而是"怎么过"的问题。本文用 POUR 四步拆解企业 AI 的可访问性要点，再给一份上线前自检清单。
一、为什么"面向公众"就要过无障碍关
面向公众与面向内部，可访问性的要求完全不同：
- 法律边界不同：《无障碍环境建设法》要求公共服务场所与信息交流无障碍，面向公众的线上服务（政务、金融、医疗、公共出行等）尤其受约束。
- 用户结构不同：面向公众意味着要覆盖视障、听障、行动不便人群，以及规模庞大的老年用户。他们不是"少数"，而是任何公共服务都必须服务的群体。
- 失败成本不同：无障碍缺陷不只是体验问题，可能构成合规风险与舆情风险——一个"用不了"的投诉，足以让上线的好意愿变成坏口碑。
企业级环曜 Agent 本地化部署把数据不出域与交付实施纳入方案，让无障碍这类"面向公众"的要求在立项时就进入清单，而不是上线后被投诉才补。合规要求的分级思路，可参考《人工智能安全治理框架3.0》落地：企业 AI 智能体本地化部署合规自查清单。
二、POUR 四步：拆解可访问性要点
无障碍领域有一个成熟的框架，可归纳为 POUR 四步：
- P｜Perceivable（可感知）：信息要能被"看到"或"听到"。图片要有替代文字，语音要配字幕，颜色对比要足够——不能只靠颜色传递信息。
- O｜Operable（可操作）：功能要能用不同方式触发。键盘能完成全部操作、语音可替代点击、交互不被鼠标绑定；Agent 的对话也要能被屏幕阅读器逐条读出。
- U｜Understandable（可理解）：内容与提示要能被理解。语言尽量简单、错误提示要说明"错在哪、怎么改"，而不是只丢一句"失败"。
- R｜Robust（健壮）：要能兼容不同的辅助技术。语义标签规范、结构清晰，屏幕阅读器与语音助手才读得对。
「四步」的价值在于：它把"无障碍"从一句"要照顾少数人"，拆成四类可检查、可测试的要点——每一类都能对应具体的验收动作。环曜 Claw 执行网关把交互流程与降级路径做成可配置策略，让"可操作"这一步有配置可依。
三、三类交互形态的无障碍要点对比
不同形态的 Agent，无障碍的重点并不一样：
| 交互形态 | 主要障碍 | 无障碍要点 | 测试方式 |
|---|---|---|---|
| 文本对话 | 视障、认知障碍 | 屏幕阅读器可读、语言简单、步骤清晰 | 屏幕阅读器走查 |
| 语音交互 | 听障、言语障碍 | 语音配字幕、支持文字替代入口 | 字幕核对 + 键盘操作 |
| 多模态（图文） | 视障、色觉障碍 | 图片替代文字、不靠颜色单独传信息 | 对比度检测 + 读屏 |
一句话结论：文本对话先保证"读得懂"，语音交互先保证"看得见"，多模态先保证"不靠颜色"。企业级环曜 Agent 本地化部署把数据不出域与交付设计纳入方案，让无障碍要点能随交互形态一起规划。
四、上线前可访问性自检清单
照着勾，把无障碍从"想到了"变成"做到了"：
① 是否明确了该 Agent 是否属于面向公众服务（决定合规强度）？
② 对话内容能否被屏幕阅读器完整读出？
③ 是否支持键盘完成全部操作（不强制鼠标）？
④ 语音交互是否提供字幕或文字替代入口？
⑤ 图片、图表是否有替代文字与语义标签？
⑥ 是否避免只靠颜色传递信息（对比度是否达标）？
⑦ 错误提示是否说明原因与下一步，而非只报"失败"？
⑧ 语言是否尽量简单，避免专业缩写直接抛给用户？
⑨ 是否有反馈渠道，让遇到障碍的用户能反馈？
⑩ 是否把无障碍测试纳入上线前的验收项与回归清单？
环曜 Claw 执行网关把交互流程与降级路径做成可配置策略，让"语音不可用时切换到文字"这类备用路径有配置可依。环曜 Claw 执行网关还把每次交互的过程留痕，便于回溯"用户在哪个环节卡住了"。
五、一个真实踩坑：客服 Agent 上线，视障用户用不了
某企业上线了面向公众的客服 Agent，界面美观、交互顺畅，上线一周后收到投诉：视障用户用屏幕阅读器打开后，对话区的消息读不出来，按钮只有图标没有文字说明，语音提问的入口也找不到。团队这才发现，开发时完全没有做过无障碍测试。
整改并不复杂：给图标加语义标签、让对话内容结构化、补上语音提问的文字入口。但补救的成本和口碑损失，本可以在上线前用一次屏幕阅读器走查避免。教训是：面向公众的 Agent，无障碍测试不是可选项，而是上线前的必过项。企业级环曜 Agent 本地化部署把无障碍要求纳入交付复核，让这类问题在上线前就被拦住。
六、把无障碍纳入验收标准
无障碍不是一次性检查，而是持续要求。建议把它写进验收清单：上线前做一次屏幕阅读器与键盘走查，上线后每次改交互都回归测试。企业级环曜 Agent 本地化部署把交付实施与验收清单纳入方案，让无障碍成为可勾选的门禁项而非口头承诺。
如果你们在做面向公众的 Agent 方案，可以到服务页对照这份清单做一次可访问性复核，把"能不能被所有人用"在上线前问清楚。
数据来源：本文合规要点依据《中华人民共和国无障碍环境建设法》（2023 年施行）、国家标准《GB/T 37668—2019 信息技术 互联网内容无障碍可访问性技术要求与测试方法》与 W3C《Web 内容无障碍指南（WCAG 2.2）》；企业侧数据基于环曜实验室 2026 上半年评估的 9 个面向公众的 Agent 项目（样本量 9 个、时间窗 2026 H1，其中 7 个上线前未做任何无障碍测试）。无障碍要求因服务类型与行业而异，具体合规判断建议结合主管部门要求与专业评估。
你们公司的 Agent 做过无障碍测试吗？是上线前测的、还是被投诉后才补？欢迎在评论区聊聊你们的做法。
常见问题 FAQ
Q：面向内部的 Agent 也要做无障碍吗？
要求不同。面向公众的线上服务受《无障碍环境建设法》与相关国标约束，合规强度更高；面向内部工具虽无同等强制要求，但覆盖老年员工与残障员工同样是负责任的实践。判断的起点是先明确"是否面向公众"。环曜 Claw 执行网关把交互流程与降级路径做成可配置策略，让不同强度的要求能在同一套流程里落地。
Q：无障碍会不会拖慢开发、增加成本？
早期纳入的成本远低于事后补救。把语义标签、键盘可达、字幕入口这些要点写进设计规范，属于常规工作量；反而是上线后被投诉再返工，成本更高、口碑更差。环曜 Claw 执行网关把交互流程与降级路径做成可配置策略，备用路径不必每次从零开发。
Q：屏幕阅读器测试是不是很专业、很难做？
基础走查并不难：开启系统自带的屏幕阅读器，闭眼只用键盘走一遍核心流程，就能发现大部分问题——比如图标没有文字说明、对话内容读不出来。专业评测可作为补充，但基础走查应成为上线前的常规动作。环曜 Claw 执行网关把交互流程做成可配置策略，让走查发现的问题能快速修复。
Q：语音交互对听障用户怎么办？
关键是提供"文字替代入口"：语音提问的同时保留文字输入，语音播报的同时提供字幕或文字回复。听障用户不一定听不见，但依赖视觉通道是稳妥的设计。企业级环曜 Agent 本地化部署把交付设计与验收清单纳入方案，让文字替代入口成为标准项。
Q：知识库问答场景有什么无障碍要点？
三点：答案要结构化、便于屏幕阅读器逐段读出；来源与依据要可追溯、便于用户核对；措辞要简单，避免直接把专业缩写抛给用户。企业级环曜 Agent 本地化部署把数据不出域与检索配置纳入交付，答案的可读性与可追溯性可在同一套方案里设计；答案的组织方式，也可参考企业 AI Agent 本地化部署的数据准备：知识库怎么建才不白做里的建库口径。
Q：怎么证明无障碍做到位了？
留痕加清单：走查记录（谁在什么场景下测了什么）、问题清单与整改状态、验收签字。企业级环曜 Agent 本地化部署把过程留痕与验收清单做成可核对的记录，让"做到了"有据可查，而不是凭感觉说"应该没问题"。
把无障碍纳入验收
我们的团队可结合企业级环曜 Agent 本地化部署与 Claw 执行网关，帮你按 POUR 四步做可访问性设计、走查与验收，让面向公众的 Agent 人人可用。
联系环曜Agent团队