Posts Posts RSS 피드 구독

“우리 서비스, 접근성 지켰다고 말해도 될까요?” 검사 도구를 돌려서 오류 0이 나오면 끝일까요? 화면이 수백 개인 서비스라면 그걸 다 돌려봐야 할까요, 아니면 몇 개만 골라 봐도 될까요? 골라 본다면 어떤 화면을, 몇 개나, 무슨 근거로 골라야 “준수했다"고 말할 수 있을까요? ...

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

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

「프론트엔드 테스트 제대로 하기」 시리즈의 14편입니다. 전체 목차 보기 · 용어집 ...

「프론트엔드 테스트 제대로 하기」 시리즈의 13편입니다. 전체 목차 보기 · 용어집 ...

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

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

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

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

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