禁用 html 手风琴某一项需同时满足：为触发按钮添加 aria-disabled="true" 和 tabindex="-1"，css 设置 pointer-events: none 并移除交互样式，js 展开逻辑中提前检查 aria-disabled 并 return。
如何让 HTML 手风琴中的某一项完全禁用（不响应点击、不展开）
直接禁用手风琴某一项，不是靠 disabled 属性（它对 <div> 或 <code><button></button> 无效），而是靠移除交互能力 + 视觉降级 + 语义隔离。核心是：阻止事件、跳过逻辑、明确状态。
- 给禁用项的触发按钮（如
<button></button>）添加aria-disabled="true"和tabindex="-1"，确保屏幕阅读器识别且键盘无法聚焦 - 用 CSS 移除 hover/focus 样式，并加
pointer-events: none阻断鼠标事件（注意：这会同时禁用所有子元素交互，需确保内部无独立可操作控件） - 在 JavaScript 展开逻辑中，提前判断
button.hasAttribute('aria-disabled') && button.getAttribute('aria-disabled') === 'true'，直接return - 不要只靠 CSS 禁用 —— 用户可能绕过样式用键盘或脚本触发；也不要只加
disabled到<button></button>后忽略 ARIA，否则无障碍支持断裂
为什么 disabled 对手风琴 <button></button> 不够用
disabled 在表单控件（如 <input>、<select></select>）上生效，但手风琴常用语义化 <button type="button"></button> —— 它虽支持 disabled，但会导致两个实际问题：
- 视觉样式不可控：浏览器默认禁用态灰度+透明，难以与设计稿对齐，且无法通过
:disabled伪类精确覆盖（尤其在 flex/grid 布局中） - 焦点管理失效：禁用的
<button></button>仍可能被Tab键跳过但未明确告知用户“此处不可用”，违反 WCAG 2.1 的 2.4.3（Focus Order）和 4.1.2（Name, Role, Value） - JS 逻辑易遗漏：若展开函数只检查
click事件，没过滤disabled状态，用户用Enter键仍可能意外触发（因为disabled按钮不触发click，但部分旧版 Safari 或自定义事件绑定可能绕过）
React/Vue 中禁用手风琴项的常见翻车点
框架组件库（如 MUI、Ant Design）的手风琴常暴露 disabled prop，但底层实现未必完整。真实项目里容易踩的坑：
- 传
disabled={true}给组件，但组件只做了pointer-events: none，没加aria-disabled—— 屏幕阅读器读作“可点击按钮”，用户困惑 - 禁用项内容区（
panel）仍保留在 DOM 中且未设aria-hidden="true"，当该项被“逻辑禁用”但未隐藏时，辅助技术可能错误朗读其内容 - 使用
v-if（Vue）或条件渲染（React）彻底移除禁用项 —— 看似干净，但破坏了手风琴的 DOM 结构稳定性，可能导致动画错乱或 SSR 与客户端不一致 - 在受控模式下，禁用项的
expanded状态仍参与 state 计算（如expandedKeys数组），导致其他项展开逻辑异常
禁用后还要检查的三个细节
禁用不是加个属性就完事。上线前必须验证：
- 键盘导航：
Tab键是否跳过该按钮？Shift+Tab是否不会反向聚焦到它？ - 屏幕阅读器行为：用 NVDA 或 VoiceOver 测试，确认朗读内容含“禁用”或“不可用”（依赖
aria-disabled="true"，而非仅靠 CSS） - 触屏设备：长按是否触发菜单或误激活？
pointer-events: none能拦截，但若父容器有ontouchstart监听，仍可能捕获事件 —— 需同步在 JS 中加event.stopPropagation()判断
