必须为多个nav元素配唯一aria-label（如“主导航”），main须为body直系子元素，aside不可替代导航，DOM顺序决定焦点流，地标有效性取决于最终渲染的role、name和level。

多个

共存时必须配aria-label，否则读屏器无法区分

页面有主导航、面包屑、页脚链接三处导航，只写三个

标签，屏幕阅读器会全部读作“导航区域”，用户无法判断哪个是当前要跳转的路径。这不是渲染问题，而是语义缺失。

• nav是语义容器，不是用途说明书；必须用aria-label显式声明功能，如aria-label="主导航"、aria-label="面包屑导航"、aria-label="页脚快捷链接"
• 避免泛化命名，aria-label="Navigation"等于没标，所有导航都叫 Navigation，辅助技术无法分辨上下文
• 英文界面统一用aria-label="Main navigation"或aria-label="Breadcrumb"，不拼写变体（如Breadcrumbs）

必须唯一且为直系子元素，嵌套即失效

React 或 Next.js 模板常把main包在div或Layout组件里，导致 Lighthouse 报“Multiple main landmarks”——这不是警告，是直接判无障碍失败。屏幕阅读器靠main定位核心内容，它被埋深一层，就等于 GPS 定位点塞进了抽屉。

• main只能是body的直接子节点，不能出现在header、section、div甚至article内部
• 框架输出 DOM 不符合要求时，必须用 JS 在DOMContentLoaded后修正：document.body.replaceChild(newMain, oldMain)，或 CSS display: contents（慎用，兼容性有限）
• main内部不需要再套section，除非该section有独立标题且需参与大纲生成；否则main + h1更干净

aside不能替代导航或页脚，语义错配会破坏地标结构

把主导航塞进aside，读屏器会把它识别为complementary（附属内容），而非navigation（导航地标）。用户按 Insert+Tab 切换地标时，根本找不到“主导航”这一项——因为浏览器压根没把它当导航处理。

html-to-pptx

将多页 HTML 演示文稿转换为美化的 PPTX 文件，便于分享和分发。

下载

• aside语义是“可独立存在但非主内容”的附属块，比如相关文章、广告、侧边工具栏；主导航、页脚版权信息、面包屑都不属于这个范畴
• 误用后果：SEO 权重错配、自动化测试报landmark-unique错误、读屏播报混乱（用户听到“补充内容”却点开首页链接）
• 若需右侧侧边栏布局，HTML 结构仍应保持main在前、aside在后，再用 CSS flex或grid调整视觉顺序；否则键盘 Tab 会先聚焦侧边栏，违背“主内容优先”原则

多栏布局中焦点流与 DOM 顺序必须一致

Flexbox 或 Grid 实现三栏（main + aside + sidebar）时，CSS 可以把aside推到右边，但若 HTML 中它写在main前面，键盘用户 Tab 还是从侧边栏开始——这会让低视力或运动障碍用户迷失在非主内容里。

立即学习“前端免费学习笔记（深入）”；

• DOM 顺序决定 Tab 流，不是视觉位置；必须让main作为第一个可聚焦内容区块出现在源码中
• 不要给aside加tabindex="0"试图“修复”焦点顺序——它不该被主动聚焦，焦点应自然流向其中的按钮或链接
• 验证方式：关闭样式（DevTools → Elements → 禁用所有 CSS），观察 Tab 键是否按预期顺序进入main → aside → footer

实际落地时最易被忽略的是：地标是否生效，不取决于你写了什么标签，而取决于最终渲染的 DOM 是否满足浏览器向辅助技术暴露的 role、name 和 level。哪怕用了nav和main，只要嵌套错位、缺aria-label、或 DOM 顺序混乱，读屏器就当它们不存在。