aria-label用于为无可见文本的交互元素提供屏幕阅读器可读的替代名称，如纯图标按钮；不可用于已有文本或非交互元素，且会覆盖内部文本，滥用反而损害可访问性。
用 aria-label 替代缺失的可见文本，而不是硬塞空格或隐藏
很多开发者看到屏幕阅读器报“按钮，未命名”就慌了，第一反应是加个 aria-label ——这没错，但常犯的错是给它填空字符串、零宽空格，或者用 display: none 隐藏文字再靠 ARIA 补救。这些做法要么被读作“空白”，要么被辅助技术忽略。
真正该做的是：如果控件本身没文字（比如 × 关闭图标、齿轮设置图标），就用 aria-label 明确表达意图；如果已有可见文字，优先用 aria-labelledby 或天然语义（如 button 里的文本）——aria-label 是兜底，不是首选。
-
aria-label="关闭对话框"✅ 清晰、动词+宾语，符合用户心智模型 -
aria-label=""❌ 屏幕阅读器跳过或读作“按钮” -
aria-label="×"❌ 符号不传达功能，应避免 - 用
span+visually-hiddenclass 包裹文字，比aria-label更利于多语言和动态更新
别手动管理 aria-expanded 和 aria-hidden，交给原生交互或 Popover API
手写折叠面板、下拉菜单时，最容易漏掉状态同步：点了展开按钮，aria-expanded="true" 改了，但内容区的 aria-hidden="false" 忘了改；或者 JS 报错导致状态卡死，辅助技术完全失联。
2026 年起，popover API 已在所有主流浏览器稳定支持，它自动处理：aria-expanded、aria-haspopup、焦点捕获、ESC 关闭、点击外部关闭、inert 隔离——你只需写：
<button popovertarget="menu">菜单</button> <div id="menu" popover> <a href="/home">首页</a> <a href="/profile">个人资料</a> </div>
- 不需要 JS 监听 click / keydown / focusout
- 不需要手动切
aria-hidden，Popover 内部自动用inert - 屏幕阅读器会自动播报“菜单已打开”，含项数和导航提示
- 旧项目若暂不能升级，至少用
details/summary替代手写手风琴
role 不是万能补丁，滥用反而破坏语义
看到一个 div 像按钮，就加 role="button"；看到一堆 li 像菜单，就套 role="menu" ——这是最危险的惯性操作。ARIA role 会覆盖原生语义，一旦没配齐配套属性（aria-pressed、aria-haspopup、aria-activedescendant 等），反而让屏幕阅读器更困惑。
优先级永远是：原生元素 > 语义化组合 > ARIA 修补。比如：
- 用
button而非div role="button"✅ 自带键盘交互、焦点、disabled状态 - 用
nav+ul+a而非div role="navigation"✅ 天然被识别为导航区 - 只有当必须用
div实现复杂控件（如日历网格）时，才用role="application"+ 全套 ARIA 模式，并严格遵循 WAI-ARIA Authoring Practices 指南 -
role="presentation"和role="none"只用于剥离无意义容器的语义，不是“去掉碍事的标签”的快捷键
表格必须配 scope 或 id/headers 关联，否则屏幕阅读器无法理解结构
纯 CSS Grid 或 Flex 布局的“表格”视觉效果，对屏幕阅读器就是一串无序的单元格。即使用了 table 标签，若没声明表头归属，视障用户听到的只是“单元格 数据1，单元格 数据2…”——完全不知道哪列对应姓名、哪列对应邮箱。
两套可靠方案：
- 简单表头（单行/单列）：给
th加scope="col"或scope="row" - 复杂表头（跨行跨列）：用
id+headers显式绑定，例如<th id="name">姓名</th>和<td headers="name">张三</td> - 绝对不要只靠视觉对齐或 CSS 类名暗示关系——辅助技术看不到 class
- 用
caption和summary（虽已废弃但部分读屏仍支持）补充表格用途，比如“用户权限配置表，共5列32行”
aria- 属性时，先问一句——这个交互，是不是已经有更简单的 HTML 方式能原生表达？前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
