WCAG 2.2 vs WCAG 2.1: 무엇이 새로워졌고 무엇을 업데이트해야 하는가

WebAIM의 2024년 접근성 분석에 따르면, 여전히 96%가 넘는 홈페이지가 기본적인 WCAG 요구사항을 충족하지 못하고 있습니다. 게다가 이 기준은 이미 5년이나 된 버전을 기준으로 한 것입니다. 2023년 10월 5일, W3C는 WCAG 2.2를 공식 웹 표준으로 발표하며, 9개의 새로운 성공 기준을 추가하고 시대에 뒤떨어진 1개의 기준을 폐지해 기준을 한 단계 끌어올렸습니다. 웹사이트를 운영하거나 디지털 제품을 만들거나 컴플라이언스를 관리하고 있다면, 이 업데이트는 무기한 미룰 수 있는 일이 아닙니다. EU, 영국, 그리고 점점 더 많은 미국 주의 규제가 이미 WCAG 2.2를 기준으로 삼는 방향으로 움직이고 있습니다.

간단한 역사: WCAG 2.1에서 WCAG 2.2까지

웹 콘텐츠 접근성 지침(Web Content Accessibility Guidelines)은 2008년 12월 WCAG 2.0이 출시된 이후 꾸준히 발전해 왔습니다. WCAG 2.1은 2018년 6월에 발표되었으며, 모바일 사용자와 저시력 사용자, 인지 장애가 있는 사람들에게 특히 초점을 맞춘 17개의 새로운 성공 기준을 추가했습니다. 이후 5년 동안 WCAG 2.1은 ADA, Section 508, EU 웹 접근성 지침과 같은 법률의 사실상 컴플라이언스 기준으로 사용되었습니다.

WCAG 2.2는 정확히 2.1이 멈춘 지점에서 다시 시작합니다. W3C는 WCAG 2.2를 시작하면서 세 가지 주요 사용자 그룹에 대한 접근성 지침을 계속 개선한다는 명시적인 목표를 세웠습니다. 바로 인지 또는 학습 장애가 있는 사용자, 저시력 사용자, 모바일 기기를 사용하는 장애인 사용자입니다. 이 계보는 이번 업데이트가 혁명적이라기보다는 점진적(evolutionary)이라는 점에서 중요하지만, 그렇다고 해서 여러분이 아무 조치도 하지 않아도 된다는 뜻은 아닙니다. 여전히 의미 있는 변화이며, 그에 따른 대응이 필요합니다.

구조적으로 가장 중요한 점 중 하나는 WCAG 2.2가 WCAG 2.1과 완전히 하위 호환된다는 것입니다. WCAG 2.2에 적합(conform)하면 자동으로 WCAG 2.1과 WCAG 2.0에도 적합하게 됩니다. 현재 귀하의 조직이 WCAG 2.1 AA를 준수하고 있다면, 2.2에서 새로 도입된 기준만 해결하면 됩니다. 처음부터 다시 시작하는 것이 아닙니다. W3C는 또한 WCAG 2.0과 2.1이 여전히 유효한 권고안이긴 하지만, 조직들이 향후 접근성 작업의 적용 가능성을 극대화하기 위해 WCAG 2.2를 사용할 것을 권장합니다.

WCAG 2.2는 또한 WCAG 2.x 계열의 마지막 점(dot) 릴리스가 될 것으로 널리 예상됩니다. 다음 메이저 버전인 WCAG 3.0은 접근성 지침의 구조를 처음부터 다시 생각한 완전히 다른 체계입니다. 이는 WCAG 2.2가 2008년부터 이어져 온 계보의 사실상 종착점이자, 지금 제대로 맞춰야 하는 버전이라는 뜻입니다.

숫자로 보는 변화: 실제로 무엇이 바뀌었나

변화의 범위를 정확히 짚어보겠습니다. WCAG 2.1에는 세 가지 적합 수준(A, AA, AAA)에 걸쳐 78개의 성공 기준이 있었습니다. WCAG 2.2는 9개의 새로운 성공 기준을 추가하고, 1개의 기준(성공 기준 4.1.1 Parsing)을 제거하여 총 86개의 활성 기준을 남겼습니다. 새로 추가된 9개 중 2개는 Level A, 4개는 Level AA, 3개는 Level AAA입니다.

