role属性需精准使用：仅在div/span自定义控件、旧项目补语义、动态容器缺上下文时手动添加；错误添加或缺失配套属性（如role="dialog"缺aria-modal、aria-labelledby、焦点陷阱）将导致无障碍失效。
直接说结论：role 属性不是“加了就有用”，它只在原生 HTML 标签无法表达准确语义时才该用；加错、漏配、不联动状态，比不加更糟。
哪些元素必须显式写 role
只有三类情况需要手动加 role：
- 用
div或span实现的自定义控件（如div模拟下拉菜单、滑块、选项卡） - 旧项目中无法重构结构，但需补足界标语义（如给一个
div class="main-content"加role="main"） - 动态插入的容器缺少上下文（如 JS 渲染的弹窗、通知条）
常见错误：给 <button> 加 role="link"，或给 <input type="checkbox"> 手动设 aria-checked。浏览器会忽略或覆盖这些声明，反而导致状态不同步。
role="dialog" 必须配齐三个硬性条件
只写 role="dialog"，屏幕阅读器只会读“对话框”，其余什么都不会做——焦点不进、背景不锁、标题不读。
立即学习“前端免费学习笔记（深入）”；
- 必须加
aria-modal="true"（不是可选，是 WAI-ARIA 1.1 强制要求） - 必须配
aria-labelledby，且值指向页面中真实存在的、可见的标题元素 ID（不能是display: none或aria-hidden="true"的节点） - 必须手动实现焦点陷阱：打开后
focus()到第一个可交互子元素，Tab 键循环限制在弹窗内，关闭后focus()回触发按钮
漏掉任意一项，视障用户就可能完全感知不到弹窗存在，或操作后焦点丢失在页面顶部。
role 和 aria-* 属性必须成套出现
单写 role 是无效的语义声明。每个角色都有其配套的必需属性和行为契约：
-
role="slider"→ 必须同时有aria-valuenow、aria-valuemin、aria-valuemax，还要响应 ←→/↑↓ 键盘事件 -
role="tab"→ 必须在role="tablist"内，配合aria-selected="true/false"、tabindex管理，且对应role="tabpanel"要用aria-hidden="true/false"控制可访问性显示 -
role="separator"→ 必须配aria-orientation="horizontal"或"vertical"，仅靠 CSS 旋转或宽高比不会被辅助技术识别
最常被跳过的动作是：JS 更新了视觉状态（比如切换了 tab 样式），却忘了同步设置 aria-selected 或 aria-expanded。辅助技术看到的是“静止的 DOM”，不是你的 CSS 类名。
role="application" 是危险信号
看到复杂交互就套 role="application"，等于主动关闭屏幕阅读器的表单模式。Tab 键失效、Enter 不触发、箭头键失灵——这不是接管控制，是制造障碍。
正确路径是：
- 优先用语义化角色：
role="combobox"、role="listbox"、role="tree" - 用
aria-owns显式关联逻辑父子（尤其 portal 渲染场景） - 用
aria-activedescendant配合键盘导航，替代手动focus()子项 - 所有可交互子项必须带
role（如role="option"），不能只靠tabindex="0"
真正难的不是写对 role，而是让 JS 状态、DOM 属性、CSS 表现、键盘行为四者始终严格同步。任何一环脱节，无障碍就断在那个点上。
