role地标属性是wai-aria定义的7个语义化角色（如banner、navigation、main等），专供屏幕阅读器识别页面结构；class或id仅用于样式与脚本，无语义，无法被辅助技术解析为地标。
什么是 role 地标属性，为什么不能只靠 class 或 id？
HTML 原生地标（landmark）不是靠 CSS 类名或自定义 ID 实现的，而是依赖 ARIA 的 role 属性值（如 role="navigation"、role="main"）被屏幕阅读器识别为独立导航区域。仅写 class="nav" 或 id="header" 对辅助技术完全无效——它们不构成语义地标，也不会出现在屏幕阅读器的“地标列表”快捷菜单里（例如 NVDA 的 D 键、VoiceOver 的 U 键导航）。
常见误操作：
• 把 <nav></nav> 标签外再套一层 div role="navigation"（冗余且可能干扰默认语义）
• 用 role="banner" 标记页脚（应为 role="contentinfo"）
• 在非容器元素（如 <p></p> 或 <span></span>）上滥用 role（违反 ARIA 规范）
7 个合法 landmark role 值及对应使用场景
WAI-ARIA 1.2 明确支持以下 7 种地标角色，每个都有不可替代的语义边界和交互预期：
-
banner：仅用于页面顶部全局性内容（logo、主站名、登录入口），**每页最多一个**；不要用于文章标题或轮播图标题 -
navigation：导航链接集合（主导航、面包屑、分页栏），可多个，建议用aria-label区分，如aria-label="主导航"、aria-label="页内锚点导航" -
main：页面核心内容区域，**必须且唯一**；不能嵌套在article或section内部作为子地标 -
complementary：辅助性但非主要内容（侧边栏推荐、相关链接），与main并列存在 -
contentinfo：页脚信息（版权、联系方式、隐私政策链接），**不是所有 footer 都该加此 role**——仅当它是全站级页脚时才适用 -
form：独立、完整、有明确提交目标的表单（如注册表单、搜索框）；搜索框若只是站内小部件，优先用role="search"（它也是地标） -
search：专指全站级搜索区域（通常含input[type="search"]和提交按钮），**不能用于表单内部的子搜索字段**
如何验证 landmark 是否生效？别只信浏览器开发者工具
Chrome DevTools 的“Accessibility”面板只显示部分 ARIA 属性，**无法准确反映地标是否被屏幕阅读器识别**。真实验证必须结合辅助技术：
- NVDA + Firefox：按
D键呼出地标列表，检查名称是否清晰（无名地标会显示为 “region”） - VoiceOver + Safari：按
Ctrl + Option + U打开“Web 揭示”，选择 “Landmarks” 分类 - axe 浏览器插件：运行扫描后查看 “landmark-one-main”、“landmark-no-duplicate-banner” 等规则报错
- 注意：若地标内没有可聚焦元素（如链接、按钮、带
tabindex="0"的容器），部分屏幕阅读器可能跳过该区域——可在地标根元素加tabindex="0"强制可聚焦（仅当内部确实无可聚焦子元素时）
role 和原生 HTML5 标签怎么共存？优先级和冲突点
原生语义标签（<header></header>、<nav></nav>、<main></main> 等）已隐含对应 role，**无需重复添加**。但存在两个关键例外：
-
<section></section>和<article></article>默认无地标 role，若需作为独立导航区（如“相关文章列表”），必须显式加role="complementary"或role="region"（后者需配aria-labelledby） - 旧项目中大量使用
<div>，此时必须补 <code>role——但比改结构成本低，属于渐进式修复手段 - 冲突场景：给
<nav></nav>加role="application"会覆盖其默认navigation语义，直接丢失地标功能；任何覆盖原生语义的role赋值都需三思
最易被忽略的一点：多个同类型地标（如两个 navigation）必须通过 aria-label 或 aria-labelledby 提供唯一可读名称，否则屏幕阅读器无法区分——这比写对 role 值更影响实际可用性。
