UI 无障碍设计要让用户在看不清颜色、放大文字、只用键盘或借助读屏软件时，仍能理解内容并完成关键操作。设计时应同时处理文字与背景对比、非颜色状态提示、可辨认的焦点、明确的表单标签，以及出错后的恢复方式。只换一套配色或加几个 alt，无法解决按钮到不了、错误找不到、输入被清空这些任务障碍。
可以先用墨刀设计整理控件的默认、聚焦、错误和成功状态，在设计稿旁标明阅读顺序与行为，再交给研发实现。本文以“申请加入团队”这一常见表单为例，从颜色、键盘到反馈逐项说明，帮助你把要求落在具体页面上。
从完整任务开始，而不是只检查某一块颜色
设想用户要填写姓名、工作邮箱、申请理由，提交后等待管理员审核。一次完整操作包括看懂要求、进入字段、填写信息、发现错误、修正并确认提交。任何一步只支持一种感知或操作方式，都可能让用户中途停下。
例如，邮箱输入框只有浅灰色占位文字，输入后标签消失；校验失败仅把边框变红；提交后页面顶部闪一下“成功”，随后自动跳走。视觉正常、全程用鼠标的熟练用户也许能猜到发生了什么，换成放大页面或用键盘操作，问题就会明显暴露。
无障碍并不等于把界面做得朴素。清晰的分组、稳定的名称和可恢复的操作，同样能支持精致的视觉。你需要减少的是理解和操作上的阻碍，而不是删掉产品的视觉风格。
颜色：正文能读清，状态也不能只靠红和绿
正文、标签、说明和占位文字都要检查与实际背景的对比。以 WCAG 2.2 AA 的文字要求为参考，普通文字通常至少达到 4.5∶1；大字通常至少 3∶1。这里的大字通常指至少 18pt 的常规字，或至少 14pt 的粗体字；按常用 CSS 单位换算约为 24px 与 18.67px，不能凭“看上去挺大”套用较低阈值。该标准对标志、不可用控件等有特定例外，详见W3C 文字对比说明。
在团队申请表单里，辅助说明“请使用工作邮箱”也属于用户需要阅读的信息，不应为了弱化层级而变得难以辨认。可先通过字号、间距和布局建立主次，再选择有足够对比的次级文字色。背景换成浅紫色卡片以后，要重新测这组前景与背景，不能沿用白底时的结果。
错误状态采用“图标＋明确文字＋适当颜色”，例如“请输入包含 @ 的完整邮箱地址”。成功状态写“申请已提交，等待管理员审核”。红色边框和绿色对勾可以加强识别，但即使移除颜色，用户也应该知道当前状态和下一步。
输入框边界、复选框等用于识别控件的必要视觉信息，还涉及非文本对比要求；不要把所有图形一律套成文字的 4.5∶1。设计稿中分别记录文字色、背景、关键边界和状态，研发更容易按正确对象核对。
| 设计对象 | 容易出现的问题 | 本例可采用的做法 |
|---|---|---|
| 工作邮箱标签 | 只用占位文字，输入后不知道字段是什么 | 输入框上方保留“工作邮箱”标签 |
| 必填提示 | 只放红色星号，没有解释 | 明确写“必填”或在表单前解释标记 |
| 错误信息 | 边框变红，却没有可读原因 | 字段旁写原因与修改办法，并与字段关联 |
| 提交进度 | 按钮变淡，没有文字说明 | 显示“正在提交”，防重复提交但保留当前输入 |
| 成功状态 | 只有短暂绿色气泡 | 显示可回读的结果、审核状态和后续入口 |
键盘：用户要知道自己在哪里，也要能走出去
从表单入口开始，用 Tab 依次移动，应该能到达必要字段与操作；Shift＋Tab 能往回走。进入控件后，遵循相应平台与控件的常用操作方式，例如原生按钮、单选组、下拉框各自的键盘行为，不需要让用户学习一套只适用于这张页面的快捷键。
W3C 的键盘可操作要求关注功能能否通过键盘完成。设计阶段应标出顺序和状态，运行阶段还要确认真实实现能够操作；画一圈焦点线并不等于控件已经支持键盘。
焦点顺序优先跟随阅读和任务顺序：姓名 → 工作邮箱 → 申请理由 → 提交。页面中有帮助链接时，让它出现在合理的位置；不要为了视觉排版，把焦点顺序排成左侧第一项、右侧底部按钮、再回到中间字段。隐藏或不可用内容也不应形成一串让人迷失的停靠点。
焦点样式要清楚区别于悬停与选中。蓝色外框可以表示当前焦点，复选标记表示选中，二者不能混为同一件事。固定导航和底部操作栏还可能遮住正在操作的控件；WCAG 2.2 AA 的焦点不被完全遮挡是最低要求，实际设计宜尽量让控件和焦点提示完整可见。
若“查看申请须知”打开模态窗口，交互说明要写清打开后焦点落在哪里、窗口内部怎样操作、如何关闭以及关闭后回到哪里。不能让焦点落在被遮挡的背景内容上，也不能让用户进入弹窗后找不到退出方式。这里可参考W3C 模态对话框模式，采用成熟实现，不靠设计稿中的一张遮罩代替行为定义。
表单：标签说明用途，错误帮助用户完成修正
标签回答“这是什么字段”，帮助文字回答“怎样填写”，错误信息回答“哪里不对、怎样改”。三者分工清楚，用户才不需要反复猜。例如“工作邮箱”作为标签，“用于接收审核结果”说明用途，“邮箱地址缺少 @，请检查后再提交”处理具体错误。
可见标签需要在代码中与输入控件正确关联，不能只把一段文字摆在旁边。实现时优先使用适合的原生表单元素；如果必须使用自定义控件，就要补齐名称、角色、状态和操作。W3C 表单标签教程解释了标签关联与可访问名称的关系。
本例可以在用户离开已经填写的邮箱字段时检查格式，提交时再统一检查。不要在用户刚输入第一个字符时就不断宣布错误；也不要只禁用提交按钮，却不解释还缺什么。校验时机要兼顾错误发现和不中断输入，两者不是靠“所有字段实时变红”解决的。
提交发现多个错误时，在表单顶部提供简短汇总，如“有 2 处需要修改：工作邮箱、申请理由”，每项可定位到对应字段。字段旁保留具体错误；修正邮箱时不要清空已经写好的申请理由。错误汇总和就地提示服务不同阅读路径，不能只保留一个“提交失败”的总提示。
| 阶段 | 用户看到什么 | 设计与实现说明 |
|---|---|---|
| 初始 | 永久可见的字段标签、必填说明 | 帮助文字与控件建立关联，输入顺序与阅读顺序一致 |
| 格式错误 | 邮箱旁显示具体原因，顶部列出错误位置 | 程序能识别无效状态；用户可定位并修正，不清空其他字段 |
| 正在提交 | 按钮文字变为“正在提交” | 避免重复请求，必要时通过状态信息告知进度，不无故移动焦点 |
| 网络失败 | “暂时未能提交，请重试”，输入仍在 | 提供重试；不要把网络问题说成用户填写错误 |
| 已提交 | “申请已提交，等待管理员审核”及查看入口 | 区分收到申请与审核通过，结果可以再次读取 |
异步完成或失败时，要让辅助技术能够获得相应状态，而不是只改变屏幕上一块颜色。具体是用状态区域、错误提示还是移动焦点，应依据变化的紧急程度和页面结构决定；不要把所有轻微更新都做成强打断。相关实现可以参考W3C 表单通知教程。
放大与触控：别让清楚的文字被固定布局截掉
把浏览器放大后，检查字段标签、帮助文字、错误提示和底部按钮是否仍然完整。最常见的问题不是文字不够大，而是容器高度写死、两列挤在一起、按钮文字溢出，或者底部固定栏盖住最后一个字段。
对普通表单，窄屏时改成单列通常比让用户横向拖动整张页面更直接。W3C 的重排要求针对特定视口与缩放条件，并对确实需要二维布局的内容设有例外；不要将地图或大型数据表的例外扩展到普通表单。实际检查时，应覆盖浏览器缩放和常见手机宽度。
触控目标也不能只看图标本身。一个 16 像素的关闭图标可以有更大的点击区域，但区域必须真实可点击，不能仅在设计稿上画透明框。WCAG 2.2 AA 的目标尺寸最低要求通常为 24×24 CSS 像素，同时存在间距、等效操作、行内目标等例外。这是最低要求，并不意味着所有主要按钮都应该压到这个尺寸。
团队申请表单的提交按钮、帮助入口和关闭操作，可以根据使用场景留出更充分的尺寸和间距。相邻的“取消”与“提交”不要挤得难以区分，也不应为了放下两个按钮而缩小到难以操作。
设计师交付什么，研发与测试检查什么
设计交付不应只有默认界面。把本例整理为初始、焦点、校验失败、提交中、网络失败和已提交几种状态，并在同一份文件中标明字段标签、错误文字、焦点顺序和成功后的去向。状态复用组件时，确保真实页面中的背景、密度和文字长度仍然适用。
对于读屏，图片 alt、标题层级、控件名称与状态、字段关联等最终依赖实现。设计师可以明确意图并审查页面，但不能根据截图宣布“已经通过 WCAG”。自动工具能发现一部分问题，键盘操作、读屏流程与真实用户的理解仍需要人工检查。
- 只用键盘完成一次申请。从进入页面到查看提交结果，不使用鼠标；记录到不了的控件、消失的焦点和无法退出的位置。
- 主动制造一次填写错误。邮箱漏掉 @、理由为空，确认错误位置清楚、能修正、其他内容仍保留。
- 放大后重复关键操作。检查提示不被截断，按钮不被固定栏遮挡，普通表单不迫使用户来回横向移动。
- 在目标读屏环境检查语义。确认字段名称、必填与错误状态、提交结果都能被理解；记录所用浏览器和辅助技术，避免把单次通过扩大成全平台结论。
- 邀请有相关需求的用户完成任务。观察他在哪一步需要额外帮助，把问题落到控件、文案或行为上，而不是只问“看起来是否友好”。
若页面还包含统计图，颜色之外的识别、摘要和数据表需要单独设计，可以继续参考图表无障碍设计。先把一条完整任务做通，再把可复用的状态和说明沉淀为组件规范，比在上线前临时给所有页面加一轮颜色检查更有效。
