<area> 默认对屏幕阅读器“不可见”，因其不被主动解析，须满足图像有非空alt、usemap正确关联、每个area含alt或aria-label三前提；且原生不支持tabindex、无焦点样式、无法键盘导航。
HTML 中的 <area> 标签本身不被屏幕阅读器直接朗读，除非它被正确包裹在 <map> 内、关联到图像，并补充可访问性语义。原生 <area> 缺少焦点管理、键盘交互和上下文描述能力，是无障碍高危区域。
为什么 <area> 默认对屏幕阅读器“不可见”
屏幕阅读器不会主动解析 <area> 列表，除非满足三个前提：图像有 alt（非空）、<map> 通过 usemap 关联、且每个 <area> 至少提供 alt 或 aria-label。更关键的是：<area> 不支持 tabindex，无法被键盘聚焦；点击区域无视觉焦点样式；用户无法用 Tab 键逐项导航到热区。
-
<img>的alt为空或缺失 → 屏幕阅读器跳过整张图，<area>彻底失效 -
<area>只写title属性 → 大部分 AT（如 NVDA、VoiceOver）完全忽略title，不播报 - 多个
<area>共享同一alt值 → 用户无法区分“北京办公室”和“上海办公室”热区
<area> 必须配 alt，但不能只靠 alt
alt 是强制属性，但仅靠它不足以支撑完整导航。WCAG 要求每个可交互热区需有唯一、简洁、功能明确的描述，且需与键盘操作同步。
- 必须为每个
<area>设置非空alt，例如：<area shape="rect" coords="10,10,100,50" href="/beijing" alt="北京办公室位置"> - 若热区功能复杂（如“点击查看北京团队介绍并展开地图”），单靠
alt表述不清，应叠加aria-label（优先级高于alt） - 禁止用
alt=""配合aria-hidden="true"隐藏热区——这会让键盘用户卡在不可聚焦又不可知的空白区域
替代方案比修补 <area> 更可靠
当热区需要键盘导航、焦点管理、状态反馈（如 hover/focus 样式）或动态内容更新时，<area> 架构已到能力边界。现代做法是放弃客户端图像映射，改用语义化容器 + CSS 定位模拟。
立即学习“前端免费学习笔记（深入）”；
- 用
<div role="region">包裹背景图，内部用绝对定位的<button>模拟热区，每个按钮自带tabindex="0"、focus样式和完整 ARIA 标签 - 保留原图作背景，但移除
<map>和所有<area>，避免混淆可访问性树 - 若必须保留
<area>（如遗留系统），至少加一层 JS 聚焦代理：监听keydown，在 Tab 进入图像区域时，用element.focus()手动跳转到第一个<area>对应的逻辑目标（需额外维护映射关系）
测试时最容易漏掉的点
多数人只测鼠标点击和 alt 是否存在，但真实障碍常出现在键盘流中：Tab 进入图像后焦点消失、Enter 键无响应、屏幕阅读器播报后无法二次确认当前热区、多热区间缺乏顺序逻辑。
- 用键盘 Tab 到
<img>，检查是否能继续 Tab 进入热区（原生<area>不行，必须靠 JS 代理或替换成<button>） - 在 VoiceOver 中启用“Rotor”→“Landmarks”，确认
<map>未被识别为地标——它本就不该是 - 运行 axe 或 WAVE 工具，重点看 “
<area>missing alternative text” 和 “interactive element not keyboard accessible” 报错
