KWCAG 2.2 자동 진단 24항목 — ViewCheck는 한국형 웹접근성 지침을 어떻게 읽어내는가

"접근성 점검 다 했어요"라는 말이 실제로 얼마나 어려운 일인지, 자동화로 어디까지 갈 수 있는지를 솔직하게 이야기한다

들어가며 — "접근성은 했어요"라는 말의 무게

공공 웹사이트 담당자와 이야기하다 보면 이런 문장을 꽤 자주 듣는다.

"저희 접근성은 다 했어요. 인증도 받았거든요."

그 말을 듣는 순간 마음속에 떠오르는 질문이 있다. '인증 기준 시점에 어떤 페이지로 받았을까?' '그 뒤로 콘텐츠가 얼마나 바뀌었을까?' '메인만 통과했는데 신청 화면이나 로그인 화면은 어떨까?' '이미지 alt 텍스트는 지금도 채워져 있을까?'

인증을 받았다는 것은 그 시점, 그 페이지 범위가 기준을 충족했다는 뜻이다. 하지만 살아 움직이는 웹사이트에서 접근성은 한 번 받고 끝나는 게 아니다. 콘텐츠가 바뀌고, 개발자가 바뀌고, 배너가 올라가고, 팝업이 생기면서 접근성 문제는 어느 틈엔가 슬그머니 다시 끼어든다.

그래서 우리는 KWCAG 2.2—한국형 웹 콘텐츠 접근성 지침—를 ViewCheck LLM 분석의 24개 기능 중 하나로 다루기로 했다. 매번 사람이 한 페이지 한 페이지 들여다보는 대신, URL 하나로 사이트 전체의 접근성 상태를 자동으로 훑어내는 것. 이게 어디까지 가능하고, 무엇이 아직 어려운지를 이번 편에서 솔직하게 이야기해보려 한다.

밝은 공간에서 휠체어 사용자와 고령자를 포함한 다양한 사람들이 디바이스를 편안하게 사용하는 모습. — 접근성은 특정 사용자를 위한 배려가 아니다. 신체 조건이나 기술 수준에 관계없이 누구나 쓸 수 있는 웹 — 그게 접근성의 출발점이다.

미리 말해두겠다. 자동화로 접근성의 전부를 잡을 수는 없다. 이 글에서도 그 한계를 숨기지 않을 것이다. 다만 '전부를 자동으로 못 하니까 자동화는 쓸모없다'는 결론도 틀렸다. 우리가 답을 찾고 있는 건 그 중간 어딘가다. 자동으로 잡을 수 있는 것을 최대한 빠르고 정확하게 잡고, 사람이 꼭 봐야 하는 것을 명확하게 남겨두는 것. 그 균형점이 어디인지를 같이 생각해보자.

KWCAG 2.2 — 한국형 접근성 지침의 현재

먼저 기준부터 정리하자. KWCAG는 'Korean Web Content Accessibility Guidelines'의 약자다. 한국형 웹 콘텐츠 접근성 지침이라고 풀어 쓴다. 국내에서 공공기관 웹사이트를 운영한다면 반드시 알아야 하는 기준이다.

이 지침은 2005년 처음 제정됐고, 이후 국내외 기술 변화와 법령 개정에 맞춰 지속적으로 개정되어 왔다. 현재 적용되는 버전은 KWCAG 2.2다. 2022년 12월 28일 개정됐고, 한국정보접근성인증평가원(wa.or.kr)에서 해당 지침 원문을 공개하고 있다.

KWCAG 2.2는 세 계층으로 구성된다.

4가지 원칙: 인식의 용이성(Perceivable), 운용의 용이성(Operable), 이해의 용이성(Understandable), 견고성(Robust)
14개 지침: 각 원칙을 달성하기 위한 구체적인 방향
33개 검사항목: 각 지침의 준수 여부를 확인하는 체크포인트

33개 항목의 원칙별 배분은 이렇다.

원칙	지침 수	검사항목 수	핵심 내용
인식의 용이성	3	7	대체 텍스트, 멀티미디어 대체 수단, 색 정보, 텍스트 크기
운용의 용이성	4	9	키보드 접근성, 초점, 응답 시간, 깜박임, 페이지 제목/링크
이해의 용이성	4	6	기본 언어, 사용자 요구 콘텐츠, 오류 정정 등
견고성	2	2	마크업 오류 방지, 웹 애플리케이션 접근성

KWCAG는 국제 표준인 WCAG(Web Content Accessibility Guidelines)를 한국의 법적·기술적 맥락에 맞게 재해석한 지침이다. WCAG 2.2는 W3C가 2023년 10월 5일 W3C 권고안(Recommendation)으로 공식 발표했다. 9개의 새로운 성공 기준이 추가됐으며, 시각 장애, 신체 장애, 인지 장애 등 다양한 사용자 집단을 더 넓게 다루도록 보강됐다.

한 가지 알아두면 좋은 점은, WCAG 2.2를 충족하는 콘텐츠는 WCAG 2.0과 2.1도 충족한다는 것이다. 하위 호환성이 보장된다(W3C WAI, 2023). 한국의 KWCAG 2.2 역시 WCAG 2.2와의 정합성을 높이는 방향으로 개정됐다.

이 기준이 왜 중요한가. 단순히 '좋은 것이어서'가 아니라, 법적 의무이기 때문이다. 다음 장에서 그 법적 맥락을 짚겠다.

법적 의무로서의 웹 접근성 — 장애인차별금지법과 디지털포용법

KWCAG를 알아야 하는 이유는 두 가지 법령에 직결된다.

첫째, 장애인차별금지 및 권리구제 등에 관한 법률(장애인차별금지법) 제21조다. 이 조항은 국가기관 등이 인터넷을 통해 정보나 서비스를 제공할 때 장애인·고령자 등이 쉽게 웹사이트를 이용할 수 있도록 접근성을 보장하도록 명시한다. 준수 의무자는 공공기관에서 시작해 교육기관, 의료기관, 문화예술사업자, 법인 등 광범위하다. 공공기관의 경우 2009년 4월 11일부터 의무 적용이 시작됐고, 이후 단계적으로 의무 범위가 확대됐다.

의무를 지키지 않을 경우의 결과도 분명하다. 국가인권위원회의 권고, 법무부장관의 시정명령, 확정된 시정명령 불이행 시 3,000만 원 이하의 과태료가 부과될 수 있다(법무부·국가인권위원회).

둘째, 디지털 포용법이다. 이 법에 따라 과학기술정보통신부는 웹 접근성 품질인증 기관을 지정한다. 웹 접근성 품질인증은 KWCAG 2.2를 준수한 웹사이트에 품질 마크를 부여하는 제도다. 한국디지털접근성진흥원(kwacc.or.kr) 등이 인증기관으로 활동하고 있다.

현실을 보면, 웹와치(webwatch.or.kr) 기준으로 전체 17,586건의 웹 접근성 품질인증 사이트가 있다. 숫자 자체는 적지 않아 보이지만, 대한민국의 공공 웹사이트 수를 생각하면 아직 갈 길이 멀다. 그리고 인증을 받은 사이트도 인증 이후 콘텐츠 변화로 접근성이 저하되는 경우가 적지 않다.

