通过 WCAG 重流标准，也不保证页面在400%缩放下竖向可读
一个通过了 WCAG 1.4.10 重流检查的页面，在400%放大时仍可能竖向挤得几乎读不了。实测显示损失的竖向空间是固定的82像素，屏幕越小这个数占的比例越大。
标签
WCAG
15篇文章
400% 放大之后正文只剩 118px：一笔与视口高度无关的固定像素通行费
横向回流判定 8 行全过，320x200 条件下正文顶部却只剩 118px，页面中部更掉到 110px。损失不是随视口缩放的百分比，而是一笔 82px 的恒定像素代价，大半来自应用 CSS 之外的第三方固定容器。本文给出可复现的测量口径、发布回归门槛该怎么划，以及为什么不该定一条通用及格线、而要改用回归比较。
决定成败的不是那 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 个元素的文字被切断了。这篇把四条声明拆开逐个测，看谁才是丢内容的那一个。
CI 一直是绿的，审计报告却有三十条：用 W3C 的 1,213 个标准答案量自动检查的边界
W3C ACT 公开了 1,213 个带人工标注的测试用例。把 axe-core 全量跑一遍，387 个「应该失败」的用例里只有 145 个（37.5%）报出了对应成功标准的违规，36 条标准中有 22 条挂零，而这些沉默里有一部分只是规则默认没开。
往下按 Tab 零违规，往上按 16 条：吸顶头部吞掉的键盘焦点
同样六个页面，用 Tab 往下走测出 WCAG 2.4.11 违规 0 条，用 Shift+Tab 往上走测出 16 条。原因在于浏览器把焦点目标滚进视口时，对齐方式取决于你从哪个方向来。一行 CSS 把 16 条降到 0 条的实测记录。测的方向一换，结果就跟着换，这不是偶然误差，而是对齐规则本身。
26个抽样页漏掉的3类违规：把WCAG-EM 2.0用在1,342个页面上
W3C 于 7 月 23 日以 Group Note 形式发布 WCAG-EM 2.0。我照着文档的抽样流程挑出 26 个页面，又把同一次构建的 1,342 个页面全部用 axe-core 扫了一遍做对照。抽样只抓到 4 类违规中的 1 类，而随机样本给出新发现的概率只有 0.29%，几乎等于没有。
div 网格做的表格悄悄丢掉了什么：无障碍树与文本抽取的同步实测
把同一张营业时间表用四种标记方式写出来，分别过 axe-core 和五个抽取器。axe 对四种都给出零违规，可一旦把 HTML 还原成 Markdown 或纯文本，其中三种只能复原 0/7 行。role="table" 到底在哪一层帮不上忙，这里用实测日志说清楚。
aria-modal="true" 什么都没拦住：模态框焦点逃逸实测与 inert
一个带 role="dialog" 和 aria-modal="true" 的「标准」模态框，按第三次 Tab 时焦点就逃到了遮罩层背后，而 axe 报告的焦点类违规为 0。我把同一份标记分别换成 aria-hidden 和 inert，逐次记录键盘焦点的实际落点。
WCAG 2.2 最小目标尺寸：藏在92分绿灯背后的AA不合格
一排22×22的分页链接，拇指总按偏，Lighthouse却给了无障碍92分。我把WCAG 2.2新增的SC 2.5.8（最小24×24）种进沙箱，用自写脚本和Lighthouse各测一遍。自动工具如今能抓尺寸违规，却把例外判定甩回给你。连24px圆是否相交的间距例外计算，都用实测日志和CSS修复讲清楚。
自动无障碍检测亮了绿灯，仍留下的四道墙
我往一张结账页面里故意埋了八处WCAG障碍，再用axe-core跑一遍。规则型的四处被抓住，需要人来判断的四处却在绿灯背后原样留着。本文用实测日志说清楚自动化在结构上看不到什么，以及补上这块缺口的人工复查清单。
无障碍名称一旦错位，语音控制和AI智能体都按不了这个按钮
给按钮加了aria-label，无障碍树读出来的却是屏幕上根本看不到的字。我在沙盒里复现了WCAG 2.5.3 Label in Name违规，直接从无障碍树读出问题，再用Lighthouse 13.3.0新增的Agentic Browsing评分，看着它从0分变成100分。
同一份标记，不同判定 — 把 axe-core 塞进 CI 时 color-contrast 为何悄悄消失
我把一个 AI 生成的预订组件分别用 axe-core 跑在 jsdom 和真实浏览器里。四条结构性违规不用浏览器就被抓住，唯独 color-contrast 在 jsdom 里落到了 incomplete。这篇讲清楚原因，以及如何把 CI 流水线拆成两层、让覆盖率的洞不再出现，附带真实日志。
无障碍分数从55到100 — 用Lighthouse实测并修复WCAG违规
把一个虚构的面包店落地页扔进Lighthouse无障碍审计，得了55分。这里是逐条修复6个WCAG违规、做到100分的实测日志，以及自动化工具始终没能发现的键盘陷阱。