대부분의 웹사이트는 기본적인 접근성 기준을 충족하지 못하고 있으며, 법적·비즈니스 리스크는 빠르게 커지고 있습니다. 이 가이드는 WCAG 접근성 감사가 정확히 무엇인지, 이를 수행하는 방법, 그리고 사이트가 모든 사용자를 위해 제대로 작동하도록 결과를 어떻게 활용해야 하는지를 설명합니다.

최신 WebAIM Million 보고서에 따르면, 백만 개의 홈 페이지 전반에서 5,600만 개의 개별 접근성 오류가 감지되었습니다. 페이지당 평균 56개의 오류입니다. 이는 절대 다수의 웹사이트가 매일같이 장애가 있는 사용자들을 적극적으로 외면하고 있다는 뜻입니다. 만약 당신이 웹사이트 소유자, 개발자, 또는 컴플라이언스 담당자로서 자신의 사이트가 WCAG를 준수하는지 궁금하다면, 그 답은 거의 항상 제대로 된 접근성 감사를 수행하는 것과 연결됩니다. 문제는 이것이 실제로 무엇을 의미하는지, 그리고 어떻게 올바르게 수행하느냐입니다.

접근성 감사가 더 이상 선택이 아닌 이유

웹 접근성은 이제 선의의 차원을 훨씬 넘어섰습니다. 점점 더 많은 관할 구역에서 법적 요구사항이 되었고, 비준수의 결과는 구체적이고 측정 가능합니다. 2024년 미국에서는 4,000건이 넘는 웹 접근성 소송이 제기되었고, 이 추세는 계속 증가하고 있습니다. 미국 법원은 일관되게, 일반 대중에게 개방된 비즈니스의 웹사이트는 ADA Title III에 따라 접근 가능해야 한다고 판시해 왔습니다. 한편, European Accessibility Act는 2025년 6월부터 모든 EU 회원국에서 시행되었으며, 요구사항을 정부 사이트를 넘어 은행 앱, 전자상거래 플랫폼, SaaS 제품 등으로 확대했습니다.

숫자는 냉혹한 현실을 보여줍니다. 전 세계 인구의 약 16% — 대략 13억 명 — 이 어떤 형태로든 장애를 가지고 있습니다. 미국에서만 성인 4명 중 약 1명이 장애를 가지고 있습니다. 이들은 예외적인 사용자가 아닙니다. 이들은 고객이자, 직원이자, 학생이자, 시민이며, 대부분의 개발자가 생각조차 하지 않는 장벽을 웹사이트에서 매일 마주하고 있습니다.

법적 위험을 넘어, 비즈니스 관점에서도 측정 가능한 이점이 있습니다. 접근 가능한 웹사이트는 검색 엔진에서 더 좋은 성과를 냅니다. 스크린 리더에 도움이 되는 구조적 명료성 — 시맨틱한 헤딩, 설명적인 대체 텍스트, 깔끔한 마크업 — 은 크롤러에게도 도움이 되기 때문입니다. 포괄적 디자인은 모든 사람의 사용성을 일관되게 향상시킵니다. 자막은 시끄러운 환경에 있는 사람들에게 도움이 되고, 높은 대비는 밝은 햇빛 아래 있는 사람들에게 도움이 되며, 키보드 내비게이션은 파워 유저에게 이점을 줍니다. 접근성 감사는 이러한 모든 이점을 확보하기 위한 첫 단계입니다.

또 하나 중요한 변화가 있습니다. ADA Title II는 이제 미국 주 및 지방 정부 기관에 대해 웹 접근성을 명시적으로 요구하며, DOJ는 WCAG 2.1 Level AA를 기술 표준으로 채택했습니다. 인구 50,000명 이상을 서비스하는 기관은 2026년 4월 26일까지 준수해야 합니다. 공공 부문 클라이언트와 일하거나 규제 산업에서 활동한다면, 감사는 더 이상 선택이 아니라 시급한 과제입니다.

WCAG 접근성 감사란 정확히 무엇인가?

