Codeslog — 웹접근성과 프론트엔드 개발 기록

시각적 회귀 테스트 — 스크린샷 비교

「프론트엔드 테스트 제대로 하기」 시리즈의 16편입니다. 전체 목차 보기 · 용어집 모든 테스트가 초록불인데 화면이 깨진 적, 있으시죠? 로직은 멀쩡한데 CSS 하나가 레이아웃을 무너뜨린 경우요. 시각적 회귀 테스트는 기준 스크린샷(baseline)을 저장해두고 픽셀을 비교해서, 이런 “눈으로 봐야 아는 회귀"를 자동으로 잡는 기법입니다. Playwright에 내장돼 있어 한 줄이면 시작해요 — 대신 흔들리지 않게 찍는 요령과 환경 차이라는 복병까지, 이 글에서 다 짚습니다. ...

세상은 우리와 함께일 때 더 잘 작동한다 — 7월, 장애 프라이드의 달

달력에는 표시되지 않지만, 세계 곳곳에서 챙기는 한 달이 있습니다. 7월, 장애 프라이드의 달(Disability Pride Month)입니다. “장애"와 “프라이드"라는 두 단어의 조합이 낯설게 느껴질 수 있습니다. 우리에게 익숙한 장애 관련 기념일의 정서는 주로 ‘배려’나 ‘극복’이었으니까요. 그런데 프라이드의 달은 조금 다른 이야기를 합니다. 장애는 극복하거나 숨겨야 할 무언가가 아니라, 한 사람의 정체성을 이루는 자연스러운 일부라는 이야기요. ...

웹은 1년 전보다 덜 접근 가능해졌다 — WebAIM Million 2026 리포트

100만 개의 홈페이지를 자동 검사기에 넣고 돌리면 무슨 일이 벌어질까요? 약 5,600만 개의 접근성 오류가 쏟아져 나옵니다. 페이지당 평균 56.1개입니다. 숫자만 보면 “원래 웹이 그렇지” 하고 넘길 수도 있습니다. 문제는 방향입니다. 작년에는 51개였거든요. 1년 사이 10.1% 늘었습니다. 몇 년간 느리게나마 나아지던 웹 접근성이, 올해는 뒷걸음질을 쳤습니다. ...

수천 개 페이지 중 무엇을 검사할까 — 접근성 대표 페이지 자동 선정 알고리즘

접근성 검사기를 하나 돌린다고 해봅시다. 사이트 주소를 넣으면, 검사기는 어느 페이지를 봐야 할까요? 홈 하나만 보면 될까요? 그러면 “이 사이트는 접근성이 좋다/나쁘다"라고 말할 근거가 약합니다. 그렇다고 전부 보자니, 게시판·블로그·쇼핑몰은 글이 수백에서 수천 개예요. 다 검사하면 시간도 비용도 감당이 안 됩니다. ...

접근성 E2E — @axe-core/playwright로 스캔

「프론트엔드 테스트 제대로 하기」 시리즈의 15편입니다. 전체 목차 보기 · 용어집 버튼 하나에 이름이 붙었는지는 그 버튼만 봐도 압니다. 그런데 글씨 색이 배경과 충분히 대비되는지, 페이지에 언어가 지정됐는지, id가 중복되진 않았는지는 요소 하나만 봐선 알 수 없어요. 화면 전체를, 그것도 실제로 그려진 상태로 봐야 하죠. 이건 사람이 매번 눈으로 하기엔 지치는 일이고, 그래서 자동 검사 엔진이 필요합니다. ...

접근성 평가에도 표준이 있습니다 — 12년 만의 WCAG-EM 2.0

↻ 2026-08-12 업데이트 한국 품질인증의 근거 법령을 바로잡았습니다. 2026년 1월 22일 「디지털포용법」 시행으로 「지능정보화 기본법」 제47조가 삭제되고 인증 제도는 디지털포용법 제21조·제22조로 넘어갔는데, 이 글이 옛 조문을 근거로 들고 있었습니다. 본문·FAQ·비교 그림을 함께 고쳤습니다. “우리 서비스, 접근성 지켰다고 말해도 될까요?” ...

'검사중'에 멈춘 좀비 작업 — Vercel Deployment Protection이 범인이었다

운영 중인 서비스의 로그를 습관처럼 넘겨보다가 손이 멈추는 순간이 있습니다. 저는 그날, 웹 접근성 점검 서비스 A11y Check의 검사 로그에서 그런 순간을 만났어요. 검사 2건이 몇 시간째 “검사중” 상태로 멈춰 있었습니다. ...

웹접근성 점검 도구를 오픈소스로 — 알리첵(A11y Check) 이야기

“우리는 인증도 받았으니 괜찮겠지.” 웹사이트를 만드는 쪽에서 이렇게 안심하기 쉽습니다. 그런데 인증 마크가 붙은 사이트에서도, 스크린 리더 사용자가 로그인 버튼을 못 찾고 저시력 사용자가 회색 위 회색 글씨를 못 읽는 일은 흔합니다. 점검을 한 번 받았다는 것과, 지금 이 순간 쓸 수 있다는 것은 다른 이야기거든요. ...

트레이스·디버깅·리트라이로 원인 추적

「프론트엔드 테스트 제대로 하기」 시리즈의 14편입니다. 전체 목차 보기 · 용어집 “내 컴퓨터에선 되는데 CI에선 빨간불.” E2E를 운영하는 모든 개발자의 숙제이자, console.log를 도배하게 만드는 주범이죠. Playwright에는 이 미스터리를 증거 기반으로 푸는 도구가 셋 내장돼 있습니다 — 실패 순간을 통째로 되감는 트레이스, 시간여행하듯 보는 UI 모드, 그리고 신호로 쓰는 리트라이. 이 글에서 셋 다 챙깁니다. ...

픽스처·인증 재사용·병렬 실행

「프론트엔드 테스트 제대로 하기」 시리즈의 13편입니다. 전체 목차 보기 · 용어집 E2E 테스트가 열 개를 넘어가면 두 가지가 아파옵니다. 테스트마다 복붙되는 준비 코드, 그리고 순서대로 도느라 느려지는 스위트. Playwright의 픽스처(반복 준비를 테스트에 주입하는 장치)와 병렬 실행이 이 둘을 한 번에 해결합니다 — 이 글에서 커스텀 픽스처, 인증 재사용(storageState), 병렬 안전 수칙까지 정리해요. ...