ux-baseline-check

UX 基线检查

角色与范围

ADS 状态和组件契约负责人。根据请求的行为和产品契约选择状态，而不是穷举所有能想到的状态。微小的文案或间距调整，只需检查其影响到的行为，不要凭空添加加载、表单、权限或额外页面。使用 ADS 任务预算；这份清单属于同一轮工作／评审，而不是单独的流程。

组件契约先于复制

在引入新的可复用组件或复制组件之前，应从现有代码／类型／故事中还原或定义其契约。如果这些内容已经能回答以下问题，就不需要另写文档：

• 组成结构和内容插槽
• 属性和有意义的变体
• 适用的数据、交互、验证、加载、错误和成功状态
• 目标断点下的响应式行为
• 键盘、指针、触控和语义行为
• 它复用的现有组件和设计令牌

每个实例都应遵循相同的契约。没有契约的组件尚未准备好推广使用。

状态清单

任何页面或组件在标记为“完成”之前，都要确认每个适用状态均已实现：

1. 数据状态

• 空状态 — 尚无数据。提供有帮助的说明和明确的行动号召，而不是空白页面
• 加载中 — 保持内容布局稳定，并明确显示确实尚在处理的工作；不要为了显示加载指示器而延迟缓存数据或快速返回的数据
• 已加载 — 显然，这是理想路径
• 错误 — API 失败、网络问题。提供对用户友好的说明和重试操作
• 部分加载 — 部分数据已加载，部分加载失败。不要隐藏已正常加载的内容
• 长内容 — 有 200 项时会怎样？名称长达 2000 个字符时会怎样？请进行测试

2. 交互状态

• 悬停 — 提供适当的指针反馈；不要让触控或键盘操作依赖悬停
• 焦点 — 键盘导航有效，焦点环清晰可见
• 激活／按下 — 按钮点击时应有视觉反馈
• 禁用 — 使用原生语义，并让状态清晰可辨；必要时在附近用持久显示的文案说明原因，不要依赖必须聚焦禁用控件才能查看的工具提示
• 选中 — 多选项、当前标签页和启用的筛选条件都应有清晰的视觉区分

3. 表单状态

• 验证 — 及时提供字段级指引，并根据任务选择合适的失焦／提交时机；不要过早拒绝尚未完成的输入
• 必填字段 — 明确标记
• 成功反馈 — 让用户知道操作已成功（提示消息、行内提示或重定向）
• 破坏性操作的恢复 — 对可撤销的操作优先提供撤销；对确实不可逆或影响重大的操作进行确认，同时保留产品的权限模型
• 自动填充 — 浏览器自动填充时不会破坏布局

4. 响应式

使用受支持的目标断点；以下宽度仅为示例，并不要求必须提供四种截图：

• 移动端（375px） — 不仅可见，而且可用。触控目标尺寸 ≥48px，彼此间距 ≥8px
• 平板（768px） — 布局应适配，而不只是缩小
• 桌面端（1280px） — 主要目标，呈现效果经过精心设计
• 宽屏（1800px+） — 内容不会被拉伸得过分。设置最大宽度或居中显示

5. 无障碍

• 键盘导航 — 可用 Tab 键访问所有交互元素
• 屏幕阅读器 — 使用语义化 HTML，为图标添加 aria-label，为图像添加替代文本
• 颜色对比度 — 根据适用的文本／控件要求，测量最终合成颜色；不要以为不透明度百分比就能证明对比度达标
• 不只用颜色表示状态 — 不要只依赖红色／绿色表示状态

6. 边缘情况

• 首次使用 — 通过引导流程或空状态为用户提供指引
• 权限被拒 — 让用户了解无法访问的原因，而不是看到损坏的页面
• 数据过时 — 数据可能过时时，显示时间戳或刷新指示器
• 并发编辑 — 两个人同时编辑同一内容时会怎样？

相邻操作一致性

对于已更改的只读、禁用、离线、权限受限或具有破坏性的状态，请检查受影响断点上的所有相邻主要操作、次要操作、工具栏操作和内联操作。标签、强调方式、启用状态、原生语义和辅助文本必须与状态一致。发现矛盾时，请移除、禁用、重新标注或说明，同时保留未受影响状态下仍有效的操作。修复后再次验证；只修复指定控件是不够的。

在 ADS 检查中的应用

在实现前确定适用的状态，并在给出设计结论前逐一验证。即使只是小幅表单变更，也仍需进行相关的表单和无障碍检查；静态页面则无需臆造异步状态。仍缺失的必需状态应保持未解决，并阻止宣称功能已完成。请将无法获取的证据或有意推迟的产品事项单独记录，而不是标记为通过。对于有实际意义的交互变更，请使用真实浏览器验证；如适用，还应验证目标移动端/WebKit 环境。仅凭源代码字符串和屏幕截图无法证明状态转换。