400%拡大が残す画面領域を実測したら、固定ピクセルという通行料が見つかった
320pxのリフローに合格したページでも、短いビューポートでは本文に残る縦方向の空間が118pxまで減っていた。損失は割合ではなく82pxの固定ピクセル通行料で、その大半はアプリケーションCSSの外側にあるサードパーティの固定コンテナから生じていた。測定手順と回帰ゲートの設計、閾値の置き方まで記録する。
タグ
CSS
6件の記事
popoverが肩代わりするのは半分だけ: ツールチップ7実装で測ったSC 1.4.13
ツールチップの実装を7つ作り、WCAG 2.2 SC 1.4.13のDismissible・Hoverable・Persistentを個別に測った。CSSだけの3つは全部Dismissibleで落ち、popover="hint"はDismissibleを無料でくれる代わりにHoverableで落ちた。
リフローを320pxの幅だけで測ると半分しか測れない: 400%拡大の高さ200px
WCAG 1.4.10 リフローを 320x844・320x256・320x200 の3条件で同時に測った。横方向の判定は3条件で1ピクセルも違わず、400%拡大で実際に変わるのは高さのほうだ。82pxの sticky ヘッダーがビューポートの41%を占め、本文の可視領域は6割を切っていた。測定スクリプトも置いた。
字間を0.12em広げたら570か所が切れた: チェッカーが通したAA基準
axe-coreはWCAG 1.4.12に違反0件を返した。その基準が要求する4つの値を実際に当てると、570個の要素で文字が切れた。4つを1つずつ分けて当て、どの宣言がコンテンツを失わせるのかを分解した記録。
同じページを逆向きに辿ったら違反16件: 固定ヘッダーが飲み込むキーボードフォーカス
同じ6ページをTabで下りながら測ると WCAG 2.4.11 の違反は0件、Shift+Tabで上りながら測ると16件だった。ブラウザがフォーカス対象を画面内に入れる際の寄せ方が進行方向で変わるからだ。CSS一行で16件を0件にした実測記録である。測る向きを変えると、結果そのものが変わる点が核心だ。
CSS一行で強制レイアウトが27.3ms→1.8msに — content-visibility実測
同じHTML・同じバイト数なのに、CSSを一行足しただけで強制レイアウトが27.3msから1.8msに縮んだ。400セクションのページを二つ作りChromeトレースで content-visibility: auto の削減量を測り、contain-intrinsic-size と落とし穴まで整理する。