area标签必须有alt属性，否则屏幕阅读器直接跳过该区域；alt为空字符串表示纯装饰，否则须描述功能如“查看肝脏详情”，title不可替代alt，缺失alt将导致WCAG 2.1 1.1.1级别A违规。
area 标签没写 alt 属性，屏幕阅读器直接跳过该区域
alt 是 area 的必需属性，不是“可选提示”。W3C 标准明确要求每个 area 必须包含 alt，否则 HTML 验证失败；主流无障碍检测工具（如 axe、WAVE）会直接标记为严重问题。
原因很简单：屏幕阅读器靠 alt 知道这个热区是干什么的。没 alt，它就当不存在——用户完全无法感知、也无法操作该区域，相当于功能对视障用户彻底消失。
- 写
alt=""表示“纯装饰、无需朗读”，仅适用于真正无功能的空区域（极少见） - 写
alt="删除订单"或alt="查看肝脏详情"，必须描述行为或目的，不是描述图形形状（如“红色圆形图标”） - 千万别用
alt="decorative"或alt="icon"—— 这类值会被屏幕阅读器当作无效内容忽略
Chrome 控制台会报 warning，但不阻止渲染
浏览器不会因缺失 alt 而让图片热区失效，视觉上一切照常，所以开发者容易忽略。但 Chrome DevTools 会在 Console 中输出类似这样的警告：
Warning: The <area> element has no alt attribute. Consider adding one to improve accessibility.
这类 warning 不影响页面运行，却暴露了可访问性硬伤。CI/CD 流水线若接入 axe-core 扫描，会直接阻断发布。
立即学习“前端免费学习笔记（深入）”；
- warning 不等于 error，但它是无障碍合规的明确红灯
- 部分企业内网审计工具（如 IBM Accessibility Checker）会将缺失
alt判定为 WCAG 2.1 1.1.1 级别 A 违规 - 即使你当前没做无障碍适配，留着这个 warning 就等于给未来埋雷——等要过等保或政府采购验收时，返工成本远高于写一行
alt
alt 和 href 同时缺失时，area 彻底“隐形”
area 是空元素，本身不渲染任何内容。它的可点击性、语义、焦点管理全靠属性支撑。一旦 alt 和 href 都没写，它在 DOM 中就像一粒透明灰尘：
- 键盘 Tab 无法聚焦（没有可交互语义）
- 屏幕阅读器既不朗读也不提供导航入口
- 自动化测试脚本（如 Puppeteer + axe）查不到该节点的可访问名称（accessible name）
- 即使你写了
onclick或 JS 监听，辅助技术用户也根本点不到它
注意：title 属性不能替代 alt。很多浏览器（尤其是 Safari）压根不把 title 当作可访问名称来源，且移动端几乎不支持 hover 提示。
真实项目中最容易被忽略的场景
不是新手乱删属性，而是团队协作中隐性遗漏：
- 设计师提供坐标后，前端批量生成
area，脚本漏掉alt字段拼接 - 用 CMS 或低代码平台导出热区配置，后台字段映射没绑定到
alt - 动态插入
map和area时，JS 创建元素后只设了href和coords，忘了setAttribute('alt', ...) - 国际化项目里，
alt写死中文，但切换语言时没同步更新（应走 i18n key，而非硬编码）
真正难的从来不是“怎么加 alt”，而是确保它在所有生成路径、所有语言环境、所有动态上下文中都稳定存在——这需要约束机制，比如 ESLint 插件 eslint-plugin-jsx-a11y 的 alt-text 规则，或 CI 阶段跑 axe-core 扫描 HTML 文件。
