AI无障碍：从法律争议到产品落地，多模态如何赋能残障人群

这次我们不看新模型跑分也不做一键包评测。先看一个来自 Hacker News 的提问“Why not expand accessibility laws to include the right to use AI?”直译过来是——为什么不能把无障碍法律扩展一下让“使用 AI”本身成为残障人群的一项法定权利这个问题挂在 HN 上说明它已经不只是法学界或公益组织关心的事。AI 正在变成信息获取、工作、学习和日常生活的基础设施。如果一个盲人用户想看懂一张没有替代文本的图片过去只能靠读屏软件读出文件名现在可以把图片交给多模态模型得到一段完整的自然语言描述。那么问题来了当 AI 已经是解决一类障碍最有效的工具时法律为什么还停留在“网站必须有 alt 文本”的阶段而没有进一步承认残障用户有“使用 AI”的权利这篇文章不打算只做道德表态而是把它当成一个技术产品问题来拆现有无障碍法律覆盖到哪一步、AI 对残障人群的实际能力边界在哪、法律想扩也扩不动的卡点是什么、产品团队和开发者现在能做什么。文章不构成法律意见涉及具体法规时请以官方文本为准。适合给做 AI 产品、多模态应用、无障碍改造、数据合规的团队参考。1. 先把问题拆清楚什么叫“使用 AI 的权利”第一次看到这个标题很容易理解成“要不要给 AI 赋予法律人格”。不是。这个问题的主体始终是残障人士问的是法律是否应当保障残障人士能够获得并使用 AI 工具来消除因身体、认知、感官障碍带来的参与壁垒。要讨论就得先确定这里说的“权利”是哪一种。从无障碍法律的传统逻辑看至少有三层可能含义权利层级通俗理解对 AI 服务的含义工具准入权不能因为残疾而在软件、网站、公共服务中被排除在外残障用户使用 AI 服务时不应被界面、格式、验证码或操作方式挡住合理便利雇主、学校、公共服务提供者应在合理成本内提供辅助条件在必要场景下应当为残障用户提供 AI 辅助工具或替代通道质量兜底不仅“能进入”而且“能完成目标”完成质量要可用AI 生成的结果要准确、可验证、可追责不能靠幻觉应付这三层差异很大。如果说的是第一层那今天大多数 AI 产品只要做到网页符合 Web 无障碍规范即可如果说的是第三层那就意味着法律要对 AI 模型输出质量设定下限这会直接牵动模型评测、认证、责任归属和商业模式。现实情况是目前大部分无障碍法规处理的是第一层和第二层的一部分。它们保证一个用户能打开网站、能操作表单、能读到正文但不保证他能免费拿到一台高配置电脑也不保证他能获得某家公司的付费 API 额度。因此“为什么不能把无障碍法律扩展到 AI 使用权”这个问题真正要回答的是当某类 AI 工具已经成为消除某种障碍的事实标准时法律和政策应不应该用强制手段降低残障用户使用这类工具的阻力。2. 现有无障碍法律到底覆盖到哪一步无障碍不是新鲜事。国际和主要国家地区已经有一套以“消除信息与通信障碍”为核心的法律框架。法规 / 标准适用范围对 AI 的覆盖程度联合国《残疾人权利公约》缔约国公共政策、信息通信、无障碍环境原则性条文要求识别和消除障碍没有具体技术条款美国 ADA《美国残疾人法案》公共场所、就业、公共服务网站与 App 在判例中被逐步纳入要求数字服务对残障用户可达却没有专门规定“AI 服务”美国 Section 508联邦政府采购和使用的电子信息技术对政府系统提出可访问要求多数场景引用 WCAG 标准欧盟《欧洲无障碍法案》(EAA)面向消费者的一系列产品与服务2025 年 6 月起适用规定了无障碍要求主要基于 WCAG 2.1 这类技术标准中国《无障碍环境建设法》无障碍设施、信息交流、社会服务对基础网站和应用提出规范要求鼓励信息无障碍技术研发应用过去十多年数字无障碍的主流合规方式就是对照 WCAGWeb 内容无障碍指南做改造。WCAG 最早处理的是静态网页后来扩展到 Web 应用和移动端核心关注点包括文本替代、键盘操作、对比度、焦点顺序、表单标签、字幕和错误提示。你能用键盘走完整个流程吗读屏软件能读出按钮含义吗没有声音时有没有字幕这些检查项解决的是“通道”问题。所以你会发现一个很明显的断代旧法规保证的是“通道畅通”而 AI 时代的新问题是“通道畅通之后用户还需要一个能替他处理信息的智能体”。让一个盲人用户能打开一个图片网站不等于他能读到图片里的信息让一个听障用户能播放一段视频不等于他能理解视频中的对话和音效。通道打开之后还需要一层“信息转译”能力而这正是当前法规最薄弱的地方。美国 ADA 已经有大量要求网站无障碍的判例法院多次认定网站属于“公共 accommodation”范畴。如果一家餐饮企业只提供服务却无法让视障用户通过 App 下单就可能构成歧视。这类判决的逻辑是当线上渠道成为获取服务的主要方式时它就必须对残障用户开放。顺着这个逻辑继续推当 AI 成为现代社会读取、转译、生成信息的通用渠道“使用 AI 的权利”就不再是一个夸张的口号而是旧逻辑在新工具上的自然延伸。3. AI 对残障人群的真实能力边界谈法律之前先把技术现状说清楚。AI 为什么能成为无障碍工具不是因为某个模型“聪明”而是因为它能把人从一种不兼容的表达形式里解放出来。障碍类型典型需求现有 AI 能力成熟度判断视觉障碍理解图片、图表、视频画面内容OCR、图像描述、结构化信息抽取中高但复杂场景仍会出错听觉障碍理解语音内容、参与会议语音转文字、实时字幕、说话人分离中高准确率依赖口音和环境肢体障碍用有限的肢体操作电脑和手机语音控制、眼动追踪、Agent 多步执行中依赖硬件与系统配合言语障碍用辅助方式表达想法文本转语音、AAC 辅助表达工具中高读写与认知障碍理解复杂文本、处理长文章文本简化、摘要、解释概念、口头与书面语转换中错误会影响理解以视觉场景为例。多模态模型已经不是单纯输出一句“图片里有一只猫”而是可以完成更细的任务把一张药品说明书的文字完整抽出来、把一张数据图表转成表格、描述一张照片里的空间关系、判断一份法律文件里哪几段是免责条款。对低视力或阅读障碍用户来说这相当于给每个人配了一个可以随时问的“转译员”。更值得关注的是 AI Agent 类工具。过去一个肢体障碍用户要完成一个多步骤流程比如订票、填表、取消订阅每一步都有键盘、鼠标和视觉上的障碍。现在 Agent 可以把“帮我完成这个在线申请流程”拆成多个子任务并操作界面完成。它能替代的不只是一次问答而是一整套操作链条。这也是为什么很多讨论把 AI Agent 和无障碍放在一起它可能是比聊天框更接近“数字无障碍基础设施”的形态。但必须泼一盆冷水演示视频里的成功和法律意义上的“可用”是两回事。图像描述模型很可能漏读一张图里的关键文字语音识别在安静录音室里效果很好在嘈杂的公共场合会明显退化文本简化模型可能把重要但复杂的知情同意条款简化成误导性内容。无障碍场景不允许“大部分时候对”因为一旦出错用户可能做出错误决策甚至面临人身和财产风险。4. 为什么不直接立法强制“AI 使用权”如果只看价值判断几乎没有人会反对残障群体更好地使用 AI。但法律不是价值口号它得写清楚谁有权、找谁要、要什么、做不到怎么罚。这也是“扩展到 AI 使用权”迟迟推进不下去的几个真实原因。第一义务主体不清楚。无障碍法规通常只约束两类对象政府机构和面向公众的服务提供者。AI 产业链太长了。底层模型由大厂或开源社区提供中间有云服务商、API 网关、客户端产品再往上才是残障用户用的具体应用。如果法律要求“AI 服务必须无障碍”到底是要求模型训练方负责还是要求调用 API 的上层应用负责模型能力不足应用层优化得再好也没用。第二缺乏稳定的质量标准。WCAG 能成为法律引用标准是因为它有明确的检查点对比度达到多少、键盘能不能操作、错误提示能不能被读屏读出。这些检查点可以被自动化工具扫描也可以由人工审计判定。AI 服务应该怎么测按什么指标判定一个聊天机器人“对盲人用户友好”上下文长度多长算合格回答准确率要达到多少输出速度要多快这些指标还没有形成像 WCAG 那样的社会共识。没有可执行标准法律条款写出来也很难强制执行。第三法律责任落不下来。无障碍领域过去主要讨论“能不能进入”进入之后用户自己处理信息。AI 场景下模型直接替用户解读和决策出错时的责任归属变得很棘手。假设一个视障用户让 AI 朗读并解释一份手术知情同意书模型漏掉了“可能发生严重并发症”这句话导致用户做出了错误的医疗决策。这算谁的如果 AI 只是辅助工具人类用户应该自己核对可残障用户往往没有能力用其他方式完成同样信息获取这时候严格免责并不公平。第四成本分担模式没有想清楚。网页加 alt 文本边际成本接近零。AI 服务则相反好的模型需要付费订阅调用 API 需要按 token 或次数付费本地部署需要高性能设备。如果把 AI 当作合理便利雇主或服务方需要买单如果把它定义成公共服务那就需要财政预算支持。多数国家的无障碍政策还没有想清楚谁来承担这个持续增加的运营成本。第五立法速度追不上模型迭代。一部法律从起草到生效通常需要数年而 AI 模型一年内能力会发生明显变化。现在立法把某类“图像描述能力”写成强制要求两年后这项能力可能已经被整合进操作系统底层条文失去意义反过来也可能今天还很弱的能力两年后突然成为刚需。这些原因并不等于“不该扩”。它们更像是在说与其抽象地宣布一项“AI 使用权”不如把问题拆成更小、更可执行的服务义务比如“特定公共服务场景必须提供 AI 辅助转译”或“面向残障用户的 AI 服务必须具备人工核查通道”。5. 把 AI 当无障碍工具的五个硬约束从产品落地角度看即使法律问题暂时无解工程层面的硬约束已经很明显。任何一个想认真做无障碍 AI 产品的团队都要同时处理这五个问题。5.1 设备、网络与算力门槛很多无障碍方案建立在大模型在线推理之上这要求用户有一台性能足够的手机或电脑并且有稳定的网络连接。现实中有大量残障用户收入偏低、设备老旧、网络不稳定。更极端的情况下某些偏远地区的用户连高质量带宽都没有云侧 AI 服务根本不可用。本地部署是绕开网络和数据上传的一种思路AI 模型部署本身已经相当成熟支持 CPU 推理的小体量模型、量化版本、各类推理框架也很多。但要真正达到“看得懂复杂图片、听得懂方言语音”的水平本地部署对硬件的要求会迅速提高。显存占用、内存占用和推理速度取决于模型规模、量化方式和输入长度没有统一答案。以通用实践看小参数模型可以在普通 CPU 上运行但多模态大模型要达到生产可用通常需要独立显卡和足够显存具体需要多少必须按实际模型版本和推理参数测试。这不是障碍用户能自己解决的问题产品团队必须提前设计端侧、云侧或混合方案。5.2 成本与计费模式无障碍领域的许多基础工具能普及是因为操作系统厂商愿意把它们内置到系统中。AI 服务需要持续调用 GPU 算力每一轮对话都有真实成本。如果只靠慈善式免费额度一旦用户量大服务方很难支撑如果全部转成收费订阅又会把低收入残障用户挡在门外。可行的路线通常是分层基础无障碍能力由系统或公共平台内置进阶能力按合理价格提供特定公共服务场景由政府或机构统一采购并开放。5.3 隐私与数据合规残障用户在使用 AI 工具时往往会暴露大量敏感信息。让 AI 阅读一封医疗邮件、解读一份心理健康问卷、转录一段与医生的对话这些数据一旦泄露后果很严重。无障碍 AI 产品必须默认做到数据最小化、本地优先、加密传输、设置明确保留期并提供关闭数据用于训练的入口。如果需要处理医疗、金融、法律等场景还需要走更严格的合规流程。5.4 语言与偏见覆盖今天的多模态模型和语音模型效果在主流语言、主流口音、标准化场景下最好在方言、少数民族语言、非标准发音、罕见疾病相关文本上表现会明显下降。无障碍能力不能只看“平均准确率”还要看对少数人群的覆盖。模型训练数据的偏差会直接转化为障碍用户实际使用体验的偏差。5.5 评测难度无障碍需求的个体差异极大。同样是低视力用户有人需要超大字体有人需要对比度调整有人需要语音输出有人需要的是 OCR 文字提取。一套固定的自动化测试并不能覆盖所有组合。真实可用的评测需要大量真人用户参与并且要求覆盖不同障碍类型和使用环境。这在工程上是一件成本很高、周期很长的任务。6. 产品团队现在就能做的“无障碍友好型 AI”法律可以慢慢讨论但产品不应该等。无论将来是否立法下面这些做法都是当前 AI 产品应该具备的基本素质。让 AI 功能有非 AI 的回退路径。图像描述结果可以失败模型可能超时语音识别可能没有声音。产品要保证用户在这些情况下仍然能完成主要任务。比如一个“图片转文字”功能除了在线模型识别还要允许用户手动上传文件或联系人工处理。支持多种输入输出通道。用户可能不方便打字也可能不方便听语音。真正合格的产品应该同时支持文本、语音、图片输入以及文字、语音、结构化数据输出而且每一种通道之间可以互相切换。AI 功能不能只存在于一个漂亮的语音交互界面里必须保留键盘操作和读屏软件兼容路径。输出结果要结构化。与其让模型生成一大段自然语言描述不如同时输出结构化字段让读屏软件可以按标题、段落、列表逐项朗读。图片描述、OCR 结果和字幕文件都应该有对应的结构化导出格式。设置人工核查和置信度提示。对高风险内容产品应当在界面上提示“AI 生成结果可能不准确”并提供人工复核入口。不要用绝对肯定的语气呈现模型输出尤其是医疗、法律、财务内容。一份面向工程和内审的“无障碍能力声明”可以先从配置化开始。下面这只是一个通用模板具体字段需要按产品和框架要求调整{ api_version: 1.0, accessibility: { screen_reader_compatible: true, keyboard_operable: true, captions_export: true, text_fallback_for_image: true, voice_command_fallback: true, human_review_available: true }, data_policy: { local_first: true, retention_days: 0, user_opt_out_training: true } }再往下一层产品可以把不同残障场景明确写进服务目录。这里的 YAML 同样是示意用来帮助团队对齐“每个功能到底为谁服务、以什么格式输出、达到什么阈值才允许上线”services: - name: image-description output_formats: [text, structured_json] max_image_size_mb: 20 confidence_threshold: 0.85 human_review_required: true fallback: manual-support - name: speech-to-text output_formats: [text, vtt, srt] caption_granularity: sentence accent_coverage: [mandarin, cantonese] fallback: text-upload配置本身解决不了体验问题但它能让团队在验收时有一个可争议、可修改的标准而不是靠感觉判断“无障碍做得怎么样”。7. 面向 AI 无障碍的验收与测试思路无论最后法律怎么写产品上线前都应该做一套类似下面这种评估流程。这个流程设计上不针对某一款模型而是针对“某个 AI 功能是否能给某类残障用户提供可用服务”。第一步建立场景清单。不要抽象地说“支持无障碍”而是要列出具体任务。比如“视障用户上传药品包装照片后能获得完整文字和用法信息”“听障用户在会议录音中能找到某个发言人的话”。第二步定义客观指标。对每一个场景至少确定四个维度关键任务成功率、输出延迟、数据安全、失败回退率。可以用下表作为起点指标建议观察方式说明关键任务成功率由真人测试者在标准场景中执行任务必须统计失败原因不能只看平均数输出延迟从用户提交输入到界面呈现结果在线模型应关注可用性过长会让交互不可用回退完成率在 AI 失败时用户能否人工完成目标无障碍产品的底线是绝对不能“只有 AI 一条路”数据泄露风险日志中是否包含敏感明文对医疗、法律等场景要高优先级第三步找真人做小样本验证。自动化测试能发现明显的按钮标签缺失、焦点问题但发现不了“这段描述是否符合真实场景认知”这类体验问题。测试时应当邀请不同障碍类型、不同技术熟悉程度的用户每个人使用的辅助工具可能完全不同。第四步把结果沉淀成回归用例。将每次测试发现的问题加入自动化检查列表。例如可以用脚本从页面里扫描缺失的 alt 属性为后续人工补写或模型补全做准备。下面是一个仅做扫描的 Python 示例依赖 requests 和 BeautifulSoup具体细节需要按目标站点调整import requests from bs4 import BeautifulSoup def find_images_missing_alt(page_url: str) - list: 扫描页面中所有缺少 alt 的图片返回图片路径列表。 html requests.get(page_url, timeout10).text soup BeautifulSoup(html, html.parser) images soup.find_all(img) missing [] for img in images: alt img.get(alt) if alt is None or alt.strip() : missing.append(img.get(src) or img.get(data-src)) return missing if __name__ __main__: # 这里替换成自己的测试地址 for path in find_images_missing_alt(https://example.com): print(missing alt:, path)这个脚本本身没有用 AI但它可以作为后续生成 alt 文本的前置扫描器先找出缺什么再决定用模型补全还是让人工作者补写。这种做法比直接在页面上批量生成 alt 更安全因为关键图片的 alt 文本如果由模型生成错误会直接影响视障用户对页面的理解。8. 常见误区与错误示范实践中很多团队对“AI 无障碍”的理解停留在表面下面几个误区值得单独说。误区问题在哪里正确做法“模型能看图所以图片无障碍已经解决了”图像识别不等于图像可访问结果需要及时、准确、结构化地呈现给辅助工具对关键信息采用多模型二次校验并保留人工回退“加一个语音助手就无障碍了”听障用户无法使用纯语音交互语音之外保留文字输入和文字输出“自动生成 alt 文本就能通过合规”模型可能漏掉关键文字或误读信息对复杂图片建议人工参与生成或者至少提供用户补充入口“使用开源模型就是免费无障碍”开源模型仍需硬件、部署和运维云端共享和公共支持比让每个用户自己部署更现实“无障碍只针对少数人”WHO 估算全球有十亿级有某种形式残疾的人且老龄化会扩大这一群体应当作为基础产品能力而非小众需求“模型输出准确率到 99% 就够好了”在医疗、法律、财务等领域错误需要具体情况具体评估对高风险任务设置置信度阈值和人工核查点“只要用户能打开页面就算无障碍”旧标准只保证通道没有保证任务完成验收应以“帮助残障用户完成任务”为目标这些误区本质上是不把无障碍当作一个持续迭代的系统来建设。判断一款 AI 产品无障碍做得好不好最直接的方法是找不同障碍类型的用户用他们日常真实需求做一轮任务测试而不是只看产品经理演示几条流畅对话。9. 给不同角色的行动建议把这个话题拉回工程落地不同角色可以有不同的行动重点。产品经理在需求文档里为每个 AI 功能明确无障碍字段注明主要用户群体、支持通道、回退方案、数据保留策略。上线前把无障碍测试加入发布门禁而不是发布后再补。前端与客户端开发者保证所有 AI 交互元素都有可访问名称焦点顺序合理支持键盘操作配合读屏软件测试。对模型输出的长文本要正确使用标题、列表和段落标签。算法与后端开发者监控模型在不同语言、口音、图像类型上的表现差异。提供延迟、置信度、关键错误率指标。设计对敏感数据脱敏后再调用云服务的流程。数据合规人员明确残障用户数据收集的合法性基础保留用户对数据用于训练的拒绝权。如果涉及医疗或生物识别类数据必须有专门评估。公共采购与服务提供方在采购 AI 服务时要求供应商提供无障碍能力声明并把这项要求写进合同而不是默认所有 AI 都“自然会用”。10. 结论与下一步回到最初的问题为什么无障碍法律没有直接扩展成“使用 AI 的权利”更稳妥的判断是法律现在很难为一个仍在快速变化的技术工具直接赋予抽象权利但这不等于它不应该往这个方向走。真正的扩法路径很可能是把“AI 使用权”分解成具体的、可测试、可救济的服务义务公共服务场景能不能提供 AI 辅助转译残障用户是不是有多条可替换的信息获取通道高风险 AI 输出有没有人工核查数据隐私有没有得到保护。这些点实际上不需要等法律通过产品团队现在就可以做。无障碍和 AI 的结合最终会走向一种“默认能力”而不是某个残障用户主动申请的特权。下次产品评审时可以多问一句我们的 AI 功能在最糟糕的情况下能不能让一个不方便看、不方便听、不方便操作键盘的用户独立完成目标如果答案是不确定那这个问题就还没做完。