企业官网建设流程全解析

在无障碍审核中，alt 文本经常是最容易被误解的一项。扫描工具报告“全部通过”，页面上的图片却可能对依靠屏幕阅读器访问页面的用户造成严重的信息断层。原因在于，alt 文本是否合格，本质上不是字段填写问题，而是一个语义决策问题。自动化检查可以确认<img>标签存在、alt 属性非空、长度不超限，但它无法判断这段替代文本在当前页面上下文里是否准确、简洁、功能完整。这篇文章从 alt 文本的消费机制讲起，分析自动化检查的能力边界，再用具体案例说明什么样的 alt 文本才算真正合格，最后给出可执行的评价规范和团队落地建议。

1. 先理解 alt 文本的机制，再谈自动化检查为什么局限

1.1 alt 文本不是“图片描述”，而是图片在特定上下文中的功能替代

很多开发者在写 alt 文本时，习惯把它当成“图片标题”或者“图片注释”，于是写出alt="公司团建照片"、alt="产品图片"这类内容。严格来说，这个理解从起点就偏了。

alt 文本的正式名称是 alternative text，作用是“当图片无法被用户感知时，用文本向用户提供与图片等价的信息”。注意重点是“等价信息”，不是“图片里有什么”。一张展示销售数据的柱状图，如果 alt 写成“柱状图”，用户只知道自己读的页面上有一张柱状图，但不知道数据趋势；如果 alt 写成“2024 年 Q1 到 Q4 销售额从 120 万增长到 320 万”，用户即使完全看不到图，也能获得图片要传达的核心结论。

所以判断 alt 是否合格，第一个标准不是“有没有写”，而是“写完后，看不到图片的人是否获得了和看到图片的人等量的关键信息”。这个标准天然依赖上下文：同样一张人物照片，放在新闻正文里当配图，与放在“领导团队”列表里作为成员头像，合格的 alt 内容完全不同。

1.2 浏览器和屏幕阅读器如何消费 alt 文本

先看 HTML 中图片的标准写法：

<!-- 装饰性图标，不传达信息 --> <img src="decorative-line.png" alt=""> <!-- 链接内图片，alt 描述链接目标 --> <a href="https://example.com/download"> <img src="download-icon.png" alt="下载安装包"> </a> <!-- 页面顶层需要描述的配图 --> <img src="campus-2024.jpg" alt="2024 年新投入使用的东区教学楼，外立面为灰色石材与玻璃幕墙">

浏览器在正常显示图片时，alt 文本是隐藏的，用户通常不会看到。但发生以下情况时，alt 文本会直接进入用户的感知通道：

• 图片加载失败，浏览器在图片占位区域渲染 alt 文本；
• 用户使用屏幕阅读器，例如 NVDA、JAWS、VoiceOver，图片被跳过，改为朗读 alt 文本；
• 用户使用纯文本浏览器或开启“减少动态效果”“关闭图片”等设置；
• 搜索引擎索引图片时，将 alt 文本作为判断图片内容的重要信号。

屏幕阅读器用户的操作流程需要重点理解。当焦点或浏览光标进入一张图片时，读屏软件通常会把图片角色和 alt 内容一并读出，例如：

• 有 alt 的图片读作：“图片，2024 年新投入使用的东区教学楼……”
• alt=""的图片直接跳过；
• 没有 alt 属性的图片读作：“图片”——只有角色，没有任何内容；
• 有 alt 但内容是文件名alt="DSC00123.JPG"的图片读作：“图片，DSC 00123 JPG”。

由此可见，alt="DSC00123.JPG"比空 alt 更糟，因为用户不仅没有得到信息，还要处理噪音。真正合格的 alt 目标是：让读屏用户获得的信息结构与视觉用户尽量一致，既不缺失，也不冗余。

1.3 自动化检查到底在检查什么

常见的自动化检查工具包括 Lighthouse、axe-core、pa11y、W3C HTML Validator，以及各类前端工程里集成的 eslint-plugin-jsx-a11y。它们对图片的检查规则大体集中在以下三类：