웹 접근성 감사는 W3C가 개발한 디지털 접근성에 대한 국제적으로 인정된 기술 표준인 Web Content Accessibility Guidelines(WCAG) 준수 여부를 체계적으로 평가하는 작업입니다. 실제로 감사는 장애가 있는 사용자가 콘텐츠를 인지하고, 이해하고, 탐색하고, 상호작용하는 것을 방해하는 구체적인 장벽을 식별합니다. 그런 다음 이 장벽을 WCAG 성공 기준에 매핑하고, 심각도 수준을 부여하며, 개선(리미디에이션) 로드맵을 도출합니다.

WCAG는 현재 2023년 말에 발행된 2.2 버전이며, 2025년 5월 W3C에 의해 웹 접근성의 최고 표준으로 공식 재확인되었습니다. WCAG 2.1 대비 9개의 새로운 성공 기준이 추가되었으며, 키보드 포커스 가시성, 최소 터치 타깃 크기, 드래그 동작의 대안, 일관된 도움말 메커니즘 등의 영역을 다룹니다. 중요한 점은 WCAG 2.2가 하위 버전과의 호환성을 유지한다는 것입니다. 2.2를 충족하면 2.1과 2.0도 함께 충족하게 됩니다.

WCAG는 세 가지 적합성 수준으로 구성됩니다. Level A는 가장 치명적인 장벽을 다루며, 이 수준에서의 실패는 일부 사용자에게 콘텐츠를 완전히 사용 불가능하게 만듭니다. Level AA는 ADA, European Accessibility Act, Section 508을 포함한 전 세계 대부분의 접근성 법률에서 요구하는 목표 수준입니다. Level AAA는 가장 높은 기준을 의미하며, 일반적으로 법적 요구사항이라기보다 지향점에 가깝습니다. 누군가 자신의 사이트가 “WCAG를 준수한다”고 말할 때, 거의 항상 WCAG 2.1 또는 2.2의 Level AA를 의미합니다.

WCAG는 흔히 POUR라는 약어로 기억되는 네 가지 핵심 원칙 위에 구축되어 있습니다. 콘텐츠는 Perceivable(인지 가능 — 사용자가 감지할 수 있어야 함), Operable(운용 가능 — 사용자가 상호작용할 수 있어야 함), Understandable(이해 가능 — 사용자가 이해할 수 있어야 함), Robust(견고 — 보조 기술과 안정적으로 작동해야 함)해야 합니다. 모든 성공 기준은 이 네 가지 원칙 중 하나에 대응하며, 철저한 감사는 이들 모두에 대한 적합성을 점검합니다.

감사에서 가장 자주 발견되는 실패 유형

감지된 접근성 오류의 약 96%는 단 6가지 범주에 속합니다. 무엇을 찾아야 하는지 아는 것이 감사 노력을 우선순위화하는 가장 빠른 방법입니다.

낮은 대비의 텍스트. 이는 일관되게 가장 흔한 실패 유형입니다. 홈 페이지의 거의 84%에서 일반 텍스트에 대해 WCAG 2 AA 대비 기준인 4.5:1을 충족하지 못하는 텍스트가 있습니다. 감사자는 TPGi Colour Contrast Analyser 같은 도구를 사용해 전경색과 배경색의 대비 비율을 확인합니다.
대체 텍스트 누락. 홈 페이지 이미지의 16% 이상이 alt 속성을 전혀 가지고 있지 않아, 스크린 리더 사용자는 이미지 내용을 이해할 방법이 없습니다. 링크된 이미지에 alt 텍스트가 없는 경우는 특히 치명적입니다. 이들은 의미 없는 내비게이션 타깃이 됩니다.
빈 링크. 눈에 보이는 텍스트도, 접근 가능한 이름도 없는 링크는 키보드 및 스크린 리더 사용자에게 막다른 길을 만듭니다. 이들은 링크가 어디로 가는지 알 수 없습니다.
폼 입력 레이블 누락. 프로그래밍 방식으로 연결된 레이블이 없는 폼은 스크린 리더 사용자에게 사용 불가능합니다. 여기에는 눈에 보이는 레이블뿐 아니라 aria-label 또는 aria-labelledby를 사용하는 숨겨진 레이블도 포함됩니다.
빈 버튼. 내비게이션이나 슬라이더에서 흔히 볼 수 있는 아이콘 전용 버튼에 접근 가능한 이름이 없으면, 비시각 사용자들은 버튼이 무엇을 하는지 알 수 없습니다.
문서 언어 누락. <html> 요소의 lang 속성은 스크린 리더에게 어떤 언어를 사용할지 알려줍니다. 이 속성이 없으면 텍스트 음성 변환에 의존하는 사용자에게 발음 오류와 혼란을 야기합니다.

