자동 접근성 검사 결과를 사람이 다시 확인해야 하는 이유

웹 접근성 자동 검사 도구(Lighthouse, axe-core 등)를 실행하여 '접근성 100점' 또는 '위반 사항 0개(0 violations)'라는 결과를 마주하면, 많은 실무자가 해당 웹페이지의 접근성 작업이 완전히 끝났다고 오판합니다. 그러나 W3C 웹 접근성 이니셔티브(WAI)의 공식 통계와 실무 접근성 감사 보고서에 따르면, 자동화 알고리즘이 포착할 수 있는 WCAG 성공 기준은 전체 기준의 약 30%에서 40% 수준에 불과합니다. 나머지 60% 이상은 인간의 문맥 이해, 논리적 사고, 실제 보조공학 기기(보조기술)와의 상호작용을 통해서만 검증할 수 있는 영역입니다. 이 글에서는 자동화 도구가 완벽하다고 판정한 페이지에서도 스크린리더 사용자와 키보드 사용자에게 심각한 장벽을 초래하는 대표적인 허점들을 분석하고, 실무자가 반드시 거쳐야 하는 4단계 수동 검토 가이드라인을 상세히 다룹니다.

자동 진단 알고리즘의 본질적 한계와 맹점

접근성 자동 검사 엔진은 기본적으로 HTML DOM(Document Object Model) 트리와 CSS 스타일 규칙을 구문 분석(AST Parsing)하여 정형화된 규칙에 대입하는 방식으로 작동합니다. 예를 들어 <img> 태그에 alt 속성이 누락되었는가, 폼 컨트롤(<input>)에 연관된 <label>이나 aria-label이 존재하는가, 텍스트 전경색과 배경색의 수학적 상대 휘도(Relative Luminance) 비율이 4.5:1 이상인가와 같은 기계적 규칙은 밀리초 단위로 정확하게 검출합니다.

그러나 기계는 '의미의 맥락(Semantic Context)'을 이해하지 못합니다. <img> 태그에 alt='image123.jpg'나 alt='사진'이라는 의미 없는 파일명이나 일반 명사가 적혀 있어도, 자동화 도구는 'alt 속성이 비어있지 않음'으로 처리하여 당당하게 합격 판정을 내립니다. 스크린리더를 사용하는 시각장애인에게 이것은 이미지가 아예 없는 것보다 더 큰 혼란을 줍니다. 또한 쇼핑몰 상품 목록에서 20개의 상품 링크 텍스트가 모두 '상세보기'나 '더보기'로만 작성되어 있어도, 자동화 도구는 <a> 태그 내부에 텍스트 노드가 존재한다는 이유만으로 완벽한 통과로 간주합니다.

자동 도구가 놓치는 4대 핵심 접근성 장벽

실제 웹사이트 구축 현장에서 자동화 검사를 100점으로 통과했음에도 불구하고 장애인 사용자 테스트에서 치명적인 불합격을 받는 대표적인 네 가지 패턴이 있습니다.

• 1. 대체 텍스트의 실제 맥락 적합성(WCAG 1.1.1): 단순한 설명이 아니라 해당 이미지가 문맥에서 전달하려는 핵심 정보와 감정이 일치하는지 여부. 장식용 이미지라면 차라리 alt=''로 비워두어야 하지만, 자동 점수를 올리려고 불필요한 설명을 장황하게 채워 넣어 스크린리더 청취 피로도를 극대화하는 사례가 매우 흔합니다.
• 2. 시각적 배치와 DOM 초점 순서의 괴리(WCAG 2.4.3): CSS Flexbox의 order 속성이나 CSS Grid의 좌표 배치로 인해 시각적으로는 좌상단에서 우하단으로 자연스럽게 배열되어 있지만, 실제 HTML DOM 순서가 뒤죽박죽인 경우 키보드 Tab 키 이동 순서가 화면 전체를 무작위로 건너뛰는 현상이 발생합니다.
• 3. 인터랙티브 상태 변화의 인지성(WCAG 4.1.2, 4.1.3): 버튼을 눌러 비동기(Ajax) 장바구니 담기가 완료되었거나 폼 검증 에러가 발생했을 때, 화면에는 붉은 글씨가 뜨지만 스크린리더 사용자에게는 아무런 음성 안내(aria-live)가 전달되지 않는 침묵 현상은 정적 검사 도구가 결코 잡아낼 수 없습니다.
• 4. 키보드 초점 표시자의 시각적 가시성(WCAG 2.4.7, 2.4.11): CSS에 :focus { outline: none; }을 걸어두고 대체 스타일을 지정하지 않았거나, position: sticky 고정 헤더 아래로 초점이 가려져 사용자가 자신의 현재 위치를 잃어버리는 문제는 실제 마우스를 치우고 키보드로 탭을 눌러보지 않고는 감지하기 어렵습니다.

실무 배포 전 필수 4단계 수동 검토 루틴

개발 팀과 QA 팀은 자동 검사 도구의 통과를 '출시 준비 완료'가 아닌 '수동 검토를 시작할 수 있는 최소한의 조건'으로 정의해야 합니다. 배포 전 체크리스트에 다음 4단계 수동 검증 순서를 의무화할 것을 권장합니다.