• 图片元素必须包含 alt 属性；
• alt 属性不能为空字符串，除非图片被标记为role="presentation"或aria-hidden="true"；
• 标题属性与 alt 不应完全重复，避免读屏软件重复朗读。

在 axe-core 的规则文档中，与图片直接相关的规则是image-alt，它只检查 img 元素是否有可访问名称。如果 alt 属性缺失，会报Ensures <img> elements have alternate text。如果 alt 属性存在且不为空，工具就会判定通过。

这带来一个典型误读：Lighthouse 无障碍分数 100，图片来源就全部合格。实际上，自动化工具默认了一个前提：只要作者手动写了 alt，作者就具备判断能力。它无法判断这段 alt 是否准确、是否和页面文字重复、是否包含了图片传达的全部关键信息、是否适合当前语言环境。这些都需要人类判断，或者需要更高维度的系统约束。

下面用一个快速验证的示例说明自动化检查的粒度：

<!-- 场景 A：会被工具判定为通过 --> <img src="chart-revenue.png" alt="营收图"> <!-- 场景 B：会被工具判定为通过 --> <img src="chart-revenue.png" alt="2024 年各季度营收曲线整体呈上升趋势，Q1 为 120 万，Q4 为 320 万"> <!-- 场景 C：会被工具判定为通过 --> <img src="chart-revenue.png" alt="营收图 2024 年各季度营收曲线整体呈上升趋势 Q1 为120万 Q4 为320万 数据来源 财务部 制表人 张三">

三个场景在 axe 和 Lighthouse 面前等效，但在真实用户面前差异极大。场景 A 信息不足，场景 B 相对合格，场景 C 虽然信息全但冗余、不聚焦。自动化检查无法区分这些差异，这是它最核心的能力边界。

2. 自动化检查能发现的问题和无法发现的问题

2.1 自动化检查能稳定发现的问题

先说自动化工具擅长的事情。这类工具适合做“机器可判定的语法和结构检查”，对于以下问题很可靠：

• 图片缺少 alt 属性；
• 装饰性图片使用alt="some-id"而非空 alt；
• img 被aria-hidden="true"包裹但内部仍有内容；
• 同时使用 alt 和 title，且二者内容完全一致，可能导致重复朗读；
• CSS background 图片无法获取 alt 文本（这个通常不会被 image-alt 报出来，但会被人工评审发现）。

把自动化检查当作“语法层”把关是合理的。它可以在 CI 中拦截明显不合规的写法，提醒开发人员补写属性，减少人工评审的低级轮次。

2.2 自动化检查必然误判的场景

下面这五类场景，自动化工具几乎都判断不了，但它们恰恰是 alt 文本质量差异的主要来源。

第一类是纯装饰图片和功能图标的区分。页面背景上的装饰性线条图案，视觉上没有任何信息，正确写法是alt=""。而链接中的下载图标，功能是告诉用户“点击后下载”，正确写法是alt="下载 PDF 合同模板"。工具只能检查 alt 是否存在，无法判断这个图片到底是装饰还是功能。

第二类是 alt 与周围文本是否互为补充。如果标题下面已经写明了“2024 年 Q1 营收 120 万”，图片 alt 再写“2024 年 Q1 营收 120 万”，读屏用户会听到两遍相同信息。这属于冗余，但自动化工具会认为 alt 写得很好。

第三类是 alt 是否准确描述图片功能。一个“联系我们”的按钮图标，alt 写成alt="icon"，读屏用户听到“链接，图片，icon”，无法判断点击后会进入哪个页面。自动化工具不会判断“icon”是否有意义。

第四类是图片中是否包含文字。如果一张截图里包含关键操作路径，例如菜单路径“设置 > 安全中心 > 两步验证”，alt 没有把这些文字放进去，使用读屏软件的视障用户就完全无法感知截图内容。该场景在微信、文档工具、管理后台截图里极其常见。

