role不是“增强可访问性”的万能开关，而是html语义缺失时的补救手段；用错比不用更危险，如给原生加role="button"会覆盖默认语义，或给加role="button"却不配tabindex="0"和键盘事件监听，导致键盘不可聚焦、不可触发。
直接说结论：role 不是“增强可访问性”的万能开关，它是语义缺失时的补救手段；用错比不用更危险——比如给 <button></button> 加 role="button"，或给 <div> 加 <code>role="button" 却不处理键盘交互。
role="button" 必须配套 tabindex 和键盘事件
屏幕阅读器看到 role="button" 就会朗读为“按钮”，但不会自动让它可聚焦、可触发。用户按空格/回车没反应，Tab 键也进不去，等于挂了个假招牌。
-
tabindex="0"是基础：让元素进入标准 Tab 流，否则键盘用户根本碰不到它 - 必须监听
onkeydown，显式处理Enter和Space键（注意：Space需要preventDefault()，否则会触发页面滚动） - 视觉焦点样式不能少，否则键盘用户看不到当前聚焦在哪
- 禁用状态要用
aria-disabled="true"+ CSS 灰显，不能只靠disabled类名
哪些元素绝对不该加 role？
原生 HTML 元素自带完整语义和交互行为，强行叠加 role 会覆盖默认逻辑，导致辅助技术误判。
-
<button></button>、<a href></a>、<nav></nav>、<main></main>等已有隐式角色，加role属于反模式 -
<button role="button"></button>在部分旧版 NVDA 中会被识别为“未知按钮”，而非标准按钮 <div role="link"> 比 <code><a></a>更糟：它没有href，无法被键盘用户跳转，也无法被搜索引擎索引role="alert" 和 aria-live 的配合要点
动态通知类消息依赖
role+aria-live协同工作，但组合错误会导致播报失败或打断过度。
anything-to-html下载将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
role="alert"默认启用aria-live="assertive"，适合“登录失败”“网络断开”等需立即干预的场景 - 非紧急提示（如“已保存”）该用
role="status"+aria-live="polite"，避免打断用户当前操作 - 不要把
aria-live直接加在role="alert"外层容器上——如果容器本身是动态插入的，屏幕阅读器可能根本来不及注册它 - 每次更新内容前，建议先清空旧文本再写入新内容，否则某些读屏器会拼接播报（如“已保存已保存”）
aria-hidden="true" 的继承陷阱
aria-hidden="true"不是“视觉隐藏就加它”，它会整棵树从可访问树中剔除，连里面真实的按钮、链接、输入框都不可见、不可聚焦。- 模态框开启时，背景区域常用
aria-hidden="true"，但必须确保模态框自身未设该属性，或显式设为aria-hidden="false" - 如果父容器加了
aria-hidden="true"，子元素想恢复可访问性，必须显式写aria-hidden="false"（仅设tabindex="0"不起作用） - 纯装饰性 SVG 图标可用
aria-hidden="true"，但带交互的图标按钮（如“关闭”叉号）绝不能套这个
最常被忽略的一点：
role的合法性不是靠人眼判断，而是靠浏览器「Accessibility」面板实时校验——比如role="checkbox"缺少aria-checked，面板会直接标红；别等上线后被视障用户反馈才改。-