감사는 가장 피해가 큰 실패 유형이 동시에 가장 고치기 쉽다는 사실을 일관되게 보여줍니다. 낮은 대비, 누락된 대체 텍스트, 레이블이 없는 폼 필드는 종종 몇 달이 아니라 며칠 안에 개선할 수 있습니다.

이 여섯 가지 외에도, 철저한 감사는 스킵 내비게이션 링크 누락(키보드 사용자가 매 페이지마다 모든 헤더 요소를 탭으로 통과해야 하게 만드는 문제), 잘못된 헤딩 계층 구조, 포커스를 잘못 가두는 접근 불가능한 모달과 다이얼로그, 자막이 없는 동영상, 태그 구조가 없는 PDF, ARIA를 통해 접근 가능한 역할과 상태를 노출하지 않는 커스텀 JavaScript 위젯 등을 함께 찾아냅니다.

접근성 감사를 수행하는 방법: 단계별 안내

제대로 된 접근성 감사는 단일 스캔이 아니라, 자동화 도구와 전문가의 판단을 결합한 다단계 프로세스입니다. 다음은 이를 체계적으로 접근하는 방법입니다.

1단계: 범위 정의

어떤 테스트를 실행하기 전에, 무엇을 감사할지 결정해야 합니다. 대규모 사이트의 경우 모든 페이지를 테스트하는 것은 비현실적입니다. 대신 W3C가 개발한 WCAG-EM(Website Accessibility Conformance Evaluation Methodology) 접근법을 적용하십시오. 모든 고유한 페이지 템플릿, 모든 주요 사용자 여정, 모든 서로 다른 콘텐츠 유형을 포괄하는 대표 샘플을 정의하는 것입니다. 전자상거래 사이트의 샘플에는 홈 페이지, 카테고리 페이지, 상품 상세 페이지, 장바구니, 체크아웃 플로우, 계정 로그인, 문의 폼, 블로그 게시물이 포함될 수 있습니다. 동적 상태도 반드시 포함해야 합니다. 열린 메뉴, 폼 오류 메시지, 모달 다이얼로그, 로드된 검색 결과 등은 모두 평가 대상입니다.

2단계: 자동화 스캔 실행

자동화 도구는 효율적인 감사의 기반입니다. 이들은 HTML을 빠르게 스캔하고, 명확한 규칙 위반을 표시하며, 기본적인 이슈 목록을 제공합니다. 주요 도구는 다음과 같습니다.

axe DevTools(브라우저 확장 또는 CLI) — 널리 사용되며, 오탐률이 낮고, CI/CD 파이프라인과 통합 가능
WAVE(WebAIM) — 페이지에 오류 아이콘을 시각적으로 주석으로 표시해 비기술 팀 구성원도 직관적으로 이해할 수 있음
Lighthouse(Chrome DevTools 내장) — 성능 및 SEO 지표와 함께 접근성 점수를 제공
Colour Contrast Analyser(TPGi) — 화면의 임의 색상을 선택해 WCAG 대비 기준에 맞는지 확인
PAC 2024 — 다운로드 문서를 위한 전용 PDF 접근성 검사 도구

중요한 한계점이 있습니다. 자동화 도구는 WCAG 이슈의 30%에서 40%만 감지할 수 있습니다. 이들은 누락된 속성, 잘못된 ARIA 역할, 대비 비율 같은 규칙 기반 실패를 표시하는 데 뛰어납니다. 하지만 대체 텍스트가 의미 있는지, 폼이 논리적으로 구성되어 있는지, 사용자가 실제로 작업을 완료할 수 있는지 여부는 판단할 수 없습니다. 이것이 자동화가 전체 감사가 아니라 2단계에 불과한 이유입니다.