이 두 가지 법적 맥락이 ViewCheck가 KWCAG 2.2 자동 진단에 공을 들이는 이유다. 담당자가 매번 전문 기관에 의뢰하거나 체크리스트를 직접 들여다보지 않아도, 현재 상태를 빠르게 파악하고 개선 포인트를 찾아낼 수 있도록 하는 것 — 그게 목표다.

태블릿의 고대비 접근성 인터페이스를 손으로 탐색하는 모습의 클로즈업. — 고대비 인터페이스, 충분한 터치 영역, 명확한 포커스 표시 — 이런 것들이 실제 사용자에게 '쓸 수 있는 웹'을 만든다.

자동화로 접근성을 잡는다는 것 — 가능성과 한계의 현실

접근성 점검을 자동화한다는 발상은 새로운 것이 아니다. axe-core, IBM Equal Access Checker, HTML CodeSniffer 같은 오픈소스 도구들이 이미 있다. ViewCheck도 이 도구들을 실제로 활용한다. 그런데 '자동화로 접근성을 잡는다'는 게 정확히 어디까지를 의미하는지, 숫자로 먼저 짚어보자.

Deque의 연구 결과를 보면, 자동화 테스트가 디지털 접근성 이슈의 평균 **57%**를 찾아낼 수 있다고 한다. 이 수치는 2,000건 이상의 감사, 13,000여 페이지, 300,000건 가까운 이슈 데이터를 분석한 결과다(Deque, "Automated Testing Identifies 57% Digital Accessibility Issues", 2021). 다만 이는 '이슈 건수 기준'이다. WCAG 성공 기준(Success Criteria) 기준으로 보면, 자동화로 테스트 가능한 건 33개 중 약 30% 수준인 15~16개 항목에 그친다는 분석도 있다(EasyA11yGuide, "How much can automated accessibility tools do?").

쉽게 말하면 이렇다. 자동화는 자주 반복적으로 나타나는 유형의 이슈(alt 텍스트 누락, 색상 대비 부족, 폼 라벨 연결 누락 등)는 꽤 잘 잡는다. 하지만 '이 링크 텍스트가 의미상 충분한가', '이미지가 실제로 의미 있는 정보를 전달하고 있는가', '키보드로 탐색할 때 논리적 순서가 유지되는가' 같은 맥락 의존적 판단은 자동화로 포착하기 어렵다.

GOV.UK의 접근성 테스트 가이드라인도 같은 입장이다. GOV.UK는 "자동화 도구로 모든 접근성 문제를 발견할 수 없다"고 명확히 밝히며, JAWS·NVDA 같은 스크린 리더와 키보드 전용 내비게이션 등의 수동 테스트를 병행할 것을 요구한다. WCAG 2.2 AA를 충족하지 못하면 법을 위반하는 것일 수 있다는 경고와 함께(GOV.UK Service Manual, "Testing for accessibility").

그렇다면 ViewCheck는 이 현실 앞에서 어떤 선택을 했는가. '자동화로 다 된다'고 말하지 않기로 했다. 대신 다중 엔진 교차 검증이라는 방향을 택했다.

ViewCheck의 접근성 진단 구조 — 4개 엔진을 교차 검증한다

ViewCheck의 접근성 분석은 단일 도구 하나로 돌아가지 않는다. 다음 4가지 엔진의 결과를 교차 검증한다.

① axe-core (Deque) 가장 널리 쓰이는 오픈소스 접근성 엔진이다. WCAG 2.0·2.1·2.2 Level A/AA/AAA, Section 508, 모범 사례 체크를 포함하며 약 90여 개의 개별 규칙을 실행한다(axe-core 4.9 기준). 오탐(false positive)을 극도로 줄이는 방향으로 설계되어 있어, 결과의 신뢰도가 높다. Playwright와의 통합이 용이해 우리 크롤링 파이프라인과 잘 맞는다.

② IBM Equal Access Checker IBM이 개발한 오픈소스 접근성 엔진이다. WCAG 2.2를 포함한 접근성 이슈를 감지하며, 브라우저 확장뿐 아니라 CI/CD 파이프라인에 통합해 사용할 수 있다. axe-core와는 다른 규칙 세트와 판정 기준을 갖고 있어, 두 엔진을 함께 쓰면 각각의 사각지대를 서로 보완한다.

③ HTML CodeSniffer WCAG2AA 표준을 감사하는 도구다. HTML 구조와 ARIA 속성의 규범 준수를 점검한다. 특히 마크업 수준의 오류를 세밀하게 잡아내는 데 강점이 있다.

④ KWCAG 34항목 커스텀 검증 위 세 가지 오픈소스 엔진만으로는 KWCAG 2.2의 한국적 맥락을 전부 커버하지 못한다. 예를 들어 KWCAG에는 WCAG에 없거나 다른 방식으로 해석되는 항목들이 있다. 이런 영역을 위해 우리는 KWCAG 2.2 기준에 맞춘 커스텀 검증 로직을 별도로 구현한다. 이게 4번째 레이어다. (KWCAG 항목이 33개인데 '34항목 커스텀 검증'으로 부르는 이유는, 실제 구현 시 일부 항목을 세분화해 검사하기 때문이다.)

이 네 가지를 교차해서 사용하는 이유는 단순하다. 각 엔진이 잡는 것과 못 잡는 것이 다르기 때문이다. 하나만 쓰면 사각지대가 생기고, 여럿을 교차하면 그 사각지대가 줄어든다. 물론 교차 검증은 결과가 충돌할 때 어떻게 판정할 것인지의 문제를 낳는다. 이 부분은 솔직히 아직 완전히 정답을 찾지 못했다. 어떤 엔진이 '옳다'고 할 때 다른 엔진이 '아니다'라고 하는 경우, 그 충돌을 어떻게 해소할지는 계속 실험 중이다.

KWCAG 2.2 33개 항목 — 자동으로 판정 가능한 것과 아닌 것

이제 KWCAG 2.2의 33개 항목을 하나씩 들여다보자. 우리가 어떤 항목을 어떻게 접근하는지를 원칙별로 정리한다.

원칙 1: 인식의 용이성 (Perceivable) — 7개 항목

정보와 사용자 인터페이스 요소를 인식할 수 있어야 한다는 원칙이다. 7개 항목으로 구성된다.

1.1.1 대체 텍스트 모든 비텍스트 콘텐츠에 대체 텍스트를 제공해야 한다. 이미지에 alt 속성, 장식 이미지에 빈 alt, 의미 있는 이미지에 적절한 설명을 붙이는 것이다. axe-core가 alt 속성 존재 여부를 자동으로 잡는다. 다만 'alt 텍스트가 그 이미지를 제대로 설명하는가'는 자동화가 판단하기 어렵다. "사진.jpg"나 "image001.png"를 alt로 쓴 경우를 기계가 잡아내기는 어렵다.

1.2.1 음성·영상 콘텐츠 대체 오디오나 비디오에 자막, 수어, 또는 텍스트 대본을 제공해야 한다. 이건 대체로 수동 점검 영역이다. 자막 트랙이 존재하는지는 DOM에서 확인할 수 있지만, 그 자막이 내용을 정확히 전달하는지는 사람이 들어봐야 한다.

