dom操作后aria-*属性丢失的典型表现是屏幕阅读器读不出按钮用途或表单关联失效，主因是innerhtml替换或框架未透传属性；须用setattribute增量更新、显式复制属性、过滤用户输入并刷新可访问性树。
DOM操作后aria-* 属性丢失的典型表现
页面交互后屏幕阅读器突然读不出按钮用途、表单控件失去aria-label或aria-describedby关联，大概率是JS直接替换innerHTML或用replaceChild()清掉了原有属性。React/Vue等框架更新DOM时若未透传可访问性属性，也会复现该问题。
实操建议：
- 避免对已挂载节点使用
element.innerHTML = ...，改用element.textContent配合setAttribute()增量更新 - 手动创建新元素时，必须显式复制原节点的全部
aria-*属性（含aria-hidden、aria-live等），不能只复制innerText - 检查第三方UI库（如Bootstrap Modal、Ant Design Table）的DOM重绘逻辑，确认其是否保留
role和aria-属性
动态插入内容时role与tabindex未同步生效
常见于加载完异步数据后追加列表项，但新<li role="option">无法被键盘Tab聚焦，或aria-expanded="true"切换后子菜单不可读——本质是角色/状态变更未触发浏览器可访问性树刷新。
实操建议：
- 插入带
role的元素后，立即调用element.setAttribute('role', '...')而非依赖HTML字符串中的静态声明 - 动态显示隐藏区域时，优先用
aria-hidden="false"+element.focus()，而非仅靠display: block - 避免在
setTimeout中批量设置tabindex，应确保DOM插入完成后再赋值（可用MutationObserver监听childList）
用innerHTML注入用户输入内容引发的aria污染
用户提交的富文本含aria-* 属性时，直接插入会导致语义冲突（如aria-live="polite"被嵌套在非实时区域），甚至被AT误读为关键更新。
实操建议：
- 所有用户生成内容必须经
DOMPurify.sanitize(html, { ADD_ATTR: ['aria-label', 'aria-describedby'] })白名单过滤，禁用aria-hidden、aria-live等高风险属性 - 服务端返回HTML片段时，强制剥离
role和aria-属性，前端按容器语义重新注入（例如评论区统一设role="article"） - 测试环节用
axe.run()扫描动态区域，重点关注aria-allowed-role和aria-valid-attr-value规则失败项
Chrome DevTools里快速验证动态可访问性状态
开发者工具的“Accessibility”面板默认只显示初始状态，DOM变更后需手动刷新树结构，否则看不到真实AT读取内容。
实操建议：
- 右键目标元素 → “Inspect” → 切换到“Accessibility”标签页 → 点击右上角
Refresh按钮（非页面刷新） - 在Console中执行
getComputedAccessibleName(element)和getComputedAriaValue(element)，比肉眼检查属性更可靠 - 用
document.addEventListener('DOMSubtreeModified', () => console.log('a11y tree may be stale'))标记高风险操作点，后续针对性校验
DOM操作和可访问性不是二选一——每次appendChild()、classList.toggle()或dataset修改，都得同步问一句：屏幕阅读器现在知道这是什么、能怎么操作吗？漏掉一次，就可能让某个用户卡在登录按钮三秒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