3단계: 수동 전문가 테스트

지식 있는 사람 — 이상적으로는 팀 — 이 수행하는 수동 테스트가 감사의 깊이를 결정합니다. 여기에는 다음이 포함됩니다.

키보드 전용 내비게이션. 마우스를 사용하지 말고 Tab, Shift+Tab, Enter, Space, 방향키만으로 모든 핵심 사용자 여정을 완료해 보십시오. 모든 인터랙티브 요소에 도달할 수 있습니까? 포커스 인디케이터는 항상 보입니까? 포커스가 컴포넌트 안으로 사라지는 경우가 있습니까?
스크린 리더 테스트. Windows에서는 Chrome 또는 Firefox와 함께 NVDA를, macOS와 iOS에서는 Safari와 함께 VoiceOver를 사용하십시오. 헤딩, 랜드마크, 링크, 폼 단위로 탐색해 보십시오. 시각적 맥락 없이도 페이지가 이해됩니까? 모든 인터랙티브 요소가 올바르게 안내됩니까?
시각 및 인지적 검토. 헤딩 계층 구조가 논리적인지 확인하고, 오류 메시지가 설명적이며 올바른 필드와 연결되어 있는지 검증하고, 시간 기반 미디어에 자막과 대본이 있는지 확인하며, 안내가 색상, 모양, 위치에만 의존하지 않는지 검토합니다.
코드 검사. HTML 시맨틱, ARIA 사용, 커스텀 위젯의 포커스 관리, 랜드마크 영역을 검토합니다. 포커스를 가두지 않는 모달이나, 키 입력마다 작동하는 ARIA 라이브 영역 같은 문제는 이 수준에서만 발견됩니다.

4단계: 실제 사용자와의 보조 기술 테스트

가장 높은 기준이자, 종종 가장 많은 인사이트를 주는 단계는 보조 기술에 매일 의존하는 실제 사용자와 함께 테스트하는 것입니다. 스크린 리더, 스위치 액세스 장치, 음성 제어 소프트웨어를 사용하는 사람들은 전문가 수동 테스터조차 완전히 재현하지 못하는 방식으로 탐색합니다. 평가에 장애가 있는 사용자를 포함하면 도구와 체크리스트로는 예측할 수 없는 실제 세계의 마찰 지점을 드러낼 수 있습니다.

5단계: 결과 문서화 및 우선순위 설정

실패 목록 원본만으로는 감사 보고서가 아니라 출발점에 불과합니다. 유용한 감사 문서는 영향을 받는 URL 또는 컴포넌트, 위반된 WCAG 성공 기준, 심각도(치명적, 높음, 중간, 낮음), 영향을 받는 사용자에 대한 영향, 그리고 가능한 경우 코드 예시를 포함한 구체적인 개선 지침을 명시해야 합니다. 우선순위는 기술적 편의성보다 사용자 영향에 기반해 설정해야 합니다. 체크아웃을 막는 깨진 폼 레이블은 블로그 사이드바의 비최적 헤딩 레벨보다 훨씬 긴급합니다.

6단계: 개선, 검증, 모니터링

수정 사항을 적용한 후에는, 개선이 실제로 작동한다고 가정하지 말고 반드시 검증해야 합니다. 원래 감사에서 사용한 것과 동일한 도구와 수동 점검 조합으로 각 수정을 재테스트하십시오. 기본적인 적합성 수준을 달성한 후에는 지속적인 모니터링을 구축해야 합니다. 새로운 콘텐츠, CMS 업데이트, 서드파티 스크립트는 언제든지 회귀를 유발할 수 있습니다. 접근성을 보안과 같이 다루십시오. 한 번 달성하고 잊어버리는 것이 아니라, 지속적으로 유지해야 하는 것입니다.

자동화 스캔 vs. 전체 감사: 차이를 이해하기

