main 必须唯一且顶层，嵌套在 article 等标签内会导致屏幕阅读器跳过或重复播报、焦点顺序错乱；修复成本是预防的 3–5 倍，axe-core 报错常误指父容器，建议用 devtools landmarks 视图验证。
规范 HTML 结构不是为了“看起来更专业”，而是直接降低可访问性（a11y）修复成本——多数 WCAG 问题（如屏幕阅读器跳过内容、焦点顺序错乱、语义缺失）都源于结构松散或误用标签，修复它们比预防贵 3–5 倍。
为什么写错位置会让 a11y audit 多花 2 天
浏览器和辅助技术依赖语义标签建立内容层级与导航路径。main 必须且只能出现一次，且不能嵌套在 article、section 或 aside 内部。一旦写成 <article><main>...</main></article>，NVDA 或 VoiceOver 就会把这部分内容识别为“嵌套主区域”，导致：
- 屏幕阅读器跳过该
main，或重复播报 - 键盘 Tab 顺序被破坏（因隐式 role 被覆盖）
- axe-core 检测报
region-missing-label和duplicate-main，但错误提示指向父容器而非真实源头
实操建议：
- 用 DevTools 的 Accessibility 面板 → “Landmarks” 视图，一眼确认
main是否唯一且顶层 - CI 中加一行检查：
grep -n "<main src wc>，大于 1 就阻断构建</main> - 团队模板里禁用
main手动输入，改用 Prettier 插件自动插入到直接子级
aria-label 和 aria-labelledby 混用时的焦点陷阱
当一个按钮既带图标又无可见文本（如 ? 搜索按钮），仅靠 aria-label="Search" 是安全的；但若同时写了 aria-labelledby="search-label"，而对应 ID 元素又未渲染或被 display: none，就会触发“label not found”警告，部分读屏器静默失败。
常见错误现象：
- 按钮可 Tab 进入，但读不出任何文字（尤其在 iOS VoiceOver + Safari 组合下）
- axe 报
aria-label-is-valid，但实际运行时 label 被忽略 - React/Vue 中动态渲染 label 元素，但挂载时机晚于按钮，造成短暂不可读
实操建议：
- 优先用
aria-label—— 简单、可控、不依赖 DOM 存在性 - 必须用
aria-labelledby时，确保目标元素始终存在且非hidden或aria-hidden="true" - 避免在同一个元素上同时写
aria-label和aria-labelledby：后者会完全覆盖前者
嵌套超过三层的表单结构让键盘导航失效
一个典型的“地址选择器”组件可能写成：<div><div><form><div>
<label>...</label><input>
</div></form></div></div>。这种结构本身不报错，但会导致：
- Tab 键在输入框间跳跃时，焦点被中间两层
div拦截（尤其当它们有tabindex="0"） - 屏幕阅读器将整个区块读作“group”，而非独立控件列表
- 自动化测试工具无法定位
label与input的绑定关系（因中间多层干扰）
实操建议：
- 表单控件层级严格控制在一层：
<form><label><input></label></form>，必要时用fieldset/legend分组 - 删掉所有无 class/id/事件/JS 绑定的
div包裹，用 CSS Grid/Flex 实现布局 - 用 Chrome DevTools 的 “Accessibility > Keyboard focusable elements” 视图，快速筛出意外可聚焦的容器
真正难的不是写对第一个 nav 或 main，而是让整站所有模板、CMS 输出、第三方组件注入的内容，都遵循同一套结构契约——这需要工具链兜底，而不是靠 Code Review 记住每条规则。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
