应使用 aria-current="step" 标记当前答题卡，因其是浏览器原生支持的语义化方式，屏幕阅读器可直接识别“当前步骤”，配合 [aria-current="step"] CSS 选择器与 data-status 区分业务状态，确保无障碍、多设备、服务端渲染下状态准确一致。
怎么用 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 标准。
必须叠加至少两种差异信号，比如颜色 + 图标 + 文字提示：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
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 上用键盘、在无障碍模式下靠语音命令切换——只有数据层统一，高亮才不会漏掉任何一种路径。
