HTML答题卡导航高亮与状态区分详解

本文深入解析了HTML答题卡导航中高亮与状态区分的最佳实践，强调以语义化、无障碍和跨设备一致性为核心：通过标准属性 `aria-current="step"` 精准标识当前题目，让屏幕阅读器自然播报“当前步骤”，并结合 `data-status` 清晰分离业务状态（已答/未答），避免仅依赖视觉样式导致的可访问性缺陷；同时指出仅用 `:focus` 或 `:hover` 实现高亮的本质错误，阐明状态必须由数据驱动而非交互伪类，并给出React中防闪动、保复用的同步方案，确保在服务端渲染、键盘导航、触控操作及语音辅助等全场景下状态准确、表现稳定、符合WCAG 2.1 AA标准。

怎么用 aria-current 标记当前答题卡

浏览器原生支持的语义化方式，比 class 切换更可靠，屏幕阅读器能直接识别「这是当前页」。aria-current 是专为这类导航高亮设计的属性，不是 hack，也不依赖 JS 状态同步。

常见错误是写成 aria-current="true" 或 aria-current="active" —— 实际只接受特定值："page"（最常用）、"step"、"location" 等。答题卡属于步骤型导航，用 "step" 更准确：

<nav aria-label="答题进度">
  <button aria-current="step">第1题</button>
  <button>第2题</button>
  <button>第3题</button>
</nav>

• aria-current="step" 触发系统级高亮提示（如 VoiceOver 会读作“第1题，当前步骤”）
• 配合 CSS 用 [aria-current="step"] 选择器控制样式，比维护 .active 类更解耦
• 服务端渲染或静态页面也能直接输出正确状态，不依赖 JS 初始化

CSS 怎么安全地高亮已答/未答题卡

仅靠视觉颜色区分「已答」「未答」「当前」三态容易出错：色盲用户难分辨，对比度不足通不过 WCAG 2.1 AA 标准。

必须叠加至少两种差异信号，比如颜色 + 图标 + 文字提示：

button[aria-current="step"] {
  background: #007bff;
  color: white;
}
button[data-status="answered"]::before {
  content: "✓";
}
button[data-status="unanswered"]::after {
  content: "○";
}

• 用 data-status 区分业务状态（"answered"/"unanswered"），和 aria-current 的语义职责分开
• 避免仅用 opacity 或浅灰文字表示「未答」—— 对比度常低于 4.5:1
• 图标要用 ::before/::after 伪元素，不塞进 HTML，否则屏幕阅读器可能误读

React 里怎么同步更新答题卡状态而不闪动

关键在避免「先清空所有状态再重设」，否则 DOM 重绘会导致高亮跳变。要精确 diff 当前题号与已答列表。

• 不要每次点击都重生成整个 button 数组，用 key={questionId} 保持节点复用
• 判断逻辑写在 render 内，而非提前算好 class 字符串： {isCurrent ? 'current' : status === 'answered' ? 'answered' : 'unanswered'}
• 如果使用 useReducer 管理答题状态，确保 action.type === 'ANSWER_QUESTION' 时只更新对应题目的 status 字段，不重置其他字段

为什么不能只靠 :focus 或 :hover 做高亮

:focus 只反映键盘焦点，:hover 只响应鼠标悬停，两者都不代表「当前题」或「已作答」的真实业务状态。

典型翻车场景：

• 用户用 Tab 键切换到第5题按钮，:focus 生效，但实际还在第2题作答中
• 鼠标移开后高亮消失，用户无法回顾自己答到哪一题
• 移动端无 hover，纯靠点击触发，:hover 样式完全失效

业务状态必须由数据驱动，CSS 只负责呈现，别把交互反馈和状态标识混为一谈。

最麻烦的是跨设备一致性：同一套答题卡，在 iPad 上用触控、在 PC 上用键盘、在无障碍模式下靠语音命令切换——只有数据层统一，高亮才不会漏掉任何一种路径。

今天关于《HTML答题卡导航高亮与状态区分详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！