1.3.1 정보와 관계 구조와 관계가 콘텐츠에 코드로 표현되어야 한다. 예를 들어 폼의 라벨과 입력 필드 연결, 테이블의 헤더 연결, 목록의 의미론적 구조 등이 여기에 해당한다. axe-core와 HTML CodeSniffer가 상당 부분 자동으로 잡는다.

1.3.2 의미 있는 순서 콘텐츠가 의미 있는 순서로 제공되어야 한다. DOM 순서와 시각적 순서가 일치하는지의 문제다. CSS absolute positioning이나 flex/grid를 복잡하게 쓴 페이지에서 읽기 순서가 뒤바뀌는 경우가 있다. 어느 정도는 자동으로 감지할 수 있지만, 복잡한 레이아웃에서는 한계가 있다.

1.3.3 감각적 특성 무의존 방향, 색상, 크기, 모양, 위치 등 감각적 특성에만 의존해 콘텐츠를 이해하게 해서는 안 된다. "빨간 버튼을 클릭하세요"처럼 색에만 의존한 안내는 문제다. 이건 자동화로 잡기 어렵다. 텍스트 내용의 의미를 이해해야 판단할 수 있기 때문이다.

1.4.1 색 정보 색을 정보 전달의 유일한 수단으로 사용하지 않아야 한다. 예를 들어 오류 표시를 색만으로 하면 색맹 사용자가 인식하지 못한다. 텍스트 또는 아이콘을 함께 써야 한다. DOM에서 어느 정도 감지할 수 있지만 100% 자동화는 어렵다.

1.4.2 배경음 제어 자동으로 재생되는 배경음이 있다면 제어 수단을 제공해야 한다. 자동으로 판정 가능하다.

원칙 2: 운용의 용이성 (Operable) — 9개 항목

사용자 인터페이스 요소와 내비게이션을 운용할 수 있어야 한다는 원칙이다. 9개 항목이다.

2.1.1 키보드 사용 보장 키보드만으로 모든 기능을 이용할 수 있어야 한다. 이건 접근성에서 가장 중요한 항목 중 하나다. 마우스를 쓸 수 없는 사용자에게 키보드 접근성은 그 웹사이트를 쓸 수 있는가 없는가를 결정한다. axe-core가 일부 자동 감지하지만, 실제 키보드 탭 탐색이 모든 기능에 도달하는지는 Playwright의 키보드 시뮬레이션으로 보완한다.

2.1.2 키보드 함정 방지 키보드 포커스가 특정 요소에 갇히지 않아야 한다. 모달 팝업이 열렸을 때 Tab 키로 팝업 밖으로 나가버리거나, 반대로 영구히 팝업 안에 갇히는 경우가 대표적이다. 자동화로 감지할 수 있는 항목이다.

2.2.1 응답 시간 조절 시간 제한이 있는 콘텐츠에 대해 사용자가 충분한 시간을 확보할 수 있어야 한다. KWCAG 2.2에서 보강된 항목으로, 사용자가 추가 시간을 요청할 수 있는 옵션을 제공해야 한다. 로그인 세션 만료, 폼 입력 제한시간 등이 해당한다. DOM에서 일부 감지하지만 실제 동작은 수동 테스트가 필요하다.

2.2.2 정지·일시정지·숨김 움직임, 깜박임, 스크롤 등 자동 업데이트 콘텐츠에 대해 이를 일시정지하거나 숨길 수 있는 수단을 제공해야 한다. 자동으로 재생되는 슬라이더, 배너 등이 대상이다. DOM 분석으로 일부 감지 가능하다.

2.3.1 깜박임 사용 제한 초당 3~50Hz 사이로 깜박이는 콘텐츠를 제한해야 한다. 광과민성 발작 방지를 위한 항목이다. 자동화로 감지하기 어려운 영역이다.

2.4.1 건너뛰기 링크 메뉴처럼 반복되는 콘텐츠를 건너뛰어 본문으로 바로 이동하는 수단을 제공해야 한다. '본문 바로가기' 링크가 대표적이다. 자동으로 판정 가능하다.

2.4.2 제목 제공 각 웹 페이지에 주제를 설명하는 제목(title)을 제공해야 한다. title 요소의 존재와 내용 자동 감지 가능하다.

2.4.3 초점 이동 키보드 탭 이동 시 초점이 논리적 순서로 이동해야 한다. DOM 탭인덱스 분석으로 일부 감지 가능하다.

2.4.4 링크 목적 이해 링크의 목적을 링크 텍스트만으로 이해할 수 있어야 한다. '더 보기', '클릭', '여기'처럼 맥락 없는 링크 텍스트는 스크린 리더 사용자에게 무의미하다. axe-core가 일부 케이스를 잡지만, 링크 텍스트의 의미 판단은 자동화의 한계 영역이다.

원칙 3: 이해의 용이성 (Understandable) — 6개 항목

정보와 사용자 인터페이스의 운용은 이해할 수 있어야 한다는 원칙이다. 6개 항목이다.

3.1.1 기본 언어 표시 웹 페이지의 기본 언어를 식별할 수 있어야 한다. html lang 속성으로 지정한다. 자동 감지 가능하다.

3.2.1 초점 변화에 의한 맥락 변환 방지 키보드 포커스를 받을 때 사용자 요청 없이 맥락이 바뀌어선 안 된다. 예를 들어 드롭다운을 선택하면 자동으로 페이지가 이동하는 경우다. 어느 정도 DOM으로 감지하지만, 실제 동작 여부는 수동 확인이 필요하다.

3.2.2 입력 변화에 의한 맥락 변환 방지 사용자 요청 없이 입력 변화만으로 맥락이 변경되면 안 된다. 수동 테스트 비중이 높다.

3.3.1 오류 정정 오류가 발생하면 어떤 항목에서 오류가 발생했는지 사용자에게 알려야 한다. 폼의 오류 메시지가 프로그래밍적으로 연결되어 있는지를 axe-core가 일부 감지한다.

3.3.2 레이블 제공 입력 서식에 레이블이나 지시 사항을 제공해야 한다. 모든 입력 필드에 연결된 레이블이 있는지 자동 감지 가능하다. 이게 없으면 스크린 리더 사용자는 해당 필드에 뭘 입력해야 하는지 알 수 없다.

3.3.3 오류 목록 여러 오류가 있을 때 오류 목록을 제공해야 한다는 항목이 KWCAG에 포함된다.

원칙 4: 견고성 (Robust) — 2개 항목

콘텐츠는 미래 기술을 포함한 다양한 사용자 에이전트에 의해 해석될 수 있을 만큼 견고해야 한다는 원칙이다. 검사항목은 2개다.

4.1.1 마크업 오류 방지 HTML 마크업이 시작/끝 태그 중첩, 중복 속성, ID 유일성 같은 기본 문법을 준수해야 한다. 자동으로 감지 가능하다. html-validate 같은 도구로 자동 검사한다.

4.1.2 웹 애플리케이션 접근성 사용자 인터페이스 요소의 역할, 상태, 값을 프로그래밍 방식으로 식별할 수 있어야 한다. ARIA 역할, 상태(aria-expanded, aria-checked 등), 이름 속성이 올바르게 구현되어 있는지를 axe-core가 꼼꼼히 확인한다.

