语义化标签是保障无障碍访问的最简可靠方式：用替代确保导航识别，表单必用显式绑定，动态更新按需设置aria-live，标题层级与地标区域须严格符合语义结构。
直接用语义化标签就能让屏幕阅读器正确识别结构，不需要额外加 role 或 JS 补救——这是最省力也最可靠的方式。
用 <nav></nav> 包裹主导航，别用 <div class="nav">
<p>屏幕阅读器靠原生标签的隐式 role（比如 <code><nav></nav> 自带 role="navigation"）来跳转区域。如果用 <div> 模拟导航，即使加了 <code>role="navigation"，部分读屏器仍可能忽略或误判。
-
<nav></nav> 内部只放核心跳转链接（首页、产品、关于、联系），不混入搜索框、登录按钮、广告
- 一个页面可以有多个
<nav></nav>，但需用 aria-label 或 aria-labelledby 区分用途，比如 <nav aria-label="主导航"></nav> 和 <nav aria-label="页脚导航"></nav>
- 避免写成
<nav role="navigation"></nav>——冗余，某些校验工具会警告
表单必须用 <label></label> 显式绑定，不能靠视觉对齐
<nav></nav> 内部只放核心跳转链接（首页、产品、关于、联系），不混入搜索框、登录按钮、广告<nav></nav>，但需用 aria-label 或 aria-labelledby 区分用途，比如 <nav aria-label="主导航"></nav> 和 <nav aria-label="页脚导航"></nav>
<nav role="navigation"></nav>——冗余，某些校验工具会警告<label></label> 显式绑定，不能靠视觉对齐仅把文字写在 <input> 旁边，屏幕阅读器完全无法关联两者。聚焦输入框时，用户听不到“邮箱”或“密码”，只能听到“编辑文本”。
- 推荐用隐式包裹：
<label>邮箱地址<input type="email" name="email"></label>，无需维护id/for配对 - 若需分离标签与控件（如布局限制），用
for+id：给<input id="phone">配<label for="phone">手机号</label> - 禁用
aria-label替代<label></label>：它绕过表单验证逻辑，且某些读屏器在组合键（如 NVDA + B）遍历表单控件时不会朗读
动态内容更新必须用 aria-live，但要控制打断强度
表单错误提示、步骤切换、加载状态这些看不见的变更，屏幕阅读器默认不播报。硬编码 aria-live="assertive" 会导致每输一个字就打断语音流，体验极差。
- 轻量提示（如“已保存”）用
aria-live="polite"，等用户暂停操作后再播报 - 关键中断（如“提交失败，请检查网络”）才用
aria-live="assertive" - 只包裹最小必要节点，比如只包
<div aria-live="polite"><p id="error-msg"></p></div>，不要包整个<form></form> - 错误信息必须用
aria-describedby关联到对应输入框，例如<input aria-describedby="email-error"><span id="email-error">邮箱格式不正确</span>
标题层级和地标区域不能错乱
<h1></h1> 到 <h6></h6> 不是样式选择，而是内容大纲。屏幕阅读器用户常用快捷键（如 NVDA + F7）调出标题树快速跳转。如果全用 <h2></h2>，等于告诉用户“所有内容平级”，失去导航依据。
-
<main></main>页面中只能出现一次，且不能嵌套在<article></article>或<section></section>内 -
<header></header>和<footer></footer>应放在合理上下文中；孤立的<header></header>可能被误读为 banner 地标 - 避免跳级：从
<h2></h2>直接到<h4></h4>，中间缺失<h3></h3>，会让读屏器用户困惑结构断裂点
最容易被忽略的是：语义标签一旦用了，就必须保证其内部内容符合该角色的语义意图。比如 <nav></nav> 里塞了个搜索表单，<main></main> 里混进了页脚链接——这些都会让屏幕阅读器用户在“按区域跳转”时产生严重误导，比不用标签还糟。
