优化复杂页面无障碍的核心是正确使用原生语义标签：确保唯一且不嵌套的、带标题的与独立可复用的；用真实替代class模拟导航；表单控件必须绑定并避免for/id错配；善用、、等小众语义标签，并保障其dom层级与焦点流真实有效。
复杂页面的HTML结构一旦混乱，屏幕阅读器会“读丢”关键内容，键盘焦点顺序错乱，残障用户根本没法用——这不是样式问题，是结构缺陷。优化核心不是加更多ARIA，而是让原生语义标签真正承担起结构职责。
用对 <main></main>、<section></section> 和 <article></article> 避免嵌套失焦
很多项目把整个页面内容塞进一个 <div id="app">，再靠JS动态挂载，结果 <code><main></main> 要么缺失，要么被包在多层 <div> 里。屏幕阅读器无法识别主内容区，用户按 <code>Ctrl+Alt+Home（NVDA）或 R（JAWS）跳转时直接失效。
-
<main></main>必须且只能出现一次，且不能嵌套在<article></article>、<aside></aside>、<footer></footer>等标签内 -
<section></section>表示有主题关联的一组内容，需带<h2></h2>–<h6></h6>；纯装饰性分隔不用<section></section> -
<article></article>是可独立分发/复用的内容单元（如博客正文、新闻卡片），内部必须有标题，不能只包<p></p>
别让 <nav></nav> 变成“导航类名容器”
常见错误是写成 <div class="nav"><ul>...</ul></div>，即使加了 role="navigation"，也绕不开语义缺失：浏览器不会把它纳入导航地标（landmark），键盘用户无法用 D 键快速跳转到导航区。
- 真实
<nav></nav>应包裹完整导航逻辑链，包括主导航、面包屑、页内锚点跳转列表 - 多个导航区要加
aria-label区分，例如：<nav aria-label="主导航"></nav>、<nav aria-label="文章相关链接"></nav> - 响应式下折叠的移动端菜单，仍需保留在
<nav></nav>内，仅用hidden或aria-hidden="true"控制可见性，不可移除DOM
表单控件必须绑定 <label></label> 且禁用 for/id 错配
复杂页面常有动态生成的表单项，JS拼接HTML时容易漏掉 <label></label>，或 for 值与实际 id 不一致。后果是：屏幕阅读器读不出控件用途，语音指令（如“点击邮箱输入框”）完全失效。
- 优先用显式包裹：
<label>邮箱<input type="email"></label>，避免for/id手动配对出错 - 禁用空
<label for="xxx"></label>—— 这会让阅读器静默跳过，用户不知道这是什么控件 - 多选/单选组用
<fieldset></fieldset>+<legend></legend>，而非仅靠视觉分组，否则组标题不会被读出
<time></time>、<address></address> 等小众语义标签不是摆设
这些标签在复杂页面中极易被忽略，但它们直接影响辅助技术对信息类型的判断。比如活动页的时间字段若写成 <span>2026年7月15日</span>，屏幕阅读器只会读作普通文本；而 <time datetime="2026-07-15">2026年7月15日</time> 会被识别为日期类型，支持语音快捷跳转和日历集成。
-
<time></time>的datetime属性必须是机器可解析格式（ISO 8601），中文显示文本可自由定制 -
<address></address>仅用于最近一级<article></article>或的联系信息，不是所有地址都该用它 -
<figure></figure>+<figcaption></figcaption>是图片/图表的语义闭环，比单独<img>+<p></p>更可靠，阅读器会把标题和图像当整体播报
最易被忽略的点：语义标签不是“写了就完事”，必须配合真实的DOM层级和焦点流。比如 <main></main> 里混入 <nav></nav> 或 <aside></aside>，或用 display: contents 让语义标签“消失”于渲染树，都会让辅助技术彻底失效——结构优化最终要落到可操作、可验证的渲染结果上。
