骨架屏必须通过结构、语义和渲染逻辑三重校验才真正可用：骨架元素禁用aria-hidden，须保留在DOM中并用visibility:hidden隐藏；真实内容区域需声明role="region"和aria-live="polite"；背景色应使用CanvasText等系统语义色适配高对比度模式；首屏骨架须带aria-busy="true"和aria-label，且文字行骨架必须用独立div配合role="heading"等语义标签，确保WCAG 2.2合规。
骨架屏不是“看起来像就行”，而是必须通过结构、语义和渲染逻辑三重校验才能算真正可用——尤其对屏幕阅读器、键盘导航和强制配色模式用户，aria-hidden乱用、display: none误删、硬编码灰度值，都会直接导致可访问性断裂。
为什么 skeleton 元素不能加 aria-hidden="true"
很多开发者图省事，在骨架层上直接写 aria-hidden="true"，以为“反正只是占位，不该被读”。但问题在于：当真实内容加载完成、骨架被 display: none 隐藏时，如果它之前被设为 aria-hidden，部分屏幕阅读器（尤其是 NVDA + Firefox 组合）会缓存该状态，导致切换后真实内容仍不被朗读。
- 正确做法是让骨架元素始终保留在 DOM 中，仅用
visibility: hidden或opacity: 0配合pointer-events: none隐藏，而非移除或屏蔽语义 - 真实内容区域必须显式声明
role="region"和aria-live="polite"，确保内容替换时能触发通告 - 所有骨架
div不设tabindex，也不响应focus事件——它们本就不该进入焦点流
如何让骨架屏适配强制配色模式（如 Windows 高对比度）
硬编码 #f0f0f0 这类灰度值在高对比度模式下会被系统强制替换为纯黑/纯白，导致骨架块消失或反色错乱。CSS 变量和 color-scheme 控制是唯一可靠路径。
- 骨架背景统一用
background-color: CanvasText或background-color: GrayText，这些是系统定义的语义色，会随配色模式自动适配 - 渐变动画改用
background-image: linear-gradient(to right, CanvasText 25%, Canvas 50%, CanvasText 75%)，避免任何十六进制色值 - 在
<head>中声明<meta name="color-scheme" content="light dark">，并为骨架 CSS 加@media (prefers-contrast: high)覆盖规则，禁用 background-image，改用纯色+border模拟轮廓
首屏骨架内联时如何避免阻塞可访问性树构建
内联骨架 HTML 虽快，但如果写在 <body> 开头且未加 aria-busy="true"，AT（辅助技术）会立刻开始遍历它，而此时 JS 尚未注入状态控制逻辑，用户可能听到一串无意义的“灰色方块、灰色方块……”。
立即学习“前端免费学习笔记（深入）”；
- 首屏骨架容器必须带
aria-busy="true"和aria-label="页面内容正在加载中"—— 这是 AT 唯一能识别的“请稍等”信号 -
aria-busy由服务端初始注入，JS 只负责在数据就绪后改为false并移除aria-label，不主动添加新属性 - 禁止在骨架内部嵌套
<h1>、<button>等语义化标签——它们没有实际功能，却会污染语义层级
文字行骨架必须用独立 div，不能靠伪元素模拟
用 ::before 或 ::after 生成多行灰块看似简洁，但在 VoiceOver（iOS）和 TalkBack（Android）中，伪元素默认不被朗读，且无法设置 aria-hidden，导致部分机型将伪元素内容当作真实文本重复播报。
- 每行文字对应一个
<div class="skeleton-text-line"></div>，高度固定为1rem，行距用margin-bottom - 所有
.skeleton-text-line必须设aria-hidden="false"（显式声明），确保 AT 明确知道这是占位，而非遗漏内容 - 若真实标题是
<h2>，骨架层对应位置只能用<div role="heading" aria-level="2"></div>，不能降级为<span>
最易被忽略的是：骨架屏一旦上线，就不再是“临时占位”，而是页面不可分割的可访问性基础设施——它得经受住 WCAG 2.2 的 4.1.2（名称、角色、值）和 4.1.3（状态）条款审查，而不是只跑通 Lighthouse 的自动化检测。