ViewCheck LLM 분석 접근성 탭에서 KWCAG 2.2 항목별 진단 결과가 정리된 실제 화면 캡처. — ViewCheck LLM 분석의 접근성(KWCAG) 기능 실제 화면. 4개 엔진의 교차 검증 결과가 항목별로 정리되어 표시된다. — 실제 분석 화면

axe-core가 KRDS 846규칙과 만나는 지점 — 두 층위의 접근성

여기서 ViewCheck 접근성 분석의 독특한 구조를 짚어야 한다. 접근성은 사실 ViewCheck 안에서 두 층위로 처리된다.

층위 1: KWCAG 2.2 직접 검증 (접근성 탭) 앞서 설명한 4개 엔진(axe-core, IBM Equal Access, HTML CodeSniffer, KWCAG 커스텀 검증)이 작동하는 층위다. WCAG/KWCAG 기준으로 직접 판정한다.

층위 2: KRDS 846규칙 안의 접근성 관련 규칙 (컴포넌트·기본패턴 탭) KRDS의 846개 규칙 중 상당수가 접근성과 겹친다. 버튼에 적절한 ARIA 레이블이 있는가, 폼에 오류 안내가 제공되는가, 모달에 초점 트랩이 있는가 등이다. 이 규칙들은 KRDS 컴포넌트(CP)와 기본 패턴(BP) 카테고리 안에 포함되어, DOM 기반 KRDSrule 엔진이 판정한다.

두 층위가 겹치는 부분이 있다. 예를 들어 폼 라벨 누락은 KWCAG 3.3.2(레이블 제공)로도 위반이지만, KRDS CP 규칙으로도 위반이 된다. 두 관점에서 모두 잡히는 셈이다. 이게 ViewCheck가 단순히 '접근성 도구' 하나를 쓰는 것보다 더 넓은 커버리지를 확보하는 방식이다.

axe-core의 결과와 KRDS 846규칙 결과를 함께 보면, 'KRDS 관점의 접근성'과 'KWCAG 관점의 접근성'이 어떻게 같고 어떻게 다른지도 드러난다. KRDS는 KWCAG를 내재화하면서도, 한국 공공 서비스의 특수한 컴포넌트 구조와 패턴을 더 세밀하게 다룬다. 이 두 층위를 교차해서 보는 것이 ViewCheck 접근성 분석의 핵심 설계다.

한편 axe-core와 KRDS 규칙 간의 매핑도 구현했다. axe-core의 99개 규칙 중 KRDS 48개 규칙과 연결점이 있다. axe-core가 'aria-required-attr 위반'을 잡으면, 그것이 KRDS의 어떤 규칙에 해당하는지를 연결해 사용자에게 통합된 시각으로 보여주려는 시도다.

실제 분석에서 보이는 패턴들 — 공공 웹 접근성의 반복 문제

ViewCheck로 공공 웹사이트들을 분석하다 보면 반복해서 보이는 패턴들이 있다. 개별 사이트를 공개적으로 평가하는 게 목적이 아니라서 특정 URL을 언급하지 않겠지만, 우리가 실제 분석 과정에서 자주 마주친 유형들을 정리해보면 이렇다.

가장 흔히 발견되는 문제: 대체 텍스트 부재 또는 부실 이미지에 alt 속성이 아예 없거나, alt="" (빈 값)으로 처리해버리는 경우가 많다. 빈 alt는 장식 이미지에 적합하지만, 의미 있는 정보를 담은 이미지에 빈 alt를 쓰면 스크린 리더 사용자는 그 정보를 놓친다. "배너1.jpg", "img_20240101.png" 같은 파일명이 alt로 들어온 경우도 있다.

두 번째로 흔한 문제: 폼 라벨 연결 누락 입력 필드 옆에 텍스트 레이블이 시각적으로는 보이지만, HTML의 <label for> 와 <input id>가 연결되어 있지 않은 경우다. 눈으로 보면 이상이 없어 보이지만, 스크린 리더는 "이름", "이메일"이라는 레이블을 읽지 못하고 "입력창"이라고만 안내한다.

세 번째: 색상 대비 부족 회색 텍스트를 흰 배경 위에 올리거나, 파스텔 배경에 연한 글씨를 쓰는 경우다. WCAG/KWCAG는 일반 텍스트의 경우 배경과 전경의 대비를 최소 4.5:1 이상으로 요구한다. 이 수치를 충족하지 못하는 경우를 빈번하게 만난다.

네 번째: 키보드 포커스 미표시 탭 키로 이동할 때 현재 포커스가 어디 있는지 시각적으로 보이지 않는 경우다. CSS에서 outline: none을 전역으로 설정하면 이렇게 된다. 마우스 없이 키보드로 페이지를 쓰는 사용자는 자신이 어디에 있는지 알 수 없게 된다.

다섯 번째: 건너뛰기 링크 미제공 메인 GNB(글로벌 내비게이션 바)를 탭으로 다 통과하고 본문으로 가려면 수십 번의 탭 키가 필요한 사이트들이 있다. '본문 바로가기'처럼 반복 콘텐츠를 건너뛰는 링크가 없기 때문이다.

이 다섯 가지는 자동화로 감지하기 비교적 수월한 유형이고, 실제로 ViewCheck가 잡아내는 항목들이다. 반면에 위에서 언급한 '의미 있는 순서', '링크 목적 이해', '응답 시간 조절' 같은 항목들은 여전히 자동화가 어려워서 N/A(해당없음) 또는 수동 점검 권고로 남기는 경우가 많다.

이건 아직 해결하지 못한 부분이다. 솔직히 말하면, N/A로 남기는 항목들 중 일부는 '정말 해당 없는 것'이고 일부는 '우리가 아직 자동으로 잡지 못하는 것'이다. 이 두 가지를 제대로 구분해 보여주는 것이 앞으로 보강해야 하는 부분이다.

클립보드의 체크리스트를 검토하는 접근성 전문가가 노트북 옆에 앉아 있는 모습. — 자동화가 잡아낸 항목 목록을 들고, 어디가 실제로 문제인지를 검토하는 과정 — 자동화는 단독이 아니라 사람의 판단을 보조할 때 빛난다.

다중 페이지 분석이 접근성에서 특히 중요한 이유

접근성 분석에서 다중 페이지를 보는 것이 왜 중요한지, 이 주제를 조금 더 들여다보자.

한 가지 가상의 시나리오를 생각해보자. 공공기관 A의 메인 페이지는 접근성 인증도 받았고, 실제로 대체 텍스트, 키보드 접근성, 색상 대비 모두 잘 구현되어 있다. 그런데 이 사이트에서 시민들이 실제로 가장 많이 쓰는 화면은 '민원신청 화면'이다. 신청 양식에 첨부파일 업로드 기능이 있는데, 그 버튼에 ARIA 레이블이 없다. 키보드로는 파일을 첨부하기 어렵고, 스크린 리더 사용자는 그 버튼이 무엇을 하는지 알 수 없다.

