QBUS5010 Group Dashboard Project｜用一条用户任务串起界面验收
🧭 先固定一条能走完的任务
看板能打开、图表会动，还不足以让 accessibility 落到可检查的动作上。我会先让小组写出一条目标用户必须走完的路径，再沿着这条路观察信息在哪里断掉。路径尽量只保留一个决策目的，后面的界面修改、视频演示和报告解释都继续用它。
比如先假设用户需要从一批结果里找到值得关注的对象，那么可以把动作写成：
- 选择一个范围；
- 识别需要关注的对象；
- 打开细节确认判断；
- 清除筛选，回到全局。
这个例子不替团队决定受众或数据，它只把核心任务写成可以重跑的顺序。任务一旦固定，下一次测试只换操作条件，不换筛选范围和判断对象。这样看到的中断更容易指向具体组件。
🔎 沿同一路径换四种条件
接下来把同一条路径跑四遍。每一遍都保留原来的目的，只暂时拿掉一种常用线索或改变一种操作方式。
| 检查条件 | 任务仍需保留的证据 | 中断后优先检查 |
|---|---|---|
| 暂时拿掉颜色含义 | 状态还有文字、正负号、形状或位置 | 颜色编码与标签 |
| 不打开 hover | 关键数值、比较对象和方向仍可读 | 直接标注、文字摘要或数据表 |
| 只用键盘 | 焦点依次到达筛选器、结果摘要、替代信息和恢复动作 | 焦点顺序与键盘交互 |
| 改变筛选条件 | KPI、图表、表格和范围标签使用同一范围 | callback、数据状态与空结果 |
比如某个异常状态原本只靠红绿区分。临时改成灰阶后，旁边仍有状态文字和正负号，用户就能继续识别。再比如关键差异只藏在 hover 里，关闭 hover 后，直接标注和文字摘要应继续交付同一个比较结果。这里检查的是信息能否换一种方式被读到。
🧪 每次只换一个读取或操作条件，核心任务、筛选范围和判断对象保持不变；失败停在哪个动作，修复就落到哪个组件。
