根本原因是第三方html组件粗暴注入污染全局语义结构，导致role冲突、tabindex重叠、aria-live覆盖及焦点管理失效；shadow dom是唯一能隔离可访问性树的原生方案，需用open模式、template注入并重置内部语义。
第三方 HTML 组件破坏全局可访问性，根本原因不是它“没写 ARIA”，而是它被粗暴注入主文档后，直接污染了整个页面的语义结构——role 冲突、tabindex 重叠、aria-live 区域被覆盖、焦点管理失效。Shadow DOM 是唯一能真正隔离语义上下文的方案，否则任何 ARIA 修补都是临时止血。
为什么直接 innerHTML 会毁掉可访问性
第三方组件（比如一个带搜索框的营销横幅）常自带 role="application"、aria-hidden="true" 或硬编码 tabindex="0"。一旦用 innerHTML 插入到主页面，这些属性就混进全局 DOM 树，和宿主页面已有的 main、nav、banner 等语义区域打架。屏幕阅读器读取顺序错乱、焦点跳转中断、甚至整个页面被识别为单个“应用”而跳过语义导航。
-
aria-hidden="true"被插在main内部时，会把整块主要内容屏蔽掉 - 组件内
button没配aria-label，但宿主 CSS 把它样式化成图标按钮，视觉用户能懂，辅助技术用户完全不知其用途 - 组件 JS 动态插入
div[role="alert"]，却没调用aria-live="polite"，或与宿主已有的 live 区域冲突，导致错误提示不播报
必须用 Shadow DOM 隔离语义边界
Shadow DOM 不仅隔离样式，更关键的是隔离可访问性树（Accessibility Tree）。浏览器会为每个 shadow root 单独构建一套语义上下文，外部 aria-hidden 不影响内部，内部 role 也不泄露到外层。这是目前唯一被所有现代浏览器支持的原生方案。
- 必须用
attachShadow({ mode: 'open' })——'closed'会让辅助技术无法遍历 shadow 内容 - 不要在 shadowRoot 上直接写
innerHTML = htmlString，否则script不执行、link加载到全局、aria-*属性虽存在但上下文错乱 - 正确做法：用
<template></template>包裹完整 HTML（含<style></style>和<script></script>），再用shadowRoot.appendChild(template.content.cloneNode(true)) - 组件初始化时，所有 DOM 查询必须限定在
this.shadowRoot下，例如this.shadowRoot.querySelector('input')，否则document.querySelector找不到节点，aria-labelledby引用失效
组件内部可访问性必须重置而非继承
Shadow DOM 内部不能依赖宿主页面的语义环境。你得把它当作一个独立页面来对待：
- 每个交互元素必须有明确的
role+aria-label/aria-labelledby，不能指望宿主 CSS 的“图标即含义” - 若组件含模态框，必须手动管理焦点循环：
focusin监听器 +tabindex="-1"控制可聚焦范围，否则 Tab 键会跳出 shadow 进入宿主页面 - 动态内容更新（如加载状态）要显式使用
aria-live="polite"并挂载在 shadow 内部节点上，避免与宿主 live 区域竞争 - 禁止在 shadow 内使用
aria-hidden="true"包裹整个组件——这等于告诉屏幕阅读器“这里什么都没有”，应改为对非语义装饰节点单独隐藏
最易被忽略的点是：Shadow DOM 隔离了样式和 DOM，但不自动修复组件自身的可访问性缺陷。你得先确保原始 HTML 片段本身语义正确，再封装——否则只是把一堆问题打包进了一个干净的盒子里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
