alt标签：内容与技术如何协作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /703ac3983bac.html
📄
alt标签：内容与技术如何协作
alt标签的协作核心只有一句话：内容人员负责“这张图在页面里承担什么信息”，技术人员负责“这个信息如何以正确、稳定、可维护的方式写进HTML”。两者不是谁交给谁一张表就结束，而是要先约定图片分类规则，再按规则分别处理描述文本与代码实现，最后用抽查清单验证结果。
先分清三类图片，协作方式完全不同
把页面上的图片先归入以下三类，再决定alt标签写到什么程度。这一步由内容与技术共同确认，不能只由一方拍板。
- 信息型图片：图片本身承载用户需要的内容，例如流程图、数据图表、产品细节图。alt需要把图中关键信息说清楚，不能只写“示意图”。
- 功能型图片：图片是链接、按钮或表单控件的一部分，例如搜索图标、购物车图标。alt要说明操作结果，例如“搜索”，而不是描述图标长什么样。
- 装饰型图片：纯为视觉分隔、背景纹理、排版留白服务，不传递额外信息。这类图片应使用空alt，即
alt=""，让辅助技术跳过它。
判断标准很简单：假设图片加载失败，用户只看alt文字，是否还能理解页面在说什么、能完成什么操作。能，就属于信息型或功能型；不能且不影响理解，就属于装饰型。
内容侧要交付什么，技术侧要接住什么
内容人员的交付物不是一句“给图加alt”，而是一份可核对的图片清单，至少包含：图片文件名或位置标识、所属页面、图片分类、建议alt文本、是否可替换为文字。技术人员拿到清单后，负责确认三件事：alt是否写进了正确的<img>标签、装饰图是否真的留空、动态插入的图片是否有对应字段。
协作中最容易出问题的是动态内容。例如文章正文由编辑器插入图片，alt往往来自上传时的“替代文本”输入框。此时内容人员必须在上传环节就填写，而不是等页面上线后再回头补。技术侧要检查的是：这个输入框的值是否真的输出到了前端的alt属性，而不是只存进了数据库却没渲染。
可执行检查清单：每项都写清查什么、怎么查、结果说明什么
- 查图片分类是否落地。随机抽取一个页面，把页面上的图片逐张标为信息型、功能型或装饰型。如果同一张图两个人分类不一致，说明分类规则还不够具体，需要补充例子。
- 查alt是否与图片角色匹配。在浏览器中查看页面源代码，找到
<img>标签，读它的alt值。信息型图片的alt应能独立传达信息；功能型图片的alt应描述操作；装饰型图片应为alt=""。如果装饰图写了“蓝色背景图”，说明内容侧还在描述外观而非功能。 - 查动态插入路径。在后台发布一篇带图内容，填写替代文本后保存，再到前台查看源代码。如果前台
alt为空而后台已填，问题在模板或接口，属于技术修复项；如果后台本身没填，问题在内容流程。 - 查链接图片的可访问名称。找到被
<a>包裹的图片，确认它的alt能说明链接去向。如果alt为空且链接内没有文字，用户和辅助技术都无法判断这个链接做什么。 - 查批量替换风险。搜索全站是否用同一句alt套在所有图片上。这种做法会让不同图片失去区分度，应回到分类规则逐张处理。
两种处理方案的适用条件
实际工作中常遇到两种方案：一种是内容人员逐张填写alt，另一种是技术侧用规则批量生成alt。前者适用于图片数量少、信息型图片多、每张图含义差异大的页面，例如产品详情、教程步骤。后者适用于装饰图占绝大多数、图片由模板统一输出的列表页，但仍需保证装饰图输出空alt，而不是自动拼出文件名。
判断依据是“出错代价”：如果一张信息型图片的alt写错，用户会得到错误信息，代价高，应逐张确认；如果一张装饰图alt为空，代价低，可以批量处理。两者混用时，先让技术侧把装饰图统一置空，再把信息型和功能型图片交给内容侧逐张填写，协作边界最清晰。
假设一个页面有二十张图，其中十五张是装饰纹理、五张是操作步骤截图。合理分工是：技术侧确认十五张装饰图输出alt=""，内容侧只针对五张步骤图写清“第几步、操作什么、看到什么结果”。这样既不会让内容人员做无用功，也不会让关键信息丢失。
下一步
选一个已有页面，按上面的清单逐项走一遍，把发现的问题分成“内容侧补文本”和“技术侧改输出”两类，分别记录负责人和验证方式。跑通一个页面后，再把同样的分类规则和检查项扩展到同类模板。