이 구분은 특히 법적 맥락에서 매우 중요합니다. 자동화 스캔은 렌더링된 HTML에 대해 규칙 기반 검사를 실행합니다. 몇 초 또는 몇 분이 걸리며, 감지된 위반 목록을 반환합니다. 이는 명백하고 대량으로 발생하는 이슈를 잡고, 새로운 회귀가 배포되기 전에 막기 위해 CI/CD 워크플로에 통합하는 데 탁월합니다. 많은 오버레이 및 위젯 제품 — 접근성 도구를 포함해 — 은 기능의 일부로 자동화 스캔 대시보드를 제공하며, 이는 지속적인 모니터링에 실제로 유용합니다.

반면 전체 감사는 자동화 스캔, 전문가 수동 검토, 스크린 리더 테스트, 키보드 전용 내비게이션을 결합해 적용 가능한 모든 WCAG 성공 기준에 대해 사이트를 평가합니다. 자동화와 수동 방법을 결합한 포괄적인 감사는 자동화만으로는 최대 30–40%에 그치는 것과 달리, 접근성 이슈의 90% 이상을 찾아낼 수 있습니다. 법적 요구 서한, 조달 요구사항, 규제 기관의 질의를 마주하게 될 경우, 필요한 문서를 제공해 줄 수 있는 것은 전체 감사뿐입니다.

많은 조직은 실용적인 하이브리드 전략을 사용합니다. 자동화 스캔은 CI/CD에서 지속적으로 실행되어 회귀를 조기에 포착하고, 전체 수동 감사는 매년 또는 대규모 사이트 리디자인 이후에 수행하는 방식입니다. 이는 철저함과 효율성의 균형을 맞추고, 시간이 지나도 준수 상태를 관리 가능하게 유지합니다.

어떤 도구도 단독으로 사이트가 접근성 표준을 충족하는지 판단할 수 없습니다. 사이트가 진정으로 접근 가능한지 판단하려면 지식 있는 사람의 평가가 필요합니다. — W3C Web Accessibility Initiative

감사 결과를 활용하는 방법: 개선 계획 수립

완료된 감사는 행동으로 이어질 때에만 가치가 있습니다. 개선 작업의 우선순위를 어떻게 정하느냐는 이슈를 식별하는 것만큼 중요합니다. 실용적인 개선 우선순위 프레임워크는 다음과 같습니다.

치명적(즉시 수정): 핵심 작업을 완전히 막는 이슈 — 깨진 체크아웃 폼, 접근 불가능한 로그인 모달, 키보드로 접근할 수 없는 내비게이션 메뉴 등입니다. 이들은 가장 높은 법적 위험과 가장 큰 사용자 영향을 의미합니다.
높음(현재 스프린트 또는 릴리스 주기 내 수정): 장애가 있는 사용자의 사용성을 크게 저해하지만 완전히 막지는 않는 이슈 — 상품 이미지의 누락된 대체 텍스트, 본문 텍스트의 낮은 대비, 인터페이스 전반의 레이블 없는 아이콘 버튼 등이 해당됩니다.
중간(계획된 개선): 마찰을 유발하지만 우회 방법이 있는 이슈 — 일관되지 않은 포커스 인디케이터, 누락된 스킵 링크, 비최적의 헤딩 계층 구조 등이 있습니다.
낮음(담당자가 지정된 백로그): 대부분의 경우 사용성에 큰 영향을 주지 않지만 모범 사례에 해당하는 개선 사항 — AAA 수준 향상, 사소한 ARIA 장황성 개선 등이 여기에 속합니다.

모든 수정이 완료되기 전이라도 개선 계획과 일정을 문서화하십시오. 규제 기관과 법원은 일반적으로 아무것도 하지 않는 것보다, 입증 가능한 지속적이고 성실한 개선 노력을 긍정적으로 평가합니다. 요구 서한을 받게 될 경우, 감사 보고서와 개선 일정이 함께 있다면 아무 문서도 없는 것보다 훨씬 유리한 위치에 서게 됩니다.

