关于 feedback-and-status
feedback-and-status 是通过多种渠道传达界面反馈的设计技能，帮助团队让不同感官需求及辅助技术用户都能感知状态变化。
主要功能
- 01通过多种渠道提供反馈
- 02避免仅用颜色表示状态
- 03及时反馈用户操作
- 04区分短暂与持续消息
- 05向屏幕阅读器播报状态变化
- 06说明任务进度
适用场景
- 01设计易访问的成功与错误状态
- 02让屏幕阅读器用户感知动态更新
- 03展示短时和长时任务的进度
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/feedback-and-status确认已加载。
详细介绍
反馈与状态设计
设计能够触达每位用户的系统反馈，无论他们能否看见屏幕、听见声音或感受到振动。不能只依赖一种感官渠道。
核心原则
切勿只通过一种感官传达状态。用户看不见、听不见或感受不到时会怎样？
多渠道规则
每条反馈都应至少通过两个渠道传达：
| 反馈类型 | 视觉 | 文本 | 声音 | 触觉 |
|---|---|---|---|---|
| 成功 | 绿色勾号 | “保存成功” | 确认音 | 短促振动 |
| 错误 | 红色高亮 | 具体错误消息 | 警示音 | 两次振动 |
| 加载中 | 转圈动画/进度条 | “正在加载……” | 无（静音） | 无 |
| 警告 | 黄色横幅 | 警告文本 | 可选提示音 | 可选振动 |
屏幕阅读器是重要的第三种渠道——所有视觉反馈都必须向辅助技术播报。
设计模式
不要只依赖颜色
- 对 8% 有色觉缺陷的男性来说，红色/绿色无法区分
- 始终结合颜色与以下元素之一：图标、文本标签、图案或位置
- 错误状态：红色 + 错误图标 + 文本说明
- 成功状态：绿色 + 勾号图标 + 文本确认
- 测试：改为灰度显示后，传达的信息是否仍然相同？
即时反馈
- 按钮按下：在 100ms 内显示视觉变化（按下状态）
- 提交表单：在 1 秒内显示加载指示器
- 完成操作：结束后 2 秒内显示成功消息
- 错误：高亮具体字段，而不只是顶部的横幅
持续与短暂反馈
- 短暂反馈（Toast/小型通知栏）：仅用于非关键确认信息。至少显示 5 秒，并提供查看错过消息的方式。
- 持续反馈（行内显示）：用于错误、警告以及用户需要处理的任何信息。错误消息绝不能自动消失。
- 屏幕阅读器用户可能会错过短暂消息——对非紧急更新使用 aria-live="polite"，对关键警报使用 aria-live="assertive"。
进度传达
- 可确定的进度（时长已知）：显示百分比或步骤数
- 不确定的进度（时长未知）：显示转圈动画，并配上“正在加载你的结果……”之类的文本
- 耗时较长的操作（超过 10 秒）：添加预计剩余时间
- 耗时极长的操作：允许在后台处理，并在完成时发送通知
无视觉条件下的状态传达
- 所有状态变化都必须向屏幕阅读器播报
- 使用 aria-live 区域播报动态内容更新
- 不要只依赖视觉位置来传达状态 （例如，看板中的项目移动后，需要通过文本播报）
- 错误消息必须通过程序与对应字段关联（aria-describedby）
评估问题
- 是否有任何状态只通过颜色来指示？
- 屏幕阅读器用户能否感知每次状态变化？
- 错误消息是否会一直显示，直到问题解决？
- 短暂消息是否显示足够长的时间，以便用户读完？
- 用户的每项操作是否都会产生可感知的反馈？
评论
支持 Markdown