屏幕阅读器主要识别影响可访问性树和焦点流的CSS样式，如display:none会彻底移除元素，而opacity:0或绝对定位仍保留在可访问性树中；需配合ARIA属性与语义HTML协同工作。
screen reader能识别哪些CSS样式
绝大多数屏幕阅读器（如NVDA、VoiceOver）不读取纯视觉样式，只关注语义结构和可访问性属性。真正影响读屏体验的不是color或font-size，而是那些隐藏/显示内容、改变语义或破坏焦点流的CSS。
-
display: none和visibility: hidden会让元素彻底从辅助技术树中消失——即使它有aria-label也没用 -
opacity: 0或position: absolute; left: -9999px仍保留在可访问性树中，屏幕阅读器能读，但键盘焦点可能无法到达（需额外加tabindex="0"） -
clip-path、transform: scale(0)等视觉隐藏方式，多数读屏器仍会暴露内容，属于“伪隐藏”，慎用于敏感信息
用CSS控制aria-live区域的播报时机
动态更新内容（如搜索建议、表单错误）要让屏幕阅读器及时播报，不能只靠aria-live属性，CSS状态变化也得配合。
- 确保
aria-live容器始终存在于DOM中，不要用display: none切换显隐；推荐用opacity+pointer-events: none+height: 0组合实现“视觉隐藏但可访问” - 当JS把新文本注入
aria-live区域后，CSS里别加过渡动画（如transition: opacity 0.3s），否则NVDA可能在动画中途就停止播报 - 若需延迟播报（比如防抖错误提示），用
aria-live="polite"+ JS控制文本插入时机，而非靠CSS延时显示
focus-visible和键盘导航的CSS陷阱
用:focus统一处理鼠标点击和键盘聚焦，会导致鼠标用户看到多余焦点框；但盲目上:focus-visible又可能在旧浏览器或某些OS设置下完全不生效。
- Chrome/Firefox支持
:focus-visible，Safari直到v15.4才支持，iOS VoiceOver下该伪类行为不稳定——线上项目建议用@supports selector(:focus-visible)渐进增强 - 别写
a:focus { outline: none }这种粗暴重置，必须提供等效视觉反馈，比如a:focus-visible { outline: 2px solid #0066cc; outline-offset: 2px; } - 自定义组件（如
role="button"的div）必须手动加tabindex="0"，否则:focus-visible压根不会触发
媒体查询里的prefers-reduced-motion如何影响读屏交互
@media (prefers-reduced-motion: reduce)不只是关动画，它也暗示用户可能依赖节奏稳定的交互反馈——这对屏幕阅读器的停顿、语速、甚至错误提示的呈现方式都有实际影响。
立即学习“前端免费学习笔记（深入）”；
- 启用该偏好后，部分读屏器（如VoiceOver）会自动降低语音语速、延长段落间停顿；你的CSS不该再叠加
animation干扰这个节奏 - 别用
reduced-motion媒体查询去“隐藏错误提示”，而应改用更明确的aria-live="off"+ 手动控制播报逻辑 - 测试时别只开系统设置，还要在Chrome DevTools的Rendering面板里勾选“Reduced motion”，因为某些读屏器只响应这个信号，不查系统级偏好
最常被忽略的是：CSS本身没有“无障碍模式”，所有响应都依赖它与HTML语义、ARIA属性、JS行为的配合。改一个display值，可能让整块表单对盲人用户彻底不可操作——得连着DOM结构和焦点管理一起看。
