语义标签（如<header><nav><main>）是读屏器解析页面结构的基础，不可用<div>加ARIA补救；aria-labelledby优先于aria-label；aria-live的politeness需按提示重要性分级设置；自定义组件须配对角色与状态属性并管理焦点顺序。
用 <header> <nav> <main> 替代 <div> 不是装饰，是基础读屏逻辑
屏幕阅读器（如 NVDA、VoiceOver）依赖语义标签构建页面结构树，<div> 默认无角色，读屏时只会说“组”，无法传达导航、主体、页脚等意图。浏览器原生语义标签自带隐式 ARIA role（例如 <nav> 等价于 role="navigation"），且无需额外 JS 维护。
常见错误：用 <div class="header"> 模拟页眉，但没加 role="banner" —— 多数读屏器会跳过或误读为普通容器。
- 必须优先使用
<header>、<nav>、<main>、<aside>、<footer>，而非靠 ARIA 补救 - 避免混合使用：比如
<nav role="navigation">是冗余的，role会被忽略或触发校验警告 -
<main>页面中只能出现一次，且不应嵌套在<article>或<section>内
aria-label 和 aria-labelledby 到底该选哪个？
两者都用于提供可访问的名称，但触发时机和维护成本差异很大：aria-label 是硬编码文本，aria-labelledby 指向页面中已存在的可见元素 ID，内容同步更新、支持多语言切换。
典型错误：给图标按钮写 aria-label="search"，但 UI 后续改成放大镜+文字“查找”，文案和提示不一致；或在多语言站点里把 aria-label 写死成英文，导致翻译失效。
立即学习“前端免费学习笔记（深入）”；
- 优先用
aria-labelledby：例如搜索框旁有<label id="search-label">查找商品</label>，输入框写aria-labelledby="search-label" - 仅当无对应可见文本时用
aria-label：如纯图标按钮、加载中 Spinner - 绝对不要同时写
aria-label和aria-labelledby—— 后者会被忽略，且 Lighthouse 会报错
动态内容更新时，aria-live 的 politeness 值怎么设才不打断用户？
aria-live 控制读屏器何时播报区域变化，politeness（off/polite/assertive）决定打断强度。设错会导致用户正在听导航时被弹窗强行中断，或关键错误（如表单提交失败）完全被忽略。
常见错误：所有提示都设 aria-live="assertive"，结果每输入一个字就播报“输入中…”，语音流彻底混乱。
-
polite：适合状态变更类提示（如“已保存”、“还有 3 条未读”），等当前语音说完再播 -
assertive：仅限中断性操作（如登录失败弹出错误、支付超时警告），需立即打断 - 避免对整块区域设
aria-live，应包裹最小必要 DOM 节点（比如只包<span class="status">，而非整个<form>）
自定义组件（如 Tab、Dropdown）为什么光加 role 不够？
仅设置 role="tablist" 或 role="combobox" 只是告诉读屏器“这是个什么”，但不提供交互逻辑。键盘焦点管理、键位响应（Tab/Arrow/Enter/Escape）、状态同步（aria-selected、aria-expanded）全要手动实现。
典型问题：下拉菜单加了 role="listbox"，但没监听 ArrowDown 键，键盘用户无法用方向键选择；或选项没设 aria-selected="true"，读屏器读不出当前选中项。
- 必须配对使用状态属性：如
role="tab"→ 需aria-selected；role="treeitem"→ 需aria-expanded和aria-level - 确保
tabindex正确：可聚焦元素需tabindex="0"，禁用态加aria-disabled="true"（而非仅tabindex="-1"） - 别重复造轮子：优先用原生
<details><summary>实现折叠面板，它自带语义、键盘支持和无障碍状态
最常被忽略的是焦点顺序与视觉顺序不一致——CSS order 或 flex-direction: row-reverse 会打乱可访问流，但读屏器仍按 DOM 顺序读。修复它比加一堆 ARIA 属性更根本。
