图片alt属性：内容与技术如何协作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f9bd6544e907.html
📄
图片alt属性：内容与技术如何协作
图片alt属性的内容与技术协作，核心是一份可执行的清单：内容人员决定每张图要表达什么，技术人员保证这个表达被写进正确的HTML位置，再由双方共同验证。最关键的一步不是写文案，也不是改模板，而是先确认图片的用途分类，因为装饰图、信息图、功能图对alt的要求完全不同，分类错了后面全错。
准备：先按用途给图片分类
在动手写任何alt文本之前，把页面上的图片过一遍，归入三类。这一步决定了后续所有判断，跳过它就会出现“每张图都硬写一段描述”的低效结果。
- 装饰图：纯视觉分隔、背景纹理、与正文含义无关的配图。这类图应使用空alt，即
alt=""，让辅助技术跳过它。注意空alt与完全不写alt是两回事，后者会让部分工具读出文件名。 - 信息图：图表、流程图、产品实拍、截图。这类图的alt要传达图中承载的信息，而不是描述画面长什么样。
- 功能图：作为链接或按钮的图片，例如搜索图标、购物车图标。alt要说明点击后会发生什么，而不是图片外观。
分类时的判断依据很简单：如果这张图被删掉，读者会丢失信息吗？会，就是信息图或功能图；不会，就是装饰图。
实施：内容写什么，技术放哪里
内容侧的职责是产出alt文本本身。写法上把握两点：一是描述用途而非外观，二是避免“图片”“图像”这类冗余开头，因为辅助技术已经会播报这是图片。例如信息图写“2024年各季度退货率对比，第三季度最高”，而不是“一张柱状图”。
技术侧的职责是保证这段文本落到正确位置，并处理内容人员看不到的情况。常见的协作点包括：
- 模板中的图片组件是否预留了alt字段，还是写死在代码里。
- 内容管理系统是否允许编辑逐图填写alt，还是只能填一个统一值。
- 响应式图片使用
<picture>或srcset时，alt写在<img>上而不是<source>上。 - 图标字体或CSS背景图无法承载alt，需要技术人员判断是否改用
<img>或补充可见文本。
协作的接口就是这份字段清单：内容人员按图给出alt文本，技术人员确认每一条都有对应的写入位置。批量图片较多的站点，可以用表格逐行登记图片位置、用途分类、alt文本、负责人，避免口头交接遗漏。
验证：怎么确认写对了
验证分两层，缺一不可。
第一层是技术验证，检查alt是否真的出现在页面源码里。打开页面查看源代码，搜索 alt=，确认信息图和功能图有描述性文本、装饰图为 alt=""。也可以用浏览器开发者工具检查图片元素，或使用只读的无障碍检测工具扫描，但工具只能发现“缺失”和“疑似冗余”，无法判断文案是否准确。
第二层是内容验证，由不熟悉该页面的人只看alt文本，判断能否还原图片要传达的信息。如果对方读完仍不知道图表说明什么，说明alt写的是外观而不是信息。这一层无法自动化，必须人工过一遍。
判断结果的标准：装饰图不产生播报噪音，信息图能独立传达要点，功能图能说明操作结果，三者都满足才算通过。
维护：把规则固定下来再谈规模
一次性改完不等于问题解决。新图片每天都在进入页面，维护的关键是把分类规则和字段要求写进内容发布流程，而不是靠事后补救。
可执行的做法包括：在内容模板中把alt设为必填项并附上分类说明；在编辑审核清单中加入“图片用途是否已分类”一项；对历史图片按流量或重要性分批回查，优先处理信息图和功能图。装饰图数量通常最多，但优先级最低，可以最后处理。
需要说明的是，alt属性主要服务于无法看到图片的读者和需要理解图片内容的程序，它不保证任何收录或排名结果。把它当作内容质量的一部分来维护，比当作技巧来使用更稳妥。
下一步建议从当前访问量最高的一个页面开始，把该页所有图片按三类归好，列出alt文本对照表，再交给技术人员确认写入位置。跑通这一个页面，就能得到适合自己站点的协作模板。