第五类是语言和地区语义。一个简体中文网站配一个alt="Company Overview"，虽然非空，但读屏用户听到的是一句英文，这种问题工具也发现不了。

2.3 自动检查与人工评审结果对照

这张表的结论很清楚：自动化检查在“形式完整”这一层有用，到“内容合格”这一层几乎无效。正确策略是让自动化工具承担入口拦截，让人工评审承担质量判断。

3. 用真实案例区分“通过检查”和“真正合格”

3.1 案例一：装饰性图片写成非空 alt，信息没增加反而更糟

常见场景是页面装饰分割线、圆角装饰、渐变背景上的小光点。有些开发者为了通过自动化检查，把这类图片写为：

<img src="yellow-dot.png" alt="黄点">

自动化检查通过。但读屏用户听到“图片，黄点”，完全不知道这个黄点代表什么。更合理写法是：

<img src="yellow-dot.png" alt="">

这样读屏用户不会收到任何噪音，页面信息不因装饰图而中断。判断标准只有一个：如果把这行 img 从页面中删除，视觉用户看到的信息有没有变化。没有变化，就使用空 alt。

3.2 案例二：按钮图标 alt 写成图片文件名，交互目标丢失

管理后台常见的操作为“编辑”“删除”“导出”三个图标。如果写成：

<a href="/edit/1001"> <img src="edit.png" alt="edit.png"> </a>

读屏用户听到“链接，图片，edit.png”。用户不知道链接是指向编辑功能，还是打开一个名为 edit.png 的下载文件。这是功能性 alt 失效的典型情况。

正确写法是描述链接行为，而不是描述图片视觉：

<a href="/edit/1001"> <img src="edit.png" alt="编辑订单 1001"> </a>

这类 alt 的检查点在读屏体验上等价于“这个链接的文本是什么”。如果图片不可见，用户能够仅凭 alt 判断点击结果，就算合格。

3.3 案例三：信息图只有一句描述，关键结论全部丢失

信息图是最容易暴露 alt 质量问题的图片类型。一张包含“四个步骤、六条数据、两条注意事项”的总览图，如果 alt 只写“安全迁移系统步骤图”，读屏用户只能知道页面有一张图，但不知道任何步骤。正确的做法有两种。

第一种是图片本身简单，把所有关键信息写进 alt：

<img src="migration-steps.png" alt="系统迁移四步：备份数据库，关闭旧应用，切换配置，启动新应用并验证访问" >

第二种是图片信息复杂，在正文中提供等价数据表格或文字说明：

<figure> <img src="migration-steps.png" alt="系统迁移步骤示意图"> <figcaption> 系统迁移四个步骤： 1. 备份数据库； 2. 关闭旧应用； 3. 切换配置； 4. 启动新应用并验证访问。 </figcaption> </figure>

第二种做法更适合信息量大的图。alt 提供概览，figcaption 或相邻文字提供完整数据，读屏用户获得的信息与视觉用户基本一致。

3.4 案例四：alt 与相邻文本重复，读屏变得啰嗦

设计系统里的常见页面一般长这样：

<h2>2024 年第四季度营收</h2> <p>2024 年 Q4 营收为 320 万元，环比增长 15%。</p> <img src="q4-revenue.png" alt="2024 年第四季度营收为 320 万元，环比增长 15%">

自动化工具看到非空 alt，标记通过。读屏用户却会听到两遍相同的数字。此时 alt 应该只承担图片图形结构的信息，例如“折线图，展示 2024 年 1 月至 12 月营收逐月变化，年中有一段时间平缓，年末快速上升”。数字和结论已经在页面文字中，不需要重复放入 alt。

4. 建立可执行的 alt 文本评价规范

4.1 四个评价维度：功能、简洁、上下文、独立

把真正合格的 alt 文本拆成四个可判断的维度，团队评审时不必凭感觉打分。

第一个维度是功能性。先问这个图片在页面里承担什么职责：是传达数据，还是引导跳转，还是纯装饰。职责不同，写法完全不同。

