AI 在信息无障碍里能补哪一段，四个不足要提前知道

2026-10-06 发布来源：我告诉你AI导航阅读

早上八点，一位视障用户站在公交站，手机里的地图应用弹出一张线路图——图上标着三辆车的位置，但读屏软件只念出一串没有意义的按钮编号。他要的信息就在屏幕上，取不出来。这类卡点在过去两年被 AI 撬开了一部分：图像能转成语音描述，对话能转...

早上八点，一位视障用户站在公交站，手机里的地图应用弹出一张线路图——图上标着三辆车的位置，但读屏软件只念出一串没有意义的按钮编号。他要的信息就在屏幕上，取不出来。这类卡点在过去两年被 AI 撬开了一部分：图像能转成语音描述，对话能转成字幕，说话能转成文字。但撬开的是哪一段、剩下哪一段还得靠产品自己改，很多人并不清楚。这篇把 AI 真正补上的几个环节拆开，再说清它替不了什么。

卡住的往往不是内容，是取不出来

信息无障碍要解决的问题，说到底是「同一份信息，换一种感官也能拿到」。视觉信息给听觉，听觉信息给视觉，操作方式从点击换成说话。这三条转换路径，恰好是 AI 这几年的强项：语音识别把声音变文字，语音合成把文字变声音，图像理解把画面变描述。三条路径对应三类用户，也对应三种完全不同的技术难度。

理解这个分工，就能明白为什么有些功能突然好用，有些依然别扭。凡是「把一种模态转成另一种模态」的活，模型做得越来越好；凡是「界面本身没设计好」的问题，模型只能绕，绕不过去就得改产品。前者是能力问题，后者是工程和意愿问题。

从打开页面到完成操作，四段各补到哪

把一次典型操作拆成四段，AI 的落点就清楚了：

环节	能做	不能做
读屏增强	把图标、图表、验证码说明、复杂表单的层级关系转成连贯的口头描述；给没有替代文本的图片补一段说明	修复没有标签的按钮、错乱的焦点顺序、被弹窗抢走的焦点，这些要在代码层改
实时字幕	把会议、课程、视频的声音转成可读文字，带说话人区分与时间轴；会后生成可检索的记录	在强噪声、多人抢话、术语密集的场合仍然准确；方言与口音仍会掉字
语音输入	把口述转成文字，支持标点与简单指令；让不方便打字的人完成搜索、填表、发消息	替代完整的键鼠操作；处理需要精确点选的小目标；在嘈杂环境稳定工作
图像描述	说出画面主体、场景、文字内容、大致空间关系；对文档拍照后朗读全文	判断哪一处细节对当前任务关键；描述人脸身份与情绪；做到细节不漏

第二列是可以依赖的部分，第三列是出问题时必须回到产品侧解决的部分。四行里最容易被高估的是图像描述——它听起来什么都能说，实际给的是「大致对」的画面，遇到需要精确判断的场合，比如核对一张账单上的金额，仍然要配合文字识别和结构化朗读。

读屏、字幕、语音输入，门槛各不相同

读屏增强的难点不在识别，在组织。屏幕上的信息是二维的，读屏输出是一维的，把一棵界面树压成一句话，需要判断哪些节点重要、哪些可以跳过、层级怎么表达。做得好不好，用户一听就知道：好的朗读会先说「这是一个对话框，包含三个选项」，差的朗读从第一个按钮开始念，念到第十个用户已经忘了前面。

实时字幕的难点在延迟和断句。字幕晚两秒，对话就跟不上；断句断错，意思会反。多数产品会把延迟压到一秒以内，代价是准确率下降，于是出现「字幕在跳、人在猜」的状态。这类场景对语音识别的要求，比对事后转录高得多——后者可以慢慢改，前者必须在说话的同时给结果。

语音输入的难点在纠错。说错一个字，改起来比重新说还慢；专业名词、人名、地名几乎必错。多数输入法用上下文做二次纠正，效果取决于领域词表。这三段里，语音输入是普通人用得最多、也最容易忽略其局限的一段——它在安静环境里很顺，一旦换到地铁或会场，体验会断崖式下降。

界面本身的可访问性，模型替不了

这里要说清楚一件事：AI 补的是信息转换，补不了设计缺陷。一个按钮如果没有可访问名称，读屏软件读出来的就是「按钮」，模型再怎么增强也不知道它是「提交订单」。焦点顺序错乱、颜色对比不足、只能用拖拽完成的操作、弹窗关闭按钮藏在角落——这些都是界面层的问题，必须在设计和开发阶段解决，靠外挂一层 AI 只能打补丁。

补丁还有副作用。有的产品用模型给整页生成一段「页面摘要」，听起来贴心，实际把结构信息压平了：用户想跳到第三个表单项，摘要里没有这个入口。无障碍的核心是可控——用户能自己决定读什么、跳什么、重复什么，一段自动生成的流畅描述反而剥夺了这种控制权。

这也是多模态 AI在无障碍场景里的真实位置：它把不同模态之间的墙打薄，但墙的位置由产品结构决定。墙没拆，转换再顺也还是绕路。

四个不足，落在使用时的哪一步

准确率不稳定，最先暴露在专有名词上。人名、药名、型号、地名，模型倾向于给出一个「像」的结果，而不肯说「没听清」。听障用户看字幕，一个数字听错，可能就是一班车、一笔钱。

延迟问题在实时场景里最致命。字幕、语音助手、口述输入都要求说完就出来，而模型推理需要时间。把模型做小能降延迟，代价是准确率；把模型做大能提准确率，代价是延迟。这个取舍在端侧设备上尤其明显，手机的算力和电量都是硬约束。

描述不够细，是因为模型不知道你要干什么。同一张厨房照片，做饭的人想知道灶上有没有火，找东西的人想知道东西放在哪一层。模型的默认描述是平均视角，要拿到有用信息，得在提问里补上目的。这类按任务提问的技巧，和提示词的写法是同一套逻辑：说清场景，答案才有针对性。

适配不足是四个里最难改的。很多产品的无障碍支持是在上线后补的，补的时候只测了主流程，边角功能一律漏掉。而用户碰到的往往正是边角：改密码、开发票、取消订阅、填一份多页表单。

怎么判断一个功能值不值得依赖

三个观察点。第一，出错时它说不说「不确定」。愿意输出「这张图里文字看不清」的系统，比一律给答案的系统可靠。第二，能不能中途打断和重问。无障碍使用是交互式的，用户需要随时纠正方向，一次性输出一段长描述的产品很难用。第三，有没有非 AI 的兜底路径。人工客服、结构化表单、快捷键，这些老办法在模型失灵时是唯一出路。

对开发者来说，判断标准更简单：把页面里的图片替代文本全部清空、把按钮标签全部去掉，看产品还能不能用。能用，说明结构是好的，AI 是加分项；不能用，说明 AI 在替结构背锅。