sr-only类确保元素视觉隐藏但保留在可访问性树中，供屏幕阅读器解析和键盘聚焦；not-sr-only用于响应式或焦点状态下恢复显示，手动添加display: none会破坏可访问性。
为什么 display: none 和 visibility: hidden 会让屏幕阅读器跳过内容？
这两个声明不仅视觉隐藏，还会从可访问性树中移除元素——屏幕阅读器根本“看不见”它们。哪怕你只是想隐藏图标文字、仅对视觉用户显示的装饰性内容，或为键盘焦点准备的“跳转到主内容”链接，用它们就等于直接切断了视障用户的交互路径。
常见错误现象：sr-only 类没生效，但检查发现用了 display: none 覆盖；或者用 opacity: 0 + pointer-events: none 想“隐形但保留结构”，结果屏幕阅读器仍朗读、键盘却无法聚焦。
- 真正需要的是：视觉上不可见，但保留在可访问性树中、能被键盘
Tab访问、能被屏幕阅读器解析 - Tailwind 默认的
sr-only就是为此设计，原理是绝对定位 + 极大负偏移 + 尺寸归零 + 裁剪溢出 - 别手动覆盖
sr-only的width/height或加display: none—— 这会直接破坏可访问性
如何正确使用 Tailwind 的 sr-only 和 not-sr-only？
sr-only 是 Tailwind 内置的无障碍隐藏工具类，它让元素只对屏幕阅读器可见；not-sr-only 则用于在特定断点（比如响应式场景）下取消该隐藏，恢复视觉显示。
典型使用场景：跳过导航链接、表单必填星号的文本说明、SVG 图标的 title 或 aria-label 替代文案。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
<a href="#main-content" class="sr-only focus:not-sr-only">跳转到主内容</a>
—— 默认隐藏，获得焦点时显示（方便键盘用户） - 错误写法：
<span class="sr-only">必填</span><span class="text-red-500">*</span>
—— 星号无语义，应把*放进sr-only容器，或用aria-hidden="true"标记星号 - 注意：如果父容器用了
overflow: hidden（比如轮播图容器），sr-only的负偏移可能被裁剪，导致键盘焦点“丢失”——此时需确保父级不限制溢出，或改用clip-path替代方案
什么时候不该用 sr-only？替代方案有哪些？
当你要隐藏的是纯装饰性内容（如分隔线 SVG、背景花纹），或明确不需要被任何辅助技术感知时，sr-only 就过度了——应该用更轻量、更语义的方式处理。
- 装饰性图标：直接加
aria-hidden="true"，不套sr-only—— 减少 DOM 干扰，也避免意外获得焦点 - 纯视觉状态提示（如成功 toast 的绿色边框）：用
border-green-500即可，无需额外文本；若需传达状态，用role="status"+ 动态aria-live，而不是靠隐藏文字 - 需要动画淡入/滑入的“隐藏态”：别用
sr-only控制显隐，它不是为动画设计的。改用opacity-0+pointer-events-none+aria-hidden="true"组合，并在显示时同步更新aria-hidden和焦点管理
自定义 sr-only 时最容易踩的兼容性坑
Tailwind 的默认 sr-only 基于 position: absolute，这在 flex/grid 容器中可能导致布局错乱，或与某些 CSS-in-JS 库的样式隔离机制冲突。
- 不要仅复制官方 CSS 声明到自定义类里——Tailwind v3.3+ 的
sr-only已改用clip-path方案，兼容性更好，旧版绝对定位在 Safari 15.4 之前有焦点渲染问题 - 如果你必须重写，优先用：
.my-sr-only { position: absolute; clip-path: inset(50%); }，比负 margin 更稳定 - 测试关键点：用 VoiceOver +
Tab切换，确认隐藏元素是否出现在焦点流中；用 Lighthouse 的“Accessibility”审计，检查是否触发 “[aria-hidden] must not be present on focusable elements” 报错
最常被忽略的点：动态插入的元素（比如 JS 创建的 toast）如果用了 sr-only，但没设置 role 或 aria-live，屏幕阅读器根本不会主动朗读——隐藏逻辑和语义播报必须配套处理。
