旧版html可访问性迁移核心是重写结构契约而非仅加aria：先用开发者工具或lighthouse检测div伪装、标题树断裂、空交互元素三类硬伤；必须将div.header/nav/main/sidebar替换为header/nav/main/aside等语义标签，禁用多重main、错误嵌套及滥用aria；迁移后需人工验证tab流、屏幕阅读器朗读逻辑与高对比度适配。
旧版HTML做可访问性迁移，不是加几个aria-label就能过关——核心是重写结构契约，否则屏幕阅读器读出来的仍是“一堆div”，而不是“导航栏、主内容、侧边推荐”。
怎么判断旧HTML是否具备可访问性改造基础
先别动代码，打开浏览器开发者工具的“Accessibility”面板（或用Lighthouse跑一次A11y审计），重点看三类硬伤：
-
document.querySelectorAll("div[role], div[aria-*]")返回大量结果 → 说明原作者试图打补丁式修复，但语义结构本身已坍塌，必须重构DOM层级 - 所有
h1~h6标签被包裹在div里，且h1缺失或重复 → 标题树断裂，屏幕阅读器无法构建导航大纲 -
document.querySelectorAll("a, button")中超过30%没有innerText或aria-label→ 键盘焦点停在空链接上，用户完全不知道该操作什么
哪些旧标签必须立刻替换，不能只加ARIA
ARIA是补救手段，不是替代方案。以下标签一旦存在，必须用语义化标签重写，否则role属性会被浏览器忽略或覆盖：
<div class="header"> → 改为<code><header></header>，且确保页面中仅有一个<header></header><div class="nav"> → 改为<code><nav aria-label="主导航"></nav>，避免嵌套<nav></nav><div class="main-content"> → 改为<code><main></main>，禁止出现多个<main></main>（Lighthouse会报document-multiple-main-elements）<div class="sidebar"> → 改为<code><aside></aside>，但前提是内容确实与主文相关（如文章引用、作者简介）；纯广告位请用<section></section>+aria-labelledby旧代码里最常踩的ARIA坑
很多团队加了ARIA反而让可访问性更差，因为没理解ARIA和原生语义的优先级关系：
-
role="button"加在<div>上，却不加<code>tabindex="0"和keydown事件监听 → 键盘用户根本无法聚焦，屏幕阅读器朗读为“button”，但实际不可操作 - 给
<img>同时设置alt=""和aria-hidden="true"→ 屏幕阅读器跳过，但视觉用户看到破损图，又无替代文本，双重信息丢失 - 用
aria-live="polite"包裹整个<div id="content"> → 内容更新时整块区域被反复朗读，打断用户当前操作流；应只包裹真正需要动态播报的节点（如表单错误提示） <li> <code>aria-expanded绑定在<span></span>而非触发按钮上 → 屏幕阅读器无法关联展开/收起状态，用户不知道点击后会发生什么 - 关闭CSS，用
Tab键从头到尾走一遍：焦点顺序是否符合视觉流？跳过的内容是否真无关紧要？ - 开启VoiceOver（macOS）或NVDA（Windows），听完整页朗读：标题层级是否连贯？
<nav></nav>是否被识别为“navigation”，而不是“group”？ - 把浏览器缩放到200%，检查所有文字是否仍可读、控件是否可点：高对比度模式下，
color和background-color是否都显式声明？
迁移后必须验证的三个真实场景
自动化工具只能发现50%的问题，剩下靠人工模拟真实使用路径：
最容易被忽略的是：旧系统里那些“看起来没问题”的
onclick内联事件，迁移到语义标签后，必须重绑click和keydown（含Enter和Space），否则键盘用户永远点不动。-
