무슨 일이냐면요
한 웹 개발 팀이 시각장애인 고객과 함께 일하면서 겪은 이야기를 공유했어요. 결론부터 말하면, 눈으로 볼 땐 멀쩡하고 자동 검사 도구도 통과했던 웹사이트가, 실제 스크린 리더 사용자에겐 제대로 안 쓰였다는 거예요. 우리가 흔히 놓치는 '보이지 않는 접근성 구멍'을 정면으로 마주한 사례죠.
여기서 접근성(accessibility, 줄여서 a11y)이 뭐냐면요, 장애가 있는 사람도 웹을 문제없이 쓸 수 있게 만드는 걸 말해요. 그중에서도 시각장애인은 스크린 리더(screen reader)라는 프로그램을 써요. 화면의 내용을 소리로 읽어주는 도구인데, 맥의 보이스오버(VoiceOver)나 윈도우의 NVDA 같은 게 대표적이에요. 이 사용자들은 마우스 대신 키보드로 이동하고, 귀로 페이지를 '듣는다'고 보면 돼요.
자동 검사만으론 부족한 이유
많은 개발자가 접근성을 '라이트하우스(Lighthouse)나 axe 같은 자동 도구 돌려서 점수 잘 나오면 끝'이라고 생각해요. 그런데 이게 함정이에요. 자동 도구는 기계적으로 확인할 수 있는 것만 잡거든요. 예를 들어 이미지에 대체 텍스트(alt)가 있는지, 색 대비가 충분한지, 버튼에 라벨이 붙어 있는지 같은 것들이요.
하지만 스크린 리더로 실제로 써보면 완전히 다른 문제들이 튀어나와요. 이게 뭐냐면요.
- 읽는 순서가 엉망인 경우. 화면상으로는 잘 배치돼 있어도, 스크린 리더가 코드 순서대로 읽으면서 맥락이 뒤죽박죽되는 거예요.
- 동적 변화가 안 알려지는 경우. 예를 들어 '저장되었습니다' 같은 알림이 화면엔 떴는데 스크린 리더엔 아무 소리도 안 나서, 사용자는 성공했는지조차 몰라요. ARIA live 영역(변화를 소리로 알려주도록 표시하는 속성)을 안 걸어둔 게 원인이죠.
- 포커스가 미아가 되는 경우. 모달 창(팝업)을 열었는데 키보드 포커스가 엉뚱한 데 남아 있으면, 사용자는 지금 어디 있는지 길을 잃어요.
- 의미 없는 라벨. 버튼 이름이 '클릭'이나 '여기'라고만 돼 있으면, 앞뒤 맥락을 못 보는 사용자에겐 '클릭 버튼, 클릭 버튼'만 반복돼서 아무 의미가 없어요.
핵심 교훈: 진짜 사용자와 테스트하라
이 팀이 얻은 가장 큰 깨달음은 '실제로 그 도구를 쓰는 사람과 함께 테스트해야 진짜 문제가 보인다'는 거예요. 개발자가 눈 감고 스크린 리더 한번 켜보는 것과, 매일 그걸로 인터넷을 쓰는 사람이 만지는 건 차원이 달라요. 우리가 당연하게 여기는 인터페이스가 누군가에겐 미로일 수 있다는 걸, 옆에서 직접 봐야 체감하거든요.
업계 맥락
접근성은 이제 '착한 일'을 넘어 '의무'가 되고 있어요. 미국은 ADA, 유럽은 2025년부터 시행된 유럽 접근성법(EAA)으로 웹 접근성을 법으로 강제하고 있고, 한국도 장애인차별금지법에 따라 일정 규모 이상의 웹사이트는 접근성을 지켜야 해요(KWCAG라는 한국형 지침이 있어요). 안 지키면 소송이나 시정 요구를 받을 수 있고요. 즉 '여유 있으면 하는 것'이 아니라 '안 하면 리스크'인 시대예요.
한국 개발자에게
당장 실무에서 해볼 수 있는 건 이래요. 개발한 화면을 마우스 없이 키보드 탭 키만으로 끝까지 써보세요. 포커스가 순서대로 잘 이동하고 지금 어디에 있는지 눈에 보이면 절반은 성공이에요. 그다음 맥이라면 보이스오버(Cmd+F5)를 켜고 내 페이지를 '들어'보세요. 처음엔 낯설지만, 내가 만든 화면이 소리로 어떻게 들리는지 아는 것만으로도 시야가 확 바뀌거든요. 그리고 시맨틱 HTML(button, nav, main처럼 의미가 담긴 태그)을 쓰는 습관만 들여도 접근성의 절반은 공짜로 얻어요. div에 onClick 붙이는 대신 button을 쓰는 것부터요.
마무리
핵심은 '자동 검사 통과가 곧 실제로 쓸 수 있음은 아니다'라는 거예요. 여러분의 서비스, 마우스 없이 키보드만으로 끝까지 써본 적 있으세요? 오늘 딱 5분만 탭 키로 여러분 화면을 돌아다녀 보는 건 어떨까요?
🔗 출처: Hacker News