axe-core vs IBM Equal Access vs ViewCheck — 엔진 교차검증

세 접근성 자동검사 엔진이 같은 페이지에서 서로 다른 문제를 잡는다는 것, 그게 우리가 교차검증을 포기 못 하는 이유

---

들어가며 — "접근성 자동검사 다 했는데요"라는 말 앞에서

공공 웹 접근성 작업을 해본 사람이라면 이 장면을 안다. 개발팀에서 "접근성 자동검사 다 했습니다"라고 보고한다. 어떤 도구를 썼는지 물으면, 열에 아홉은 axe-core라고 답한다. 브라우저 확장 프로그램으로 돌렸거나, CI 파이프라인에 연동했거나, 어쨌든 axe-core 기반의 무언가였을 가능성이 높다. 오류 0건이 나왔다면 그걸 "접근성 통과"로 결론 짓는다.

그런데 같은 페이지를 IBM Equal Access Checker로 돌리면 다른 항목들이 걸린다. 또 HTML CodeSniffer로 돌리면 또 다른 경고가 나온다. 세 도구가 같은 HTML을 보고 있는데, 서로 다른 문제를 리포트한다. 이게 왜 그럴까? 어떤 도구가 맞고 어떤 도구가 틀린 걸까? 그리고 ViewCheck는 이 상황을 어떻게 다루고 있을까?

이 편은 그 질문을 붙잡고 가는 글이다. 접근성 자동검사 엔진 비교라는 주제는 단순히 "어떤 도구가 좋다"는 이야기가 아니다. 각 엔진이 어떤 철학으로 설계되었고, 어떤 규칙을 어떻게 해석하며, 어디서 교차하고 어디서 갈라지는지를 이해해야 한다. 그리고 그 이해 위에서, 여러 엔진의 결과를 교차검증함으로써 단일 도구보다 더 높은 신뢰도를 얻을 수 있다는 것 — 이게 이 편이 하고 싶은 이야기다.

미리 솔직하게 말해두자. 접근성 자동검사는 아직도 어렵다. 자동화로 잡을 수 있는 문제의 한계가 분명히 있고, 교차검증이 만능도 아니다. 우리가 지금 하는 실험이 최선의 답이라고 주장하는 게 아니다. 다만 "도구 하나로 끝"이라는 생각보다는, "도구마다 잡는 게 다르다는 걸 알고 함께 쓴다"는 접근이 더 낫다는 것 — 그 방향을 공유하고 싶다.

---

웹 접근성 자동검사의 지형 — 왜 이렇게 많은 엔진이 존재하는가

본격적인 비교에 앞서, 왜 접근성 자동검사 엔진이 하나가 아닌지부터 짚고 가자. 애초에 하나의 '표준 도구'가 있었다면 이런 혼란이 없었을 텐데.

