最近在一次前端无障碍改造项目中我遇到了一个很有意思的现象页面上所有图片都通过了自动化无障碍检查但让视障用户实际使用读屏器操作时仍然有大量图片信息无法被正确理解。检查报告是绿的用户体验却是差的。问题就出在 alt 文本上——它能通过自动化检查不代表它真的合格。本文就从“alt 文本自动化检查的边界”出发聊一聊为什么检查通过不等于内容合格以及我们作为开发者、测试者应该如何真正把 alt 文本写对、审好。在开始之前先同步一下语境本文讨论的 alt 是 HTML 中img标签的alt属性也就是图片的替代文本而不是键盘上的 Alt 键。很多同学在搜索资料时会发现搜“alt”能搜出高比例的结果是关于 Excel 中 AltEnter 批量换行、Blender 中 Alt 左键操作、CtrlAltA 截图冲突这类内容。这里我们不涉及这些快捷键系功能而是聚焦在 Web 无障碍Accessibility和 SEO 相关的图片 alt 属性上。1. 背景与核心概念1.1 什么是 alt 文本alt 文本是 HTML 中alt属性所包含的文字描述用于在图片无法显示、网络加载失败或者用户使用屏幕阅读器Screen Reader时代替图片向用户传递信息。img srclogo.png alt公司Logo这个属性看起来简单但它的设计有一个重要原则alt 文本不是图片标题也不是图片文件名而是“图片在页面中的功能与信息”的等效文本。对于一张展示产品图的图片alt 文本应当说明产品名称、关键外观或关键信息对于一张“返回首页”的箭头图标alt 文本应当说明按钮的功能是“返回首页”而不是单纯描述“一个蓝色箭头”。在 Web 无障碍标准 WCAGWeb Content Accessibility GuidelinesWeb 内容无障碍指南中alt 文本是“文本替代”原则的基础。无论用户是因为视觉障碍、网络原因、设备限制而无法看到图片alt 文本都承担着让信息不丢失的兜底作用。换句话说alt 文本不是写给搜索引擎看的 “图片关键词堆砌区”而是写给真实用户的内容等价物。1.2 自动化检查在检查什么自动化检查工具例如 Lighthouse、axe-core、WAVE、HTML Validator 等会通过解析 DOM 和规则引擎快速扫描页面中的图片元素。它们最常见的检查逻辑大致有这几类图片是否存在alt属性alt属性是否为空alt属性长度是否超过某个阈值不同工具有不同阈值按钮图片以img形式实现的按钮是否有替代文本装饰性图片是否错误地添加了非空 alt 导致读屏器重复阅读图片被包裹在链接中时链接的文本内容是否合理可辨识。这些检查有一个共同特点基于显式特征判断不涉及语义质量判断。工具能知道你写了 alt能知道你 alt 有多长但不知道你写的文字是否与图片内容一致也不知道这个 alt 在当前页面语境下是否传达出了真正的信息更不知道旁边已经有一段文字描述、alt 重复是否造成了冗余朗读。1.3 为什么“通过检查”不等于“合格”这里需要理解“检查”的本质。自动化检查执行的是“是否满足特定规则”的布尔判断。它把无障碍这个抽象目标拆成了若干可计算、可枚举的规则例如“所有 img 必须有 alt 属性”。这条规则可以自动化验证但规则只是最小底线。举个例子一张数据分析报表截图图片下方正文已经有一段完整的表格数据说明。这时 alt 如果写“数据报表截图”自动化检查会通过因为 alt 非空且长度合适。但对使用读屏器的用户来说这个 alt 完全没有传递任何可用数据。这种 alt 就是典型的“通过了检查但实际不合格”。再比如页面中有一张产品照片alt 全部写成了统一的“产品图片1”“产品图片2”。自动化检查仍然显示通过可这类占位文本没有任何信息增量。如果把 alt 当作“应付检查的作业”最终牺牲的一定是真实用户的可访问性体验。2. 自动化检查能力的边界2.1 自动化检查能稳定判断的问题把能力边界说清楚才能知道可信什么、不可信什么。目前各类自动化规则能稳定判断的主要集中在“是否存在”和“是否为空”这一类结构性问题上检查点示例能否自动化img 是否有 alt 属性img srca.jpg缺失 alt能alt 是否显式声明为空img srcdecor.png alt能作为控件的图片是否有可访问名称img srcclose.png alt关闭能alt 是否能被读屏器识别为可编程文本使用 JS 动态插入 alt能在渲染后检查装饰性图片是否错误使用非空 alt背景图误用 img 实现部分能链接图片的替代文本是否为空整图链接 alt 为空且链接内无其他文本能这些检查价值很高能快速筛出页面里大量低级的无障碍问题。比如漏写 alt、图片按钮没有名称、装饰图乱加 alt 导致读屏器读出一堆无意义内容。对于这些场景“通过自动化检查”基本可以放心。2.2 自动化检查天然无法判断的问题自动化工具无法判断的核心是语义和上下文。下面这些问题工具几乎很难做到准确判断alt 内容与图片内容是否一致。工具无法“看懂”图片只能看文字自然无法判断你写的是否匹配。alt 在页面语境下是否必要。如果图片相邻文本已经完整描述了图片内容alt 可能只需要简短甚至为空工具无法理解这种上下文。重复 alt 是否造成干扰。多个页面区域出现同一个 alt 文本读屏器用户会反复听到相同内容工具很难识别是否存在干扰。alt 中是否包含真正有意义的信息。例如“图片”“照片”“示意图”这类通用词工具无法判断它是不是有价值。复杂图片图表、地图、流程是否需要结构化描述。一张流程图可能需要用列表或表格结构来完整描述工具无法判断 alt 是否足够。这也是为什么 WCAG 和各大无障碍规范都反复强调自动化测试不能替代人工测试。自动化检查适合做“守门员”不适合做“评分员”。2.3 常用自动化工具与实现思路常见的自动化检查工具有LighthouseGoogle 提供的开源自动化工具可在 Chrome DevTools、命令行、CI 中使用会生成“Image elements do not have [alt] attributes”等检查项。axe-coreDeque 公司推出的可访问性测试引擎可集成到 Jest、Cypress、Playwright 等测试框架中。WAVE浏览器扩展能可视化高亮页面中的 alt 相关问题。HTML Code Sniffer基于浏览器运行的代码检测工具。这些工具底层通常依赖统一的规则集例如 axe-core 的规则库中关于图片的规则基本是围绕“属性存在性、可访问名称、文本替代必要性”展开。这也解释了为什么它们擅长结构检查却不擅长语义判断。如果想要在自己项目中实现一个轻量的 alt 检查脚本思路也非常简单遍历所有img元素读取alt属性然后对属性值做一系列规则判断。下面我们用一个 Python 脚本演示常见检查逻辑。3. 一个能发现“伪合格 alt”的检测脚本虽然自动化工具不能判断语义但我们仍然可以通过脚本将“明显无意义”的 alt 初步过滤出来。这相当于在常规检查的基础上再增加几道低成本防线减少人工审核工作量。3.1 环境准备本文示例使用 Python 3需要安装requests和beautifulsoup4。如果你本地没有这两个库可以先执行pip install requests beautifulsoup4如果你的网络环境无法直接安装也可以换成 Python 标准库中的urllib和html.parser思路完全相同。下面的示例重点演示规则逻辑不依赖特定版本。3.2 基础检查缺失 alt 与空 altimport requests from bs4 import BeautifulSoup def scan_page(url): resp requests.get(url, timeout10) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) issues [] for img in soup.find_all(img): alt img.get(alt) src img.get(src, ) if alt is None: issues.append({src: src, reason: 缺失 alt 属性}) elif alt.strip() : # 需要结合图片用途进一步判断这里先记录 issues.append({src: src, reason: alt 为空可能是装饰图需人工确认}) return issues if __name__ __main__: for issue in scan_page(https://example.com): print(issue)这段代码可以快速找到结构性缺失的图片。不过需要注意alt对部分装饰图是合理的不能一概而论脚本的作用是标记出来供人工确认。3.3 进阶检查识别“伪合格 alt”前面提到很多 alt 并非缺失而是“写了等于没写”。我们可以配置一个关键词黑名单例如“图片”、“照片”、“图形”、“示意图”“image”、“photo”、“picture”、“pic”“banner”、“img”纯文件名例如DSC001.jpg无意义字符组合例如123456import re PLACEHOLDER_PATTERNS [ r^图片$, r^照片$, r^image$, r^img$, r^pic(ture)?$, r^[a-zA-Z0-9_\-]\.(jpg|jpeg|png|gif|webp|svg)$, r^\d$, ] def is_placeholder(alt): text alt.strip() if not text: return False for pattern in PLACEHOLDER_PATTERNS: if re.match(pattern, text, re.IGNORECASE): return True return False def scan_quality(url): resp requests.get(url, timeout10) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) issues [] for img in soup.find_all(img): alt img.get(alt) src img.get(src, ) if alt and is_placeholder(alt): issues.append({src: src, alt: alt, reason: alt 为占位文本}) return issues这里的正则规则可根据项目需要扩展。运行后你会很快发现很多开发者的确写了 alt但写的是 “img1”“banner”“产品图片”。这些 alt 能通过 Lighthouse 的“存在性”检查却不能让用户获得有效信息。3.4 检查 alt 长度异常的图片另一种“伪合格”场景是 alt 过长或过短。alt 没有强制标准长度但如果是内容型图片一个单词“产品”通常不足以说明信息如果是复杂图表alt 里塞 500 字长描述又会让读屏器用户听得很辛苦。我们可以把长度异常项也找出来def scan_length(url, max_len120): resp requests.get(url, timeout10) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) issues [] for img in soup.find_all(img): alt img.get(alt) src img.get(src, ) if alt and len(alt.strip()) max_len: issues.append({src: src, alt_length: len(alt.strip()), reason: alt 过长建议使用文内描述或 longdesc/aria-describedby}) return issues这个脚本只能提示“可能有问题”因为确实存在个别场景需要较长的 alt 文本。但将异常值抽取出来能帮助人工审核更聚焦。3.5 把脚本集成到 CI 中实际项目中这类检查不必每次通过浏览器手动跑。可以把它封装成一个命令行工具或 Node.js 脚本接入 CI 流程。这样每次代码合并前至少能阻止最明显的占位 alt 进入生产环境。当然这类脚本仍然不能解决语义问题。它只是把人工从“所有图片都要看一遍”中解放出来让人工只需要关注“被标记为疑似问题”和“未被标记但语义复杂”的图片。4. 什么样的 alt 文本才算合格要回答“合格”先要明确 alt 文本的作用场景。同一个图片在不同页面、不同上下文下合格的 alt 并不一样。4.1 按图片类型区分 alt 写法图片类型作用alt 写法示例功能性图片按钮、图标、链接传达操作功能alt关闭弹窗而不是alt叉号图片内容型图片产品照片、新闻配图传达内容信息alt2024年秋季新款红色羽绒服正面照图文重复型图片旁有相同文字避免重复朗读alt或使用空 alt配合相邻文字装饰性图片背景纹理、纯修饰不传达信息alt或使用 CSS 背景图复杂图片图表、流程图需要完整描述信息简短 alt 邻近详细文本或aria-describedby链接图片链接的标签即图片功能如链接到订单页alt查看我的订单这个表格背后的核心原则是先判断图片的“功能或信息”再决定用什么文字替代。空 alt 不是错误错误是空 alt 用在了内容型图片上长 alt 也不是最佳选择最佳做法是让长文本出现在页面正文中。4.2 写 alt 的常见误区把 alt 当作关键词堆砌。例如alt手机 华为 手机促销 降价 5G。这样不仅读屏器体验极差对 SEO 也有风险容易被搜索引擎判定为过度优化。alt 只描述图片表象。比如alt红色圆按钮却没有说明红色圆按钮是“提交订单”。你应该写的是这个按钮的功能alt提交订单。alt 与周边文本重复。如果图片下方已经有一段标题“华为 Mate 60 Pro 手机 256GB 曜石黑”图片 alt 再写一遍完全相同的内容读屏器会重复朗读反而降低体验。这时 alt 可以留空或只补充图片中额外信息。所有图片用同一个 alt。比如全部写alt图片自动化检查当然过但没有信息量。忽略动态图片和懒加载图片。某些图片的 alt 由 JavaScript 异步插入初始 HTML 中没有 alt自动化检查在“未执行 JS”和“执行后”的结果会不同需要结合渲染后检查。遗漏背景图和 CSS 生成的元素。CSSbackground-image中的信息性图片不会被读屏器识别需要通过roleimg加aria-label处理。4.3 复杂图片怎么处理对于图表、地图、架构图这类复杂图片一个很长的 alt 并不是最佳实践因为读屏器用户很难一次性听完几百字描述。更推荐的做法是给图片一个简洁的 alt概括图片主题在图片下方或页面其他位置提供完整的文字说明用aria-describedby关联详细描述。示例img srcsales-chart.png alt2024年第一季度各区域销售额折线图 aria-describedbychart-desc p idchart-desc 2024年第一季度华东区销售额最高达到 1200 万元华北区 980 万元华南区 860 万元西南区 520 万元。整体趋势自 2 月起呈上升态势3 月达到季度峰值。 /p这样读屏器用户可以在听到简洁标题后决定是否继续阅读详细描述避免了“被迫听完一大段”的情况。5. 人工审核哪些必须靠人看自动化检查 脚本过滤能解决大量低频问题但最终质量仍取决于人工审核。建议将以下检查点纳入人工抽查或走查流程。5.1 五个肉眼检查点遮挡图片看上下文想象自己看不到图片。让同事把页面上所有图片隐藏只保留文字和 alt 对应的占位文本看是否能理解页面主要信息。检查 alt 是否冗余连续读几个图片的 alt感受是否存在重复、啰嗦、无意义。检查 alt 是否匹配当前语境同一张图片在不同页面出现时alt 是否根据语境做了调整。检查空 alt 是否真的装饰标记为空 alt 的图片确认它们不承载内容信息。检查动态内容轮播图、列表加载、用户上传图片等动态场景确保运行时生成的 alt 也符合规范。5.2 使用屏幕阅读器走查如果你没有专门的视障用户测试环境至少可以使用 NVDAWindows或 VoiceOvermacOS进行一次基础走查。操作方式也很简单打开页面后使用读屏器的“浏览模式”和快捷键依次浏览图片文本记录听到的内容是否符合预期。这一步能发现自动化工具无法发现的朗读顺序、重复、信息遗漏问题。5.3 将 alt 审核纳入工作流alt 文本质量不是上线前“突击检查”能解决的。更有效的做法是在 UI 设计稿评审阶段要求设计标注哪些图片是装饰性的哪些是内容性的在开发阶段将 alt 编写作为字段校验的一部分不允许提交空的占位文本在测试阶段加入人工可访问性走查用例在发布后定期用脚本扫描新图片并抽样审核。6. 常见问题与排查思路问题现象常见原因解决思路Lighthouse 提示图片缺少 altimg未写 alt 属性为图片补充合适的 alt 或显式设置alt读屏器把图片读成“图片”alt 为空或缺失读屏器使用默认名称补充有意义的 altalt 写了但读屏器没有朗读图片是 CSS 背景图或使用了display:none改为roleimgaria-label或改用imgalt 内容为 “点击查看” 等无意义文本开发者未理解图片信息重新编写为具体功能或内容描述图片按钮无法点击或焦点重复alt 太长读屏器识别内容异常精简 alt将详细说明放在页面其他位置所有图片 alt 一致复制粘贴导致全局搜索替换逐张确认语义搜索结果中出现大量 AltEnter 教程搜索关键词“alt”歧义实为 Excel 中的按键使用“HTML img alt 属性”等更精确关键词自动化检查通过但用户反馈混乱检查工具只校验结构问题补充人工走查和屏幕阅读器测试注意alt为空和alt缺失是两个完全不同的概念。空 alt 表示“装饰图内容不需要被替代”缺失 alt 表示“图片信息没有被声明”。自动化工具通常会区分这两种情况。7. 总结与学习路线alt 文本这件事本质上是“技术与体验的交叉点”。你不能只把它当成一个 HTML 属性更不能只看自动化检查报告。自动化检查是效率工具它能拦住漏写、空写、占位等字段级问题但语义正确性、上下文适配性、用户阅读体验必须依靠人工审核、屏幕阅读器走查和真实用户反馈。如果你想在自己的项目里逐步建立 alt 文本质量标准可以按照下面四个阶段推进第一阶段先跑通自动化检查把缺失 alt、空 alt、动态加载 alt 这类硬伤清零。第二阶段引入关键词占位检测脚本清理“图片”“banner”“photo”这类无意义 alt。第三阶段建立团队内部的 alt 编写规范按照功能性图片、内容型图片、装饰图、复杂图片分类给出示例。第四阶段把人工走查和屏幕阅读器测试加入发布流程并定期抽样审查线上页面。最后再强调一遍一个 alt 文本合不合格最终判断标准是“图片被移除后用户是否仍然能获得等效信息”而不是工具面板上的绿色对勾。希望你下一次写 alt 时能多花十秒钟想一下它背后的真实用户。