메인 페이지만 점검했다면 이걸 발견하지 못한다. 우리가 '다중 페이지 분석을 기본값으로' 한다고 반복해서 강조하는 이유가 바로 여기에 있다. 접근성 문제는 대체로 '사용자가 실제로 쓰는 깊은 화면'에서 발생한다. 화려하고 관리받는 메인 페이지는 의외로 접근성이 잘 지켜져 있고, 날마다 업데이트되는 게시판, 분기에 한 번 열리는 신청 화면, 또는 외부 업체가 납품한 서브시스템에서 문제가 터진다.

ViewCheck는 메인뿐 아니라 검색, 목록, 상세, 신청, 로그인 등 다양한 유형의 페이지를 균형 있게 수집해 분석한다. 그리고 여러 페이지에 걸쳐 나타나는 접근성 문제를 OR 로직으로 집계한다. 한 페이지라도 어떤 KWCAG 항목에서 위반이 있으면 그 항목은 위반으로 집계된다. 이게 엄격하게 들릴 수 있지만, 반대로 생각하면 당연하다. "이 사이트의 로그인 화면에서 키보드 접근성이 깨진다면, 그 사이트는 KWCAG 2.1.1을 충족하는 사이트라고 할 수 없다."

한 페이지씩 분리해서 보면 각각은 통과할 수 있어도, 사이트 전체로 보면 위반인 경우가 많다. 그 전체 그림을 보여주는 것이 다중 페이지 분석의 핵심 가치다.

KWCAG 분석 결과가 24개 기능 카드로 펼쳐지는 방식

ViewCheck의 24개 기능 중 '접근성(KWCAG)'은 하나의 독립된 카드로 제공된다. 사용자가 URL을 넣으면 분석이 완료된 후 이 카드가 대화에 등장한다. 이 카드 안에는 대략 다음과 같은 내용이 담긴다.

KWCAG 2.2 4원칙 × 점수 요약 인식·운용·이해·견고성 4가지 원칙별로 점수와 현황을 한눈에 보여준다. 전체 합산 점수도 함께 제공한다. 이 점수가 얼마인지보다는, 어느 원칙이 상대적으로 취약한지를 파악하는 게 중요하다.

항목별 통과/미통과/N/A 목록 33개(또는 34개) 항목 각각의 판정 결과를 보여준다. 통과, 미통과, 해당없음(N/A)으로 나뉜다. 미통과 항목에는 어떤 요소에서 어떤 이유로 위반이 발생했는지 구체적 근거가 함께 표시된다.

위반 발생 페이지 정보 다중 페이지 분석이므로, 특정 항목이 어떤 페이지에서 위반됐는지도 함께 제공한다. "이 항목은 신청 페이지와 로그인 페이지에서 위반됐습니다"처럼. 어디서 고쳐야 하는지를 바로 파악할 수 있다.

수동 점검 권고 목록 자동화로 판정하지 못한 항목들을 별도로 나열하고, 어떻게 수동으로 확인해야 하는지를 안내한다. 이 부분이 중요하다. '자동화가 못 한다'고 그냥 숨기는 것과, '이 항목은 이런 방법으로 수동 확인이 필요하다'고 안내하는 것은 다르다. 후자가 훨씬 솔직하고 더 유용하다.

KRDS 846규칙과의 연결 정보 위반된 KWCAG 항목이 KRDS의 어떤 규칙과 연결되는지를 보여준다. 이 연결이 있으면, KWCAG 관점의 위반이 동시에 KRDS 관점에서도 어떤 의미를 갖는지를 한눈에 파악할 수 있다.

사용자는 이 카드를 보고 궁금한 점이 생기면 채팅으로 직접 물을 수 있다. "3.3.2 레이블 제공이 미통과라고 나왔는데, 어떻게 고치면 돼?"라고 물으면, 구체적인 HTML 수정 방법과 함께 KWCAG 원문 근거가 나온다.

스크린 리더 시뮬레이션 — 자동화의 새로운 경계

접근성 자동화의 흥미로운 도전 중 하나가 스크린 리더 시뮬레이션이다. 스크린 리더(JAWS, NVDA, VoiceOver 등)를 실제로 사용하는 시각장애 사용자가 경험하는 방식을 자동으로 재현할 수 있을까?

완전한 재현은 현재 기술로 어렵다. 스크린 리더는 브라우저의 접근성 트리(accessibility tree)를 읽는데, 이 트리가 어떻게 생성되는지는 브라우저·OS·스크린 리더 버전의 조합에 따라 달라진다. 같은 HTML도 VoiceOver(macOS/iOS)와 NVDA(Windows)가 다르게 읽는 경우가 있다.

그럼에도 불구하고 우리는 접근성 트리를 분석하는 방향으로 접근한다. Playwright는 접근성 트리를 직접 추출하는 API를 제공한다. 이 트리를 분석하면 스크린 리더 사용자가 어떤 순서로 어떤 정보를 듣게 되는지를 상당히 유추할 수 있다. 완벽하지는 않지만, 아무것도 안 보는 것보다는 훨씬 낫다.

특히 KWCAG의 견고성 원칙(원칙 4)과 연결되는 부분에서 이 접근성 트리 분석이 유용하다. ARIA 역할이 올바르게 노출되는지, 동적으로 업데이트되는 콘텐츠가 스크린 리더에게 전달되는지 같은 것들이 어느 정도 감지된다.

아직 갈 길이 멀다는 걸 솔직히 인정한다. GOV.UK가 말하는 것처럼, 진짜 스크린 리더 사용자와 함께하는 테스트를 대체하는 방법은 현재로서는 없다. 자동화는 그 테스트로 가기 전에 '가장 명백한 문제들을 미리 걸러내는 첫 번째 필터' 정도로 보는 게 적절하다.

다양한 참여자들이 편안하게 디바이스를 사용하고 있는 포용적 워크숍의 모습. — 다양한 참여자가 함께하는 접근성 워크숍 — 자동화가 발견한 것들을 사람이 함께 검증하는 것이 결국 가장 좋은 방법이다.

'N/A 줄이기' 연구 — 자동화의 사각지대를 어떻게 좁힐 것인가

KWCAG 자동 진단에서 'N/A'로 남는 항목들을 어떻게 줄일 것인가는 우리 팀의 큰 숙제다. 현재 KWCAG 분석에서 N/A로 처리되는 유형을 세 가지로 분류해 보면 이렇다.

유형 1: 정당한 N/A — 해당 요소/기능이 없는 경우 예를 들어 동영상 콘텐츠 없는 사이트에서 '1.2.1 음성·영상 대체'가 N/A로 나오는 건 맞다. 이건 진짜 해당없음이다.

유형 2: 기술적 한계로 인한 N/A — 자동화가 판정 불가능한 경우 예를 들어 '2.3.1 깜박임 사용 제한'은 동적 동작을 봐야 하는데, 정적 스냅샷으로는 판단이 어렵다. '1.3.3 감각적 특성 무의존'은 텍스트 의미를 이해해야 하는데, 그게 현재 자동화의 한계 영역이다. 이 유형은 자동화로 해결하기 어렵고, 솔직히 그렇게 표시해야 한다.

유형 3: 개선 가능한 N/A — 더 잘 구현하면 자동화 가능한 경우 폼이 있는 페이지에만 적용되는 '3.3.1 오류 정정' 같은 항목은, 폼 요소가 없으면 N/A가 맞다. 그런데 폼이 있는 페이지에서도 오류 메시지의 연결 여부를 더 정교하게 감지하면, 지금보다 더 많은 케이스를 자동으로 판정할 수 있다.