대부분의 조직이 목표로 삼는 Level AA 준수 — 대부분의 법과 규제가 참조하는 수준 — 관점에서 보면, 실제 영향은 새로 구현해야 할 기준이 6개라는 뜻입니다. 세 개의 Level AAA 추가 기준은 모범 사례로 간주되며, 정부나 의료 분야에서 자주 권장되지만, 오늘날 대부분의 관할 구역에서 법적으로 강제되는 요구사항은 아닙니다.

새로운 기준은 주로 실제 접근성 감사에서 기존 표준이 충분히 다루지 못한다고 반복적으로 지적되었던 네 가지 문제 영역을 다룹니다. 키보드 포커스 가시성, 터치 및 포인터 상호작용, 인지적 접근성, 인증 장벽입니다. 이는 이론적인 문제가 아닙니다. 로그인, 양식 작성, 고정 헤더가 있는 페이지 탐색처럼, 장애가 있는 사람들이 일상적인 작업을 완료하지 못하게 만드는 유형의 장벽들입니다.

아홉 가지 새로운 성공 기준 설명

각 새로운 기준이 무엇을 요구하고, 실제로 왜 중요한지에 대한 설명입니다. 기준은 적합 수준별로 제시하므로, 개선 작업의 우선순위를 정하는 데 도움이 될 것입니다.

Level A (최소 — 모든 곳에 필수)

• 2.4.11 Focus Not Obscured (Minimum): UI 구성 요소가 키보드 포커스를 받을 때, 작성자가 만든 콘텐츠에 의해 완전히 가려져서는 안 됩니다. 여기서 가장 흔한 문제 요소는 페이지 위에 겹쳐지는 스티키 헤더, 떠 있는 쿠키 배너, 라이브 채팅 위젯입니다. 사용자가 Tab 키를 눌러 포커스가 스티키 내비게이션 바에 완전히 가려진 버튼에 도달한다면, 이 기준을 위반한 것입니다. Level A에서는 부분적으로 가려지는 것은 허용된다는 점에 유의해야 합니다. 요소가 100% 숨겨지지만 않으면 됩니다.
• 2.5.7 Dragging Movements: 드래그 동작이 필요한 모든 기능 — 예를 들어 드래그 앤 드롭 파일 업로드, 정렬 가능한 리스트 항목, 슬라이더 컨트롤 등 — 은 드래그 없이 단일 포인터 동작(클릭이나 탭 등)만으로도 조작할 수 있어야 합니다. 이는 정교한 드래그 제스처를 안정적으로 수행하기 어려운 운동 장애 사용자에게 매우 중요합니다. 이 요구사항은 작성자가 만든 콘텐츠에 적용되며, 브라우저의 기본 동작은 예외입니다.

Level AA (표준 준수를 위한 필수 수준)

