必须用增量更新而非全量替换，因全量替换会引发JS绑定丢失、焦点状态重置、辅助技术上下文断裂三类风险；增量更新要求每次只改一个data-component模块，并通过版本校验、axe扫描和Puppeteer+NVDA回放验证确保可访问性不退化。
不能靠“一次性重构完再上线”来保障可访问性——大型HTML重构中，增量更新不是可选项，而是唯一能守住无障碍底线的路径。
为什么必须用增量而非全量更新
全量替换 HTML 结构（比如把所有 div class="btn" 一口气替换成 button）会直接触发三类不可控风险：JS 绑定丢失、焦点状态重置、辅助技术上下文断裂。尤其当页面含 contenteditable 区域或动态表单时，innerHTML = newHTML 会导致 iOS 输入法失焦、AT（辅助技术）读取中断、已选文本清空。
- 真实案例：某电商商品页将 200+ 个
div role="button"批量替换成button后，屏幕阅读器跳过全部操作按钮，因未同步补全aria-label和键盘事件处理逻辑 - DOM 复用失效：浏览器对
button和div[role="button"]的 focus/blur 行为处理不同，强行替换等于重置交互生命周期 - 构建产物不可控：Webpack/Vite 在 HTML 拆分后若未锁定
data-component版本，不同模块可能混用新旧语义结构，导致 axe 测试结果忽好忽坏
怎么设计可落地的增量更新节奏
核心是把“可访问性修复”绑定到具体组件的发布周期里，而不是独立于业务迭代之外。每次只改一个 data-component 模块，并确保它通过三项硬校验：
- 模块根元素必须带
data-component="xxx"和data-version="2.1"，CI 流程比对 JS 逻辑版本与 HTML 片段版本是否一致 - 替换前先跑本地 axe-core 扫描，记录当前
div[role="tablist"]的违规数；替换后必须 ≤ 原值，否则阻断合并 - 关键交互路径（如键盘 Tab 进入、Enter 触发、Screen Reader 朗读顺序）需在 Puppeteer + NVDA 组合下录制回放验证，不依赖人工抽检
示例：优化搜索框时，不碰整个 header，只提取 data-component="search-bar" 子树，将 input[type="text"] 外层 div 替换为 form，同时补上 aria-labelledby="search-label" 和 autocomplete="off" —— 其他区域保持原状。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的 DOM 更新陷阱
即使按模块拆分，仍可能因底层 DOM 操作方式引入可访问性退化：
- 用
innerHTML替换整个data-component内容：会销毁内部所有input的value、selectionStart和输入法状态，正确做法是用DocumentFragment只更新变更节点 - 懒加载嵌入内容（如
iframe loading="lazy"）未设title：屏幕阅读器遇到无title的 iframe 会静默跳过，必须在插入前动态注入title="地图：门店位置" - 响应式切换时移除/添加语义标签：比如移动端折叠导航用
div，桌面端才显示nav，这违反 W3C “语义一致性”原则，应始终保留nav，仅用display: none控制可见性
真正的难点不在“改什么”，而在“什么时候改、改多少、怎么验证没改坏”——每一次 DOM 更新都得带着可访问性断言往前走，否则重构越深入，残障用户可用性反而越脆弱。
