直接比对外层html会失败，因chrome、safari、firefox解析策略不同导致outerhtml不一致；应使用提取纯净dom快照，并结合playwright的aria快照与手动焦点走查保障可访问性。

为什么直接比对 outerHTML 会失败

重构后拿 document.documentElement.outerHTML 做字符串比对，看似简单，实则在多浏览器下必然不一致。Chrome 会自动补全 <tbody>，Safari 可能忽略未闭合的 <code><p></p> 后续节点，Firefox 对 <main></main> 直接嵌套在 <p></p> 内直接拒绝解析——同一段 HTML，三者返回的 outerHTML 字符串长度、标签嵌套深度、甚至节点数量都不同。

这不是代码写错了，是浏览器解析策略差异导致的正常现象。靠字符串 diff 判定“结构没变”，等于拿三把尺子量同一根线，还要求读数完全一样。

• 必须先跑 https://validator.w3.org/，修复所有 “End tag implied” 类警告
• 显式写出 <tbody>、<code><tr>、<code><thead>，哪怕规范允许省略 <li>禁止把 <code><main></main>、<section></section> 塞进 <p></p> 或 <div role="button"> 里 <h3>用 <code><template></template> 提取纯净 DOM 快照

  <template></template> 是唯一绕过实时解析差异的原生机制：它不渲染、不执行脚本、不加载资源，只存原始字符串。把待测 HTML 写进 <template></template>，再用 content.cloneNode(true) 获取副本，就能在 Chrome/Firefox/Safari 中拿到完全一致的初始 DOM 树。

  别用 el.innerHTML = htmlStr 注入，改用：

  

  HTML Extract

  使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

  下载

  const template = document.createElement('template');
  template.innerHTML = htmlStr;
  const docFragment = document.importNode(template.content, true);

  之后所有断言都基于 docFragment，不是实时页面 DOM。

  • 表格结构测试前，确保 <template></template> 内已含 <tbody></tbody>
  • 调用 el.normalize() 合并相邻文本节点，避免换行/空格处理差异影响 textContent
  • 只读取 el.tagName、el.hasAttribute('aria-label')、el.children.length、el.textContent.trim()

  Playwright 中验证可访问性树是否稳定

  结构快照只是基础，可访问性回归测试真正要捕获的是辅助技术“看到”的那棵树。Playwright 的 page.accessibility.snapshot() 返回结构化 JSON，比 outerHTML 更贴近真实 AT 行为。

  关键不是截图，而是比对语义层级：

  • 用 page.evaluate(() => document.querySelector('main').innerHTML) 提取主内容区 HTML 片段，再喂给 <template></template> 做结构校验
  • 用 await expect(page).toMatchAriaSnapshot(snapshotPath) 验证 ARIA 角色、名称、状态是否一致
  • 禁用动态内容：过滤掉含 data-timestamp、id="ad-slot-*" 的节点，避免快照漂移
  • 不要断言 el.offsetWidth 或 el.getClientRects() —— 这些值受布局引擎差异影响，和可访问性无关

  键盘焦点流必须手动走查，不能靠自动化覆盖

  所有快照和断言都建立在“结构正确”的前提上，但结构正确 ≠ 键盘可达。Tab 焦点跳过某个按钮？不是因为 HTML 缺 tabindex，很可能是滚动容器没设 tabindex="0"，或模态框关闭后没恢复焦点。

  重构后必须从新标签页打开，全程禁用鼠标，只用 Tab/Shift+Tab/Enter 操作：

  • 观察 document.activeElement 是否始终落在预期元素上
  • 在 DevTools Accessibility 面板中确认 Focusable: true 和 Focused: true 同时成立
  • 遇到焦点“消失”，优先检查父容器是否缺失 tabindex="0"，而非怀疑子元素
  • 反向 Tab（Shift+Tab）路径必须与正向完全对称，否则说明 tabindex="-1" 或 inert 使用不当

  可访问性回归测试最易被忽略的点，从来不是 HTML 标签写得对不对，而是焦点管理逻辑有没有随 DOM 结构变化同步更新——这部分没法快照，只能人盯。