现代前端无障碍是涵盖语义标签、键盘交互、动态内容播报的全链路实践：必须用原生标签替代div+role，表单显式关联label，键盘事件同时响应Enter/Space，aria-live按场景选polite/assertive并保持DOM稳定。
现代前端开发里，HTML无障碍可访问性不是“加几个aria-属性就完事”，而是从标签选择、DOM结构、事件绑定到动态内容更新的一整套约束性实践——漏掉任一环，都可能让键盘用户卡在焦点里、让屏幕阅读器读不出表单错误、甚至让整个导航区域对辅助技术完全“隐身”。
用原生语义标签代替div+role是底线，不是加分项
几乎所有交互和结构场景都有对应原生标签，强行绕开它们会直接破坏焦点管理、键盘行为、禁用状态处理和无障碍树节点生成。
-
<button type="button">必须替代<div role="button" tabindex="0">：前者自带 Enter/Space 触发、disabled语义、焦点进入自动滚动可视区；后者需手动补全全部逻辑，且aria-hidden或tabindex="-1"极易误用 -
<nav>替代<div role="navigation">：前者被所有主流屏幕阅读器识别为导航地标（Landmark），支持快捷跳转；后者需额外配aria-label或aria-labelledby才勉强可用 -
<main>、<header>、<footer>不是“可选装饰”，而是定义页面主干结构的强制语义锚点——没有它们，AT 用户无法快速定位核心内容
表单必须显式关联label，且不能只靠aria-label
aria-label 是兜底方案，不是首选。它会完全覆盖元素的可访问名称（accessible name），导致屏幕阅读器读不出input本身的placeholder或周围上下文。
- 优先用
<label for="id">用户名</label><input id="username">：双向绑定、点击 label 自动聚焦 input、支持所有 AT - 若 DOM 结构不允许包裹（如复杂布局），用
<label>用户名<input></label>：隐式关联更稳定，无需维护for/id匹配 - 仅当以上两种都不可行时，才用
aria-label或aria-labelledby，且必须确保该文本是唯一、无歧义的操作说明（例如aria-label="搜索商品关键词"，而非"搜索框"）
键盘事件必须同时响应Enter和Space，不能只绑click
React/Vue/Svelte 中写 onClick 或 @click 很自然，但键盘用户按空格键触发交互是 Web 标准行为，不实现等于关闭了整个键盘操作链路。
立即学习“前端免费学习笔记（深入）”；
- React：必须同时写
onClick={handleClick}和onKeyPress={e => (e.key === 'Enter' || e.key === ' ') && handleClick(e)} - Vue：用
@click.prevent+@keydown.enter.prevent+@keydown.space.prevent组合，避免默认滚动或表单提交 - Svelte：监听
on:keydown|preventDefault并检查event.key，不要依赖on:click的冒泡行为——它在键盘触发时不一定触发 - 所有自定义按钮类元素（包括图标按钮）都要做这套处理，哪怕只是
<span aria-label="删除">✕</span>
aria-live必须紧贴动态内容，且值要按场景选
框架中状态驱动的 DOM 更新对屏幕阅读器是“静默”的。aria-live 不是加在组件根节点上的装饰属性，它的作用域、生命周期和播报策略都直接影响可访问性效果。
- 表单校验提示（如“密码长度不足6位”）：用
aria-live="polite"，等用户停顿再播报，避免打断输入 - 全局通知（如“保存成功”）：用
aria-live="assertive"，立即中断当前播报并强制读出 -
aria-live区域必须保持 DOM 稳定——不能随组件重渲染被销毁重建，否则 AT 会丢失引用；推荐放在不会卸载的父容器内，内容用innerHTML或条件渲染更新 - 绝对不要把
aria-live="off"当默认值写上去，它等于主动屏蔽所有播报
最常被忽略的是：语义标签和键盘事件是“静态保障”，而 aria-live 和焦点管理是“动态保障”。两者缺一不可，且必须在真实用户流中验证——比如用 Tab 键走一遍表单、用 VoiceOver 试一次搜索结果加载，而不是只跑自动化检测工具。