• 2.4.12 Focus Not Obscured (Enhanced): 2.4.11의 더 엄격한 버전입니다. Level AA에서는 요소가 키보드 포커스를 받을 때, 포커스 표시의 어떤 부분도 작성자가 만든 콘텐츠에 의해 가려져서는 안 됩니다. 이는 Level A 버전의 허점을 없애고, 포커스된 요소가 부분적으로가 아니라 완전히 보여야 함을 요구합니다.
• 2.5.8 Target Size (Minimum): 인터랙티브 요소의 클릭 또는 탭 가능한 영역은 최소 24×24 CSS 픽셀이어야 하며, 인라인 텍스트 링크, 사용자 에이전트가 제어하는 요소, 인근에 동등한 24×24 타깃이 존재하는 경우 등 특정 예외가 있습니다. 이는 WCAG 2.1과 비교했을 때 상당한 변화입니다. 2.1에서는 44×44 픽셀 타깃 크기가 AAA 수준에서만 권장사항이었기 때문입니다. 이제 최소 기준이 AA 수준에서 강제될 수 있습니다. 24×24px는 최저선일 뿐이며, AAA 기준(2.5.5)은 여전히 44×44px를 권장하고 있고, 이는 터치 친화적 디자인의 골드 스탠더드로 남아 있습니다.
• 3.2.6 Consistent Help: 웹사이트가 어떤 도움 메커니즘 — 사람의 연락처 정보, 셀프 헬프 도구, 자동화된 채팅, 문의 양식 등 — 을 제공하고, 그 메커니즘이 여러 페이지에 걸쳐 나타난다면, 각 페이지에서 동일한 상대적 위치에 나타나야 합니다. 특히 인지 장애가 있는 사용자를 포함해, 도움이 필요한 사용자는 매번 찾느라 헤매지 않고 항상 같은 위치에서 도움을 찾을 수 있어야 합니다.
• 3.3.7 Redundant Entry: 사용자가 동일한 프로세스의 이전 단계에서 이미 입력한 정보는 다시 타이핑하지 않도록 자동으로 채워주거나 선택할 수 있도록 제공해야 합니다. 예를 들어 여러 단계로 이루어진 결제 흐름에서 청구지 주소를 입력한 뒤, 다시 배송지 주소를 묻는 경우를 생각해 보십시오. 사용자는 이미 입력한 내용을 복사할 수 있는 방법을 제공받아야 합니다. 보안을 위해 재입력이 필수적인 경우(비밀번호 확인 등)나, 이전에 입력한 데이터가 더 이상 유효하지 않은 경우에는 예외가 허용됩니다.
• 3.3.8 Accessible Authentication (Minimum): 퍼즐 풀기, 비밀번호 암기, 이미지 CAPTCHA의 문자를 옮겨 적기와 같은 인지 기능 테스트는 인증의 유일한 수단으로 요구되어서는 안 됩니다. 대체 방법이 제공되거나, 비밀번호 관리자를 허용하거나 비밀번호 필드에 복사-붙여넣기를 허용하는 등 사용자를 돕는 메커니즘이 있어야 합니다. 이 기준은 CAPTCHA를 전면 금지하는 것이 아니라, 이를 완료할 수 없는 사용자에게 CAPTCHA가 유일한 옵션이 되어서는 안 된다는 점을 요구합니다.

Level AAA (강화 — 대부분의 경우 권장되지만 의무는 아님)

• 2.4.13 Focus Appearance: 키보드 포커스 표시가 보일 때, 특정 최소 크기와 명도 대비 요구사항을 충족해야 합니다. 포커스 영역은 요소를 둘러싼 두께 2 CSS 픽셀의 둘레(perimeter)만큼의 영역보다 작지 않아야 하며, 포커스된 상태와 포커스되지 않은 상태 간의 명도 대비는 최소 3:1이어야 합니다. 이 기준은 원래 Level AA에 포함될 예정이었으나, 복잡성 때문에 AAA로 이동되었습니다. 이는 AA만을 목표로 할 경우, 포커스 표시의 최소 크기에 대한 규범적인 정의는 여전히 없고, 단지 포커스 표시가 보여야 한다는 요구만 존재한다는 뜻입니다.
• 2.5.9 Dragging Movements (Enhanced): 잠깐 — 이번 릴리스에는 2.5.9가 없습니다. AAA 수준의 드래그 관련 강화 요구사항은 아래 3.3.9에 포함되어 있습니다.
• 3.3.9 Accessible Authentication (Enhanced): 3.3.8의 더 엄격한 버전입니다. Level AAA에서는 객체 인식 및 개인 콘텐츠 테스트(예: "모든 신호등을 클릭하세요" 또는 "계정에서 사진을 선택하세요")도 금지되며, 이는 AA 수준에서 허용되던 예외를 포함합니다. 예외는 네 가지가 아니라 두 가지로 줄어듭니다.

제거된 항목: 4.1.1 Parsing

