웹접근성 웹접근성 RSS 피드 구독

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

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

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

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

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

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

시험에서 71점을 받았다고 상상해보세요. “잘했다"고 하기엔 아쉽지만, “노력했다"고 하기엔 충분한 점수죠. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 7편입니다. 전체 목차 보기 · 용어집 Testing Library는 React를 비롯한 컴포넌트 테스트의 사실상 표준 도구입니다. 그런데 이 도구의 진짜 알맹이는 API가 아니라 철학 하나예요 — 컴포넌트 테스트에 들어서면 “클래스 이름으로 찾을까? 내부 state를 들여다볼까?” 하는 유혹이 생기는데, Testing Library는 단호하게 말합니다. 사용자가 하는 대로 하라. 이 글에서 그 철학이 무슨 뜻인지, 쿼리를 고르는 순서, 그리고 왜 이 방식이 접근성과 한 몸인지를 검색 컴포넌트를 직접 만들며 확인합니다. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 1편입니다. 전체 목차 보기 · 용어집 “테스트요? 지금도 잘 돌아가는데요.” 한 번쯤 해봤거나, 들어봤을 말이죠. 저도 오랫동안 그랬습니다. 눈으로 보고, 손으로 클릭해보고, “어 되네” 하면 그걸로 충분하다고 생각했어요. 그런데 기능이 늘고, 코드를 고칠 때마다 “이거 고치면 저쪽이 안 터지나?” 하는 불안이 스멀스멀 올라오기 시작하면, 그때가 바로 테스트가 필요해지는 순간입니다. ...

오늘 하루를 잠깐 돌아봐 주세요. 지하철에서 소리 없이 자막으로 영상을 봤나요? 햇빛 아래서 화면이 안 보여 밝기를 한껏 올렸나요? 한 손에 짐을 들고 엄지 하나로 스마트폰을 조작했나요? 눈이 피로해서 야간 모드나 다크모드를 켰나요? ...