表单控件必须有明确且持久的标签，使用绑定或嵌套；错误提示需具体、可定位、持续可见并正确关联；链接按钮文字须自解释；缩写首次出现时须用展开。
表单控件必须有明确且持久的标签
WCAG要求所有用户输入控件（如 、、）都具备可编程关联的标签，不能仅靠视觉位置或占位符（placeholder）暗示含义。屏幕阅读器不会读取 placeholder 作为标签，且它在用户输入后即消失，破坏上下文连续性。
正确做法是始终使用 元素并绑定 for 属性与控件 id，或把控件嵌套在 内：
<label for="email">电子邮箱地址</label> <input type="email" id="email" name="email"><label> 订单备注 <textarea name="notes"></textarea></label>
- 避免仅用
aria-label或aria-labelledby替代原生—— 它们不触发浏览器默认的点击聚焦行为，也不被所有辅助技术一致支持 - 禁用空
：这会导致屏幕阅读器静默或报“无标签” - 多个控件共用同一语义意图时（如性别单选组），用
+包裹，而非重复写相同
错误提示必须具体、可定位、持续可见
WCAG 3.3.1（错误识别）和 3.3.3（错误建议）要求：表单提交失败时，错误信息不能只靠颜色（如红字）传达，也不能仅出现在顶部全局提示栏里——用户无法快速定位到对应字段。
关键实操点：
- 每个出错字段旁紧邻放置错误消息，用
aria-invalid="true"标记该字段，并用aria-describedby指向错误元素id - 错误文本需说明“哪里错了”和“怎么改”，例如“手机号格式不正确（应为11位数字）”，而不是“请输入有效值”
- 不要依赖
title属性显示错误：它不被所有屏幕阅读器朗读，且悬停才出现，不符合键盘操作需求 - 校验应在用户离开字段（
blur）或提交时触发，避免输入中频繁中断（影响认知障碍用户）
链接和按钮文字必须自解释，不依赖上下文
WCAG 2.4.4（链接目的）规定：单独看一个链接或按钮文本，用户应能准确预判其结果。常见反例是“点击这里”“查看详情”“更多信息”——它们对屏幕阅读器用户毫无意义，尤其当多个同类链接并列时。
改进方式：
- 用动词+宾语结构，如
@#@#@#@#@#@#@#@#@#@0 - 若视觉设计限制只能用简短文字，用
aria-label补充语义，但确保其内容不重复视觉文本（否则会被朗读两次） - 图标按钮必须配不可见但可读的文本，例如带搜索图标的按钮：
- 避免纯图像链接（
@#@#@#@#@#@#@#@#@#@1）未设alt：此时alt就是链接目的，必须描述动作而非图像内容
缩写、首字母缩略词必须首次出现时展开
WCAG 3.1.4（缩写）要求：所有缩写（如 WCAG、ARIA、PDF）在文档中第一次出现时，必须提供全称。这对认知障碍用户、非母语者和屏幕阅读器用户尤为重要——后者可能按字母逐个朗读缩写，造成理解断裂。
标准写法是使用 元素并设置 title 属性：
<p>本系统遵循<abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1 AA级标准。</p>
-
title值必须是完整、准确、无歧义的官方名称，不能是解释性描述（如“一套网页无障碍规范”） - 不要滥用
：常见缩写如 “HTML”、“URL”、“PDF” 可视项目受众决定是否展开；但专业术语如 “ATAG”、“UAAG” 必须展开 - JavaScript 动态插入的缩写内容，也要同步注入
结构，否则初始 DOM 中缺失，屏幕阅读器无法捕获
复杂点往往不在“有没有做”，而在于“是否在所有交互路径下保持一致”：比如模态框内动态加载的表单、SPA 路由切换后新挂载的按钮、或富文本编辑器插入的链接——这些地方最容易漏掉标签、错误提示或缩写处理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
