ARIA属性本身不拖慢渲染，但常被误用于低效结构：如给div加role="button"却不处理焦点和事件，导致浏览器额外维护无障碍树、同步状态并频繁调用API；aria-hidden粗粒度应用、aria-live高频刷新、aria-expanded与aria-controls目标失配等均会引发性能开销。
为什么加 aria-* 会让页面变慢？
不是 ARIA 属性本身拖慢渲染，而是它常被用在低效结构里：比如给每个 div 都加 role="button" 却不处理键盘焦点、不拦截默认事件，结果浏览器要额外维护可访问性树 + 同步状态 + 触发更多无障碍 API 调用。Chrome DevTools 的 “Rendering” 面板里勾选 “Paint flashing”，能直观看到 aria-hidden 切换时的重绘范围——如果整页闪红，说明你把 aria-hidden 打在了父容器上，而不是精准控制到子元素。
role 和原生标签冲突时谁赢？
原生标签永远优先。写 不会变成链接，屏幕阅读器仍按按钮播报；但 会覆盖原语义，变成按钮——同时失去链接的默认键盘行为（Enter 键触发）和 SEO 权重。这种写法只该出现在极少数场景：比如用 a 实现无跳转导航，又必须让辅助技术识别为控件。更稳妥的做法是： + aria-label 显式声明意图，避免语义覆盖。
哪些 aria-* 属性真会影响性能？
以下属性在频繁更新时易引发开销：
-
aria-live：内容变更时强制通知辅助技术，若用于高频刷新区域（如实时计数器），建议设aria-live="polite"而非"assertive"，并限制更新频率（如防抖 300ms） -
aria-expanded+aria-controls：配合 JS 切换时，若目标元素未提前存在或 ID 不匹配，浏览器会反复查询 DOM，导致 layout thrashing -
aria-describedby：指向的元素若含大量文本或嵌套结构，屏幕阅读器解析耗时上升，尤其在移动端
验证方式：用 VoiceOver 或 NVDA 打开页面，观察焦点移动是否卡顿；再关闭辅助技术，用 Lighthouse 的 “Accessibility” 审计看是否有 “ARIA input fields do not have accessible names” 类报错——这类错误往往伴随冗余属性绑定。
main、section 和 ARIA 地标该怎么配？
地标角色（role="main"、role="navigation" 等）和语义标签不是二选一，而是互补关系： 自带 role="main"，无需重复写；但动态插入的内容若无法用语义标签包裹（比如第三方 SDK 渲染的弹窗），才用 role="dialog" + aria-modal="true" 补充。
常见踩坑点：
- 多个
：SSR 和 CSR 混合渲染时容易漏掉清理，导致 axe 工具报landmark-is-top-level - 用
包裹整个商品列表：它本应代表“一个主题区块”，而列表是容器；换成更准确，且对虚拟滚动友好 - 给
加aria-label="主导航"：正确；但给每个都加aria-label就冗余——原生链接文本已足够
真正难平衡的从来不是“加不加”，而是“加在哪一层、由谁控制、是否可预测”。比如 aria-hidden="true" 切换时，如果 JS 同时修改了 class、style 和多个 aria 属性，就容易让辅助技术状态不同步——建议用单一数据源驱动（如 React state 或自定义事件），而非多处手动 toggle。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
