优先修复三类高风险页面：入口页、含表单页、全局模板片段；按语义结构→键盘导航→aria补充三阶段推进，每阶段需通过lighthouse审计、纯html浏览、dom属性监听验证。
从哪几个页面优先动手
别一上来就全站扫荡。先盯住三类高风险页面：入口页（index.html、home.html）、含表单页（contact.html、login.html）、被全局 include 的模板片段（如 header.inc）。它们被爬虫首访、被屏幕阅读器高频解析、改一处影响全站，修复 ROI 最高。
常见错误是按“文件修改时间”排序——三年没动过的 footer.html 可能正包裹着所有页面的 <script></script>，一旦 JS 阻塞，可访问性直接归零。
- 入口页出问题 → SEO 掉量 + 屏幕阅读器首屏读不出主结构
- 表单页缺
label或required→ 键盘用户无法提交，W3C 验证器批量报错 - 模板片段错用
div代替nav或header→ 所有引用页的 landmark 角色全部失效
怎么划分阶段：语义结构 → 键盘导航 → ARIA 补充
可访问性不是靠堆属性修出来的，得按依赖关系分层推进。第一阶段必须搞定语义结构，否则后续所有 ARIA 都是空中楼阁。
-
阶段一（结构校准）：把泛滥的
div替换为header、nav、main、section等语义标签，确保main全局唯一、nav只包主导航链接、header是body直系子元素 -
阶段二（键盘流）：验证 Tab 焦点顺序是否与视觉流一致；禁用鼠标，纯键盘操作能否完成核心路径（如登录、筛选、提交）；移除
outline: none，用:focus重写焦点样式 -
阶段三（ARIA 注入）：仅在语义不足时补充，比如标签页加
role="tablist"、动态加载内容加aria-live；避免给button加role="button"这类冗余声明
跳过阶段一强行加 ARIA，等于给歪房子刷漆——Lighthouse 的 “landmark-roles” 和 “logical-tab-order” 审计会持续失败。
如何验证每个阶段是否真正落地
不能只看代码变漂亮了。三个硬性验证点缺一不可：
- 运行 Lighthouse Accessibility 审计，重点盯
heading-levels、landmark-roles、logical-tab-order三项全部通过 - 手动关闭 CSS，用纯 HTML 浏览页面——能否按逻辑顺序读完标题、段落、列表？如果结构崩塌，说明语义替换没到位
- 在 Chrome DevTools Elements 面板右键任意元素 → “Break on” → “Attribute modification”，观察 DOM 是否因 JS 动态操作意外覆盖了
aria-属性或 tabindex
特别注意：很多团队卡在“验证通过但实际仍不可用”，问题常出在动态组件里——比如 React 渲染后 main 被包裹进 div，或 Vue 的 v-if 导致 aria-labelledby 指向的 ID 不存在。这类问题必须在真实交互路径中测试，不能只验静态 HTML。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
