HTML前端框架不自动解决可访问性问题，关键在开发者将语义标签、ARIA属性、焦点管理、键盘导航嵌入组件生命周期；须用原生语义元素、正确role与tabIndex、aria-live常驻DOM、显式label绑定、焦点锁及真实读屏测试。
HTML前端框架本身不自动解决可访问性问题，关键在开发者是否把语义、ARIA、焦点管理、键盘导航这些“底层基建”真正嵌进组件生命周期里。
用原生语义标签替代 div + click 模拟交互
很多框架组件（比如 React 的 Button、Vue 的 v-button）默认渲染为 div 或 span，再靠 onClick 绑定行为——这会让屏幕阅读器完全忽略其可交互性。
- 必须显式传入
as="button"或用role="button"+tabIndex={0}+ 手动处理onKeyDown（Enter/Space），否则键盘用户无法触发 -
input[type="checkbox"]和input[type="radio"]永远比自定义 SVG 复选框更可靠；如需美化，用label包裹 + CSS 隐藏原生控件，保留语义链 - 菜单、下拉、弹出层（
Popover、Dropdown）必须用role="menu"/role="dialog"+aria-modal="true"+ 焦点锁（focus trap），否则读屏会跳到背景内容
动态内容更新必须用 aria-live 而非仅靠视觉反馈
框架中常见“提交成功 → 显示 toast”的场景，若只靠 CSS 动画或 visibility: hidden 切换，读屏根本感知不到变化。
- 对实时更新区域（如搜索建议、表单校验提示、加载状态），加
aria-live="polite"（低优先级）或aria-live="assertive"（中断当前播报） - 不要把
aria-live挂在条件渲染的组件上（如{showToast && <toast></toast>}），它必须常驻 DOM，仅通过textContent或innerHTML更新内容 - 避免在
aria-live区域内放链接、按钮等可交互元素——读屏可能无法聚焦，改用role="status"+ 短文本描述更稳妥
表单控件必须绑定 label 且支持 id 显式关联
框架封装的 Input、Select 组件若没暴露 id 和 aria-labelledby 配置项，就等于放弃表单可访问性的第一道防线。
立即学习“前端免费学习笔记（深入）”；
- 强制要求每个表单控件有唯一
id，且父级label用htmlFor（React）或for（Vue）指向它；不要依赖隐式包裹（label > input），SSR 或 Fragment 场景下容易断裂 - 错误提示不能只靠颜色（如红字），必须用
aria-invalid="true"+aria-describedby关联到提示文案 ID - 多选控件（如
CheckboxGroup）需用role="group"+aria-labelledby指向组合标题，否则读屏会逐个读“checkbox”，丢失上下文
键盘焦点流必须可预测，不能依赖 CSS outline 显示
框架组件常因 focusVisible 逻辑或重置样式导致键盘用户“看不见自己在哪”，这不是 UI 问题，是可访问性失效。
- 禁用
outline: none除非提供同等清晰的焦点轮廓（如box-shadow或双线边框），且确保高对比度（WCAG AAA 要求 4.5:1） - 模态框打开后，焦点必须立即移入第一个可聚焦元素；关闭后，焦点应回到触发按钮——这需要手动调用
focus()，框架的 ref 或useFocusTrap不一定覆盖所有边界 - Tab 键顺序必须与 DOM 顺序一致；用
display: flex或grid改变视觉顺序时，别用order打乱 DOM 结构，否则键盘流会跳跃
最常被忽略的是：框架文档里写的“支持无障碍”往往只指“能加 ARIA 属性”，不代表组件默认开启语义、焦点管理或 live region。真正在意可访问性，就得把每种交互路径都用 NVDA/JAWS/VoiceOver 实测一遍，而不是只跑 Lighthouse 得分。