第二个维度是简洁性。alt 文本不是图片说明文。在完成功能目标的前提下，能用一个短语表达的不要写成一个段落，能写一句话的不要写两句话。过长的 alt 不仅干扰读屏，也让维护变得困难。

第三个维度是上下文相关性。alt 必须结合它在页面中的位置来判断。同一个人物照片在“团队成员”页面和“新闻人物”页面写法不同。在团队成员页面会写“张三，研发部后端工程师”，在新闻页面会写“张三在技术峰会上讲解系统架构设计”。

第四个维度是独立性。读屏用户通常先听到 alt，再听到周边文字。alt 应该在脱离图片的情况下可以独立理解，不能包含“如上图所示”“见下图”这类依赖视觉位置的表达。

4.2 常见图片类型的推荐写法与不推荐写法

下面这张表可以直接作为团队评审依据：

验证码图片需要额外说明。出于安全考虑，验证码的 alt 不应直接包含验证码字符，否则自动化程序可以直接读取。正确做法是提示用户输入图片中的字符，并附加“无法识别时可点击获取新验证码”的说明。

4.3 开发侧如何落实评价规范

评价规范只有在落在代码审查和组件封装中才具备约束力。推荐做三件事。

第一件事是建立可复用的图片组件。在 React 项目中可以封装一个带 alt 校验的组件占位，实际项目需要结合自己的技术栈调整：

