접근성 인증 마크를 받은 사이트가 실제로는 쓸 수 없는 수준이라는 경험을 해본 분이 계실까요. 저는 있습니다. 작년에 공공기관 민원 서비스 앱 접근성 컨설팅을 진행했는데, KWCAG 검사 항목을 전부 통과한 사이트에서 실제 시각장애인 사용자가 민원 신청 폼을 3번이나 처음부터 다시 시작해야 했습니다. 인증과 사용성 사이의 간극이 이렇게 클 수 있다는 걸 그때 처음 체감했습니다.
인증 기준이 곧 사용성은 아니다
KWCAG(한국형 웹 콘텐츠 접근성 지침)는 국내 공공기관 웹 서비스의 접근성 기준으로, 2026년부터는 공공기관 의무 적용이 확대될 예정입니다. 여기서 KWCAG란 국제 표준인 WCAG(Web Content Accessibility Guidelines)를 한국 환경에 맞게 재편한 지침으로, WCAG의 80개 이상 성공 기준을 33개 검사 항목으로 압축한 것입니다. 압축 과정에서 생기는 사각지대가 실무에서 문제가 됩니다.
예를 들어 인지 장애 관련 기준이나 읽기 수준(Reading Level) 성공 기준은 KWCAG에서 빠져 있습니다. 일본의 JIS X 8341-3과 비교하면 인지 접근성 영역에서 KWCAG가 상대적으로 느슨한 편이라는 의견도 있습니다. 체크리스트 33개를 전부 통과했다고 해서 모든 사용자가 편하게 쓸 수 있다는 보장은 없다는 뜻입니다.
제가 진행한 컨설팅 결과가 그 방증이었습니다. VoiceOver와 TalkBack으로 실제 테스트를 해보니, 민원 신청 폼에서 포커스 순서(tab order)가 시각적 배치와 완전히 달랐습니다. 포커스 순서란 키보드나 스크린리더가 요소 간 이동할 때 따라가는 순서를 말합니다. 이름 입력란 다음에 전화번호가 아니라 맨 아래 제출 버튼으로 포커스가 튀어버렸고, 참가자 한 분은 폼을 완성하지 못하고 3번을 처음부터 다시 시작했습니다. 수정에 걸린 개발 시간은 2시간이었지만, 과업 완료 시간이 4분 20초에서 1분 50초로 단축됐습니다. "조금만 신경써도 UX를 눈에 띄게 개선할 수 있다"는 말이 과장이 아니었습니다.
스크린리더가 놓치는 것들, 코드 한 줄 차이
스크린리더 사용성 문제는 생각보다 단순한 코드 수정으로 해결되는 경우가 많습니다. 제가 직접 써봤는데, 처음에는 화면 전체가 뭔가 끊어지고 알 수 없는 단어들이 읽혀서 당혹스러웠습니다. 대부분의 프론트엔드 개발자가 스크린리더를 한 번도 써보지 않고 서비스를 배포한다는 게 문제의 출발입니다.
실무에서 자주 등장하는 문제들을 정리하면 다음과 같습니다.
- 아이콘 버튼에 alt 값이 없거나 빈 값이어서 스크린리더가 "버튼"만 읽는 경우
- 장식용 이미지에 alt 속성이 아예 없어서 파일명(img_empty.png 등)이 그대로 읽히는 경우
- div 태그로 만든 카드가 버튼임을 알 수 없어서 사용자가 클릭 가능 여부를 유추해야 하는 경우
- 바텀시트나 모달이 열렸는데 스크린리더 포커스가 뒤에 남아 사용자가 아무 일도 안 일어난 줄 아는 경우
- 토스트 메시지가 시각적으로만 노출되고 스크린리더에게는 전달이 되지 않는 경우
여기서 WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications)가 핵심 도구로 등장합니다. WAI-ARIA란 HTML만으로 표현하기 어려운 동적 UI의 역할과 상태 정보를 스크린리더에 전달하기 위한 속성 집합으로, role, aria-label, aria-hidden, aria-checked 같은 속성들이 여기에 속합니다.
예를 들어 체크박스처럼 선택·해제가 되는 카드 컴포넌트에 role="checkbox"와 aria-checked 속성을 추가하면, 스크린리더가 "명랑핫도그 30퍼센트, 체크상자, 선택 해제됨"처럼 읽습니다. 속성 두 개 추가로 사용자가 카드의 상태를 정확히 파악할 수 있게 됩니다. 또한 Accessible Name이란 스크린리더가 요소에 포커스했을 때 실제로 읽는 값을 말하는데, aria-label로 명시한 author가 요소의 텍스트 콘텐츠보다 우선순위가 높기 때문에 아이콘 버튼에 aria-label이나 alt를 제대로 설정하는 것이 중요합니다.
바텀시트 같은 모달 UI에는 aria-hidden이라는 속성을 활용합니다. aria-hidden="true"가 적용된 요소는 스크린리더가 해당 요소와 하위 요소를 완전히 건너뛰게 됩니다. 모달이 열릴 때 모달 바깥 영역 전체에 aria-hidden="true"를 설정하면, 포커스가 자동으로 모달 안으로 이동해 사용자가 "뭔가가 떴구나"를 인지하게 됩니다. 이 방식이 없으면 스크린리더 사용자는 버튼을 눌렀는데 아무 일도 일어나지 않는 경험을 반복하게 됩니다.
색 대비와 실제 사용자 검증이 접근성의 완성이다
스크린리더 외에 실무에서 가장 자주 충돌하는 접근성 이슈는 색 대비 문제입니다. WCAG 기준 일반 텍스트의 명도 대비(Contrast Ratio)는 4.5:1 이상이어야 합니다. 명도 대비란 배경색과 텍스트색의 밝기 차이를 수치화한 것으로, 이 값이 낮으면 저시력 사용자나 밝은 햇빛 아래에서 화면을 보는 모든 사용자에게 불편합니다. 대형 텍스트(18pt 이상 또는 굵은 14pt 이상)는 3:1 이상으로 기준이 다소 낮아집니다(출처: W3C WCAG 2.1).
솔직히 이건 예상 밖이었습니다. 제가 경험한 프로젝트 3건 중 2건은 클라이언트 브랜드 컬러가 이 기준에 미달했습니다. 작년 컨설팅에서 클라이언트의 브랜드 컬러 #87CEEB(하늘색)는 흰 배경에서 명도 대비가 2.7:1밖에 되지 않았습니다. WCAG 기준 4.5:1의 절반 수준입니다. Figma의 Stark 플러그인으로 실시간 대비를 체크하면서 대안 컬러 5개를 제안했고, 최종적으로 #2E86C1(대비 4.8:1)로 합의했습니다. 브랜딩과 접근성 사이에서 타협점을 찾는 과정이 생각보다 많은 설득을 필요로 했습니다.
접근성 기준이 실제로 어떻게 적용되고 있는지는 한국웹접근성평가센터의 인증 현황에서도 확인할 수 있는데, 인증을 받은 사이트 중에서도 실사용 과정에서 문제가 발견되는 사례가 꾸준히 보고됩니다(출처: 한국웹접근성평가센터). 인증이 품질 보증이 아닌 최소 기준 충족임을 잊으면 안 됩니다.
결국 제가 이 프로젝트에서 확실히 배운 건, 접근성은 체크리스트로 끝낼 수 없다는 것입니다. 실제 시각장애인 사용자 2명과 함께 테스트를 해보니, 기술적으로는 통과인데 사용성은 실패한 지점들이 구체적으로 드러났습니다. 코드 수정 시간은 2시간이었지만 사용자 경험이 바뀌는 폭은 훨씬 컸습니다.
2026년 공공기관 의무 적용이 코앞인 지금, "인증 마크만 받으면 된다"는 접근은 결국 누군가를 차별하는 서비스를 만드는 것과 다르지 않습니다. 스크린리더로 직접 자신이 만든 서비스를 써보는 것, 그리고 색 대비 도구로 브랜드 컬러를 점검하는 것. 이 두 가지만 습관화해도 접근성 품질은 달라집니다. 체크리스트가 아니라 설계 습관으로 내재화하는 것이 지금 필요한 변화입니다.