WCAG 2.2는 WCAG 2.0부터 존재해 온 성공 기준 하나를 제거했습니다. 바로 4.1.1 Parsing입니다. 이 기준은 원래 HTML이 잘 구성되어 있어야 한다는 것을 요구했습니다. 시작 및 종료 태그가 완전하고, 중첩이 올바르며, 중복 속성이 없어야 한다는 식입니다. 그 의도는 브라우저와 보조 기술이 마크업을 안정적으로 파싱하고, 사용자에게 콘텐츠를 올바르게 제공할 수 있도록 하는 것이었습니다.

이 제거는 논란의 여지가 거의 없습니다. 실제 기술 환경의 변화를 반영하기 때문입니다. 2008년 이후 브라우저는 잘못된 HTML을 표준화된 오류 수정 알고리즘에 따라 매우 안정적으로 처리할 수 있게 되었습니다. 스크린 리더와 같은 보조 기술은 이제 원시 HTML 소스가 아니라 브라우저의 DOM(Document Object Model)에 의존합니다. W3C는 이 기준이 현대 환경에서는 더 이상 의미 있는 접근성 이점을 제공하지 않는다고 결론 내렸습니다. 과거에 4.1.1로 포착되던 접근성 문제는 여전히 1.3.1(정보와 관계)이나 4.1.2(이름, 역할, 값)와 같은 더 구체적인 기준으로 다뤄지고 있습니다.

귀하의 팀에 대한 실질적인 의미는 다음과 같습니다. 자동화 테스트 도구가 4.1.1 Parsing 실패를 계속 표시하고 있었다면, 이제 그것은 더 이상 WCAG 2.2 기준에서의 문제는 아닙니다. 버전 업그레이드만으로도, 실제로 아무것도 고치지 않았는데 보고되는 실패 건수가 줄어드는 것을 볼 수 있습니다. 그렇다고 해서 유효하고 잘 구조화된 HTML을 작성하는 것이 중요하지 않다는 뜻은 아닙니다. 여전히 강력한 모범 사례이지만, 그 자체만으로는 더 이상 컴플라이언스 요구사항은 아닙니다.

규제 및 법적 영향

새로운 기준을 이해하는 것과, 그것이 법적 리스크에 어떤 의미를 갖는지 이해하는 것은 별개의 문제입니다. 결론부터 말하면, WCAG 2.2는 여러 관할 구역에서 사실상의 법적 기준이 되어가고 있으며, 그 전환 속도는 많은 조직이 생각하는 것보다 빠릅니다.

영국에서는 공공 부문 기관이 이미 Public Sector Bodies Accessibility Regulations에 따라 WCAG 2.2 Level AA를 충족해야 합니다. 유럽연합에서는 European Accessibility Act의 기술적 기반이 되는 표준 EN 301 549가 WCAG 2.2를 기준으로 채택하는 과정에 있습니다. EAA 자체는 EU에서 제품과 서비스를 제공하는 대부분의 민간 조직에 대해 2025년 6월을 집행 시한으로 두고 있습니다. 미국의 여러 주(예: Colorado)도 주 접근성 법을 WCAG 2.1에서 WCAG 2.2로 업데이트하겠다는 의사를 밝힌 상태입니다.

미국에서는 ADA Title II가 현재 주 및 지방 정부 웹사이트의 기술 표준으로 WCAG 2.1 AA를 참조하고 있습니다. 그러나 미국 법원은 접근성 소송에서 점점 더 WCAG 2.2를 인용하고 있으며, 방향성은 분명합니다. 연방 차원의 공식 의무화가 있을 때까지 기다리는 것은, 특히 전자상거래, 금융 서비스, 의료 기관처럼 접근성 소송의 주요 타깃이 되는 조직에게 점점 더 큰 법적 리스크를 수반하는 컴플라이언스 전략입니다.

귀하의 조직이 아직 WCAG 2.2 준수를 법적으로 요구받고 있지 않더라도, 새로운 성공 기준을 가능한 한 빨리 충족하는 것은 변화하는 규제보다 앞서 나갈 수 있게 해 줄 뿐 아니라, 더 중요한 것은 오늘날 실제 사용자들이 겪고 있는 접근성 장벽보다 앞서 나갈 수 있게 해 줍니다.

사이트를 감사하고 업데이트하는 방법