우리가 집중하는 건 유형 3이다. 유형 1은 N/A로 두는 게 맞다. 유형 2는 솔직하게 '수동 확인 필요'로 남긴다. 유형 3을 줄여나가는 것이 우리 접근성 분석의 품질을 높이는 핵심 경로다.

실제로 KRDS 846규칙 엔진에서는 BP(기본 패턴)와 SP(서비스 패턴) 카테고리의 N/A 줄이기를 계속 연구 중이다. 여기에는 DOM 컨텍스트 분석을 통해 페이지 유형을 먼저 분류하고, 그 유형에 맞는 규칙만 적용하는 방식이 효과적이다. 로그인 화면에서만 의미 있는 규칙을, 메인 페이지에 대고 'N/A'로 처리하는 게 맞는지, 아니면 아예 적용하지 않는 게 맞는지를 구분하는 것도 중요한 고민이다.

KWCAG와 KRDS의 교차점 — 접근성이 디자인 시스템에 내장될 때

여기서 잠깐, 더 넓은 시각으로 보자. KWCAG와 KRDS는 별개의 기준처럼 보이지만, 사실 깊게 연결되어 있다.

KRDS 공식 사이트(krds.go.kr)는 디지털 포용이라는 별도 섹션에서 접근성을 다룬다. KRDS가 단순한 '예쁜 디자인 시스템'이 아니라, 디지털 포용과 접근성을 핵심 가치로 삼고 있음을 명시한다. KRDS의 각 컴포넌트 페이지에는 WCAG 적합성 수준이 명기되어 있다. 컴포넌트 자체가 접근성을 내포하도록 설계된 것이다.

이게 왜 중요한가. 개발팀이 KRDS를 잘 따라서 공공 웹사이트를 구축한다면, KWCAG의 상당 부분은 자연스럽게 충족된다. 디자인 시스템에 접근성이 내장되어 있기 때문이다. 역으로 말하면, KRDS 준수율이 높은 사이트는 KWCAG 준수율도 높을 가능성이 크다.

GOV.UK Design System의 접근성 섹션은 이렇게 말한다. "GOV.UK 디자인 시스템의 스타일, 컴포넌트, 패턴을 사용하는 것이 가장 널리 쓰이는 보조기술로 검증되고 WCAG의 AA 수준을 충족하도록 만들어졌다. 그러나 디자인 시스템을 쓴다고 해서 그 서비스가 자동으로 접근성 있게 되지는 않는다. 추가적인 연구, 디자인, 개발, 테스트 작업이 여전히 필요하다"(GOV.UK Design System, "Accessibility").

이 말이 KRDS에도 그대로 적용된다. KRDS를 쓰면 접근성의 기초가 강해지지만, 그것만으로는 충분하지 않다. KWCAG 검사를 별도로 해야 하고, 실제 보조기술로 테스트해야 한다. ViewCheck가 하는 일이 바로 그 '별도 KWCAG 검사'의 자동화된 첫 단계인 셈이다.

두 기준이 교차하는 지점을 ViewCheck가 함께 보여줄 수 있다면, 담당자는 "KRDS를 잘 따랐는데 왜 KWCAG에서 문제가 나오지?"라는 질문에 더 쉽게 답할 수 있게 된다.

접근성 분석 결과를 어떻게 '쓸 수 있게' 만드는가

자동 분석이 33개 항목의 결과를 쭉 뽑아준다고 해서 담당자가 그걸 바로 실행에 옮길 수 있는 건 아니다. '쓸 수 있는 결과'를 만드는 것이 분석의 다음 과제다.

우리가 접근성 카드를 설계하면서 신경 쓴 것들을 몇 가지 적어본다.

우선순위 정보 제공 33개 항목이 다 같은 무게는 아니다. '1.1.1 대체 텍스트'가 없으면 시각장애 사용자는 그 사이트를 사용하는 것 자체가 불가능해질 수 있다. 반면 '1.4.2 배경음 제어'는 오디오 콘텐츠가 없는 사이트에서는 사실상 의미가 없다. 위반의 심각도(P0~P3)를 함께 표시해 어디서부터 대응해야 하는지를 파악할 수 있게 한다.

구체적인 요소 정보 제공 "이 사이트는 대체 텍스트 미준수"라고만 알려주면 어디서 고쳐야 하는지 모른다. "about.html의 3번째 이미지 요소에 alt 속성이 없습니다. 현재 src는 /images/team-photo.jpg입니다"처럼 구체적인 정보를 함께 제공한다. 개발자에게 바로 전달할 수 있는 수준의 정보다.

개선 가이드 연결 각 항목에 대해 'KWCAG 2.2 원문에서 이 항목이 요구하는 것', '코드 수준의 수정 방법', 'KRDS에서 이 항목을 어떻게 다루는지'를 RAG 기반으로 찾아 제시한다. 담당자는 외주 개발사에 "KWCAG 3.3.2 위반, input id="name"에 label 연결 누락, for 속성으로 연결 필요"처럼 구체적인 요청서를 바로 작성할 수 있다.

트렌드 추적 가능성 같은 사이트를 주기적으로 분석하면, 접근성 상태가 어떻게 변화했는지를 비교할 수 있다. 콘텐츠 업데이트 후 새로운 위반이 생겼는지, 지난번 지적한 항목이 개선됐는지를 확인하는 것이다. 접근성은 '한 번 받고 끝'이 아니라 '지속적으로 관리'해야 하는 영역이기 때문에, 이 추적 기능이 장기적으로 중요해진다.

여전히 어려운 것들 — 솔직한 현재 상태

이쯤에서 우리가 아직 못 하고 있는 것들을 솔직하게 열거한다.

실시간 동적 콘텐츠의 접근성 Ajax로 동적으로 로드되는 콘텐츠, 무한 스크롤, 실시간으로 업데이트되는 알림 같은 것들에서의 접근성은 정적 분석으로 잡기 어렵다. ARIA 라이브 영역(aria-live)이 제대로 구현되어 있는지, 동적 업데이트가 스크린 리더에게 전달되는지는 아직 자동화 커버리지가 낮다.

모달·팝업·레이어 내부 접근성 페이지 로드 시점에는 보이지 않다가 사용자 행동으로 열리는 모달, 팝업, 드로어 내부의 접근성은 Playwright의 동적 시뮬레이션으로 어느 정도 잡고 있지만, 완전하지 않다.

사용자 인터랙션 흐름의 접근성 회원가입, 민원신청, 공공 서비스 결제처럼 여러 단계로 이어지는 흐름의 전체적인 접근성은 판정하기 어렵다. 각 화면 자체는 통과해도, 흐름 전체에서 키보드 사용자가 막히는 지점이 생길 수 있다.

스크린 리더별 차이 앞서 언급했지만, VoiceOver·NVDA·JAWS·내레이터 간의 동작 차이를 자동화로 커버하는 건 아직 어렵다.

