area标签必须带alt属性，否则屏幕阅读器直接忽略热区；alt需描述点击行为（如“进入厨房区域”），不可为空或仅空格，且usemap与map的name必须逐字节匹配。
area 标签必须带 alt 属性，否则屏幕阅读器跳过整个热区
没 alt 的 <area> 在 Chrome 控制台会报 warning，读屏软件（如 NVDA、VoiceOver）通常直接忽略该区域，用户完全感知不到可点击——它既不被朗读，也不出现在焦点导航序列里。这不是“体验不好”，而是功能缺失。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
alt值必须描述行为意图，不是图片内容。例如：alt="进入厨房区域"比alt="厨房照片"有效得多 - 避免空字符串或纯空格：
alt=""和alt=" "效果等同于缺失，部分读屏仍会跳过 - 若热区无跳转（仅 JS 触发），
alt仍需存在，且应说明作用，比如alt="放大平面图视图"
area 不支持 title、aria-label，无障碍增强得靠外层包裹或 JS 注入
<area> 是 void 元素，原生不响应 title 属性（hover 不出 tooltip），也不能直接加 aria-label（浏览器忽略）。想补足语义，只能绕行：
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
<figure>+<figcaption>包裹整张图和<map>，在<figcaption>里写整体说明，辅助理解上下文 - 对关键热区，用 JS 动态给
<img>绑定aria-describedby，指向一个隐藏的<div id="kitchen-desc">...，里面用自然语言解释该区域用途 - 禁用
href改用javascript:void(0)时，必须同步加role="button"和tabindex="0"，否则键盘用户无法聚焦
coords 坐标不随 CSS 缩放变化，但无障碍测试常在缩放后进行
一张原始尺寸 1200×800 的图，用 CSS 缩成 300×200 显示，coords="0,0,100,100" 依然指原始左上角 100×100 像素区域——现在它只占屏幕 25×25px。触控或键盘焦点落在视觉热区外，用户点不中，读屏也无法准确定位目标。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 移动端热区最小物理尺寸建议 ≥44×44px（iOS/Android 无障碍规范），对应原始图中 coords 范围要按比例放大
- 不做 JS 适配时，优先用响应式图像（
<picture>+srcset）匹配设备像素比，让 coords 始终基于加载图的实际尺寸 - 真机测试必须包含 pinch-zoom 场景：放大后热区是否仍可被焦点捕获？VoiceOver 的“触摸探索”是否能扫到该区域？
usemap 关联失败会让所有 area 无障碍能力归零
90% 的图像热点无障碍失效，根源不在 alt 写得不够好，而在 usemap="#nav-map" 和 <map name="nav-map"> 没对上——大小写、连字符、空格、# 缺失，任一字符错，整个 <map> 就被浏览器静默丢弃，<area> 标签形同虚设。
检查要点：
- 右键图片 → “检查”，看 DOM 中是否高亮对应
<map>；不亮，说明关联断了 - Chrome DevTools 的 Accessibility 面板里，选中
<img>后查看 “Accessibility Tree”，若看不到任何link节点，基本可判定<map>未生效 - 不要依赖
id替代name：<map id="x">不触发关联，name是唯一生效属性
实际项目里最容易被忽略的，是把 <area> 当作普通链接来测——它没有 :focus-visible 样式、不进 tab 顺序、不响应 pointer-events: none 以外的 CSS 控制。无障碍验证必须从“读屏能否发现→能否聚焦→能否理解意图→能否触发动作”四步闭环走，缺一不可。
