可访问性修复关键在alt属性、label关联、role语义和焦点管理四点：功能性图片需描述性alt，表单控件须显式绑定label，动态内容更新要用aria-live通知，语义结构须严格遵循HTML规范。
可访问性问题大多不是“修不了”，而是没在正确位置动刀——90% 的修复集中在 alt、label 关联、role 和焦点管理这四个点上，改完立刻生效，无需重写逻辑。
图片缺失 alt 属性导致屏幕阅读器跳过关键信息
这是最常被忽略的硬伤：所有功能性图片（按钮图标、图表、产品图）必须有描述性 alt；纯装饰图必须显式设为 alt=""。浏览器不会自动补，屏幕阅读器遇到空 alt 或缺失 alt 会直接跳过，用户根本不知道那里有一张图。
-
alt不是“随便写个词”，要说明用途：比如<img src="submit.svg" alt="提交表单">，而不是alt="submit"或alt="icon" - 带链接的图片，
alt应描述链接目标，而非图片本身：“前往产品页”比“蓝色按钮”更有效 - SVG 作为内联元素时，需配合
<title>和aria-hidden="true"（若已用<title>）或role="img"显式声明语义 - 避免
alt重复文本内容：如果旁边已有相同含义的文字说明，alt=""更合适
表单控件无法被键盘聚焦或缺少名称
键盘用户和屏幕阅读器依赖 label 与控件的显式绑定来识别字段用途。仅靠视觉对齐或 placeholder 是无效的——它们不会被读屏软件解析为控件名称。
- 优先使用包裹式
<label>用户名<input type="text"></label>，它天然建立关联，无需额外属性 - 若必须分离（如布局限制），务必配对
for和id：<label for="email">邮箱</label><input id="email" type="email">，且id值不能重复、不能含空格或特殊字符 - 所有
<input>、<select>、<textarea>必须有可访问名称，否则aria-label或aria-labelledby是兜底方案，但不如原生label稳定 - 禁用
placeholder替代label：它不提供持久标签，且对比度常不达标，用户输入后即消失
动态内容更新后屏幕阅读器无感知
AJAX 提交成功、表单校验失败、模态框打开——这些变化若不主动通知辅助技术，视障用户会卡在旧状态里，以为操作没响应。
立即学习“前端免费学习笔记（深入）”；
- 错误提示必须用
aria-live="polite"包裹，且放在 DOM 中靠前位置（最好紧贴<form>开头），确保新内容插入时能被读出 - 模态框需同时设置
role="dialog"、aria-modal="true"和aria-labelledby指向标题元素，否则屏幕阅读器可能继续朗读背景内容 - 校验失败的字段，除了视觉高亮，必须加
aria-invalid="true"和aria-describedby指向错误消息的id，否则读屏不会读出错误文本 - 避免仅靠 CSS
display: none隐藏错误消息：它会从可访问树中移除内容。用visibility: hidden+position: absolute或aria-hidden="true"控制可见性更稳妥
语义结构错乱导致导航失效
屏幕阅读器用户靠标题层级（h1–h6）、地标区域（nav、main、aside）快速跳转。用 div 模拟这些区域，等于把路标全拆了。
- 页面必须有且只有一个
<h1>，代表主标题；子标题严格按层级递进，禁止跳级（如h1后直接h3） -
<nav>、<main>、<footer>等语义标签不能只为了样式而存在——它们自带隐式role，比手动加role="navigation"更可靠 - 避免用
div+role="button"替代<button>：前者需手动处理tabindex、Enter/Space响应、焦点样式、禁用状态等，极易遗漏 - 表格必须有
<caption>和明确的<th>范围（scope="col"或scope="row"），否则数据关系对屏幕阅读器不可知
真正卡住人的从来不是技术细节，而是“改完一处，另一处又崩”。比如加了 aria-live 却忘了清理旧消息节点，导致错误堆叠；或者修复了 label 关联，但 JavaScript 动态插入的新字段又没同步绑定。可访问性不是一次性补丁，它得嵌进每次 DOM 操作的惯性里。
