본문으로 바로가기
웹은 1년 전보다 덜 접근 가능해졌다 — WebAIM Million 2026 리포트 썸네일

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

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

글 작성일: 2026-07-28 · 글 읽기 시간: 8 분 · 글 단어 수: 3723 단어 · 글쓴이: Isaac
접근성 E2E — @axe-core/playwright로 스캔 썸네일

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

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

글 작성일: 2026-07-27 · 글 읽기 시간: 11 분 · 글 단어 수: 5429 단어 · 글쓴이: Isaac
트레이스·디버깅·리트라이로 원인 추적 썸네일

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

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

글 작성일: 2026-07-22 · 글 읽기 시간: 7 분 · 글 단어 수: 3155 단어 · 글쓴이: Isaac
픽스처·인증 재사용·병렬 실행 썸네일

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

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

글 작성일: 2026-07-21 · 글 읽기 시간: 7 분 · 글 단어 수: 3094 단어 · 글쓴이: Isaac
색은 맞는데 대비는 틀렸다: CSS opacity가 파놓은 접근성 함정 썸네일

색은 맞는데 대비는 틀렸다: CSS opacity가 파놓은 접근성 함정

CSS에는 분명 진한 회색을 적었습니다. color: #595959. 흰 배경에서 이 색의 대비는 6.4:1이니까, 접근성 기준인 4.5:1을 넉넉히 넘깁니다. 통과예요. 그런데 접근성 검사기를 돌렸더니 빨간 줄이 떴습니다. ...

글 작성일: 2026-07-21 · 글 읽기 시간: 10 분 · 글 단어 수: 4561 단어 · 글쓴이: Isaac
로케이터와 auto-wait — flaky 테스트 줄이기 썸네일

로케이터와 auto-wait — flaky 테스트 줄이기

「프론트엔드 테스트 제대로 하기」 시리즈의 12편입니다. 전체 목차 보기 · 용어집 flaky 테스트 — 코드는 그대로인데 어떤 날은 통과하고 어떤 날은 실패하는 테스트. E2E를 처음 도입한 팀이 가장 먼저 앓는 병이고, 방치하면 “또 걔야? 그냥 다시 돌려"라는 무서운 문화로 이어집니다. 다행히 원인은 대부분 하나예요: 너무 일찍, 혹은 잘못된 방법으로 요소를 찾는 것. 이 글에서 Playwright의 로케이터와 auto-wait로 그 뿌리를 뽑습니다. ...

글 작성일: 2026-07-18 · 글 읽기 시간: 8 분 · 글 단어 수: 3706 단어 · 글쓴이: Isaac
고대비 모드 제대로 지원하기: forced-colors와 시스템 색 썸네일

고대비 모드 제대로 지원하기: forced-colors와 시스템 색

화면의 색을 최대 대비로 바꿔 쓰는 사람들이 있습니다. 검은 배경에 노란 글씨, 파란 배경에 흰 글씨처럼요. 저시력 사용자에게는 이게 글자를 읽을 수 있느냐 없느냐의 문제고, 편두통이나 빛 과민이 있는 사람은 반대로 자극을 줄인 저대비 팔레트를 쓰기도 합니다. 공통점은 하나예요 — 색을 사용자가 직접 정한다는 것. 그리고 그 순간, 우리가 CSS에 적어둔 색은 상당수 무시됩니다. ...

글 작성일: 2026-07-18 · 글 읽기 시간: 12 분 · 글 단어 수: 5888 단어 · 글쓴이: Isaac
다크모드 제대로 구현하기: CSS 변수 설계부터 색 대비 검증까지 썸네일

다크모드 제대로 구현하기: CSS 변수 설계부터 색 대비 검증까지

다크모드를 켰더니 눈이 더 피로했습니다. 배경은 검은색인데 텍스트가 진한 회색이라 대비가 너무 낮았고, 링크는 기본 파란색(#0000ff) 그대로라 눈이 아팠어요. 이미지는 어두운 화면에서 홀로 눈부시게 빛났습니다. 버튼 하나는 배경과 같은 색이라 아예 보이지도 않았어요. ...

글 작성일: 2026-07-18 · 글 읽기 시간: 14 분 · 글 단어 수: 6949 단어 · 글쓴이: Isaac
Playwright E2E 입문 — 첫 시나리오 썸네일

Playwright E2E 입문 — 첫 시나리오

「프론트엔드 테스트 제대로 하기」 시리즈의 11편입니다. 전체 목차 보기 · 용어집 Playwright는 진짜 브라우저(크로미움·파이어폭스·웹킷)를 코드로 조종하는 E2E 테스트 도구입니다. E2E(End-to-End)는 이름 그대로 끝에서 끝까지 — 사용자가 접속해서 검색하고 결과를 보는 흐름 전체를 실제 브라우저에서 재현하는 테스트고요. 이 글에서 설치부터 첫 시나리오 통과까지 한 번에 갑니다. ...

글 작성일: 2026-07-18 · 글 읽기 시간: 9 분 · 글 단어 수: 4106 단어 · 글쓴이: Isaac
접근성을 테스트에 녹이기 — role 기반 쿼리 썸네일

접근성을 테스트에 녹이기 — role 기반 쿼리

「프론트엔드 테스트 제대로 하기」 시리즈의 10편입니다. 전체 목차 보기 · 용어집 “접근성 테스트"라고 하면 어떤 그림이 떠오르시나요? 전문 컨설팅을 의뢰하고, 별도의 검사 도구를 도입하고, 체크리스트 수백 개를 훑는… 그런 큰일처럼 느껴지기 쉽습니다. 그런데 놀랍게도, 접근성 검증의 절반은 컴포넌트 테스트를 “잘” 쓰는 것만으로 공짜로 따라옵니다. 이 글은 그 원리와 실전 방법입니다 — div 버튼 걸러내기, 아이콘 버튼에 이름 붙이기, 사라지는 포커스 지키기까지. ...

글 작성일: 2026-07-17 · 글 읽기 시간: 14 분 · 글 단어 수: 6622 단어 · 글쓴이: Isaac
맨 위로