400% 확대에서 남는 화면을 실측했더니, 뷰포트 높이와 무관한 고정 px 통행료가 나왔다
320px 리플로우 판정을 통과한 페이지에서도 짧은 뷰포트에서는 본문에 남는 세로 공간이 118px까지 줄었다. 손실은 비율이 아니라 82px짜리 고정 픽셀 통행료였고, 대부분 우리 CSS 밖의 제3자 고정 컨테이너에서 나왔다. 측정 방법과 배포 회귀 게이트 설계까지 정리했다.
태그
CSS
6개 글
CSS로는 Escape를 받을 수 없다: 툴팁 일곱 개로 잰 SC 1.4.13
툴팁에 :focus-visible만 붙이면 접근성은 끝난 줄 알았다. 구현 일곱 개를 만들어 Dismissible·Hoverable·Persistent 세 항목을 각각 재보니 CSS만으로 통과한 것은 하나도 없었고, popover="hint"조차 절반만 대신해 주었다.
320px로 재면 리플로우는 절반만 잰 것이다: 400% 확대의 높이 200px
WCAG 1.4.10 리플로우를 320x844, 320x256, 320x200 세 조건으로 같이 재봤다. 가로 판정은 세 조건이 한 픽셀도 다르지 않았고, 400% 확대에서 실제로 달라지는 것은 높이였다. 82px짜리 sticky 헤더가 뷰포트의 41%를 먹고 있었다.
자간을 0.12em 넓혔더니 570곳이 잘렸다: 검사기가 통과시킨 AA 기준
axe-core는 WCAG 1.4.12 텍스트 간격 기준에 위반 0건을 줬다. 그런데 그 기준이 요구하는 네 줄을 실제로 적용하자 570개 요소에서 글자가 잘렸다. 네 줄을 하나씩 따로 걸어 -webkit-line-clamp가 어디서 콘텐츠를 잃게 하는지를 분해해봤다.
Tab으로 0건, Shift+Tab으로 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 함정까지 정리한다.