许多开发者已经了解到，原生 HTML 的 aria-expanded？什么时候添加反而会引发问题？本文将把这一层逻辑彻底讲清楚，帮助你在实际开发中做出最佳决策，提升页面可访问性与搜索引擎友好度。
原生 aria-expanded 属性可以进一步提升兼容性与明确性——尤其在旧版读屏器或非标准实现中，这一做法能有效弥补原生行为的不足。
为什么 details 标签默认就“可访问”
浏览器对 role="group"）、键盘支持（Enter/Space 切换）以及状态反馈。
- 用户用键盘 Tab 进入时，焦点落在
- 屏幕阅读器会自动读出当前状态（例如“帮助信息，已折叠”）
- 不需要手动设置
aria-expanded——浏览器内部已经处理好了这个逻辑
什么情况下需要显式加 aria-expanded
只有当我们脱离原生
- 用
div+ JavaScript 手动模拟折叠面板，但视觉上模仿 - 动态替换
- 组件库封装中需要统一暴露状态供外部逻辑读取（如测试或状态同步）
这时，应该在触发元素（如按钮或自定义 summary）上添加：aria-expanded="true" 或 aria-expanded="false"，并且必须与实际 DOM 状态严格同步，避免出现不一致。
正确写法：不破坏原生语义
如果坚持使用原生 aria-expanded——这会造成冗余甚至冲突。浏览器可能忽略或覆盖该属性，反而干扰读屏体验。
- ✅ 正确：保持原生结构，仅通过 CSS 定制外观
- ❌ 错误：
常见问题 - ⚠️ 可接受（仅限降级场景）：在 JavaScript 控制的自定义折叠组件中，用
aria-expanded替代
配套建议：让提示更清晰
即使不用 aria-expanded，也可以通过一些微小优化来强化可访问性：
- 在
aria-hidden="true"隐藏图标对读屏器的干扰 - 为
aria-labelledby指向页面中已有标题，增强上下文关联 - 如果内容区包含重要操作，确保展开后首个可聚焦元素获得焦点（用
focus()）