이미 WCAG 2.1 AA를 준수하고 있다면, WCAG 2.2로의 업그레이드 경로는 관리 가능한 수준입니다. 다음은 이를 접근하는 실질적인 프레임워크입니다.

우선 새로 추가된 6개의 Level AA 기준에 대한 타깃 감사부터 시작하십시오. 대부분의 조직에 법적 영향을 미치는 기준은 이들입니다. 특히 2.4.11과 2.4.12(포커스 가려짐), 2.5.8(타깃 크기), 3.2.6(일관된 도움), 3.3.7(중복 입력), 3.3.8(접근 가능한 인증)에 집중하십시오. 숙련된 접근성 엔지니어라면, 중간 정도 복잡도의 사이트에 대해 이 기준들을 수동으로 몇 시간 안에 감사할 수 있습니다.

스티키/고정 위치 요소부터 감사하십시오. 포커스 가려짐 기준(2.4.11과 2.4.12)은 웹에서 가장 흔한 UI 패턴 — 스티키 헤더, 플로팅 액션 버튼, 쿠키 동의 바, 채팅 위젯 — 에 의해 자주 위반됩니다. Tab 키만 사용해 사이트 전체를 탐색하면서, 포커스된 요소가 고정 레이어 아래로 사라지는 경우가 있는지 관찰하십시오. CSS 수정은 보통 간단합니다.

/* 스티키 헤더가 포커스된 요소를 가리지 않도록 방지 */
:focus {
  scroll-margin-top: 80px; /* 스티키 헤더 높이에 맞추기 */
}

모든 인터랙티브 요소의 탭 타깃 크기를 감사하십시오. 이는 컴플라이언스와 사용자 경험 측면에서 모두 빠른 개선이 가능한 영역입니다. 버튼, 링크, 폼 컨트롤, 아이콘은 모두 최소 24×24 CSS 픽셀이어야 합니다. 많은 디자인 시스템이 이미 이 기준을 초과하고 있지만, 작은 아이콘 버튼 — 닫기 아이콘, 소셜 공유 버튼, 인라인 액션 링크 — 은 자주 문제를 일으킵니다. 컴포넌트를 점검하고 필요한 경우 패딩을 추가하거나 크기를 조정하십시오.

인증 흐름을 꼼꼼히 검토하십시오. SC 3.3.8(Accessible Authentication)은 실제로 영향력이 큽니다. 우회하거나 대체 방법으로 해결할 수 없는 CAPTCHA를 사용하고 있다면, 비준수일 가능성이 높습니다. 로그인, 회원가입, 2단계 인증 흐름에서 비밀번호 관리자의 자동 완성을 허용하는지, 복사-붙여넣기를 허용하는지, 매직 링크나 일회용 코드 같은 대체 인증 방법을 제공하는지, 인지적 과제를 수행할 수 없는 사용자를 위한 다른 조정 수단이 있는지 평가하십시오.

다단계 양식에서 중복 입력을 감사하십시오. 여러 단계에 걸친 프로세스 — 결제, 온보딩 흐름, 신청서 등 — 를 모두 나열하고, 사용자가 이미 제공한 정보를 다시 요구하는 모든 지점을 식별하십시오. 가능한 곳에는 자동 채우기 로직이나 "위와 동일" 토글을 추가하십시오. 이는 보통 복잡한 아키텍처 변경이 아니라, 백엔드나 폼 상태 관리 수준의 변경으로 해결됩니다.

도움 메커니즘이 일관된 위치에 있는지 확인하십시오. 여러 페이지에 걸쳐 나타나는 채팅 위젯, 도움말 링크, 전화번호 등이 있다면, 그 상대적 위치가 바뀌지 않는지 확인하십시오. 이는 보통 페이지별 문제가 아니라 템플릿이나 레이아웃 문제입니다. 컴포넌트 라이브러리나 CMS 템플릿에서 수정하면 전체에 반영됩니다.