첫 번째 단계는 'No-Mouse 키보드 완주 테스트'입니다. 마우스나 트랙패드를 물리적으로 멀리 치우고, Tab, Shift+Tab, Enter, Space, Escape, 방향키만을 사용하여 사이트의 핵심 시나리오(회원가입, 로그인, 상품 검색, 결제 진행 등)를 처음부터 끝까지 수행합니다. 이때 초점 링이 명확히 보이는지, 모달 팝업이 떴을 때 배경으로 초점이 새어 나가지 않는지, Esc 키를 눌렀을 때 원래 열었던 버튼으로 초점이 복귀하는지 집중적으로 점검합니다.

두 번째 단계는 '실제 스크린리더 청취 테스트'입니다. 윈도우 환경의 무료 표준인 NVDA(NonVisual Desktop Access) 또는 macOS/iOS의 VoiceOver를 실행하고, 모니터 화면을 보지 않은 채 귀로만 낭독되는 내용을 들으며 과업을 수행해 봅니다. 버튼의 역할(Role), 현재 상태(Expanded/Collapsed, Selected, Checked), 오류 메시지가 명확하게 전달되는지 점검합니다.

세 번째 단계는 '200% 화면 확대 및 텍스트 리플로우 검사(WCAG 1.4.10)'입니다. 브라우저 확대 비율을 200%로 설정했을 때 가로 스크롤바가 생기지 않고 콘텐츠가 한 열로 유연하게 재배치되는지, 텍스트가 겹치거나 잘려 나가는 영역이 없는지 확인합니다.

네 번째 단계는 '고대비 모드 및 강제 색상 모드(Forced Colors Mode) 확인'입니다. Windows 고대비 모드를 활성화했을 때, 배경 이미지로 처리한 아이콘이나 커스텀 보더가 완전히 사라져 조작 버튼을 분간할 수 없게 되는 치명적인 결함이 없는지 점검합니다.

기계적 점수 만능주의에서 실질적 사용자 경험으로의 전환

웹 접근성의 궁극적인 목적은 규제 기관의 벌금을 피하거나 감사 리포트에 100점짜리 인증 배지를 붙이는 것이 아닙니다. 정보 접근에 제약이 있는 실제 사용자가 비장애인과 동등하게 웹서비스의 가치를 누릴 수 있도록 기술적 장벽을 허무는 데 있습니다.

자동 검사 도구는 오타를 잡아주는 맞춤법 검사기일 뿐, 글 전체의 감동과 논리적 완결성을 보장해주지 못합니다. 자동 도구로 코드의 기초적인 문법적 결함을 빠르게 소거한 뒤, 인간 개발자와 기획자의 섬세한 수동 검토를 통해 의미와 맥락을 완성하는 2단계 검증 체계야말로 가장 안전하고 성숙한 웹 접근성 실무 접근법입니다.

자동화 도구(axe, Lighthouse)가 탐지할 수 있는 접근성 이슈의 실제 통계적 커버리지

많은 소프트웨어 개발팀이 Lighthouse 접근성 점수 100점을 획득하거나 axe-core 자동화 테스트를 통과하면 웹 접근성을 완벽히 준수한 것으로 오해합니다. 그러나 영국 정부 디지털 서비스(UK GDS) 및 미국 접근성 전문 연구 기관의 실증 연구에 따르면, 자동화 도구가 탐지할 수 있는 웹 접근성 결함은 전체의 약 30%에서 40% 수준에 불과합니다.

자동화 도구가 탐지하지 못하는 대표적인 영역은 대체 텍스트의 문맥적 적절성, 논리적 초점 순서의 의미적 자연스러움, 상태 변화의 사용자 인지성 등입니다. 이미지에 alt 속성이 존재하기만 하면 자동화 도구는 100점 판정을 내리기 때문입니다.

• 자동화 탐지 한계: 전체 접근성 결함의 약 30~40%만 기계적으로 식별 가능
• 인간 검증 필수 영역: 이미지의 문맥상 적절성, 색상 단독 정보 전달 여부, 초점 이동의 인지적 자연스러움
• 도구의 역할: 단순 규격 위반을 빠르게 걸러내는 1차 필터일 뿐, 최종 적합성의 보증서가 아님

개발팀 스프린트에 즉시 통합할 수 있는 5단계 수동 접근성 회귀 프로토콜

CI 파이프라인의 자동화 테스트를 보완하기 위해 프론트엔드 팀이 배포 전 15분 이내에 완료할 수 있는 5단계 수동 검증 프로토콜을 정례화해야 합니다.

마우스에서 손을 떼고 오직 키보드만으로 모든 기능을 조작해보는 키보드 단독 탐색, 초점 표시 인지성 검사, 200% 브라우저 줌 리플로우 검사, OS 고대비 모드 검사, 그리고 스크린리더 실측 탐색의 5단계를 거치면 자동화 도구가 놓치는 60% 이상의 결함을 사전에 완벽히 차단할 수 있습니다.

• 1단계 키보드 단독 탐색: 마우스 없이 Tab/Enter/Space/Esc만으로 핵심 전환 완수 테스트
• 2단계 초점 시각적 인지성: 모든 포커스 상태에서 명확한 아웃라인 및 헤더 가려짐 부재 확인
• 3단계 200% 줌 리플로우: 가로 스크롤바 없는 유연한 텍스트 래핑 검증
• 4단계 고대비 모드(Windows Contrast): 텍스트 및 경계선의 시각적 증발 여부 확인
• 5단계 스크린리더 헤딩 탐색: H키, K키를 통한 정보 구조의 청각적 자연스러움 청취