솔직히 저는 KWCAG 인증 마크를 받으면 접근성 문제가 해결된다고 생각했습니다. 공공기관 민원 서비스 컨설팅을 맡기 전까지는요. 실제 시각장애인 사용자를 앉혀 놓고 테스트를 돌리기 전까지, 저도 체크리스트를 통과한 서비스가 '쓸 만한 서비스'라고 믿었습니다. 그 믿음이 얼마나 안이한 것이었는지, 테스트 첫날 확인했습니다.
KWCAG 인증, 통과했는데 왜 못 쓰나
KWCAG(한국 웹 콘텐츠 접근성 지침)는 국내 웹 서비스가 접근성 인증을 받을 때 기준이 되는 검사 항목 33개짜리 체계입니다. 여기서 KWCAG란 국제 표준인 WCAG(Web Content Accessibility Guidelines)를 국내 실정에 맞게 압축·적용한 지침으로, 정보통신접근성(WA) 인증의 근거가 됩니다. 문제는 이 압축 과정에서 상당수 기준이 빠진다는 점입니다.
국제 표준인 WCAG 2.1 기준으로는 성공 기준이 80개를 훌쩍 넘습니다(출처: W3C). KWCAG가 33개로 추려지는 과정에서 인지 장애 관련 기준이나 일부 UX 실사용성 항목들이 빠졌고, 저는 이 사각지대를 현장에서 직접 목격했습니다.
제가 맡았던 공공기관 앱은 분명 KWCAG 인증을 통과한 상태였습니다. 그런데 민원 신청 폼에서 포커스 순서(focus order)가 시각적 배치와 전혀 맞지 않았습니다. 포커스 순서란 키보드나 스크린리더가 화면 요소를 탐색하는 순서를 말하는데, 이 순서가 사용자 눈에 보이는 순서와 다르면 시각장애인 사용자는 폼을 제대로 채울 수가 없습니다. 이름 입력란 다음에 전화번호가 아니라 맨 아래 제출 버튼으로 포커스가 튀어버리는 구조였고, 참가자 한 분은 3번이나 처음부터 다시 시작해야 했습니다.
이 문제를 수정하는 데 개발자 시간으로 딱 2시간이 걸렸습니다. 그런데 수정 전후 과업 완료 시간이 4분 20초에서 1분 50초로 절반 이하로 떨어졌습니다. 2시간 투자로 사용자 시간을 절반 넘게 줄려줬다는 뜻입니다. 체크리스트는 이걸 걸러내지 못했고, 실제 사람이 앉아서 쓰는 테스트가 잡아냈습니다.
스크린리더가 읽는 방식과 WAI-ARIA
스크린리더가 화면을 읽을 때 의존하는 것이 시맨틱 HTML과 WAI-ARIA입니다. 시맨틱 HTML이란 button, nav, main처럼 요소 자체가 역할을 담은 태그를 쓰는 방식으로, 스크린리더가 "이건 버튼이고, 이건 메인 콘텐츠"라고 구조를 이해할 수 있게 해줍니다. 반면 WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications)는 시맨틱 HTML만으로 표현하기 어려운 동적 UI 컴포넌트에 역할, 상태, 속성을 추가로 알려주는 규격입니다. 예를 들어 커스텀 드롭다운이 펼쳐졌는지 닫혔는지를 aria-expanded="true/false"로 전달하는 식입니다.
일반적으로 WAI-ARIA만 잘 쓰면 접근성 문제가 해결된다고 보는 시각도 있는데, 제 경험상 이건 좀 다릅니다. 시맨틱 HTML이 먼저 갖춰지지 않은 상태에서 ARIA 속성만 덧붙이면 오히려 스크린리더가 혼선을 일으키는 경우를 여러 번 봤습니다. 기초 구조가 잡혀 있어야 ARIA가 제 역할을 합니다.
모바일 스크린리더 UX 개선에서 적은 수정으로 체감 효과가 큰 케이스들을 정리하면 다음과 같습니다.
- 포커스 순서와 시각적 레이아웃 일치 — 탭 순서를 DOM(Document Object Model, 브라우저가 HTML을 읽어 구성하는 문서 구조) 순서와 맞춰 논리적 흐름 확보
- 아이콘 버튼에 aria-label 부여 — "X" 버튼이 "닫기"로 읽히도록 텍스트 대안 제공
- 모달 등장 시 포커스 이동 처리 — 팝업 열릴 때 포커스가 팝업 안으로 이동하지 않으면 스크린리더 사용자는 팝업 존재 자체를 모름
- 라이브 리전(aria-live) 설정 — 오류 메시지나 상태 변경처럼 동적으로 바뀌는 콘텐츠를 스크린리더가 즉시 읽도록 지정
색 대비 기준, 클라이언트와 싸워야 하는 이유
색 대비 문제는 제가 프로젝트에서 가장 자주 부딪히는 이슈입니다. 경험상 클라이언트 3건 중 2건은 브랜드 컬러가 WCAG 색 대비 기준에 미달합니다. 이유는 단순합니다. 브랜드 컬러는 주로 시각적 인상을 위해 만들어지고, 가독성 수치는 나중에 확인하는 경우가 많기 때문입니다.
WCAG 2.1이 규정하는 색 대비 명도 기준은 일반 텍스트 4.5:1, 대형 텍스트는 3:1입니다. 명도 대비란 전경색과 배경색의 상대적인 밝기 차이를 수치로 표현한 것으로, 이 비율이 낮을수록 저시력 사용자나 밝은 외부 환경에서 텍스트를 읽기 어려워집니다. 앞서 언급한 공공기관 프로젝트에서도 이 문제가 뼈아팠습니다. 클라이언트 브랜드 컬러 하늘색이 흰 배경 위에서 명도 대비 2.7:1밖에 안 됐습니다. WCAG 기준 4.5:1에 한참 못 미치는 수치입니다.
저는 이 상황에서 Figma의 Stark 플러그인을 활용해 대안 컬러를 제안했습니다. Stark는 Figma 내에서 실시간으로 색 대비 비율을 확인하고 기준을 통과하는 색상 범위를 시각화해주는 도구입니다. 브랜드 컬러의 채도를 유지하면서 명도만 조정한 세 가지 대안을 제시했고, 클라이언트와 최종 합의에 이를 수 있었습니다.
국내 장애인 인구는 약 264만 명으로 전체 인구의 5.1%에 달하며, 이 중 시각장애인은 약 25만 명입니다(출처: 한국장애인개발원). 색 대비 개선은 시각장애인만을 위한 조치가 아닙니다. 노안, 일시적 시야 저하, 밝은 햇빛 아래 스마트폰 사용처럼 누구나 접할 수 있는 상황에서도 가독성을 보장합니다. 이것이 접근성을 '소수를 위한 기능'이 아니라 보편적 설계 원칙으로 봐야 하는 이유입니다.
인증 마크는 최소한의 진입 조건일 뿐, 그게 곧 좋은 UX는 아닙니다. 저는 이 프로젝트 이후로 접근성을 검수 단계에서 챙기는 게 아니라 디자인 초기부터 설계 습관으로 내재화해야 한다고 생각하게 됐습니다. 색 대비 확인을 디자인 파일 열 때 먼저 하고, 포커스 순서를 마크업 설계 단계에서 잡고, 스크린리더 테스트를 QA 직전이 아닌 프로토타입 단계에서 돌리는 것이 그 시작입니다. 체크리스트는 인증을 받기 위한 도구이고, 진짜 접근성은 실제 사람이 쓸 수 있는 서비스를 만드는 태도에서 옵니다.