alt、label、role和键盘可聚焦性四点未到位即违反WCAG AA强制要求：装饰图用alt=""，功能图须描述意图（如alt="搜索"），禁用alt="icon"或缺失alt；表单控件必须有正确关联label；自定义元素加role后须配套事件与状态；键盘测试需全程Tab/Shift+Tab验证焦点流。
直接看 alt、label、role 和键盘可聚焦性，这四点没到位，基本就可以判定存在可访问性风险——不是“可能有问题”，而是“已经不符合 WCAG AA 级强制要求”。
检查 img 的 alt 是否真实有效
空字符串 alt="" 合法，但只适用于纯装饰图；图标按钮、功能型图片（如“搜索”“删除”“设置”）必须带描述性文本，不能是 alt="icon" 或 alt="button"。W3C 验证器不报错，但 axe 或 Lighthouse 会标为“missing alternative text”。
-
alt="购物车"✅ —— 明确传达功能 -
alt=""✅ —— 仅当该图无信息价值，且周围文本已说明意图 -
alt="cart-icon"❌ —— 屏幕阅读器读出来毫无意义 -
alt缺失或写成alt（无等号无值）❌ —— 浏览器可能 fallback 读取文件名，或静默跳过
验证表单控件是否具备可聚焦、可关联的 label
用 div + onclick 模拟 button，或用 input 却没配 label，是第三方代码最常埋雷的地方。这类元素无法被键盘 Tab 聚焦，也无法被屏幕阅读器识别为交互控件。
- 必须有
for/id关联，或用label包裹input——<label><input type="checkbox">接收邮件通知</label> - 禁用
placeholder替代label：它在输入后消失，对认知障碍或临时失焦用户极不友好 - 自定义下拉/开关组件若用
div实现，必须补全role="combobox"+aria-expanded+aria-controls，缺一不可
警惕 role 的滥用与残缺配套
role 不是语义化“补丁”，而是高风险操作。加了 role="button" 却没处理 Enter/Space 键响应，或写了 role="tablist" 却漏掉 aria-selected，反而比不用更糟——它向辅助技术承诺了行为，却没兑现。
立即学习“前端免费学习笔记（深入）”；
- 优先用原生语义标签：
nav、button、input[type="radio"]比div role="navigation"更可靠 - 所有非原生
role必须查 WCAG 对应的成功准则，例如role="slider"要求支持方向键、aria-valuenow、aria-valuemin/max -
role="presentation"或aria-hidden="true"若误加在父容器上，可能整块内容被屏幕阅读器跳过——要逐层确认 DOM 影响范围
用浏览器原生能力快速实测键盘流
不装插件、不跑工具，仅靠 Chrome/Firefox 就能暴露 80% 的可访问性硬伤：打开页面，按 Tab 键从头走到尾，观察焦点是否落到每个可交互元素上；按 Enter 或 Space 是否触发预期动作；焦点离开后，是否还能靠 Shift+Tab 倒退。
- 焦点“跳空”：某个按钮/链接没被 Tab 到 → 检查
tabindex="-1"是否误加，或 CSSvisibility: hidden/display: none是否隐藏了本该可聚焦的元素 - 焦点“卡死”：Tab 到某处后无法继续 → 很可能是自定义组件未实现
focusable逻辑，或tabindex值设为非 0/-1 的整数（如tabindex="99"）导致顺序错乱 - 无视觉焦点样式：
outline: none单独使用即违规；必须提供等效的box-shadow或边框高亮
第三方 HTML 片段最难缠的不是语法错误，而是“看起来能用，实际不可达”——比如一个星标组件用 div + click 实现，鼠标点得飞起，键盘用户却完全无法评分。这种缺陷不会出现在 W3C 验证结果里，也不会触发控制台报错，只能靠人工走一遍键盘流，再对照 axe 的 DOM 层级报告交叉验证。
