header、nav、main、aside、footer、form等html5语义元素自带地标角色，无需重复添加role属性；多个同类地标须用aria-label或aria-labelledby区分；role="search"必须作用于form而非input；aria-hidden="true"需配合tabindex="-1"避免焦点陷阱。
哪些HTML元素自带地标角色，不用重复写role
header、nav、main、aside、footer、form这些HTML5语义元素，浏览器和屏幕阅读器默认就识别为对应地标角色（banner、navigation、main、complementary、contentinfo、form）。硬加上role="banner"或role="navigation"不仅多余，还可能在旧版读屏器中触发警告或覆盖原生行为。
常见错误是写成<header role="banner"></header>——header本身已隐含role="banner"，加了等于画蛇添足。同理，<nav role="navigation"></nav>也该删掉role属性。
只有当无法使用语义标签时才补：比如用<div class="sidebar">替代<code><aside></aside>，才需要显式加role="complementary"。
多个相同地标（如两个nav）怎么避免被合并或跳过
屏幕阅读器按地标类型导航时，如果页面有多个nav或多个aside，不加标识就会被当成“一个导航区”或“一个侧边栏”，用户无法区分主菜单和页脚链接列表。
解决方法是用aria-label或aria-labelledby为每个同类地标提供唯一名称：
-
<nav aria-label="主导航"></nav>—— 适合固定文案，如“主导航”“页脚导航” -
<nav aria-labelledby="footer-nav-title"><h2 id="footer-nav-title">相关链接</h2>...</nav>—— 适合复用可见标题，支持翻译和SEO
别用aria-label和aria-labelledby同时写，后者优先级更高，前者会被忽略；ID必须真实存在，否则屏幕阅读器静默失败，调试时看「Name Computation」最准。
role="search"该套在form上还是input上
role="search"必须作用于<form></form>容器，而不是<input>本身。原因：搜索是一个交互流程（输入+提交），不是单个控件；屏幕阅读器靠这个角色识别“这是搜索区域”，并可能提供快捷键（如NVDA的Insert+S）直接跳转。
正确写法：<form role="search">
<label for="q">搜索</label><input type="search" id="q"><button type="submit">搜</button>
</form>
错误写法：<input type="search" role="search">——这会让读屏器误以为输入框本身是个独立搜索功能，语义断裂，且无法关联label和按钮。
注意：type="search"已自带部分搜索语义，但role="search"才是让整个表单被识别为“搜索地标”的关键。两者不冲突，但角色必须落在form上。
aria-hidden="true"和地标共存时的焦点陷阱
如果某个地标区域（比如侧边栏aside）被JavaScript临时隐藏，千万别只设aria-hidden="true"。它只是告诉屏幕阅读器“忽略内容”，但元素仍在DOM里、仍可被Tab键聚焦——键盘用户会卡在一个看不见却能触达的空区域。
安全做法是同步处理：
- 隐藏时：加
aria-hidden="true"+tabindex="-1"（移出Tab顺序） - 显示时：移除
aria-hidden+ 移除tabindex="-1"，或改回tabindex="0"（如果需要键盘进入） - 更推荐用
hidden属性：<aside hidden></aside>，它自动等效于aria-hidden="true"+ 移除焦点能力，且语义更干净
最容易被忽略的是：父元素设了aria-hidden="true"，子元素哪怕写了aria-hidden="false"也无效——ARIA隐藏具有强制继承性，没法绕过。