콘텐츠 품질 판단 alt 텍스트가 있지만 "사진입니다"처럼 의미 없는 경우, 링크 텍스트가 "자세히 보기"처럼 맥락 없는 경우 — 이런 텍스트 품질 판단은 AI의 자연어 이해 능력을 빌려야 하는데, 아직 완성도가 충분하지 않다.

이것들을 모두 "나중에 개선하겠습니다"라고만 말하고 끝내는 건 쉽다. 하지만 그렇게 하면 사용자에게 현재 결과가 얼마나 신뢰할 수 있는지를 제대로 전달하지 못한다. 그래서 우리는 결과 화면에서 '자동 판정 가능'과 '수동 확인 권고'를 명확히 구분하는 데 공을 들인다. 자동화가 100%가 아니라는 걸 숨기지 않는 것이 오히려 도구에 대한 신뢰를 높인다고 믿는다.

노트북 옆에 스크린 리더 이어폰 세트업이 놓인 모습의 클로즈업. — 스크린 리더 사용자의 실제 경험을 재현하는 것은 자동화가 아직 완전히 풀지 못한 영역이다. 그래서 자동화는 언제나 보조 수단이어야 한다.

공공 웹 담당자의 관점에서 — KWCAG 점검이 실무에서 의미하는 것

기술적인 이야기를 잠시 내려놓고, 공공 웹 담당자의 입장에서 KWCAG 점검이 실제로 의미하는 게 무엇인지를 생각해보자.

대부분의 공공 웹사이트 담당자는 접근성 전문가가 아니다. 접근성 인증을 받을 때 전문 업체에 의뢰했고, 그 업체가 체크리스트를 들고 와서 통과시켰다. 인증서가 나왔다. 그게 전부인 경우가 많다. 그 이후에 콘텐츠가 바뀌고, 개발자가 교체되고, 기능이 추가되면서 접근성이 조금씩 흐트러져도, 그걸 주기적으로 확인하는 체계가 없다.

여기에 ViewCheck 접근성 분석이 끼어들 수 있는 지점이 있다. 전문 업체에 의뢰하기 전에 '지금 내 사이트의 상태가 어떤지'를 먼저 빠르게 파악하는 도구. 인증 이후 콘텐츠 업데이트 때마다 '새로 생긴 문제가 없는지'를 점검하는 도구. 전문 기관의 심층 감사를 대체하는 게 아니라, 그 감사가 필요한 지점을 좁혀주고, 준비 과정을 도와주는 도구.

담당자 입장에서 가장 실용적인 사용 시나리오를 그려보면 이렇다.

콘텐츠 업데이트 직후: 새 배너 이미지를 올렸다. alt 텍스트를 제대로 넣었는지 빠르게 확인. URL 입력, 분석 완료, 접근성 카드에서 '대체 텍스트' 항목 확인. 1분도 안 걸린다.

분기별 자체 점검: 지난 분기와 비교해 접근성이 나빠진 항목이 있는지 확인. ViewCheck 이력 비교로 파악.

인증 갱신 준비: 인증 기관에 의뢰하기 전에 ViewCheck로 미리 점검해 명백한 위반 항목을 사전 해소. 감사 효율을 높인다.

외주 개발 납품 검수: 외부 업체가 구축한 기능이 접근성 기준을 충족하는지 납품 전에 검토.

이 시나리오들에서 공통점이 있다. ViewCheck는 전문가를 대신하는 게 아니라, 전문가의 손길이 닿기 전과 후의 공백을 채운다는 것이다.

KWCAG 2.2에서 WCAG 2.2로 — 국제 기준과의 정합성

KWCAG와 WCAG의 관계를 조금 더 짚어보자. W3C의 WCAG 2.2는 2023년 10월 5일 공식 표준이 됐다. KWCAG 2.2는 이에 앞서 2022년 12월 개정됐다. 두 기준은 4원칙(인식·운용·이해·견고성)과 기본 틀을 공유하지만, 세부 항목에서 차이가 있다.

WCAG 2.2에서 WCAG 2.1 대비 추가된 9개 성공 기준을 보면, 특히 인지 장애와 저시력 사용자를 위한 항목들이 강화됐다. 예를 들어 2.4.11~2.4.13은 포커스 가시성과 초점 외관에 관한 기준인데, KWCAG 2.2는 이와 유사한 항목을 포함한다.

KWCAG가 WCAG와 100% 동일하지 않다는 점도 알아둘 필요가 있다. 한국의 법적·기술적 환경에 맞게 조정된 부분이 있고, WCAG에 있지만 KWCAG에 없는 항목, 또는 반대로 KWCAG에서 더 강화된 항목이 있다. ViewCheck가 KWCAG 2.2를 기준으로 한국 공공 웹에 최적화해 분석하면서도, WCAG 2.2 엔진(axe-core)을 함께 활용하는 이유가 여기에 있다. 두 기준을 교차하면 더 넓은 커버리지를 확보할 수 있기 때문이다.

미국 접근성 위원회(U.S. Access Board)는 2023년 11월 WCAG 2.2가 W3C 권고안이 됐을 때 이를 공식 발표하며, 정부 기관들이 WCAG 2.2를 채택해 접근성 노력의 미래 적합성을 극대화할 것을 권고했다(U.S. Access Board, 2023. 11). 이 국제적 흐름에서 한국 공공 웹도 자유롭지 않다.

디지털 서비스의 국경이 점점 흐릿해지는 환경에서, KWCAG만 보는 것을 넘어 WCAG 2.2의 방향성도 함께 파악하는 것이 장기적으로 중요하다. ViewCheck의 접근성 분석이 KWCAG와 WCAG를 병렬로 다루는 건 그런 이유에서다.

접근성을 '지켜야 하는 의무'가 아니라 '사이트 품질의 지표'로

이 글에서 계속 '의무', '법적 요건', '인증' 같은 표현이 나왔다. 접근성의 동기가 규정 준수에서 오는 경우가 많다는 걸 반영한다. 하지만 우리는 접근성을 바라보는 관점을 조금 다르게 이야기하고 싶다.

접근성이 잘 구현된 웹사이트는 장애인 사용자만 더 잘 쓸 수 있는 게 아니다. alt 텍스트가 잘 달린 이미지는 검색엔진에도 더 잘 노출된다. 키보드로 탐색 가능한 구조는 키보드 단축키를 선호하는 비장애 사용자도 편리하게 쓴다. 명확한 오류 메시지와 레이블은 처음 방문한 사용자의 학습 비용을 낮춘다. 빠른 인터넷 연결이 없는 환경에서도, 구형 기기에서도 잘 동작하는 사이트가 접근성 있는 사이트인 경우가 많다.

W3C WAI(Web Accessibility Initiative)는 이를 '웹 접근성의 사회적, 기술적, 사업적 이점'으로 설명한다. 접근성을 키우면 더 많은 사람에게 도달하고, 브랜드 이미지가 좋아지며, 법적 리스크가 줄어들고, SEO도 향상된다(W3C WAI, "The Business Case for Digital Accessibility").

ViewCheck에서 접근성 분석이 단독 카드로 존재하면서도, 동시에 KRDS 846규칙, SEO, 반응형 분석과 연결되는 이유가 여기에 있다. 접근성은 고립된 체크리스트가 아니라, 사이트 품질의 다른 측면들과 긴밀히 엮여 있다. 접근성을 잘 하면 대체로 다른 품질 지표도 함께 좋아진다.

