ARIA属性需在HTML语义缺失时精准补位,优先使用原生语义元素;仅当组件行为或状态无法用HTML表达时才引入ARIA,且须配合JS/CSS实现对应功能。

ARIA 属性不是“加了就无障碍”,而是“在语义缺失时精准补位”——HTML 原生语义元素(如 、、)永远优先于 role 和 aria- 属性。盲目堆砌 aria-hidden="true" 或乱设 role="button" 反而会破坏读屏体验。
哪些情况必须用 ARIA?
只有当 HTML 语义无法表达组件行为或状态时,才引入 ARIA:
- 自定义下拉菜单()需要
role="listbox"+aria-expanded+aria-activedescendant- 动态加载内容区域(如无限滚动列表)需用
aria-live="polite"告知读屏器新条目已插入- 图标按钮(仅含
)必须配aria-label或aria-labelledby,否则读屏器会跳过或读作“图形”- 模态框(
)要同时设role="dialog"、aria-modal="true"和aria-labelledby指向标题role和原生标签冲突怎么办?浏览器和读屏器对原生标签的语义有强共识,强行覆盖会出问题:
- 不要给
加role="link"——它就是按钮,想让它像链接行为,该用 JS 控制逻辑,而不是欺骗辅助技术 -
已自带role="checkbox"和aria-checked,再手动加aria-checked="true"可能导致状态不同步 - 若用
模拟开关,必须完整实现:role="switch"+aria-checked+tabindex="0"+ 键盘事件(Space)+ 视觉反馈
aria-hidden的坑比你想象的多aria-hidden="true"不是“隐藏给所有人看”,它只告诉辅助技术“忽略这个节点及其所有子节点”——但视觉用户仍能看到,JS 仍可操作它:
DeepBI DHTML 页面生成器下载生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力: - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面; - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”; - 提及位于 `apps/console/src/featur
- 别对整个导航栏加
aria-hidden="true"后又靠 CSSdisplay: none隐藏——读屏器已跳过,CSS 隐藏只是锦上添花;但如果只加 CSS 隐藏没加aria-hidden,读屏器仍会朗读不可见内容 -
aria-hidden="true"父元素下的子元素,即使设aria-hidden="false"也无效(继承强制隐藏) - 模态框打开时,常有人把
设为aria-hidden="true",结果背景内容被读屏器跳过——正确做法是用inert属性(现代浏览器支持)或用tabindex="-1"+focus()锁定焦点在模态框内
验证 ARIA 是否生效?别只信浏览器检查器
DevTools 的“Accessibility”面板只显示属性是否存在,不校验逻辑是否正确:
- 用 NVDA(Windows)或 VoiceOver(macOS)真实测试交互流程:打开/关闭、Tab 导航、读取状态变化
- 检查
aria-live区域是否真被朗读——它依赖插入位置、DOM 更新方式(innerHTML替换可能丢失)、以及读屏器当前模式(浏览/虚拟光标) - 运行
axe-core(Chrome 插件或 CLI)扫描,重点看aria-allowed-attr、aria-required-children这类规则,它们能发现role="tree"下漏了role="treeitem"这类硬性错误
最常被忽略的一点:ARIA 属性本身不触发任何行为,
aria-expanded="true"不会让下拉展开,aria-disabled="true"也不会禁用点击——这些必须由 JS 和 CSS 协同实现,否则就是“说一套做一套”,辅助技术用户反而更困惑。 - 动态加载内容区域(如无限滚动列表)需用
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