웹 접근성의 국제 표준은 W3C가 관리하는 **WCAG(Web Content Accessibility Guidelines)**다. 2023년 10월, WCAG 2.2가 W3C Recommendation으로 최종 공표됐다(W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", 2023). 그리고 2025년에는 WCAG 2.2가 ISO/IEC 국제 표준으로도 승인됐다(W3C, 보도자료, 2025). 기준 자체는 이렇게 공식화되어 있다.

문제는 이 기준이 '문서'라는 점이다. WCAG는 성공 기준(Success Criteria)을 정의하지만, 그 기준이 특정 HTML 구조에서 충족되는지를 어떻게 자동으로 판단할지는 WCAG가 결정하지 않는다. 그 해석의 빈틈을, 각 도구 개발사가 각자의 방식으로 채운다.

예를 들어 WCAG 2.1의 1.1.1 항목("모든 비텍스트 콘텐츠에는 텍스트 대안이 있어야 한다")을 생각해 보자. 이미지에 alt 속성이 있으면 자동검사는 통과로 판정한다. 그런데 alt 텍스트가 "image.png"라거나 "사진"이라면? 규칙 상으로는 속성이 존재하니 통과지만, 실제로는 의미 없는 텍스트다. 이런 '의미 있는 대안 텍스트'인지는 자동으로 판단할 수 없다. 도구마다 이 경계를 어디에 그을지가 다르고, 그게 결과의 차이로 이어진다.

게다가 WCAG 성공 기준 하나에도 여러 해석이 가능한 경우가 많다. 명확한 fail로 판정할 수 있는지, 경고(warning)로만 올릴 것인지, 아니면 수동 검토가 필요한 알림(notice)으로 처리할 것인지. 이 판단이 엔진마다 다르다.

여기에 또 다른 변수가 있다. W3C는 WCAG 기준의 자동화 가능성을 높이기 위해 ACT(Accessibility Conformance Testing) 규칙을 별도로 개발하고 있다. ACT 규칙은 특정 WCAG 성공 기준을 어떻게 자동 테스트할지를 표준화한 절차다. axe-core는 이 ACT 규칙 구현체 중 하나로 W3C에 등록되어 있다(W3C WAI, "Axe-core ACT Implementation"). 하지만 모든 도구가 ACT를 따르는 건 아니고, ACT 규칙이 모든 WCAG 기준을 커버하는 것도 아니다. 그래서 도구마다 커버리지도, 판정 방식도 다를 수밖에 없다.

결국 "왜 이렇게 많은 엔진이 존재하는가"에 대한 답은 이렇다. 기준은 있지만, 그 기준의 자동 판정 방법은 표준화되지 않았다. 그 간극을 각 도구 개발사가 각자의 방식으로 해석하고 구현하다 보니, 같은 페이지를 보면서도 서로 다른 결과가 나온다.

---

axe-core — 가장 널리 쓰이는 엔진의 설계 철학

접근성 자동검사 엔진 이야기를 하면 axe-core 빼고 시작할 수가 없다. 전 세계에서 가장 많이 쓰이는 오픈소스 접근성 검사 엔진이다. Deque Systems가 처음 개발했고, 누적 다운로드 수가 40억 회를 넘었다(Deque Systems, "Axe-core by Deque", 공식 사이트). 구글, 마이크로소프트 같은 대형 테크 기업들이 신뢰한다고 알려져 있고, Lighthouse(Chrome DevTools에 내장된 웹 품질 도구)의 접근성 검사도 axe-core를 기반으로 한다.

axe-core의 가장 큰 설계 원칙은 **"제로 거짓 양성(zero false positives)"**이다(Deque Systems 공식). 자동검사 도구가 "이건 문제야"라고 말했는데 실제로는 문제가 아닌 경우 — 이걸 거짓 양성(false positive)이라고 한다. Deque는 이 거짓 양성을 철저히 억제하는 것을 axe-core의 핵심 원칙으로 내세운다. 개발자들에게 불필요한 경고를 보내지 않겠다는 약속이다.

이 원칙의 결과로 axe-core는 판정을 꽤 보수적으로 유지한다. 자동으로 "이건 확실히 실패"라고 말할 수 있을 때만 실패(violation)로 표시하고, 판단이 애매한 경우는 "검토 필요(needs review)"나 불완전한(incomplete) 상태로 남긴다. 그래서 거짓 양성이 적은 대신, 거짓 음성(false negative — 실제 문제가 있는데 통과로 처리하는 것)이 상대적으로 더 많을 수 있다는 트레이드오프가 있다.

버전 측면에서 axe-core는 4.5 버전부터 WCAG 2.2를 지원하기 시작했고(Deque, "Axe-core 4.5: First WCAG 2.2 Support and More"), 최신 버전(4.9 기준, 2024년)에서는 약 90개의 개별 규칙을 구현하고 있다. WCAG 2.0, 2.1, 2.2의 A·AA·AAA 수준과 함께 모범 사례(best practices) 규칙도 포함된다. 주목할 만한 변화 중 하나는 WCAG 2.2에서 4.1.1 파싱(Parsing) 기준이 제거된 것인데, Deque는 이에 맞춰 axe-core의 관련 규칙 처리 방식도 업데이트했다(Deque, "WCAG 2.2 Removes 4.1.1 Parsing and How axe-core is Impacted").

axe-core가 특히 강한 영역이 있다. 색상 대비, ARIA 속성의 유효성, 레이블-컨트롤 연결, 키보드 탐색 구조 등 — HTML/CSS 수준에서 구조적으로 판정할 수 있는 것들이다. 반면 "이 alt 텍스트가 충분히 의미 있는가", "이 색상 조합이 시각적으로 구분 가능한가" 같은 주관적 판단이 필요한 영역은 자동 판정을 피한다.

axe-core의 또 다른 특징은 생태계의 두께다. axe-core를 기반으로 한 파생 도구들이 많다. axe DevTools(유료 확장), axe-playwright, axe-puppeteer, Cypress + axe-core, Jest + jest-axe 등. 테스트 파이프라인 어디에나 꽂아 쓸 수 있는 유연성이 있다. 이 생태계 때문에 사실상 접근성 자동검사의 표준처럼 자리 잡았다. 그러다 보니 "axe 통과 = 접근성 통과"로 단순화되는 오해도 생겼는데, 이건 좀 뒤에 짚어보자.

2025년 Deque는 AI를 활용한 새로운 방향을 발표했다. 기계 학습과 고급 비전(vision) 기술을 활용해 기존 자동화가 놓치는 이슈를 탐지하면서도 제로 거짓 양성 원칙을 유지하겠다는 것이다(Deque, "Advancing AI for axe", 2025). 자동화의 커버리지를 높이는 방향으로 진화 중이라는 신호다.

---

IBM Equal Access Checker — 다른 철학, 다른 커버리지

IBM Equal Access Checker는 IBM이 개발하고 오픈소스로 공개한 접근성 검사 도구다. 핵심 엔진인 accessibility-checker-engine과 함께, 브라우저 확장 프로그램, Node.js 기반 통합 모듈, Cypress 래퍼 등 다양한 형태로 제공된다(IBM, Equal Access GitHub, IBMa/equal-access). IBM의 Accessibility Toolkit에 포함되어 있으며, Plan → Design → Develop → Verify라는 단계별 접근법의 'Verify' 단계에서 핵심 역할을 한다(IBM, "IBM Equal Access Toolkit", ibm.com/able/toolkit).

IBM Equal Access가 axe-core와 가장 크게 다른 점은 판정 철학이다. axe-core가 거짓 양성을 극도로 경계하는 반면, IBM Equal Access는 상대적으로 더 '민감하다'. 실제로 여러 사용자 리뷰와 비교 분석에서 IBM Equal Access가 axe-core보다 더 많은 경고(warning)와 잠재적 문제를 리포트하는 경향이 있다는 평가가 나온다(SparkBox, "IBM Equal Access Browser Extension Review"). 이 말은 거짓 양성이 더 많을 수 있다는 뜻이기도 하지만, 동시에 axe-core가 조용히 넘어가는 잠재적 문제를 더 많이 표면화한다는 의미이기도 하다.

IBM Equal Access의 또 다른 특징은 우선순위 체계다. IBM은 자체적인 접근성 요구사항을 운영하며(IBM, "IBM accessibility requirements"), 이 요구사항에 따라 Level 1(가장 중요)부터 Level 3(낮은 우선순위지만 필요)까지 단계를 구분한다. 이론적으로는 어떤 문제를 먼저 고쳐야 하는지 우선순위를 제시하는 구조인데, 실제 확장 프로그램 인터페이스에서는 이 우선순위가 직관적으로 드러나지 않아 사용자가 어디서부터 시작해야 할지 헷갈릴 수 있다는 지적도 있다(SparkBox 리뷰).

색상 대비 처리 방식도 주목할 만한 차이점이다. IBM Equal Access는 색상 대비 검사를 '위반(violation)'이 아닌 '검토 필요(needs review)'로 올리는 경우가 있다. 색상 대비가 분명히 기준 미달인 경우도 경고로 처리하는 경우가 있다는 것이다(Red Hat Design System, "Accessibility tools"). 반면 axe-core는 색상 대비 기준 미달을 명확한 violation으로 판정하는 편이다. 같은 대비 비율을 보고 한 도구는 "실패"라고 하고, 다른 도구는 "한번 확인해 봐"라고 하는 상황이 생기는 것이다.

중요한 점은, 이 두 도구를 함께 사용하면 한 도구만 쓸 때보다 더 넓은 범위의 문제를 발견할 수 있다는 것이다. 한 분석에서는 "IBM Equal Access Checker와 axe DevTools를 함께 사용하면 어느 하나만 쓸 때보다 더 많은 위반을 탐지할 수 있으며, 두 도구 모두 공통으로 표시하는 위반은 더 높은 리스크의 문제일 가능성이 있다"고 정리했다(SparkBox, IBM Equal Access 리뷰). 교차검증의 가치가 여기서 드러난다. 두 도구가 모두 "이건 문제야"라고 말한다면, 그 문제는 특히 주목할 가치가 있다.

---

HTML CodeSniffer — 오래된 엔진의 독자적 영역

HTML CodeSniffer는 Squiz Labs가 개발한 JavaScript 기반 접근성 검사 도구다(Squiz Labs, HTML_CodeSniffer GitHub; squizlabs.github.io/HTML_CodeSniffer). axe-core나 IBM Equal Access에 비해 덜 주목받지만, 공공 웹 접근성 점검 도구로서 독자적인 위치를 가지고 있다. 가장 큰 특징은 3단계 구분이다. 단순히 통과/실패가 아니라, 오류(Error), 경고(Warning), 알림(Notice)의 세 수준으로 결과를 분류한다.

HTML CodeSniffer의 공식 문서에 따르면 세 구분은 이렇게 정의된다. "오류(Error)는 사용자에게 웹 접근성 위반이 발생한 것으로 판정되는 항목, 경고(Warning)는 잠재적인 문제로 감지되었지만 수동 검토가 필요한 항목, 알림(Notice)은 자동으로 감지할 수 없어 수동으로 확인해야 하는 항목"이다(squizlabs.github.io/HTML_CodeSniffer). 이 구분이 유용한 이유는, 자동 판정이 가능한 것과 사람의 눈이 필요한 것을 명시적으로 분리하기 때문이다. '경고'나 '알림' 항목이 많다는 것은 그 페이지에 수동 검토가 필요한 영역이 많다는 신호이기도 하다.

HTML CodeSniffer가 다루는 표준은 WCAG 2.1(A, AA, AAA)과 미국 Section 508이다. WCAG 2.2는 아직 완전 지원이 이뤄지지 않았다는 점은 한계로 지적된다(GitHub 이슈 #214). 오픈소스 프로젝트 특성상 업데이트 주기가 axe-core보다 느리다는 점도 고려해야 한다.

그럼에도 HTML CodeSniffer가 여전히 독자적 가치를 갖는 이유가 있다. 북마클릿(bookmarklet) 형태로 누구나 쉽게 실행할 수 있고, 별도 설치 없이 팝업 감사 인터페이스를 제공한다. 그리고 결과를 문제 유발 요소까지 하이라이트해 보여준다는 점에서, 빠른 육안 점검 용도로 유용하다. ViewCheck가 HTML CodeSniffer를 보조 엔진으로 포함시킨 이유 중 하나도 이 가시성 때문이다.

---

자동검사가 잡을 수 있는 것과 잡을 수 없는 것

세 엔진의 특징을 살펴봤으니, 이번에는 더 근본적인 질문으로 들어가자. 접근성 자동검사는 애당초 얼마나 많은 문제를 잡을 수 있는가?

Deque가 2,000건 이상의 감사, 13,000개 이상의 페이지(총 300,000개 이상의 이슈)를 분석한 연구에 따르면, axe-core 기반 자동화 테스트는 전체 접근성 이슈의 **57.38%**를 탐지했다(Deque, "The Automated Accessibility Coverage Report"; BusinessWire, "Deque Study Shows Its Automated Testing Identifies 57 Percent of Digital Accessibility Issues", 2021). 여기에 반자동(Intelligent Guided Tests, IGT)을 추가하면 80.39%까지 올라간다고 Deque는 밝혔다.

그런데 이 57%라는 수치를 어떻게 해석해야 할까. Deque 자신도 인정하듯, 이건 "WCAG 성공 기준 개수 기준"이 아니라 "실제 이슈 볼륨 기준"으로 측정한 값이다. WCAG 기준 개수로 보면 자동화가 커버할 수 있는 비율은 더 낮다. 다른 분석들은 자동화 도구들이 전반적으로 WCAG 위반의 25~40%만 탐지한다고 본다(ExceedAbility, "Manual vs Automated Accessibility Testing: Coverage, Cost and Where Each Wins"). 측정 방법에 따라 수치가 다르게 나온다는 점 자체가 이 영역의 복잡성을 보여준다.

자동검사가 잘 잡는 것들은 이렇다. 색상 대비 기준 미달, alt 속성 누락, 폼 레이블 미연결, ARIA 속성 오용, 키보드 포커스 가능 여부, 이미지 버튼의 텍스트 레이블 누락 같은 구조적·규칙적 문제들. 이건 HTML과 CSS를 분석하면 비교적 명확하게 판정할 수 있다.

반면 자동검사가 못 잡는 것들이 있다. alt 텍스트가 존재하지만 의미 없는 경우("이미지", "image001.jpg"), 읽기 순서가 시각적 배치와 다른 경우, 복잡한 커스텀 위젯의 실제 키보드/보조기술 상호작용, 동적으로 변경되는 콘텐츠의 접근성, 인지적 접근성(읽기 어렵거나 복잡한 언어), 색상 정보에만 의존한 의미 전달(색맹 사용자 관련). 이런 건 사람이 직접 경험해 봐야, 혹은 보조기술(스크린 리더, 키보드만, 고대비 모드 등)을 실제로 써봐야 안다.

이 한계를 직시하는 게 중요하다. "자동검사 오류 0건 = 접근성 완벽"이라는 등식은 존재하지 않는다. 오류 0건은 "자동으로 탐지 가능한 명백한 위반이 없다"는 뜻이지, 접근성 문제가 없다는 뜻이 아니다. 자동검사는 강력한 첫 번째 체에 비유할 수 있다. 큰 돌멩이를 걸러내는 데 효과적이지만, 작은 모래알은 다 빠져나간다. 접근성이라는 체에 걸리는 작은 모래알들은 수동 검사와 실제 보조기술 테스트로만 잡을 수 있다.

그렇다면 자동검사는 의미가 없는가? 전혀 그렇지 않다. "빠르게, 반복적으로, 구조적인 문제를 놓치지 않도록" 하는 데 자동검사는 매우 유효하다. CI 파이프라인에 통합해 새 코드가 합쳐질 때마다 자동으로 구조적 위반을 걸러내는 역할 — 이건 수동으로 할 수 없는 일이다. 핵심은 자동검사를 '끝'이 아니라 '시작'으로 보는 것이다.

---

엔진마다 잡는 게 다르다 — 실제로 어떻게 차이가 나는가

이제 세 엔진이 실제로 어떻게 다른 결과를 내는지 좀 더 구체적으로 들여다보자.

**색상 대비(Color Contrast)**를 예로 들어보자. WCAG 2.1 기준 1.4.3에 따르면 일반 텍스트는 4.5:1 이상의 대비비를 가져야 한다. 이건 수치로 자동 측정 가능한 영역이다. 그런데 세 도구가 같은 요소를 보고 다른 결론을 낼 수 있다. axe-core는 배경색과 전경색을 CSS에서 읽어 명확하게 계산해 위반(violation)으로 올린다. IBM Equal Access는 비슷한 계산을 하지만 결과를 '검토 필요'로 분류하는 경우가 있다. HTML CodeSniffer는 오류나 경고로 표시할 수 있는데, 판정 기준의 세부 구현이 조금 다를 수 있다. 같은 픽셀, 같은 WCAG 기준인데 결과 표현이 다른 것이다.

ARIA 속성 오용의 경우는 더 복잡하다. axe-core는 ARIA 속성의 유효성 검사를 꽤 정밀하게 한다. aria-label이 빈 문자열이거나, role="dialog"인데 aria-labelledby가 없거나 하는 식의 오류를 잡는다. IBM Equal Access도 비슷한 검사를 하지만, 어떤 규칙을 더 엄격하게 해석하느냐에서 차이가 생긴다. HTML CodeSniffer는 ARIA 속성 검사에서 다소 덜 세밀한 편이다. 결과적으로 axe-core가 잡는 ARIA 관련 위반이 IBM Equal Access나 HTML CodeSniffer에서는 누락되는 경우가 있고, 반대로 IBM Equal Access가 표면화하는 경고를 axe-core는 조용히 넘기는 경우도 있다.

폼 레이블 연결에서도 차이가 난다. <input>에 <label>이 없거나, for 속성이 잘못 연결되어 있는 경우는 세 도구 모두 잡을 가능성이 높다. 그런데 aria-label로 레이블을 제공한 경우는? 이게 충분한지, 아니면 여전히 가시적 레이블이 필요한지에 대한 판단이 도구마다 다를 수 있다. axe-core는 aria-label이 있으면 레이블 있음으로 처리하는 편이고, IBM Equal Access는 가시적 레이블의 부재를 경고로 올리는 경우가 있다.

포커스 순서와 키보드 탐색은 자동 판정의 경계가 가장 모호한 영역 중 하나다. tabindex가 양수 값을 가지면 DOM 순서와 다른 탭 순서가 생길 수 있고 이건 잡을 수 있다. 하지만 CSS로 시각적 순서를 바꿔서 논리적 읽기 순서와 불일치가 생기는 경우 — 이건 자동으로 판정하기 매우 어렵다. 세 도구 모두 이 경우에는 완전한 판정보다는 알림(notice)이나 수동 검토 권고 수준에 그친다.

동적 콘텐츠는 자동검사의 공통 약점이다. 페이지 로드 후 JavaScript로 생성되는 콘텐츠, 모달 다이얼로그 열림/닫힘 시 포커스 관리, 자동 새로고침되는 콘텐츠의 ARIA live region 구현 — 이런 것들은 정적 스냅샷을 분석하는 방식으로는 제대로 잡기 어렵다. ViewCheck가 Playwright로 실제 브라우저를 띄워 동적 렌더링 결과를 수집하는 이유가 여기에 있다.

이 차이들을 정리하면, 각 엔진은 WCAG라는 같은 기준을 향해 있지만, 어디에 더 민감하게 반응하고, 어떤 경우에는 조용히 있을지를 서로 다르게 설계했다. 어느 도구가 '맞다'가 아니라, 도구마다 잘 보는 영역이 다르다.

---

교차검증의 논리 — 왜 세 엔진을 함께 쓰는가

세 엔진이 잡는 것이 다르다는 걸 이해하면, 교차검증의 논리는 자연스럽게 따라온다. 하나의 엔진만 쓰면 그 엔진의 사각지대에 있는 문제들을 모두 놓친다. 세 엔진을 함께 돌리면 각자의 사각지대가 서로 다르기 때문에 전체 커버리지가 올라간다.

여기서 '교차검증'이 어떤 방식으로 가치를 만드는지 생각해 볼 수 있다.

첫째, 공통 위반의 우선순위 상승. 세 도구 중 두 개 이상이 같은 문제를 잡으면, 그 문제는 더 높은 신뢰도를 갖는다. 이미 앞에서 인용한 것처럼, "두 도구 모두 공통으로 표시하는 위반은 더 높은 리스크의 문제일 가능성이 있다"는 분석이 있다. 공통 위반을 우선 순위에 놓는 것이 합리적인 전략이 된다.

둘째, 엔진별 고유 위반의 보충. axe-core는 잡지 않지만 IBM Equal Access는 경고로 올리는 것들, HTML CodeSniffer는 알림(notice)으로 표면화하는 것들 — 이것들을 버리지 않고 수동 검토 대기열로 넘긴다. 그러면 단일 엔진보다 더 많은 잠재적 문제를 담당자가 인식할 수 있다.

셋째, 거짓 양성 필터링. 세 도구 중 하나만 문제라고 하는데 나머지 두 개는 조용하다면, 거짓 양성일 가능성을 의심해 볼 수 있다. 물론 이게 자동으로 거짓 양성을 걸러주지는 않는다. 판단은 여전히 사람이 해야 한다. 하지만 "이 도구만 이걸 이슈라고 한다"는 신호는 수동 검토 전 사전 정보로서 유용하다.

넷째, 커버리지 보충의 투명성. 단일 도구를 쓰면 그 도구가 보지 않는 영역을 사용자는 아예 모른다. 여러 도구를 함께 쓰면, 적어도 "이 도구들을 써봤고, 이게 걸렸고, 이건 수동으로 봐야 한다"는 더 투명한 그림이 나온다. 100% 자동화는 불가능하다는 것을 인정하되, 어디까지 자동으로 봤고 어디서부터 수동이 필요한지를 명확히 하는 것 — 그게 신뢰 가능한 검사의 출발점이다.

현실적인 어려움도 있다. 세 엔진을 함께 돌리면 결과의 양이 늘어나고, 중복과 충돌을 정리하는 작업이 필요하다. "도구 A는 이게 문제라고 하고, 도구 B는 OK라고 하는데, 어느 걸 따라야 해?"라는 혼란이 생길 수 있다. 교차검증이 가치를 갖으려면, 결과를 통합하고 정리하는 레이어가 필요하다. ViewCheck가 이 작업을 어떻게 하는지가 다음 섹션의 이야기다.

---

ViewCheck의 접근 — 4개 엔진 통합과 KRDS 846규칙의 결합

ViewCheck는 접근성 검사를 위해 단일 엔진에 의존하지 않는다. 현재 4개의 엔진을 통합해서 쓴다.

1. axe-core — 구조적 위반의 기준점. 명확한 violation 항목들을 신뢰도 높게 잡아낸다.
2. IBM Equal Access — axe-core보다 민감한 커버리지. 특히 axe-core가 조용히 넘기는 영역에서 경고를 표면화한다.
3. HTML CodeSniffer — WCAG2AA 수준의 보조 검사. 3단계 분류(오류/경고/알림)로 수동 검토 필요 항목을 명시화한다.
4. KWCAG 34항목 커스텀 검증 — 한국형 웹 콘텐츠 접근성 지침 2.2 기반의 맞춤 검사. 국제 표준(WCAG)을 기반으로 하되, 한국어 환경·공공서비스 특성을 반영한 KWCAG 항목들을 별도로 검증한다.

여기서 KWCAG에 대해 조금 더 설명하자. 한국형 웹 콘텐츠 접근성 지침(KWCAG)은 국제 표준 WCAG를 그대로 번역한 것이 아니라, 한국어 환경과 공공서비스 특성에 맞게 재구성한 지침이다(NIA 디지털 접근성 아카이브, nia-a11y.github.io). 행안부 지침(고시 제2025-46호)이 요구하는 접근성은 WCAG가 아니라 KWCAG를 기준으로 한다. 따라서 글로벌 도구인 axe-core나 IBM Equal Access만으로는 KWCAG의 모든 항목을 커버할 수 없다. 커스텀 검증이 필요한 이유다.

그러면 ViewCheck는 이 4개 엔진의 결과를 어떻게 통합하는가? 핵심은 KRDS 846규칙과의 연결이다. ViewCheck는 접근성 엔진들의 결과를 그대로 던져주는 게 아니라, axe-core 결과를 KRDS 규칙에 매핑한다. 구체적으로 axe-core 99개 규칙 → KRDS 48개 규칙으로의 매핑 테이블이 있다. axe-core가 특정 위반을 잡으면, 그게 KRDS의 어떤 규칙에 해당하는지를 연결시켜 보여준다.

이 매핑의 의미는 두 가지다. 첫째, 공공기관 담당자 관점에서 결과를 읽기 쉬워진다. "axe-core rule: aria-required-attr"보다 "KRDS CP-123: 폼 컨트롤에 적절한 레이블이 필요합니다"가 담당자에게 더 직접적이다. 둘째, 접근성 이슈가 KRDS 846규칙 전체 그림 안에서 어디에 위치하는지를 볼 수 있다. 접근성은 7대 품질 영역 중 하나이고, KRDS 846규칙 안에서 CP(컴포넌트)와 BP(기본 패턴) 영역의 여러 규칙이 접근성과 연관된다. 이걸 분리해서 보지 않고 통합된 맥락으로 제시한다.

한 가지 솔직한 한계를 말해두겠다. 4개 엔진의 결과를 통합하고 KRDS 규칙과 매핑하는 작업은 복잡하다. 엔진 간 결과가 충돌할 때 어떤 것을 최종 판정으로 삼을지, 매핑이 100% 정확한지, KWCAG 커스텀 검증이 모든 항목을 제대로 커버하는지 — 이런 것들이 아직도 개선 중인 영역이다. "4개 엔진을 쓰니 접근성이 완벽하게 검증됩니다"라고 말하는 건 과장이다. 다만 "단일 엔진만 쓸 때보다 더 많은 것을 보고, 그 결과를 더 의미 있게 정리한다"는 방향은 분명하다.

---

KRDS 846규칙과 접근성 — CP와 BP에서의 교차점

ViewCheck의 KRDS 분석에서 접근성은 독립된 탭이기도 하지만, 동시에 846규칙 전체에 스며들어 있다. 이 관계를 조금 더 짚어보자.

KRDS 846규칙은 DS(디자인 스타일), CP(컴포넌트), BP(기본 패턴), SP(서비스 패턴) 4개 카테고리로 구성된다. 이 중 접근성과 가장 직접적으로 연결된 건 CP(446개)와 BP(108개)다.

CP 규칙들의 상당 부분은 컴포넌트가 접근 가능한 방식으로 구현되었는지를 본다. 버튼에 텍스트 레이블이 있는지, 입력 필드에 <label>이 연결되어 있는지, 이미지에 alt 속성이 있는지, 모달에 ARIA 속성이 적절히 붙어 있는지 — 이런 것들이 CP 규칙에 포함된다. axe-core나 IBM Equal Access가 잡는 많은 WCAG 위반이 KRDS CP 규칙과 겹친다.

BP 규칙들에서는 상호작용 패턴의 접근성이 다뤄진다. 폼에 오류가 발생했을 때 오류 메시지가 명확히 제공되는지(이건 WCAG 3.3.1과 연결된다), 동의 절차에서 사용자가 충분한 정보를 받는지, 필터와 정렬 컨트롤이 키보드로 접근 가능한지 — 이런 것들이 BP 규칙에 포함된다.

흥미로운 것은, 이 교차점에서 axe-core 같은 일반 접근성 엔진이 잡는 것과 ViewCheck의 KRDS 규칙 판정이 서로를 보완하는 구조가 생긴다는 점이다. axe-core는 "폼 레이블 없음"을 WCAG 4.1.2 위반으로 잡는다. ViewCheck는 이를 KRDS의 특정 CP 규칙 위반으로도 연결한다. 같은 문제를 두 개의 렌즈로 보는 셈이다. 이게 공공기관 담당자에게는 더 구체적인 개선 방향을 제시하는 데 도움이 된다. "WCAG 4.1.2를 고치세요"보다 "KRDS 컴포넌트 가이드 CP-XXX에 따르면 이 요소에 레이블이 필요합니다"가 더 직접적인 행동 지침이 되기 때문이다.

DS(디자인 스타일) 규칙도 접근성과 간접적으로 연결된다. 색상 대비는 DS 규칙에서 다루는 색상 토큰 관련 항목들과 접근성의 교차점이다. KRDS 디자인 토큰에 정의된 색상 조합이 WCAG 대비 기준을 충족하는지는 DS 분석에서도 검토된다.

---

현실의 사이트에서 — 세 엔진이 각자 다른 무언가를 잡는다

이론으로만 이야기하면 실감이 안 날 수 있으니, 실제로 어떤 상황이 발생하는지 조금 더 구체적으로 이야기해보자. (구체적인 사이트 이름과 수치는 밝히지 않지만, ViewCheck로 실제 공공 사이트들을 분석하면서 반복적으로 보이는 패턴을 정리한 것이다.)

패턴 1: axe-core가 잡고 다른 엔진은 조용한 경우 축약된 ARIA 구현이나 특정 HTML5 요소의 역할 오용 같은 것들. axe-core는 이런 구조적 오류를 꽤 명확하게 잡는다. HTML CodeSniffer는 같은 요소에 대해 알림(notice) 수준에 그치거나 아예 통과로 처리하는 경우가 있다. 이 경우 axe-core의 violation이 가장 신뢰도 높은 신호가 된다.

패턴 2: IBM Equal Access만 경고를 올리는 경우 색상 대비가 axe-core의 판정 임계값에 아슬아슬하게 걸치지 않는 경우, IBM Equal Access가 '검토 필요'로 먼저 알리는 경우가 있다. 계산상으로는 4.5:1을 넘어 통과지만, 특정 폰트 크기나 렌더링 환경에서는 실제로 읽기 어렵게 보일 수 있는 것들. IBM의 '경고'는 이런 경계 케이스를 표면화하는 역할을 한다.

패턴 3: HTML CodeSniffer만 알림(notice)을 올리는 경우 수동으로 확인해야 하는 항목들 — "이 미디어 파일에 대안 텍스트나 대체 수단이 제공되는지 확인하시오" 같은 알림. axe-core는 자동 판정이 어렵다고 보아 조용히 있고, HTML CodeSniffer는 이걸 명시적인 알림으로 올린다. 수동 검토 대기열에 추가할 항목이 늘어나는 것이다.

패턴 4: 세 도구 모두 잡는 경우 이미지 alt 속성 누락, 폼 컨트롤에 레이블 미연결처럼 명확한 구조적 결함. 세 도구 모두 이걸 잡는다. 이 경우가 가장 확실한 우선순위 이슈다. 세 엔진의 합의는 그 문제의 심각성을 강조한다.

패턴 5: 세 도구 모두 통과하지만 실제로는 접근성 이슈인 경우 가장 골치 아픈 패턴이다. 예를 들어 복잡한 데이터 테이블이 HTML 구조상 올바르게 마크업되어 있고 헤더도 있어 자동검사 통과지만, 실제 스크린 리더로 읽으면 정보의 흐름이 혼란스러운 경우. 또는 버튼에 ARIA 레이블이 있고 포커스도 받지만, 레이블 문구가 "버튼1", "확인하기" 같이 맥락 없는 문구인 경우. 이런 건 세 도구 모두 통과시킨다. 여기서부터는 수동 검사와 실제 보조기술 테스트가 필요하다.

이 다섯 패턴이 교차검증이 왜 의미 있는지를 보여준다. 패턴 1~3에서 단일 도구만 썼으면 놓쳤을 것들을 잡을 수 있다. 패턴 4에서 공통 발견으로 우선순위를 세울 수 있다. 패턴 5는 자동화의 한계를 명확히 인식하게 해준다.

---

---

WebAIM Million이 말해주는 현실 — 접근성 위반은 여전히 만연하다

교차검증이 왜 필요한가를 실데이터로 뒷받침해 보자. WebAIM의 "The WebAIM Million" 프로젝트는 매년 상위 100만 개 웹사이트 홈페이지의 접근성을 자동 점검하고 결과를 발표한다.

2025년 보고서(WebAIM, "The WebAIM Million 2025")의 주요 수치를 보면, 100만 개 홈페이지에서 탐지된 접근성 오류가 총 5,096만 건이었다. 페이지당 평균 51개의 오류가 있었다. 전년(56.8개/페이지) 대비 10.3% 감소했지만 여전히 압도적으로 많다.

더 충격적인 건, 94.8%의 홈페이지에 적어도 1개 이상의 WCAG 실패가 있었다는 점이다. 자동 점검을 통과한(오류 0건인) 홈페이지는 5.2%에 불과하다. 그것도 이 점검이 가능한 구조적 위반만 탐지하는 자동화 도구 기준이다. 실제 접근성 준수 비율은 이보다 훨씬 낮을 것으로 추정된다.

가장 흔한 위반 유형들도 주목할 만하다. 홈페이지의 79.1%에서 WCAG AA 수준의 저대비 텍스트가 발견됐고, 이미지 alt 텍스트 누락이 전체 홈페이지 이미지의 18.5%에서 나타났다. 이 두 가지는 axe-core, IBM Equal Access, HTML CodeSniffer 모두가 잡을 수 있는 항목들이다. 그런데 전 세계 상위 사이트들에서 여전히 이런 기본적인 문제들이 광범위하게 발견된다는 것 — 자동검사가 있어도 실제 개선은 매우 더디다는 현실을 보여준다.

이 데이터를 공공 웹에 대입해 보자. 한국의 공공 웹사이트들은 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25.)과 KWCAG 2.2 기준을 충족해야 한다. 그런데 모든 기관이 자체적으로 접근성을 정기 점검하고 있을까? 현실적으로 쉽지 않다. 담당자가 적고, 전문성이 부족하고, 예산도 한정되어 있다. 자동화 도구로 빠르게, 넓게 훑어주고 결과를 제시하는 것의 가치가 여기서 나온다.

동시에 이 데이터는 자동화의 한계도 보여준다. 5,096만 건의 오류를 자동으로 발견했는데도 여전히 94.8%가 실패한다. 자동검사의 역할은 "다 잡는 것"이 아니라 "빠르게, 일관되게, 구조적인 것들을 먼저 잡는 것"이다. 그 위에 수동 검사를 얹어야 진짜 접근성 개선이 이뤄진다.

---

axe-core와 KRDS 규칙 매핑 — 왜 매핑이 필요한가

ViewCheck에서 axe-core 결과를 KRDS 규칙으로 매핑하는 작업은, 생각보다 단순하지 않은 문제다. 이 작업을 왜 하고, 어떤 어려움이 있는지를 좀 더 솔직하게 이야기해 보자.

axe-core의 규칙들은 WCAG 성공 기준을 기반으로 정의된다. 예를 들어 color-contrast 규칙은 WCAG 1.4.3, aria-required-attr는 WCAG 4.1.2 같은 식이다. KRDS 규칙은 이와 달리 KRDS 컴포넌트·패턴 명세를 기반으로 정의된다. 두 체계가 독립적으로 설계되었기 때문에, 1:1 매핑이 아닌 경우도 많다.

예를 들어 axe-core의 label 규칙(폼 입력에 레이블 없음)은 WCAG 4.1.2와 연결되고, KRDS에서는 버튼·입력·선택 같은 다양한 컴포넌트의 CP 규칙 여러 개와 연결될 수 있다. 하나의 axe-core 규칙이 여러 KRDS 규칙을 가리키는 경우가 있고, 반대로 KRDS 규칙 하나가 여러 axe-core 규칙과 연결되는 경우도 있다.

또한 axe-core가 WCAG 기준을 따르는 반면, KWCAG와 WCAG는 완전히 동일하지 않다. KWCAG는 WCAG를 기반으로 하되 한국어 환경에 맞게 재구성됐고, 일부 항목은 WCAG에 없는 한국 특화 기준을 포함한다. 이 차이를 메우는 커스텀 검증 레이어가 KWCAG 34항목 검사다.

이 매핑 테이블이 완벽하다고 말하기 어렵다. 지금도 계속 정교화하고 있는 작업이다. 규칙 하나가 어떤 KRDS 규칙과 연결되는지, 그 연결이 실제로 의미 있는지를 검증하는 건 상당한 도메인 지식이 필요하다. 다만 방향은 분명하다 — 글로벌 접근성 엔진의 결과를 한국 공공 웹의 문맥으로 번역해 주는 레이어, 그게 이 매핑이 하려는 일이다.

---

다중 페이지에서의 접근성 교차검증 — 사이트 전체를 본다는 의미

이 편에서도 다중 페이지 이야기를 빼놓을 수 없다. 접근성 교차검증을 단일 페이지에서만 하는 것과 사이트 전체에서 하는 것은 완전히 다른 이야기다.

메인 페이지는 접근성이 잘 갖춰져 있을 수 있다. 홍보 페이지, 안내 페이지처럼 '보여주기' 위해 신경 쓰는 페이지들은 대체로 더 나은 상태다. 그런데 사용자가 실제로 민감한 경험을 하는 곳은 신청서 작성 페이지, 첨부파일 업로드 화면, 오류 발생 시 안내 화면 같은 '업무 처리 화면'이다. 이런 페이지는 상대적으로 접근성이 덜 챙겨지는 경향이 있다.

ViewCheck가 다중 페이지 분석을 기본으로 하는 이유가 여기 있다. 100개 페이지를 분석하면 각 페이지마다 axe-core, IBM Equal Access, HTML CodeSniffer를 모두 돌리고 그 결과를 집계한다. 메인 페이지는 0개 오류인데 신청 페이지에서 30개 오류가 나오는 패턴 — 이게 사이트 전체의 접근성 현실이다. 메인만 봤으면 "접근성 좋은 사이트"로 결론 냈을 것을, 사이트 전체를 보면 "신청 화면이 취약하다"는 구체적인 문제를 발견한다.

다중 페이지 집계에서 중요한 원칙이 있다. ViewCheck는 사이트 수준의 접근성 판정에 OR 로직을 적용한다. 즉, 사이트의 어떤 페이지에서라도 특정 규칙이 위반으로 판정되면, 사이트 수준에서도 그 규칙은 위반으로 본다. "한 페이지라도 문제가 있으면 사이트 전체의 문제"라는 관점이다. 이건 공공 서비스의 특성에 맞는 접근이다. 시민이 어떤 페이지에 접근했을 때 접근성 장벽을 만났다면, 그게 어떤 페이지든 간에 그 기관의 접근성 문제인 것이다.

---

접근성 자동검사의 미래 — AI와 교차검증이 어떻게 발전할까

잠시 더 긴 시야로 바라보자. 접근성 자동검사 엔진들은 지금 어떤 방향으로 발전하고 있고, 교차검증이라는 접근법은 어디까지 유효할까?

Deque의 최신 방향이 시사적이다. Deque는 2025년에 "axe를 위한 AI 진전(Advancing AI for axe)"이라는 방향을 공식화했다(Deque, "Advancing AI for axe: The next leap in digital accessibility", 2025). 핵심은 기계 학습, 고급 비전 기술, 스크린샷 분석을 활용해 "기존 자동화가 놓치는 이슈"를 AI로 탐지하겠다는 것이다. 단, 제로 거짓 양성 원칙은 유지한다는 조건이 붙는다.

이 방향이 흥미로운 이유는, 지금까지 자동화의 한계로 여겨졌던 것들 — 시각적 접근성, 의미 있는 대안 텍스트 판단, 복잡한 상호작용의 접근성 — 에 AI가 개입하기 시작한다는 신호이기 때문이다. 물론 제로 거짓 양성을 유지하면서 AI로 커버리지를 넓히는 건 기술적으로 쉽지 않은 도전이다. 얼마나 잘 해낼지는 지켜봐야 한다.

ViewCheck가 KRDScan Vision AI 엔진을 통해 스크린샷 기반 시각 분석을 하는 것도 비슷한 방향이다. DOM 구조만으로는 알 수 없는 시각적 요소 — 아이콘만으로 구성된 버튼이 충분한 크기를 가졌는지, 이미지 기반 텍스트가 있는지, 비표준 방식으로 구현된 UI 컴포넌트가 접근 가능한지 — 를 Vision AI로 보완하는 것이다. 이건 여전히 연구 단계에 가깝지만, 방향은 분명하다.

IBM Equal Access도 발전 중이다. 2026년 기준 GitHub 저장소의 최신 업데이트(IBMa/equal-access, 2026년 5월 28일 업데이트 확인)를 보면 지속적으로 규칙이 추가·개선되고 있다. HTML CodeSniffer는 오픈소스 특성상 업데이트 주기가 느리지만, WCAG 2.2 지원 이슈가 커뮤니티에서 논의되고 있다(GitHub 이슈 #214).

중요한 건, 이 엔진들이 각자 발전해도 서로 완전히 같아지지는 않을 것이라는 점이다. 각 도구의 설계 철학과 판정 기준이 다르기 때문에, 완전한 수렴보다는 부분적 수렴이 일어날 가능성이 높다. 즉, 교차검증의 가치는 AI 시대에도 계속 유효할 것이다. 어쩌면 AI 기반 탐지가 강화될수록 교차검증이 더 중요해질 수도 있다. AI 엔진마다 다른 것을 '볼' 수 있기 때문이다.

---

---

교차검증의 실용적 설계 — 결과를 어떻게 정리하고 제시할 것인가

교차검증이 가치 있다는 건 이제 충분히 설명했다. 그런데 실용적인 문제가 남는다. 세 개 이상의 엔진을 돌리면 결과의 양이 늘어나고, 중복이 생기고, 충돌이 생긴다. 이걸 어떻게 정리해서 사용자에게 보여줄 것인가?

ViewCheck가 현재 접근하는 방식은 이렇다.

첫째, 이슈 중복 제거. 세 엔진이 같은 요소의 같은 문제를 세 번 리포트하면 사용자에게 보여줄 때 한 번으로 통합한다. 어떤 엔진이 잡았는지는 내부적으로 기록하지만, 사용자가 같은 문제를 세 번 읽을 필요는 없다.

둘째, 공통 발견 우선 표시. 여러 엔진이 공통으로 잡은 이슈를 더 높은 우선순위로 표시한다. 엔진의 동의가 있다는 것은 그 이슈의 신뢰도를 높여주기 때문이다.

셋째, 엔진별 고유 발견 유지. 한 엔진만 잡은 것도 버리지 않는다. 다만 "이 항목은 복수 엔진에서 확인되지 않았습니다, 수동 검토를 권장합니다" 같은 컨텍스트를 붙인다. 거짓 양성일 수 있다는 가능성을 사용자가 인식하게 하면서도 정보를 숨기지 않는다.

넷째, KWCAG 항목 연결. 모든 이슈를 가능한 한 KWCAG 항목에 연결해 표시한다. "WCAG 1.4.3 위반"보다 "KWCAG 2.2 항목 [인식의 용이성] → 명도 대비"로 표현함으로써, 공공기관 담당자가 "이게 내가 준수해야 하는 어떤 기준인지"를 바로 연결할 수 있게 한다.

다섯째, 수동 검토 대기열 명시. 자동 판정이 어려운 항목들 — HTML CodeSniffer의 알림(notice), IBM Equal Access의 검토 필요 항목 — 을 별도로 모아 "수동으로 확인해야 할 항목" 목록으로 제시한다. 자동화가 어디까지 했고, 사람이 어디서부터 해야 하는지를 명확히 구분하는 것이다.

이 설계가 완벽하지 않다는 걸 알고 있다. 엔진 간 충돌을 어떻게 해석할지, 수동 검토 대기열의 우선순위를 어떻게 매길지 — 이런 것들이 아직도 개선 중인 영역이다. 다만 "단순히 결과를 쏟아내는 것"보다 "결과를 정리해 의미 있는 형태로 전달하는 것"에 더 많은 설계가 필요하다는 걸, 이 작업을 하면서 계속 실감한다.

---

접근성 자동검사의 한계와 수동 검사의 역할

여기서 한 번 멈추고, 자동검사가 절대 대체할 수 없는 영역을 명확히 정리해두고 싶다. 교차검증을 통해 자동화의 커버리지를 높이는 게 중요하지만, 수동 검사를 대체하는 건 불가능하다. 이걸 혼동하면 안 된다.

자동검사가 구조적 위반을 잡는다면, 수동 검사는 사용자 경험의 접근성을 본다.

스크린 리더 사용자가 실제로 이 페이지를 읽을 수 있는가? 각 항목 간의 맥락이 이해되는가? 읽기 순서가 의미 있는가? 키보드만으로 모든 기능에 접근하고 사용할 수 있는가? 저시력 사용자가 확대했을 때 레이아웃이 무너지지 않는가? 색맹 사용자가 정보를 이해하는 데 색에만 의존하는 표시가 없는가? 인지 장애가 있는 사용자가 이해할 수 있는 언어로 작성되었는가? — 이런 것들은 자동으로 판정할 수 없다.

접근성 자동화 도구를 조사한 여러 연구들이 공통으로 말하는 것이 있다. 최선의 접근법은 하이브리드다 — CI 파이프라인에 자동 도구를 통합해 빠른 회귀 검사를 하고, 마일스톤마다 전문가 수동 감사를 수행하고, 보조기술(스크린 리더, 키보드 전용 등)로 실제 사용 시나리오를 테스트하는 것이다(ExceedAbility; TestParty). 이 세 레이어가 함께 작동할 때 비로소 의미 있는 접근성 개선이 이뤄진다.

ViewCheck는 이 세 레이어 중 첫 번째(자동 도구 통합)를 담당한다. 그것도 단일 도구가 아닌 4개 엔진의 교차검증으로. 두 번째와 세 번째는 ViewCheck가 대신할 수 없다. 담당자가, 또는 전문가가 해야 하는 일이다. 우리가 ViewCheck를 "접근성 완벽 인증 도구"가 아닌 "접근성 이슈 탐지 및 우선순위화를 돕는 도구"로 포지셔닝하는 이유가 여기에 있다.

---

공공기관 담당자 관점에서 — 교차검증 결과를 어떻게 활용할 것인가

교차검증의 기술적 이야기를 충분히 했으니, 실제 공공기관 담당자 입장에서 이 결과를 어떻게 활용하면 좋을지를 생각해 보자.

첫 번째 활용법: 우선순위 결정 교차검증 결과에서 여러 엔진이 공통으로 잡은 이슈를 먼저 고친다. 이건 신뢰도가 높고, 외주 개발사에 수정을 요청할 때 "어떤 기준에서, 왜 문제인가"를 명확히 설명할 수 있는 근거가 된다. axe-core violation + IBM Equal Access 경고 + KWCAG 항목 연결이 모두 붙어 있다면, 개발사에 넘길 때 "이 세 도구가 모두 이 요소의 이 문제를 확인했고, KWCAG 2.2 몇 번 항목에 해당합니다"라고 말할 수 있다.

두 번째 활용법: 수동 검토 계획 수립 HTML CodeSniffer의 알림, IBM Equal Access의 '검토 필요' 항목들은 자동으로 판정이 안 된 것들이다. 이걸 무시하지 말고, 수동 검토 대기열로 정리해 두자. 전문 접근성 컨설턴트가 한 번 더 볼 때, 혹은 당담자가 직접 스크린 리더로 페이지를 읽어볼 때 이 목록이 체크리스트가 된다.

세 번째 활용법: 사이트 취약 지점 파악 다중 페이지 분석 결과를 페이지 유형별로 보면, 어떤 유형의 페이지에 접근성 이슈가 집중되어 있는지 파악할 수 있다. 신청 페이지, 로그인 페이지, 게시판 상세 페이지 — 페이지 유형별 취약 지점을 파악하면 한정된 자원을 어디에 집중해야 할지 판단할 수 있다.

네 번째 활용법: 진행 상황 추적 접근성 개선 작업 전과 후에 ViewCheck를 돌려 결과를 비교한다. axe-core violation이 몇 개에서 몇 개로 줄었는지, IBM Equal Access 경고가 줄었는지, KWCAG 항목 통과율이 올랐는지를 수치로 추적할 수 있다. 이건 보고서에 쓸 수 있는 객관적 지표가 된다.

공공기관 접근성 개선이 "언젠가 해야 할 일"에서 "측정 가능하고, 계획 가능한 일"이 될 수 있도록 — 그게 교차검증 결과를 활용하는 방향이다.

---

한국 공공 웹 접근성의 현실 — 기준과 실태 사이

마지막으로 한국 공공 웹 접근성의 현실을 짚어보자. 기준은 갖춰져 있지만 실태는 어떤가?

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 접근성을 7대 품질 영역의 하나로 명시하고, KWCAG 2.2를 준수하도록 요구한다. 한국형 웹 콘텐츠 접근성 지침 2.2(KWCAG 2.2)는 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성의 4원칙 아래 구체적 검사 항목들을 정의한다(a11ykr.github.io/kwcag22). KRDS(krds.go.kr)는 디자인 시스템 수준에서 컴포넌트의 접근성을 내장하여, 시스템을 따르는 것만으로 기본적인 접근성이 확보되도록 설계됐다.

기준은 있다. 그런데 현실은? 전 세계 데이터를 보면 94.8%의 홈페이지에 접근성 위반이 있다(WebAIM Million 2025). 한국 공공 사이트가 이 평균보다 훨씬 나을 것이라고 단정하기 어렵다. NIA(한국지능정보사회진흥원)에서는 웹 접근성 실태조사를 정기적으로 발표하고 있고(nia.or.kr), 매년 접근성 준수율이 조금씩 높아지는 추세지만 여전히 모든 기관이 충분한 수준에 도달해 있지는 않다.

접근성 자동검사 도구가 없던 시절에는 이 실태를 파악하는 것 자체가 어려웠다. 전문 감사 인력이 직접 방문해서 사이트를 점검하는 방식으로는 수천 개의 공공 기관 사이트를 모두 커버하기 불가능했다. 자동화가 이 스케일의 문제를 다룰 수 있게 해준다. 그리고 교차검증이 그 자동화의 신뢰도를 높여준다.

물론 자동화로 실태를 파악했다고 해서 자동으로 개선이 이뤄지지는 않는다. 결과를 담당자가 이해하고, 개선 계획을 세우고, 개발사와 협력해 실제로 고치는 과정이 있어야 한다. ViewCheck가 교차검증 결과를 단순히 수치 나열이 아닌 "우선순위별 이슈 목록", "KRDS 규칙 연결", "수동 검토 가이드" 형태로 제시하려는 이유가 여기 있다. 아는 것에서 고치는 것으로 넘어가는 다리를 놓으려는 것이다.

---

마무리 — 교차검증이 "더 정직한 접근성 검사"를 향하는 길

긴 이야기를 정리해 보자.

axe-core는 가장 넓은 생태계를 가진 엔진이고, 거짓 양성을 억제하는 명확한 원칙 위에 구현되어 있다. IBM Equal Access는 더 민감한 탐지를 하며, axe-core가 조용히 넘기는 경우 경고를 올린다. HTML CodeSniffer는 오류·경고·알림의 3단계 구분으로 자동 판정 가능한 것과 수동 검토가 필요한 것을 명시한다. 세 엔진은 같은 WCAG 기준을 향해 있지만, 어디에 어떻게 반응할지가 다르다.

이 차이를 무시하고 하나의 엔진만 믿으면 그 엔진의 사각지대를 구조적으로 놓친다. 세 엔진을 함께 돌리고 결과를 교차검증하면, 어느 하나만 쓸 때보다 더 넓은 범위의 문제를 발견하고, 공통 발견의 우선순위를 높이며, 수동 검토가 필요한 영역을 명시할 수 있다.

그리고 이 모든 자동검사는 접근성 개선의 절반도 되지 않는다는 것도 기억해야 한다. 자동화는 강력한 첫 번째 체지만, 수동 검사와 실제 보조기술 테스트 없이는 완전한 접근성을 보장할 수 없다.

ViewCheck가 4개 엔진 교차검증을 KRDS 846규칙 및 KWCAG 항목과 연결해 제시하는 것은, 이 복잡한 접근성 검사를 공공기관 담당자가 더 쉽게, 더 의미 있게 활용할 수 있도록 하려는 시도다. 아직 모든 게 완벽하지 않다. 매핑도, 통합도, 제시 방식도 계속 개선 중이다.

다만 방향은 분명하다. "한 도구가 오류 0개 = 접근성 완벽"이라는 단순화를 벗어나, "어떤 도구가, 무엇을, 왜 잡는지를 알고, 복수 엔진의 결과를 교차해 더 신뢰도 있는 판단을 내린다"는 방향으로. 그게 우리가 교차검증을 포기하지 못하는 이유다.

다음 편에서는 접근성의 또 다른 차원, 시각적 접근성 — 디자인 수준에서의 색상 대비, 글자 크기, 터치 타겟 크기 같은 것들을 어떻게 측정하고 KRDS 기준에 비춰보는지를 이야기할 예정이다. 자동검사 엔진이 구조를 보는 동안, 디자인 레벨에서의 접근성은 어떻게 봐야 하는지 — 그 이야기로 이어가겠다.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 WebSearch로 검증했다. 표준·공식 문서, 도구 공식 사이트, 국내외 연구·보고서를 함께 실었다.

국내 — 공식 기준 / 정책자료

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정) 및 품질관리 가이드 수정 안내. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
2. 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2 비공식 한국어 정리. a11ykr. https://a11ykr.github.io/kwcag22/
3. 한국지능정보사회진흥원(NIA), 웹 접근성을 고려한 콘텐츠 제작기법 2.2 — NIA 디지털 접근성 아카이브. https://nia-a11y.github.io/
4. 한국지능정보사회진흥원(NIA), 웹 접근성 실태조사. https://www.nia.or.kr/site/nia_kor/ex/bbs/List.do?cbIdx=99873

해외 — 접근성 표준 / 엔진 공식 문서

5. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2 is a W3C Recommendation", 2023년 10월 5일. https://www.w3.org/news/2023/web-content-accessibility-guidelines-wcag-2-2-is-a-w3c-recommendation/
6. W3C, "W3C Web Content Accessibility Guidelines 2.2 approved as ISO/IEC international standard", 2025. https://www.w3.org/press-releases/2025/wcag22-iso-pas/
7. W3C WAI, "Axe-core ACT Implementation" (axe-core의 W3C ACT 규칙 구현 목록). https://www.w3.org/WAI/standards-guidelines/act/implementations/axe-core/
8. Deque Systems, "Axe-core by Deque — open source accessibility engine for automated testing" (공식 소개). https://www.deque.com/axe/axe-core/
9. Deque Systems, "Automated Testing Identifies 57% Digital Accessibility Issues" (2021년 연구, 2,000건 이상 감사 기반). https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
10. Deque Systems, "The Automated Accessibility Coverage Report" (PDF). https://accessibility.deque.com/hubfs/Accessibility-Coverage-Report.pdf
11. Deque Systems, "Advancing AI for axe: The next leap in digital accessibility", 2025. https://www.deque.com/blog/advancing-ai-for-axe-the-next-leap-in-digital-accessibility/
12. Deque Systems, "Axe-core 4.5: First WCAG 2.2 Support and More". https://www.deque.com/blog/axe-core-4-5-first-wcag-2-2-support-and-more/
13. Deque Systems, "WCAG 2.2 Removes 4.1.1 Parsing and How axe-core is Impacted". https://www.deque.com/blog/wcag-2-2-removes-4-1-1-parsing-and-how-axe-core-is-impacted/
14. IBM, "Equal Access Toolkit — 공식 접근성 툴킷". https://www.ibm.com/able/toolkit/
15. IBM, "Verify — automated (Equal Access Checker 안내)". https://www.ibm.com/able/toolkit/verify/automated/
16. IBM / GitHub, "equal-access" 오픈소스 저장소 (IBMa/equal-access). https://github.com/IBMa/equal-access
17. Squiz Labs, "HTML_CodeSniffer" 공식 사이트. https://squizlabs.github.io/HTML_CodeSniffer/
18. Squiz Labs / GitHub, "HTML_CodeSniffer" 저장소. https://github.com/squizlabs/HTML_CodeSniffer
19. WebAIM, "The WebAIM Million — The 2025 report on the accessibility of the top 1,000,000 home pages". https://webaim.org/projects/million/2025
20. SparkBox, "IBM Equal Access Browser Extension Review" (IBM Equal Access vs axe-core 비교). https://sparkbox.com/foundry/ibm_equal_access_evaluation_tool_website_accessibility_audit_website_accessibility_checker
21. ExceedAbility, "Manual vs Automated Accessibility Testing: Coverage, Cost and Where Each Wins". https://exceedability.com/manual-vs-automated-testing.html
22. Equal Entry, "A Comparison of Automated Testing Tools for Digital Accessibility". https://equalentry.com/digital-accessibility-automated-testing-tools-comparison/

---