320px로 재면 리플로우는 절반만 잰 것이다: 400% 확대의 높이 200px
WCAG 1.4.10 리플로우를 320x844, 320x256, 320x200 세 조건으로 같이 재봤다. 가로 판정은 세 조건이 한 픽셀도 다르지 않았고, 400% 확대에서 실제로 달라지는 것은 높이였다. 82px짜리 sticky 헤더가 뷰포트의 41%를 먹고 있었다.
archive
칼럼 · 페이지 3
356 · 페이지 3
인용된 문장으로 되돌아오는 링크: 코드 블록에서만 15개 중 14개가 끊겼다
AI 답변이 내 글의 한 문장을 인용하고 그 문장으로 가는 링크를 걸었을 때, 그 링크가 실제로 동작하는지 크로미움에서 69개 확인했다. 산문 48개는 전부 도착했고 코드 블록 15개 중 14개가 끊겼다. 텍스트 프래그먼트의 블록 경계·단어 경계 규칙을 실측으로 정리한다.
자간을 0.12em 넓혔더니 570곳이 잘렸다: 검사기가 통과시킨 AA 기준
axe-core는 WCAG 1.4.12 텍스트 간격 기준에 위반 0건을 줬다. 그런데 그 기준이 요구하는 네 줄을 실제로 적용하자 570개 요소에서 글자가 잘렸다. 네 줄을 하나씩 따로 걸어 -webkit-line-clamp가 어디서 콘텐츠를 잃게 하는지를 분해해봤다.
W3C 정답지 1,213장에 검사기를 걸었다: 자동 접근성 게이트가 결정하는 것
W3C ACT가 공개한 정답 붙은 테스트 케이스 1,213장에 axe-core를 전수로 돌렸다. 실패해야 하는 예제 387장 중 해당 성공기준으로 위반이 잡힌 것은 145장(37.5%)이었고, 36개 기준 중 22개는 0건이었다. 침묵의 일부는 규칙이 그냥 꺼져 있어서였다.
Tab으로 0건, Shift+Tab으로 16건: 스티키 헤더가 삼킨 키보드 포커스
같은 6개 페이지를 Tab으로 내려가며 재면 WCAG 2.4.11 위반이 0건, Shift+Tab으로 올라가며 재면 16건이었다. 브라우저가 포커스 대상을 화면에 넣는 정렬이 진행 방향에 따라 달라지기 때문이다. CSS 한 줄로 16건을 0건으로 줄인 바로 그 실측이다.
1년 전 글의 Last-Modified가 어제였다: 배포가 지우는 캐시 검증자
작년에 쓴 글을 curl로 찔러보니 Last-Modified가 어제 배포 시각이었다. ETag는 파일 수정 시각과 크기를 16진수로 이어붙인 값이다. 같은 소스로 다시 빌드한 HTML 1,346장이 100% 바이트 동일한데도, 배포 한 번이 사이트 전체의 조건부 요청을 무효로 만든다.
표본 26장이 놓친 위반 3종: WCAG-EM 2.0을 1,342장에 적용한 기록
W3C가 7월 23일 WCAG-EM 2.0을 Group Note로 발행했다. 문서의 표본 추출 절차대로 26장을 뽑고, 같은 빌드의 1,342장 전체를 axe-core로 훑어 대조했다. 표본은 위반 4종 중 1종만 잡았고, 무작위 표본의 새 발견 확률은 0.29%였다.
제목을 선언하는 일곱 곳 중 여섯 곳만 내가 썼다: 앵커 텍스트 18,296개 실측
한 페이지의 제목은 title·h1·og:title·headline·RSS 등 여섯 곳에서 선언된다. 1,296편 전부 일치했다. 문제는 일곱 번째 채널이었다. 내부 링크 18,296개 중 목표 글 제목과 일치하는 앵커 텍스트는 0.7%뿐이었고, 원인은 카드를 감싼 링크 하나였다.
내부 링크 46,382개 중 24,948개가 301로 튕기고 있었다
접근성 지표를 재려고 만든 스크립트가 URL 버그를 잡아냈다. 빌드된 HTML 1,334장의 내부 링크를 전수 조사하니 절반이 넘는 24,948개가 트레일링 슬래시 없는 주소, 즉 301 리다이렉트를 거치는 주소를 가리키고 있었다. 원인과 네 단계의 수정, 그리고 0으로 만든 기록.
언어별 아카이브 네 장을 지웠더니 296편이 도달 불가가 됐다: 크롤 깊이 실측
관련 글이 평균 8개씩 걸린 사이트의 내부 링크를 도달성 기준으로 다시 세어 봤다. 빌드된 HTML 1,330장을 너비 우선 탐색하니 글 1,288편 중 1,276편이 깊이 2였다. 그런데 언어별 목록 페이지 네 장을 링크 그래프에서 빼자 296편이 홈에서 닿지 않았다.
div 그리드로 만든 표가 조용히 잃는 것: 접근성 트리와 텍스트 추출 동시 실측
같은 영업시간 표를 네 가지 마크업으로 만들어 axe-core와 추출기 다섯 벌에 통과시켰다. axe는 네 개 모두 위반 0건을 줬지만, HTML을 텍스트로 바꾸는 순간 7행이 통째로 사라지는 마크업이 셋이었다. role="table"이 못 구하는 층을 실측 로그로 정리했다.
prerender에서 LCP가 6.2초로 찍힌 이유 — activationStart를 뺀 RUM만 맞다
Speculation Rules로 페이지를 미리 렌더링하면 LCP 원본값에 사용자 대기 시간이 통째로 들어간다. Chrome 150에서 6244ms와 103.5ms의 간극을 실측하고, activationStart로 보정해야 할 지점을 RUM 계측 코드 기준으로 하나씩 정리했다.