直接删除冗余 aria 属性比盲目修复更有效，需确认其未改变可访问性行为；空值、重复声明、与原生语义冲突或无运行时依赖的属性应清理，但须经无障碍树验证和端到端测试。
直接删掉 aria-hidden="true"、role="presentation" 这类无实际作用的无障碍属性，比加一堆“修复”更有效——前提是确认它们真没用。很多项目里这些属性是复制粘贴带进来的，或旧版框架自动生成后被遗忘，既不参与读屏逻辑，也不影响焦点流，只徒增体积和维护干扰。
怎么判断 aria-* 属性是否冗余
不能光看有没有写，得看它是否改变了可访问性行为：
-
aria-hidden="true"加在不可聚焦、无内容、且父级已aria-hidden="true"的元素上，就是双重冗余 -
role="presentation"或role="none"加在原生语义明确的标签（如div、span）上，通常无意义；但加在table或ul上可能用于绕过默认语义，需结合上下文判断 -
tabindex="-1"和aria-hidden="true"同时出现，大概率是历史残留：前者控制键盘焦点，后者控制读屏器，二者目标不一致，往往只保留一个就够了 - 所有以
aria-开头但值为空字符串（如aria-label=""）或纯空白（aria-label=" "）的属性，一律视为无效，应清理
VSCode 正则批量识别空/无效 aria 属性
打开全局搜索（Ctrl+Shift+F），启用正则模式（点 .* 图标），输入以下模式之一：
匹配空值 aria- 属性：aria-[a-z-]*=["']\s*["']
立即学习“前端免费学习笔记（深入）”；
匹配仅含空白的 aria-label：aria-label=["']\s*["']
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
匹配冗余组合（aria-hidden="true" + 父级已有相同声明）：这个无法单靠正则断定，需先用上面模式定位，再人工检查 DOM 结构层级
注意：\s* 能匹配空格、制表符、换行，比写死空格更鲁棒；引号用 ["'] 同时兼容双引号和单引号
保留还是删除？关键看渲染树与辅助技术链路
有些 aria- 属性看似多余，实则影响屏幕阅读器行为：
-
aria-live即使没内容，只要存在就会注册实时区域，不能随便删 -
aria-controls、aria-expanded常成对出现，删一个会破坏交互语义，必须成组检查 -
role="application"或role="dialog"一旦设置，会显著改变焦点管理逻辑，即使当前没交互也要评估其必要性 - 第三方组件（如 React Aria、Headless UI）生成的
aria-属性，通常有运行时依赖，盲目删除可能导致键盘导航失效
最稳妥的做法：先用 Ctrl+Shift+F 批量找出所有 aria-，再在 Chrome DevTools 的 Accessibility 面板中逐个右键「Reveal in Accessibility Tree」，看该节点是否真出现在树中、状态是否被正确读出——没出现，基本可删；出现但值为空或错位，优先修正值而非删属性。
清理后必须验证的三个盲点
很多人删完就提交，结果 QA 报出读屏器跳过关键按钮、键盘 Tab 顺序错乱等问题：
- 用 NVDA 或 VoiceOver 实际朗读页面，重点测试弹窗、表单、菜单等动态区域
- 禁用 CSS 后检查视觉焦点是否仍能按逻辑顺序抵达每个可操作元素（
tabindex不为 -1 或未定义） - 运行 axe 浏览器插件扫描，重点关注
aria-allowed-attr、aria-required-children类错误——它们常由删了一半的 ARIA 结构引发
真正难的不是找到冗余属性，而是分辨“它现在没用”和“它现在没被触发但系统依赖它”之间的差别。每次清理，本质是一次对辅助技术链路的小型压力测试。
