400% 放大之后正文只剩 118px：一笔与视口高度无关的固定像素通行费
横向回流判定 8 行全过，320x200 条件下正文顶部却只剩 118px，页面中部更掉到 110px。损失不是随视口缩放的百分比，而是一笔 82px 的恒定像素代价，大半来自应用 CSS 之外的第三方固定容器。本文给出可复现的测量口径、发布回归门槛该怎么划，以及为什么不该定一条通用及格线、而要改用回归比较。
标签
CSS
6篇文章
决定成败的不是那 8px，而是它长在哪儿：七种 tooltip 实测 SC 1.4.13
把同一句提示做成七种 tooltip，分别量 WCAG 2.2 SC 1.4.13 的 Dismissible、Hoverable、Persistent。纯 CSS 的三种全部倒在 Dismissible 上，popover="hint" 白送你 Dismissible，却在 Hoverable 上翻车。
只按 320px 宽度测回流，只测了一半：400% 放大后的 200px 高度
把 WCAG 1.4.10 回流放在 320x844、320x256、320x200 三个条件下同时测量。横向判定三个条件一个像素都不差，400% 放大真正改变的是高度：82px 的 sticky 头部占掉了视口的 41%，正文可见区域最后只剩下不到六成，文末附上可复现的测量脚本与三档高度的完整数据。
字距调宽 0.12em，570 处文字被切掉：检查器放行的 AA 标准
axe-core 给 WCAG 1.4.12 判了零违规。可当我真的把这条标准要求的四个值加上去，570 个元素的文字被切断了。这篇把四条声明拆开逐个测，看谁才是丢内容的那一个。
往下按 Tab 零违规，往上按 16 条：吸顶头部吞掉的键盘焦点
同样六个页面，用 Tab 往下走测出 WCAG 2.4.11 违规 0 条，用 Shift+Tab 往上走测出 16 条。原因在于浏览器把焦点目标滚进视口时，对齐方式取决于你从哪个方向来。一行 CSS 把 16 条降到 0 条的实测记录。测的方向一换，结果就跟着换，这不是偶然误差，而是对齐规则本身。
一行 CSS 把强制布局从 27.3ms 压到 1.8ms：content-visibility 实测
同一份 HTML、同样的字节数，只多加一行 CSS，强制布局成本就降了 15 倍。我把一个 400 段的页面做了两个版本，用 Chrome 追踪和 Performance API 实测 content-visibility: auto 到底省了多少渲染，并讲清 contain-intrinsic-size 与无障碍陷阱。