type AccessibleImageProps = { src: string; alt: string; decorative?: boolean; }; function AccessibleImage({ src, alt, decorative = false }: AccessibleImageProps) { if (decorative) { return <img src={src} alt="" role="presentation" />; } if (!alt || alt.trim().length === 0) { // 开发环境抛出错误，构建阶段也可以集成 lint 规则 console.error("[AccessibleImage] 非装饰图片必须提供 alt 文本。"); } return <img src={src} alt={alt.trim()} />; }

这个组件只是最小示例。真实项目中还可以把 alt 的文案规则写进团队的代码规范文档中，并在 code review 时专门检查 alt 字段。

第二件事是配置 eslint 规则。eslint-plugin-jsx-a11y的alt-text规则可以覆盖缺失 alt 的情况，虽然它不能判断语义质量，但能在第一时间拦截“写了 img 却忘记 alt”的低级遗漏。

第三件事是把人工审查模板化。评审页面时不要只问“alt 有没有写”，要按下面的清单逐项确认。这个清单可以直接贴在代码仓库的 pull request 模板或者部门无障碍检查单里。

5. 团队协作：自动化工具 + 人工评审 + 组件约束

5.1 CI 管道中接入自动检查

自动化检查虽然不能替代人工判断，但可以在早期把基础问题挡在门外。前端项目可以在 CI 中执行以下命令：

# 使用 lighthouse-ci 对目标页面做基础无障碍扫描 npx lighthouse https://example.com/form-page --only-categories=accessibility --output=json --output-path=./lighthouse-report.json # 使用 pa11y 扫描页面 npx pa11y https://example.com/form-page

在本地开发阶段，也可以直接针对单个 HTML 文件执行 axe：

# 全局安装 axe-core 与辅助脚本后运行扫描 npx @axe-core/cli https://example.com/list

接入 CI 的核心目标是让“图片缺失 alt”这类问题在合并代码前被拦截，避免把基础错误带进生产环境。CI 中的检查结果不要作为唯一标准，它更像是提交代码前的门槛。

5.2 人工评审矩阵

人工评审通常出现在页面改造、设计走查、无障碍专项审计三种场景。评审时可以使用下面这个矩阵，给每个图片打分：

评审结果不是“通过/不通过”二选一，而是给出修改方向。评审重点放在信息完整性，而不是机械地填满 alt。

5.3 用组件封装和 lint 规则兜底

组件封装可以改变团队默认行为。例如，如果团队使用 Vue，可以要求所有图片统一走业务封装的 Image 组件，组件内部强制 alt 参数：

<template> <img :src="src" :alt="decorative ? '' : altText" :role="decorative ? 'presentation' : undefined" > </template> <script setup> import { computed } from 'vue'; const props = defineProps({ src: { type: String, required: true }, altText: { type: String, default: '' }, decorative: { type: Boolean, default: false }, }); </script>

组件封装解决的是“格式统一”，lint 解决的是“属性缺失”，人工评审解决的是“语义是否合格”。三者组合才能形成完整闭环。

另外，后台内容编辑中的图片更需要注意。CMS 系统如果允许运营人员上传图片，前端最好能够校验 alt 是否填写，并在图片库列表中把“alt 为空”作为筛选条件。许多实际项问题并不是开发时写错，而是运营后台上传的图片 alt 被留空，前端只能显示默认 alt 或文件名。

6. 常见问题排查与质量清单

6.1 常见误区与排查链路

在实际项目验收中，容易反复出现以下问题：

第一个误区是“自动化得满分就是无障碍合格”。一个页面如果所有图片都有 alt，但 alt 全部是alt="图片"，自动化检查会通过，实际体验却很差。排查方式是用读屏软件实际走一遍页面，或者让一位不了解页面的同事只凭读屏输出描述页面内容，如果描述完整清晰，才算合格。

第二个误区是“装饰图片和功能图片无法区分就统一填空”。最稳妥的方法是建立设计规范：设计稿中标注哪些图片是装饰、哪些图片包含功能。前端实现时严格按照标注填写 alt。经验欠缺的团队可以先从页面头部、侧边栏、按钮图标三个高频位置开始标注。

第三个误区是“alt 越长越好”。alt 过长会让读屏用户难以抓住重点，建议优先用正文承载详细数据，alt 只做定位和概要。例如：正文表格已经列出全部数据时，图片 alt 写“按月份排列的收支柱状图”即可，不需要重复整张表。

第四个误区是“图片里的文字不用写进 alt”。审批系统中，一张截图包含“任务已驳回”的状态，如果 alt 只写“审批截图”，读屏用户完全不知道任务被驳回。正确写法至少是“审批截图，状态为已驳回，批注为材料不全”。

排查问题时可以按以下链路从现象倒推根因：

6.2 alt 文本审核清单

给开发、测试和内容编辑共用，建议打印出来作为页面发布前的检查项：

• 检查页面中每个 img 元素是否都有 alt 属性。
• 区分装饰图片和功能图片，装饰图片使用alt=""，不使用非空文字。
• 对链接里的图片，确认 alt 描述的是链接目标，而不是图片外观。
• 对按钮里的图片，确认 alt 描述的是操作结果。
• 对数据图，确认 alt 已经传达核心数据结论，而不是只写“柱状图”。
• 对信息图，确认 alt 提供概览，完整数据在正文或可访问表格中提供。
• 对截图类图片，确认截图中的关键文字、按钮、状态已被替代文本覆盖。
• 检查 alt 与页面周边文本是否存在重复，重复部分从 alt 中移除。
• 检查多语言页面中 alt 是否使用了与页面语言一致的文本。
• 不要把重要信息只放在 title 属性中，title 依赖鼠标悬停，移动端和读屏设备都不可靠。

6.3 继续深入的方向

alt 文本只是可访问性的一个环节。真正完整的无障碍建设还需要考虑键盘可操作、焦点顺序、颜色对比度、表单标签、ARIA 使用规范、动态内容提示等。从团队落地角度，建议先从图片 alt 开始，因为它的整改成本低、判断规则清晰、影响范围广。

进阶时可以继续做三件事：一是为内容编辑提供可视化 alt 编辑与预览工具；二是建设图片素材库时强制填写 alt 元数据；三是在设计评审阶段就把 alt 内容纳入验收标准。越早在流程中定义 alt，后期返工成本越低。

对开发团队最实用的建议是：不要只在合规审计前才检查 alt。把 alt 质量纳入每次代码评审和页面验收的固定项目，并让熟悉屏幕阅读器的成员定期做真实走查。自动化工具的价值在于兜底语法，人工评审的价值在于保障语义，两者缺一不可。