语音助手无法读取页面内容的根本原因是缺乏语义化html结构锚点。必须使用（唯一且为body直接子元素）、（非class模拟）、包裹type="search"输入框（含action和method="get"），并正确绑定
语音助手读不到你的页面，大概率不是它“听不见”，而是你没给它可识别的结构锚点。光用 <div> 堆内容、靠 CSS 类名假装语义，对 Siri、VoiceOver 或 TalkBack 来说等于没写。
<h3>为什么 <code><main></main> 必须唯一且直接子元素
语音助手和屏幕阅读器把 <main></main> 当作正文入口的唯一可信信号。缺失时，系统会退回到找 role="main"，再找不到就从第一个 <h1></h1> 开始——而这个 <h1></h1> 很可能在 logo 里。
-
<main></main>必须是的直接子元素，不能嵌套在<div id="app"> 或其他容器里 <li>全页只能有一个 <code><main></main>；多个会导致语音指令“跳到主要内容”失效或随机命中 - React/Vue 项目中常见错误：根容器用了
<div>，但子组件没透出 <code><main></main>，整块内容变成“不可跳转黑盒”<nav></nav>不是 class="nav"，也不是 role="navigation"语音助手不解析 class 名，也不猜你意图。
<nav></nav>自带role="navigation"，且被 iOS/Android 系统固化为地标（landmark），支持快捷键跳转；<div class="nav"> 在可访问树里只是 <code>generic，读屏器连“导航”两个字都不会提。- 多个
<nav></nav>必须加aria-label区分，比如<nav aria-label="主导航"></nav>和<nav aria-label="页脚导航"></nav> - 用
<div role="navigation"> 替代时，漏掉 <code>tabindex="0"→ 键盘无法聚焦，语音指令无响应目标 - 别在
<nav></nav>外层再套<header></header>或加role="search"：iOS 会优先识别 role，反而忽略原生type="search"语义 -
action不能省略，哪怕只是占位路径如"/search"；漏掉时 Safari 报错“无法确定搜索目标”，Chrome 静默忽略 -
method必须是"get"：POST 会破坏书签化与分享能力，语音搜索结果必须可链接 -
<label></label>必须显式绑定（for属性或包裹 input），不能靠placeholder或aria-label单独撑场子；alt=""对装饰图有用，但aria-label单独用于 search input 可能被旧版 TalkBack 重复朗读 - Android Chrome 的语音菜单最多只显示前 2 个
<input type="search">，多余的直接过滤——别在页脚、侧边栏重复放搜索框 - 动态改
type属性（比如 JS 把type="text"改成"search"）无效：Siri 只在 DOM 初始化时扫描，改了也不认 - 避免用
<button></button>包含块级结构（如图标+多行文字）；若必须，改用role="button"+tabindex="0"+ 手动绑定 click/Enter/Space，否则语音助手可能跳过整个按钮
<form></form>+<input type="search">是语音搜索唯一有效组合仅用
<input type="text">或 div 模拟搜索框，语音助手不会把它当搜索入口——它只是个普通输入框。Siri 和 Chrome Android 的语音菜单只认<form></form>内、method="get"、有action的<input type="search">。移动端语音解析差异比想象中更硬核
iOS 和 Android 对同一份 HTML 的扫描逻辑不同，不是“差不多就行”，而是“差一点就完全失效”。
真正起作用的不是“用了语义标签”，而是标签之间是否构成被语音助手严格匹配的组合关系。一个
<main></main>缺失，整页正文就失去锚点；一个<form></form>没action，搜索框就形同虚设。这些不是可选项，是语音交互链路里的硬性节点。 - 多个
