多数可访问性问题只需语义化标签替换、关键aria属性补全和焦点流修复即可显著改善——如用替代、为标签页添加aria-selected、确保模态框焦点正确管理。
直接说结论：多数可访问性问题不需要重写组件，靠几处语义化标签替换、aria-属性补全和焦点管理微调就能显著改善体验——关键不是“做多少”，而是“改对哪几个点”。
用原生语义标签替代 div 套娃
很多团队在迭代时不敢动 DOM 结构，但其实只要把高频误用的 <div class="button"> 换成 <code><button></button>，把 <div class="nav"> 换成 <code><nav></nav>，屏幕阅读器就能立刻识别交互意图和导航区域。这类替换几乎零风险，也不影响样式（CSS 选择器照常生效）。
常见错误现象：
-
<div onclick="submit()>提交</div>—— 缺失键盘支持、无焦点、AT 无法识别为控件 <div class=" header>标题</div>—— 屏幕阅读器读作“普通文本”，不提示层级或作用
实操建议：
- 优先搜索项目中所有
onclick+div或span组合，逐个替换为<button></button>或<a href="#"></a> - 用浏览器 DevTools 的「Accessibility」面板快速定位未语义化的结构区域
- 避免用
role="button"伪装div，它只是补救手段，不如直接换标签
补全关键 aria 属性而非堆砌
很多团队一听说 ARIA 就疯狂加 aria-label、aria-describedby，结果反而干扰 AT 解析。真正需要补的只有三类场景：动态内容变化、非标准控件、多状态切换组件（如标签页、树形菜单）。
使用场景举例：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 标签页中，当前激活的
<button role="tab"></button>必须有aria-selected="true"，且对应面板需设aria-hidden="false" - 折叠菜单项需同时设置
aria-expanded="true/false"和aria-controls="id-of-panel" - 表单输入框若无可见
<label></label>，至少补aria-label；若有，就别再重复加
容易踩的坑：
- 给静态文字加
aria-hidden="true"导致信息丢失（比如隐藏的辅助说明文字） - 用
aria-live区域包裹整个页面，造成 AT 频繁播报无关更新 -
aria-labelledby指向不存在的 ID，AT 直接静默跳过该元素
修复键盘焦点流而非只加 tabindex="0"
很多“可访问”按钮能被 Tab 进入，但按下 Enter 后没反应，或者焦点卡在某处出不来——这比没焦点更糟。真正的焦点修复是确保整个交互链路完整：进得来、操作有效、出得去。
实操建议：
- 检查所有自定义控件（如滑块、开关、标签页），确认
Enter/Space触发逻辑与鼠标一致 - 模态框打开时，用 JavaScript 把焦点移到第一个可聚焦元素；关闭时，焦点必须回到触发它的按钮上
- 禁用状态的按钮要设
disabled（原生属性），而不是仅靠 CSS 灰掉 +tabindex="-1"，否则 AT 仍会将其纳入焦点流 - 避免给非交互元素（如纯图标
<img>、装饰性<span></span>）设tabindex="0"，它们不该出现在 Tab 序列里
最常被忽略的复杂点是 DOM 渲染顺序与视觉顺序不一致——比如用 CSS flex-direction: column-reverse 或 float 打乱了源码结构，会导致屏幕阅读器按 DOM 顺序读，而用户按视觉顺序理解，两者错位。这种问题不会报 ARIA 错误，但会实质性破坏可访问性。修复必须回归 HTML 结构本身，而不是靠 ARIA 弥补。
