aria-current必须设为具体语义值，最常用的是"page"（当前页面）、"step"（流程步骤）、"location"（地理定位），禁用"true"等无效值；需与URL严格同步、仅用于导航链接，并通过[aria-current="page"]等属性选择器联动CSS样式。
aria-current 应该设为什么值
它不是布尔开关，而是语义化状态标记，必须设为具体含义的字符串值。最常用的是 page（当前页面）、step（多步流程中的当前步）、location（当前 URL 对应的导航项），而 true 或 "true" 是无效值，屏幕阅读器会忽略。
实际选中逻辑由你控制：比如用 JavaScript 切换 class 的同时，也要同步设置/移除 aria-current="page"；服务端渲染时，则在模板里根据当前路由动态输出该属性。
-
aria-current="page"适用于顶部主导航中“首页”“关于”这类页面级入口 -
aria-current="step"更适合向导式流程（如注册三步走）的中间环节 - 不要对非导航容器（比如 div 块、按钮组）滥用
aria-current，它只对nav内的链接或菜单项有意义
和 CSS 样式怎么联动
不能只靠 class 来驱动高亮样式，得同时匹配 aria-current 属性——因为用户可能通过键盘聚焦或屏幕阅读器跳转，此时 DOM 状态已变但 class 没更新，样式就脱节了。
推荐写法是用属性选择器直接绑定样式，例如：
立即学习“前端免费学习笔记（深入）”；
nav a[aria-current="page"] {
font-weight: bold;
color: #0066cc;
}
这样无论 class 是否存在，只要属性在，样式就生效。如果还要兼容旧版 JS 控制逻辑，记得在 JS 中也同步操作该属性，而不是只改 class。
- 避免只写
.active类而不设aria-current，这对辅助技术不可见 - 不要用
[aria-current]这种宽泛选择器，可能误命中其他组件的aria-current - 若使用 CSS-in-JS 或框架（如 React），确保属性被真实渲染到 DOM 上，而不是仅存在于虚拟节点中
React 里容易漏掉的点
JSX 中写 aria-current={current ? "page" : undefined} 是常见写法，但要注意：传 null 或空字符串会导致属性被渲染为 aria-current=""，这是无效值；传 undefined 才能彻底移除该属性。
另外，Link 组件（如 React Router 的 NavLink）默认支持 aria-current，但需显式启用：
<NavLink to="/about" aria-current="page">About</NavLink>
否则它只加 class，不加属性。
-
aria-current不是可交互属性，别给它绑onClick或onKeyDown - 服务端渲染（SSR）场景下，确保初始 HTML 就包含正确的
aria-current，否则首屏对屏幕阅读器不友好 - 测试时用浏览器的无障碍检查工具（如 Chrome DevTools 的 Lighthouse → Accessibility）验证是否真实暴露给辅助技术
为什么有些菜单项没读出“当前页”提示
常见原因不是代码没写，而是语义结构不对：如果导航项没包在 nav 元素里，或用了 div + role="navigation" 却漏了 aria-label，屏幕阅读器可能无法识别这是导航上下文，aria-current 就失去意义。
另一个隐蔽问题是元素类型：必须是可聚焦的元素（如 a、button），如果用 span 加 click 事件，即使有 aria-current，也无法被键盘用户访问到，自然也不会播报。
- 检查父级是否为
<nav aria-label="主导航">，label 文本要具体，不能留空 - 确认当前项是原生可聚焦元素，否则要加
tabIndex="0"和role="link"（但优先改用a） - 某些旧版 JAWS 或 NVDA 版本对
aria-current支持不一致，建议测试主流组合（Chrome + NVDA / Safari + VoiceOver）
aria-current 往往被当成“锦上添花”，但它一旦缺失或错用，对依赖语音导航的用户就是信息断层。真正麻烦的不是加这一行属性，而是让它的值、位置、可访问性三者始终对齐。 