초기 탐지를 위해 자동화 도구를 사용하되, 거기서 멈추지 마십시오. 자동 스캐너는 WCAG 2.2 문제의 약 40% 정도만 감지할 수 있습니다. 타깃 크기 위반이나 명백한 포커스 관리 문제를 잡는 데는 유용하지만, CAPTCHA가 유일한 인증 옵션인지, 도움 메커니즘이 일관된 위치에 있는지 등은 평가할 수 없습니다. 키보드 전용 탐색과 스크린 리더 테스트를 포함한 수동 테스트는 여전히 필수입니다. 장애가 있는 실제 사용자와 함께 테스트하면, 어떤 자동 도구로도 발견할 수 없는 문제를 찾아낼 수 있습니다.

WCAG 2.2와 오버레이 위젯: 알아두어야 할 점

Accsible과 같은 접근성 오버레이 위젯과 SDK는 특히 글자 크기 확대, 명도 대비 변경, 키보드 내비게이션 강화와 같은 실시간 조정이 필요한 사용자에게 특정 범주의 접근성 문제를 드러내고 완화하는 데 의미 있는 도움을 줄 수 있습니다. WCAG 2.2 준수 관점에서, 오버레이가 할 수 있는 것과 할 수 없는 것을 명확히 이해하는 것이 중요합니다.

오버레이는 특정 포커스 가시성 문제를 해결하고, 대체 내비게이션 모드를 제공하며, 일부 디자인 수준의 부족함을 보완하는 사용자 측 커스터마이징을 제공할 수 있습니다. 장기적인 개선 작업이 진행되는 동안 사용자 경험을 빠르게 개선해야 하는 팀에게는 유용한 접근성 스택의 한 층입니다. 그러나 이는 근본적인 코드를 수정하는 것을 대체할 수는 없습니다. 특히 인증(3.3.8), 중복 입력(3.3.7), 드래그 동작(2.5.7)과 관련된 새로운 WCAG 2.2 기준은 단순히 표현 방식이 아니라 애플리케이션 구조 자체를 변경해야 합니다.

가장 효과적인 접근 방식은 사용자 측 적응성을 제공하는 잘 구현된 오버레이와, 새로운 2.2 기준을 충족하기 위한 적절한 코드 수준 수정 작업을 결합하는 것입니다. 오버레이 SDK를 일종의 힘을 배가시키는 도구로 생각하십시오. 더 많은 사용자에게 도달하고, 경험을 개선하며, 빈틈을 메워주지만, 그 기반은 여전히 탄탄해야 합니다.

핵심 요약

• WCAG 2.2는 9개의 새로운 성공 기준을 추가하고, 하나의 오래된 규칙(4.1.1 Parsing)을 제거합니다. 2.1과 완전히 하위 호환되므로, 기존의 컴플라이언스 작업이 무의미해지지 않습니다. 새로 추가된 부분만 덧붙이면 됩니다.
• Level AA 준수를 위해서는 여섯 가지 새로운 기준에 집중하십시오. Focus Not Obscured(2.4.11과 2.4.12), Target Size Minimum(2.5.8), Consistent Help(3.2.6), Redundant Entry(3.3.7), Accessible Authentication(3.3.8)입니다. 대부분의 조직에 법적으로 중요한 기준은 이들입니다.
• 규제 채택 속도는 빨라지고 있습니다. 영국 공공 부문은 이미 WCAG 2.2를 집행하고 있고, EU는 European Accessibility Act 하에서 WCAG 2.2로 전환 중이며, 미국 법원도 이를 점점 더 인용하고 있습니다. 귀하의 관할 구역에서 공식적인 의무화가 있을 때까지 기다리지 마십시오.
• 자동화 도구는 WCAG 2.2 문제의 약 40%만 포착합니다. 진정한 준수를 위해서는 수동 테스트, 키보드 전용 탐색 점검, 실제 사용자 테스트가 필수이며, 특히 인증과 인지적 접근성과 관련된 새로운 기준에서 그렇습니다.
• 가장 흔한 빠른 개선 영역은 포커스된 요소를 가리는 스티키 헤더 수정, 작은 탭 타깃 확대, 로그인/인증 흐름의 CAPTCHA 의존성 감사입니다. 이러한 변경은 대체로 노력 대비 효과가 크며, WCAG 2.2 개선 작업을 시작하기에 좋은 출발점입니다.