Accsible이 제공하는 것과 같은 오버레이 위젯과 SDK 도구는 개선 단계에서 의미 있는 역할을 할 수 있습니다. 이들은 개발팀이 더 깊은 코드 수준 개선을 진행하는 동안, (대비, 글꼴 크기, 간격 같은 시각적 선호 영역을 중심으로) 일반적인 이슈의 상당 부분에 대해 즉각적인 해결책을 제공할 수 있습니다. 핵심은 오버레이가 잘 해결하는 영역을 이해하고, 치명적인 장벽에 대한 코드 수준 수정의 대체물이 아니라 계층화된 전략의 일부로 사용하는 것입니다.

접근성 감사를 얼마나 자주 수행해야 할까?

단 한 번의 감사는 특정 날짜의 사이트 상태를 보여주는 스냅샷에 불과합니다. 웹사이트는 살아 있는 제품입니다. 콘텐츠가 바뀌고, 서드파티 스크립트가 업데이트되며, 컴포넌트가 교체되고, 새로운 기능이 배포됩니다. 이들 각각의 이벤트는 새로운 접근성 장벽을 도입할 수 있습니다. 지속 가능한 접근성 프로그램은 일반적으로 다음과 같은 모습을 띱니다.

지속적인 자동화 스캔을 CI/CD 파이프라인 또는 모니터링 대시보드에 통합해, 회귀가 프로덕션에 도달하기 전에 포착
분기별 수동 스팟 체크를 트래픽이 많고 위험도가 높은 페이지(체크아웃, 로그인, 문의 폼, 주요 랜딩 페이지)에 수행
연간 전체 감사를 자격을 갖춘 접근성 전문가가 수행, 특히 대규모 리디자인이나 플랫폼 마이그레이션 이후
디자인 단계에서의 감사 — 새로운 주요 기능이나 리디자인에 대해, 접근성은 사후 보정보다 처음부터 반영하는 것이 훨씬 저렴합니다.

가장 비용 효율적인 접근 방식은 접근성을 왼쪽으로 이동시키는 것입니다 — 즉, 출시 후 컴플라이언스 작업이 아니라, 처음부터 디자인 및 개발 프로세스에 통합하는 것입니다. WCAG 요구사항을 이해하는 개발자는 소스에서 이슈를 잡습니다. 색상 대비와 터치 타깃 크기를 아는 디자이너는 기본적으로 접근 가능한 선택을 합니다. 이 경우 감사는 비상 개입이 아니라 품질 게이트가 됩니다.

핵심 요약

대부분의 웹사이트는 WCAG를 충족하지 못합니다. 홈 페이지의 95% 이상에서 감지 가능한 접근성 오류가 있으며, 가장 흔한 여섯 가지 실패 — 낮은 대비, 누락된 대체 텍스트, 빈 링크, 누락된 폼 레이블, 빈 버튼, 누락된 문서 언어 — 가 대다수를 차지합니다. 이들은 모두 수정 가능합니다.
자동화 도구는 필요하지만 충분하지 않습니다. 자동화 스캐너는 많아야 WCAG 이슈의 30–40%를 잡습니다. 완전한 감사에는 키보드 테스트, 스크린 리더 테스트, 코드와 UX 플로우에 대한 전문가 수동 검토가 필요합니다.
WCAG 2.2 Level AA가 목표입니다. 이는 ADA, European Accessibility Act, Section 508 및 전 세계 대부분의 접근성 프레임워크에서 참조하는 표준입니다. 2.2 AA를 목표로 하면 하위 버전은 자동으로 포괄됩니다.
개선에는 우선순위 프레임워크가 필요합니다. 핵심 사용자 여정을 완전히 막는 이슈부터 시작해, 영향이 크고 빈도가 높은 이슈를 순차적으로 해결하십시오. 모든 것을 문서화하십시오 — 감사 보고서와 개선 계획은 최고의 법적 방어 수단입니다.
접근성은 일회성이 아니라 지속적인 작업입니다. 지속적인 자동 모니터링과 정기적인 수동 감사를 결합하고, 처음부터 디자인 및 개발 프로세스에 접근성을 통합하십시오. Accsible 같은 오버레이 위젯은 더 깊은 개선 작업이 진행되는 동안 간극을 메우는 역할을 할 수 있습니다.

접근성 감사란 무엇인가요? 웹사이트가 WCAG를 준수하는지 확인하는 방법