最近在技术社区看到一个提问为什么不能把无障碍法律扩展让“使用 AI”也成为一项被保障的权利这个问题乍看像政策讨论但对常年做 AI 产品的人来说它更像一道压到眼前的工程题。因为现实中我接触到的很多残障用户正在同时经历两种相反的体验一方面AI 语音、图像描述、字幕生成确实打开了过去根本打不开的门另一方面大量 AI 产品的界面、交互和输出机制对这些用户并不友好甚至比传统网页更不友好。低视力用户想用 AI 识别药盒上的说明结果发现对话界面里的按钮无法被读屏软件聚焦语言障碍者想用语音输入但模型面对非标准口音和节奏反复给出错误结果上肢活动受限的用户想用键盘快捷键控制 AI 应用的窗口却发现所有交互都要求拖动鼠标。这些问题不是个案而是辅助技术社区里反复出现的类型化痛点。于是问题就变成了既然 AI 正在成为公共服务、信息获取、内容生产的默认入口它为什么不适用于已有的无障碍法律如果法律真的把“使用 AI”明确为权利产品团队除了等罚款还能做什么这篇文章想从技术、产品和制度三个角度把我对这个问题的理解讲透。我的主判断是把“使用 AI”写进无障碍权利清单方向上是有价值的但单纯争论“是不是权利”容易陷入口号真正难且重要的是把 AI 产品当成一种“需要可访问性设计的基础设施”来建设并对它的不可用情况建立可申诉、可回退、可验证的机制。1. 一个矛盾AI 一边在消除障碍一边在制造新的“不可访问区域”1.1 为什么残障用户比普通用户更需要 AI先别急着讨论法律先说产品体验。AI 之所以对残障用户特别重要是因为它在“信息换算”上的能力恰好能补上人类感知和操作上的缺口。视力障碍者需要把图像、图表、界面布局转成可朗读的信息AI 视觉理解模型能做到听力障碍者需要把会议音频转成带分角色的文字记录AI 转录能完成言语障碍者想用文字或眼动设备表达复杂句子AI 语言模型可以提供更自然的句子补全肢残用户想省掉大量机械操作AI Agent 可以把多步骤网页操作压缩成一句指令。也就是说AI 最擅长做的“把一个模态的信息转成另一个模态”正好是传统无障碍技术做了几十年但做得不够好的事。过去的读屏软件只能读出页面代码里的文本遇到图片就无可奈何现在 AI 可以描述整个图片里的场景、行人和文字。过去的字幕依赖人工现在 AI 能实时生成多语言字幕。因此 AI 对残障群体的价值不是锦上添花而是替代某些昂贵的人工支持服务。1.2 但 AI 产品本身往往默认使用者是无障碍的“标准人”问题也出在这里。我用“标准人”这个词指的是产品设计时默认的隐形容器能看见图像、能稳定操作鼠标、能无障碍打字、能理解长文本、能用正常语速和语法说话、能理解错误提示。如果一个用户不在这个默认范围内就可能在使用 AI 产品时被卡住。这不是某个团队故意歧视而是 AI 产品在设计目标上的错位。很多 AI 产品把“模型能力”当成核心把“应用层可达性”当成边缘。开发时主要验证的是 prompt 响应、生成质量和速度很少把“通过屏幕阅读器操作核心流程”列入验收标准。于是一个很怪的循环出现了为了帮助视障者识别图片AI 产品要求用户先上传图片上传图片的功能却要求用户看得见“拖拽到此处”的虚线框。为了给听障用户提供实时字幕AI 软件让他先完成语音验证码语音验证码无法切换成文本形式。为了让老年人更容易操作 AI产品给了聊天式界面却忽略了字体对比度和焦点状态。AI 本应是消除障碍的工具但设计不良时它把一个需要低门槛的通道变成了新的门槛。1.3 法律视野里的“访问权”并不等于“技术能力使用权”这里需要区分两个概念。无障碍法律一直保障的是“在同等条件下访问公共设施、信息和服务”它的核心不是给残障者特别优待而是要消除环境里的物理或信息壁垒。比如一栋大楼要有坡道、一部视频要有字幕、一个网站要能被读屏器读出这些都是为了让残障者能像其他人一样“走进去”。但是 AI 产品不太一样。AI 产品不是一个有固定属性的静态对象它是可变的、生成式的、随输入变化的。同一个 AI 系统对这个用户可能输出准确答案对另一个用户可能因为口音、用词、上下文或使用的辅助技术不同而失效。所以如果只要求“AI 必须能访问”而不规定“在什么输入条件下、以什么模态、在什么失败率以下可以访问”法律就无法落地。这也是为什么“把使用 AI 作为权利列入无障碍法律”会引发争议。支持者会说如果疫情让在线服务成为默认那么 AI 时代也会有大量公共服务把 AI 当成默认入口如果残障者不能使用这个入口就会被排除在社会核心功能之外。反对者则会说AI 本身还在快速变化幻觉、不可解释性、隐私和安全问题都没解决把一个不稳定的技术写进法律义务会让厂商和企业无所适从。我觉得两边的观察都对了一半。AI 产品确实需要被纳入可访问性管理但这个问题不能只靠一个“新权利”来终结。法律上的“权利”必须有可执行的技术标准和责任主体。而目前最缺的不是法条而是一套能把 AI 能力拆解成“可输入、可输出、可理解、可兜底”的工程验收体系。2. 为什么传统无障碍标准管不住“会生成内容的模型”2.1 现有标准的根基是“确定性对象”过去几十年全球积累了比较成熟的无障碍标准比如网站内容无障碍指南、数字产品设计规范。它们能实施是因为监管对象有相对确定的属性。一个按钮颜色对比度是多少、一个视频有没有字幕、一张图片有没有替代文本这些都是可以静态检查的。符合或者不符合有明确判断依据。AI 系统破坏了这个确定性假设。用户输入一句带方言的话模型可能先理解错了然后生成一段逻辑流畅但内容错误的回复。这种错误不是页面布局层面的缺陷而是信息处理层面的偏差。现有无障碍标准可以用来检查页面上的“发送”按钮是否容易被聚焦但它检查不了“AI 有没有歧视某些残障者的语言模式”。这是传统合规框架很难覆盖的部分。还有一个差异在于传统软件按用户操作路径执行行为可预期我点击“搜索”它必然去搜索。AI 系统是概率生成同样一段提示词不同时间可能返回不同结果同一个模型对某些用户的内容风格也不是平均适配的。这种情况下你无法把“AI 的回答是否符合预期”做成一条静态验收规则只能考察“AI 系统是否提供了解释、纠错和退出机制”。2.2 AI 让“感知替代”失效的场景更隐蔽无障碍设计里有一个重要概念叫感知替代比如用音频替代视觉、用触觉替代视觉、用文本替代图像。AI 看似提升了感知替代的能力但同时引入了新的失效层。举个例子视力障碍用户让 AI 描述一张医疗检查单上的结果。AI 成功识别了图像但它在描述时误读了关键词把“未见异常”说成“检查到异常”。用户完全信任这个输出焦虑地冲到医院。这个场景里页面上的所有按钮都能被读屏器访问没有违反任何现有的无障碍标准但系统在信息质量和责任保障上彻底失败了。再举一个更隐蔽的例子AI 字幕系统可以为听障用户生成实时字幕传统字幕服务很贵AI 让它变得便宜普及。可一旦麦克风位置不太好或说话人口音较重AI 字幕就把关键术语写错。听障用户看不到语音信息只能依赖字幕而此时字幕的错漏会被当成“沉默环境里的唯一真相”。这种风险在传统无障碍语境里讨论得很少因为我们过去把字幕当成事先校验过的静态内容而不是动态生成的概率性文本。2.3 结论我们要从“检查静态属性”转向“守住使用链路”因此我建议改变策略。与其追问“这个 AI 产品是否符合无障碍”不如追问“一个残障用户能不能从头到尾完成一项核心任务”。核心任务可能包括注册账号、输入问题、理解回复、导出结果、纠正错误、联系人工。这条链路里AI 模型的输出质量只是其中一环前后还有输入模态、操作方式、反馈机制、权限设置、客服通道。传统无障碍标准擅长检查这一链路中的物理和界面层但要覆盖 AI还得增加几个新维度模型输出是不是有可替代的低风险版本遇到误判时用户能不能快速发起纠错当 AI 因为隐私或安全拒绝执行任务时用户能不能理解拒绝原因这个链路才是真正需要被法律、监管和产品团队共同守住的。3. “AI 使用权利”背后的真正需求防止 AI 变成不可替代的傲慢入口3.1 权利的本质不是让所有人都会用 AI而是不让任何人被迫使用 AI很多人听到“无障碍法律要包含使用 AI 的权利”第一反应是“每个人都应该有 AI 账号和算力补贴”。这误解了无障碍权利的历史逻辑。无障碍权利的核心是“公平进入”和“不要被排除”不是“免费获得所有服务”。在 AI 语境下它应该保护两件事第一当 AI 被广泛用于公共或民生服务时厂商不能默认只有所谓正常能力的人才能使用。比如某个政务互动助手用 AI 聊天机器人和语音导航提供服务如果听障者无法用文字和助手顺畅沟通问题就从“体验不好”升级为“权利受损”。第二当 AI 系统产生误判或者直接代替人类做出决定时用户必须有权利要求一个非 AI 的替代路径。这听起来不符合“AI 是未来”的叙事但恰恰是残障者最需要的。因为 AI 出错时普通用户可以通过视觉和常识发现问题残障用户往往依赖 AI 转换结果反而更容易被错误锁定在坏状态里。3.2 不要让 AI 成为数字世界的“单向门”我把那些在现实中已经出现的痛点梳理了一遍发现高频场景集中在几个地方AI 客服把用户困在对话循环里没有提供“转人工”入口AI 无障碍辅助功能只有在用户主动开启时才可用且无法保存个性化设置AI Agent 帮助用户操作界面但生成的操作路径与屏幕阅读器冲突导致用户越自动化越混乱。这些场景的共同特征是系统把 AI 设计成了唯一通道并默认用户有能力绕过坏路径。比如 AI 客服只放一个对话框旁边没有电话或线上工单或者所谓的“无障碍加速”按钮在每一步操作后都要重新配置。对残障用户来说这种设计相当于一个单向门走进去容易走出来很难。无障碍法律如果真的要扩展最有价值的不是让 AI 公司“提供更多智能”而是要求它们“提供不智能时的退路”。一个 AI 系统应该被看成“传统服务 智能增量”的组合。AI 可以优先回答但当 AI 说不清楚、用户表达不明、连续失败三次、出现高风险语境时必须能平滑切换到人工或保留传统界面。把这种“人工兜底”作为权利义务远比要求每个人都能自由使用 AI 更诚实。3.3 法律语言无法替代产品中的用户自主选择同时我也担心把“使用 AI”变成标签化的权利可能会产生负面效果。有些团队为了体现“人人可用 AI”会设计出一个 AI 外壳让所有服务入口都先经过一个对话助手。结果为了合规这个助手覆盖了盲人用户、听障用户、低龄用户但每个人都被迫先解释一遍自己的需求。这不是无障碍这是新的门户税。真正的无障碍权利应该包括不被强制使用 AI 的权利。如果 AI 增加了一层额外的步骤、隐私风险和认知负担用户应该可以选择原始的表单、网页或人工服务。要知道很多残障者不是害怕新技术而是受够了每次新产品都要重新学习一套交互范式、重新验证一遍自己的需求。产品应该在默认路径旁边留下低技术门槛的“简单模式”让用户自己决定需要多少 AI 加持。4. 工程实践如何在 AI 产品里建立一条真的可访问链路法律问题讨论到这里还是要落到代码和界面。很多 AI 团队的困惑是我们连无障碍标准都没有完整执行更不知道怎么为 AI 做专项可访问性。这里给出一个可执行的四层落地框架。它不要求你做一次完美的重构而是把 AI 可访问性拆成四个可以单独验证的层次。4.1 第一层输入可替代别让任何人卡在“唯一入口”先问一个扎心的问题你的 AI 产品怎么输入一条消息如果只能靠可视化文本框 鼠标点击“发送”那你就已经排除了一部分使用屏幕阅读器的用户因为他们通常依赖键盘导航和表单焦点。如果 AI 语音助手只能通过麦克风输入你就排除了部分言语障碍用户和需要安静环境的用户。如果 Agent 能自动代替用户操作页面那么一旦操作逻辑不可见用户就会失去控制感。这一层的建议是所有核心功能包括模型选择、历史记录、参数调整、导出按钮都必须能用键盘完成。语音输入之外至少保留文本输入文本输入之外提供粘贴剪贴板内容的能力。如果用了拖拽上传图片必须同时提供“选择文件”对话框。AI Agent 在执行高风险操作前要给出明确的文本确认并允许用户撤回。4.2 第二层输出可感知让生成内容不再淹没在页面动态里现在的 AI 应用越来越多采用流式输出也就是模型一边生成界面一边滚动。听起来很顺畅但对使用读屏软件的人来说流式刷新会造成一个问题内容不断插入焦点不断移动读屏器要么读不完要么在句子中间被打断。输出层的做法可以更保守一些默认提供流式开关或至少保证用户能暂停输出。生成结果出来后要保证它是稳定的、可聚焦的 DOM 节点而不是一张由 Canvas 绘制、不提供文本层的截图。当 AI 输出多模态内容时——如果模型返回图片、表格、图表——要确保每个非文本元素都有替代文本并且替代文本要基于真实内容而不是随便写的“示意图”。另外要特别注意 AI 界面里的“自动消失”。很多新式对话框在用户点空白区域时历史回答会折叠这个操作会让键盘焦点丢失。更好的做法是用清晰的“历史记录”区域展开通过按钮切换而不是依靠鼠标悬停或点击外部触发的隐藏逻辑。4.3 第三层内容可理解降低认知和语言门槛AI 模型天然是长文本生成器但可访问性不只是 UI 层面的按钮问题还有内容表达门槛。对于有认知障碍、阅读障碍、语言障碍的用户长段、密集、没有章节切分的 AI 输出几乎是不可读的。这一层的实践不是降低模型能力而是改变展示策略在生成回复时默认提供一个“摘要”字段用 1 到 2 句话说明结论。对超长回复要提供段落标题、无序列表和“跳到下一个部分”的锚点结构而不是一坨连续文本。如果模型输出了专业术语在旁边提供一个“用简单语言解释”的按钮。对时间敏感或高风险任务输出里要标出置信程度比如“这是根据说明书内容推断的结果不代表医疗建议”。还有一个容易忽视的点错误页面和权限提示的信息也要低门槛。AI 因为内容安全检查拒答时应该告诉用户是哪类问题被拒绝了而不是只弹出一个模糊的“无法响应”。残障用户面对一个晦涩的断句往往更难判断是模型能力问题还是自己输入的问题。4.4 第四层失败可兜底把异常反馈变成可申诉的闭环这是与 AI 结合最紧密的一层。在传统软件里如果按钮坏了用户还能看到“按钮没反应”。在 AI 系统里输出大多是流畅的但可能暗中出错。所以需要像设计备份系统一样为错误设计“逃生通道”。落地建议至少包含四项功能每次 AI 生成回复后都能让用户一键提交“这个回答不对”提交时自动附上输入上下文和模型版本便于追溯。如果一个任务连续失败三次或者检测到用户处于高风险请求场景界面应给出“联系人工”按钮而不是继续让用户重试。如果用户依赖某种定制辅助工具比如个性化语音模型或外部读屏器要在设置里允许导入和保存这些偏好而不是每次会话都重来。保存完整的无障碍日志记录用户使用的辅助技术版本、输入设备、失败链路方便支持团队复现问题。4.5 一个可以直接用的小框架AI 无障碍验收四问把前面四层收成一个小框架产品无论大小都能用它做自测。上线前找真实用户或至少自己模拟问四个问题一个只能使用键盘和读屏器的用户能完成你产品的核心任务吗一个看不见界面但依赖文字输出的用户能理解并处理 AI 返回的内容吗一个说话困难或口音明显的人能顺利通过语音方式使用你的 AI 功能吗当 AI 输出错误、卡住或拒绝回答时用户有没有一条路径能找到真实的人类支持这四个问题不需要一次全部做到满分但至少要在 sprint 排期里成为准入条件。没有通过前三个的 AI 功能只能算“demo”没有第四个的 AI 功能不建议进入公共服务场景。5. 警惕不要让“AI 无障碍权利”变成新的表面合规5.1 低质量 AI 辅助可能比没有更危险法律扩张的动机是好的但工程上有个严峻问题把 AI 当成无障碍工具会带来一种“我们给了你智能辅助”的错觉实际却可能增加风险。一个视障用户过去用传统 OCR 识别文字OCR 虽然死板但错误的模式基本固定用户能学会判断哪些场景不可靠。AI 描述图片则不一样它会用充满信心的语气写一段很具体的描述但可能漏掉关键内容或凭空增添细节。用户无法判断哪里可信任。如果把这种带有系统性幻觉风险的 AI 功能定义为“满足无障碍权利的默认方案”反而可能剥夺用户采用更谨慎、更低速但更可靠的传统方案的权利。所以在产品里需要把 AI 辅助分成“低风险增强”和“高风险关键路径”。低风险增强比如把文章标题生成为标题列表出错影响不大高风险关键路径比如帮助盲人识别处方药、帮助听障者理解紧急广播这时候 AI 生成结果必须附带可追溯来源、人工确认流程以及对风险的明确提示。法律保护这类场景没错但工程上必须先建立分级。5.2 AI 偏见会放大传统辅助技术的盲区无障碍用户不是同质群体AI 模型往往在最主流的标准语言和标准图标里表现最好受益者恰恰是本身资源更充分的那部分残障用户。举个例子英文场景下的 AI 无障碍工具比小语种成熟得多中英文都能使用的模型在少数民族语言或方言上的表现通常不稳定。言语障碍者的语音模式千差万别模型如果只在“标准普通话样本”上训练就无法服务于真正需要语音识别支持的亚群体。这里有一个明显的风险无障碍合规会鼓励厂商优先服务“最容易让 AI 表现好的群体”然后宣称已经支持残障用户。但真正被排除的是那些数据稀缺、使用小众辅助技术、表达方式不够“标准化”的边缘人群。这也是为什么必须把真实用户纳入测试而不是只靠一个测试库跑过就算通过。5.3 成本与责任谁为“可访问 AI”买单最后一个现实问题是谁来承担成本。给主流产品做无障碍本来就需要投入AI 产品还要额外负担模型评测、人工兜底、辅助技术兼容性测试。如果法律只是简单地把“使用 AI 的权利”定义为强制义务而没有配套的豁免、分级和促进机制小团队和公益项目可能因为合规成本过高而退出反而减少了残障用户的选择空间。更合理的路径是阶梯式监管对高风险公共服务里的 AI 系统要求强制人工兜底和可申诉流程对中小规模工具允许先采用较简单的 AI 无障碍说明和用户反馈入口对模型准确度不确定的功能要求在产品中明确标注风险级别。法律文本需要的是一个精密的约束框架而不是一句“所有 AI 都必须人人可用”的漂亮口号。6. 从法律到产品现在能做的是把“可访问 AI”变成验收项回到最初那个问题。如果无障碍法律真的扩展把“使用 AI”列为权利最高兴的也许不是残障用户而是律师和咨询机构。但如果只是法条变了产品没有任何变化那这种权利就是徒劳。所以我更愿意把这个讨论翻译成产品团队的待办事项。在等待法律细则成型之前已经有几件事可以做在采购或自研 AI 能力时把“是否有辅助技术兼容方案”列入技术选型评分。如果你连读屏器、键盘导航都跑不通就不应该声称自己在提供 AI 无障碍服务。每次 AI 功能发版前用辅助技术跑一遍核心链路而不是只做视觉回归测试。可以用最低成本的方案打开系统自带读屏器关掉鼠标尝试完成一次提问。给 AI 生成内容增加“风险级别”字段并且在 UI 上区分信息性内容和关键决策建议。不要把所有输出都渲染成权威事实。建立用户反馈闭环特别是针对无障碍体验的反馈渠道。哪怕一开始只有一个简单的邮箱或表单也需要允许用户描述自己使用的辅助技术、设备型号和失败步骤。保留一条非 AI 替代路径。这不仅是法律兜底也是产品信任度的一部分。用户需要知道即使 AI 帮不了我我也还有一个“人”或一个“传统界面”可以求助。在这里我想强调不要把“无障碍”窄化为只是为了满足某种合规指标。它本质上是对产品默认设计的一种纠偏是你是否愿意承认你的用户拥有各种各样的身体、感知、语言和使用场景而不是一张精心设计的数据集画像。AI 不应该成为另一个“普通人特权工具”也不应该被用来假装解决所有复杂的人类问题。如果哪一天法律真的把“使用 AI”明确为无障碍体系的一部分我希望届时我们已经有足够的工程积累让这个条款不只是出现在文件里而是体现在每一次键盘点击、每一句可感知的提醒、每一个出错后的逃生通道里。到那时候讨论谁是权利主体已经不那么重要了重要的是在 AI 快速进入生活每个角落时我们有没有来得及给每个人留一扇始终能打开的门。