공공 웹사이트 담당자에게 권하고 싶은 마음의 전환은 이것이다. "접근성 인증 받아야 하니까"에서 "우리 사이트가 더 많은 시민에게 실제로 잘 열려 있는지"로. 전자가 체크리스트를 넘기는 일이라면, 후자는 사이트를 계속 더 좋게 만들어가는 일이다. ViewCheck가 도구로서 함께할 수 있는 건 두 번째 방향이다.

ViewCheck 접근성 카드의 한계 — 놓치지 않기 위한 솔직한 정리

이 글을 마무리하기 전에, ViewCheck의 KWCAG 접근성 분석이 현재 무엇을 놓칠 수 있는지를 한 번 더 명확히 적어두겠다. 과장하거나 숨기고 싶지 않기 때문이다.

현재 자동화가 잘 작동하는 영역:

대체 텍스트 부재 여부 (alt 속성 존재/빈값/파일명)
폼 라벨 연결 여부 (label-input 연결)
색상 대비 비율 (텍스트 vs 배경)
마크업 구조 오류 (중첩, 중복 속성, ID 유일성)
ARIA 역할·상태·이름 기본 검증
페이지 제목 존재 여부
건너뛰기 링크 제공 여부
언어 속성 표시 여부

자동화가 부분적으로 작동하는 영역 (정확도 변동):

키보드 접근성 (Playwright 탭 시뮬레이션, 모든 기능 커버 불완전)
초점 가시성 (CSS 분석, 일부 케이스 누락 가능)
폼 오류 메시지 연결 (구조 분석, 내용 품질은 불가)

자동화가 아직 어려운 영역 (수동 점검 권고):

콘텐츠 의미 기반 판단 (alt 텍스트 품질, 링크 텍스트 적절성)
동영상·오디오 자막 품질
깜박임 및 모션 동작
다단계 사용자 흐름 전체
실제 스크린 리더 재현

이 구분을 결과 화면에서 명확히 보여주는 것, 그리고 '수동 확인이 필요한 항목에 대한 체크리스트를 함께 제공하는 것'이 우리가 지금 작업 중인 개선 방향이다.

마무리 — 접근성 자동화의 현재 지점에서

KWCAG 2.2 자동 진단을 한마디로 요약하면, "자동화로 잡을 수 있는 것을 최대한 빠르고 정확하게, 잡지 못하는 것을 솔직하게 남긴다"다.

자동화는 만능이 아니고, 앞으로도 만능이 될 수 없는 영역이 있다. 진짜 스크린 리더 사용자가 겪는 경험, 콘텐츠의 의미를 이해하는 판단, 다단계 플로우 전체의 흐름 — 이건 사람의 눈과 귀가 필요하다.

그럼에도 불구하고 자동화가 하는 일은 분명히 있다. 공공 웹사이트의 수백 개 페이지에 걸쳐 가장 흔하게 반복되는 접근성 문제들을, 담당자가 한 줄의 URL만 입력해도 수분 안에 파악하게 해주는 것. 전문 감사자가 오기 전에 명백한 문제들을 먼저 수정할 수 있게 해주는 것. 콘텐츠 업데이트마다 새로 생긴 위반을 빠르게 캐치하게 해주는 것.

우리는 그 자동화의 범위를 조금씩, 그리고 정확하게 넓혀가고 있다. '정확하게'라는 단어가 중요하다. 잘못된 결과를 더 많이 내보내는 게 아니라, 맞는 결과를 더 많이 낼 수 있는 방향으로.

KWCAG 2.2의 33개 항목이 모두 자동으로 판정되는 날이 올까? 솔직히 모르겠다. 아마 어떤 항목들은 사람의 판단 없이는 영원히 자동화되지 않을 것이다. 그 한계를 인정하면서, 그 안에서 우리가 할 수 있는 것을 최대한 잘하자는 게 ViewCheck 접근성 분석의 현재 방향이다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검색 검증했다. 국내 공식 기준과 국제 연구·기관 자료를 함께 실었다.

국내 — 공식 기준 / 법령 / 인증 기관

한국정보접근성인증평가원, 「한국형 웹 콘텐츠 접근성 지침 2.2」 (2022. 12. 28. 개정). https://www.wa.or.kr/board/view.asp?sn=22592&page=1&BoardID=0004
국가법령정보센터, 「장애인차별금지 및 권리구제 등에 관한 법률」 제21조. https://www.law.go.kr/lsInfoP.do?lsiSeq=195377
한국디지털접근성진흥원, 정보통신접근성(웹접근성) 인증 현황 및 관련 법률. https://www.kwacc.or.kr/Accessibility/Certification
KRDS 공식 사이트, 디지털 포용 — KRDS와 접근성. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/html/site/utility/utility_04.html
한국형 웹 콘텐츠 접근성 지침 2.2 (a11ykr.github.io 비공식 게시). https://a11ykr.github.io/kwcag22/

국내 — 업계 자료 / 해설

pxd XE Blog, "한국형 웹 콘텐츠 접근성 지침 2.2". https://tech.pxd.co.kr/post/한국형-웹-콘텐츠-접근성-지침-2-2-228
WebWatch (webwatch.or.kr), 웹 접근성 품질인증 현황 및 국가인증 기준. https://webwatch.or.kr/WA/010201.html?MenuCD=120

해외 — W3C / 국제 기관

W3C WAI, "Web Content Accessibility Guidelines (WCAG) 2.2". W3C Recommendation, 2023. 10. 05. https://www.w3.org/TR/WCAG22/
W3C WAI, "What's New in WCAG 2.2". https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
U.S. Access Board, "W3C WCAG 2.2 Now Available" (2023. 11). https://www.access-board.gov/news/2023/11/27/w3c-wcag-2-2-now-available/
GOV.UK Service Manual, "Testing for accessibility" — WCAG 2.2 AA 준수 및 스크린 리더 테스트 요건. https://www.gov.uk/service-manual/helping-people-to-use-your-service/testing-for-accessibility
GOV.UK Design System, "Accessibility". https://design-system.service.gov.uk/accessibility/
GOV.UK Accessibility Blog, "Get to WCAG 2.2 faster with the GOV.UK Design System" (2024. 1. 11). https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/

해외 — 자동화 테스트 도구 및 연구

Deque Systems, "Automated Testing Identifies 57% Digital Accessibility Issues". Business Wire, 2021. 3. 10. https://www.businesswire.com/news/home/20210310005156/en/Deque-Study-Shows-Its-Automated-Testing-Identifies-57-Percent-of-Digital-Accessibility-Issues-Surpassing-Accepted-Industry-Benchmarks
Deque, "The Automated Accessibility Coverage Report". https://www.deque.com/automated-accessibility-coverage-report/
IBM Equal Access Accessibility Checker — WCAG 2.2 지원 오픈소스 접근성 엔진. https://github.com/IBMa/equal-access
Easy A11y Guide, "How much can automated accessibility tools do?" https://easya11yguide.com/tips/how-much-can-automated-accessibility-tools-do/
Playwright 공식, "Accessibility testing" (axe-core 통합). https://playwright.dev/docs/accessibility-testing