必须主动适配prefers-reduced-motion：在@media (prefers-reduced-motion: reduce)中将transition-duration设为0.01s（视觉禁用但保布局），禁用transition: none，覆盖所有含transition的选择器，并在JS层同步监听matchMedia变化。
transition 动画会干扰“减少动画”系统偏好怎么办
操作系统和浏览器支持 prefers-reduced-motion 媒体查询，用户开启“减少动画”后，你的 transition 仍会照常执行，可能引发眩晕或注意力分散——这不是 bug，是默认行为。
必须主动适配：在根元素或动画容器上加一层判断，把过渡时长降为 0.01s（视觉上等同于禁用，又不破坏布局逻辑）：
@media (prefers-reduced-motion: reduce) {
* {
transition-duration: 0.01s !important;
}
}- 不要用
transition: none—— 它会中断属性变化的渲染流程，导致状态跳变甚至布局抖动 - 避免只对部分元素加媒体查询，应覆盖所有含
transition的选择器，或统一用通配符 +!important保证优先级 - 若使用 CSS-in-JS 或框架（如 Vue 的
:style），需在 JS 层监听window.matchMedia变化，动态切换类名而非硬编码样式
为什么 hover 动画在触摸设备上失效且影响可访问性
:hover 在无指针设备（如手机、平板）上无意义，且屏幕阅读器用户无法触发它。把关键交互逻辑（比如展开菜单、显示提示）只绑在 :hover 上，等于直接屏蔽了大量用户。
正确做法是分离触发机制：
立即学习“前端免费学习笔记（深入）”；
- 用
:focus-within或显式.is-open类替代纯:hover控制的动画 - 按钮、开关类组件必须支持键盘
Tab+Enter/Space操作，并同步触发动画类 - 如果保留
:hover仅作增强，确保对应功能在无 hover 时仍完整可用（例如悬停显示 tooltip，但焦点态也必须显示）
transition-delay 导致焦点顺序错乱怎么排查
当给一个按钮加了 transition-delay: 0.2s，再配合 :focus 改变边框颜色，用户按 Tab 切入时，视觉反馈会滞后——这违反 WCAG 2.4.7（焦点可见性）要求。
根本问题是延迟打断了“焦点获得即反馈”的即时性：
- 所有与焦点、键盘导航强相关的动画，禁止使用
transition-delay - 若需入场动画（如模态框淡入），改用
animation+animation-fill-mode: forwards，并用prefers-reduced-motion控制其开关 - 检查是否误将
transition写在伪类里（如a:focus { transition: … }），它必须始终声明在基础状态（a）上
opacity + transform 过渡为何在读屏软件中丢失语义
用 opacity: 0 + visibility: hidden 隐藏元素时，即使加了 transition，屏幕阅读器仍可能在动画中途就移除该节点的可访问树路径，导致语音朗读中断或跳过内容。
真正安全的隐藏方式是结合 ARIA 状态控制：
- 初始状态用
aria-hidden="true"+opacity: 0+pointer-events: none - 动画开始前，先移除
aria-hidden；动画结束帧再设回（可用transitionend事件监听） - 避免仅靠视觉隐藏（如
left: -9999px），它不改变可访问性状态，读屏器仍会朗读
过渡动画的无障碍陷阱不在“动得不够美”，而在“动得不合时宜”。最常被忽略的是：动画本身不是功能，它是功能的副产品；一旦它开始遮蔽操作意图、延迟反馈、或绕过输入方式，就该被约束，而不是被优化。
