쿠키 동의 접근성: 동의 배너의 WCAG 2.2 준수
키보드 사용자가 닫을 수 없거나, 화면 읽기 프로그램이 알릴 수 없거나, 색맹 방문자가 읽을 수 없는 쿠키 배너는 단순히 나쁜 UX만의 문제가 아닙니다 — 두 가지 측면에서 동시에 준법 위반입니다. 2025년 6월 유럽 접근성법이 발효된 이후, EU 사용자에게 서비스를 제공하는 상업 웹사이트의 동의 인터페이스는 WCAG 2.1 Level AA를 충족해야 하며, 2026년에는 WCAG 2.2가 강력히 권장됩니다. 동의가 "자유롭게, 구체적으로, 정보에 기반하여, 명확하게" 이루어져야 한다는 GDPR 요건과 결합하면, 접근성이 없는 배너는 현재 이중 법적 위험을 지닙니다. 이 가이드는 2026년의 WCAG 준수 쿠키 배너가 어떻게 생겼는지 정확히 설명합니다.
접근성과 동의가 현재 겹치는 이유
GDPR은 배너를 보고 클릭할 수 있는 사람만이 아니라 모든 사용자로부터 동의를 얻을 수 있도록 요구합니다. 유럽 데이터 보호 위원회는 데이터 주체가 사이트가 수용하지 않은 장애로 인해 동의 인터페이스와 의미 있는 상호작용을 할 수 없는 경우 동의가 유효하게 취득되지 않는다고 명확히 했습니다. 즉 쿠키는 처음부터 로드되지 않았어야 한다는 의미입니다.
접근성 측면에서, 모든 EU 회원국에서 국내법으로 전환된 유럽 접근성법(EAA)은 소비자 서비스를 제공하는 민간 부문 웹사이트 및 앱의 최소 기준으로 WCAG 2.1 AA를 규정합니다. 제재 제도는 국가별로 다르지만 일반적으로 위반당 €50,000에서 €500,000 범위이며, 지속적인 비준수에 대해서는 시장 철수 명령이 추가됩니다.
쿠키 배너의 핵심 WCAG 요건
키보드 조작성
배너의 모든 컨트롤 — 수락, 거부, 환경설정 관리, 닫기 — 은 키보드만으로 접근 및 조작할 수 있어야 합니다. 사용자는 Tab 키로 논리적인 순서로 버튼을 이동하고 Enter 또는 Space로 활성화할 수 있어야 합니다. 포커스는 배경 대비 최소 3:1 대비 비율로 시각적으로 확인할 수 있어야 합니다.
모달 배너의 포커스 트랩
배너가 페이지의 나머지 부분과의 상호작용을 차단하는 경우, 사용자가 선택할 때까지 키보드 포커스는 배너 내부에 갇혀 있어야 합니다. 사용자는 Tab으로 배너를 벗어나 기본 페이지를 스크롤할 수 없어야 합니다. 포커스가 갇혀 있다가 배너가 닫힐 때, 포커스는 배너를 트리거한 요소 또는 합리적인 기본값으로 돌아가야 합니다.
화면 읽기 프로그램 알림
배너는 접근 가능한 이름과 역할을 가진 대화 상자로 알려져야 합니다. 배너 제목을 가리키는 `aria-labelledby` 및 설명 텍스트를 가리키는 `aria-describedby` 와 함께 `role="dialog"` 또는 `role="alertdialog"` 를 사용합니다.
색상 대비
본문 텍스트는 배경 대비 4.5:1 대비를 충족해야 합니다. 큰 텍스트(18pt+ 또는 14pt 굵게)는 3:1이 필요합니다. 버튼 텍스트, 아이콘 및 포커스 표시기는 각각 고유한 대비 최솟값이 있습니다. 흰색 배경의 밝은 회색 "거부" 버튼은 감사에서 자주 보이는 WCAG 실패 사례입니다.
색상 단독 사용 신호 없음
수락과 거부를 구분하는 데 색상만 의존하지 마십시오. 색맹 사용자가 버튼을 구분할 수 있도록 뚜렷한 레이블, 아이콘 또는 모양을 사용합니다.
다크 패턴과 접근성
WCAG 2.2는 다크 패턴을 직접 겨냥한 새로운 기준을 도입합니다 — 동의와 특히 관련이 있습니다:
- 3.3.8 접근 가능한 인증 — 동의 마찰로서의 인지적 퍼즐을 금지합니다.
- 3.3.7 중복 입력 — 사용자는 동의를 철회하기 위해서만 정보를 다시 입력할 필요가 없어야 합니다.
- 2.4.11 포커스 가려지지 않음 — 배너 자체가 뒤에 있는 요소의 포커스 표시기를 가려서는 안 됩니다.
- 2.5.7 드래그 동작 — 배너에서 드래그로 수락 상호작용을 사용하는 경우 단일 포인터 대안이 있어야 합니다.
RTL 및 국제화
접근성은 우에서 좌로 쓰는 언어(아랍어, 히브리어, 페르시아어, 우르두어) 및 화면 읽기 프로그램 발음까지 확장됩니다:
- 문서 언어가 RTL일 때 배너에 `dir="rtl"` 설정 — 버튼 순서와 포커스 흐름이 읽기 방향과 일치하도록.
- 번역된 배너 텍스트에 올바른 `lang` 속성 사용 — 화면 읽기 프로그램이 올바른 음운으로 단어를 발음하도록.
- 아이콘 미러링 — 화살표 및 진행 표시기는 RTL 로케일에서 뒤집혀야 합니다.
WCAG 준수를 위한 배너 테스트
단일 도구에만 의존하지 마십시오. 자동화된 스캐닝과 실제 보조 기술 테스트를 결합하십시오:
- axe DevTools 또는 Lighthouse — WCAG 실패의 약 30~40%를 자동으로 감지합니다.
- Windows의 NVDA 또는 JAWS, Mac/iOS의 VoiceOver, Android의 TalkBack — 실제 화면 읽기 프로그램으로 테스트합니다. 화면 읽기 프로그램만 사용하여 배너를 알리고, 탐색하고, 닫을 수 있습니까?
- 키보드 전용 탐색 — 마우스를 뽑습니다. 수락, 거부, 환경설정 관리를 할 수 없다면 키보드 사용자도 할 수 없습니다.
- 색맹 시뮬레이션 — Chrome DevTools에 내장 시각 장애 시뮬레이터가 있습니다. 적록색맹, 녹적색맹, 청황색맹 상태에서 수락과 거부가 구분되는지 확인합니다.
- 400% 확대 — WCAG는 수평 스크롤 없이 400% 확대에서 콘텐츠가 사용 가능해야 함을 요구합니다. 고정 위치 배너는 이 테스트를 종종 통과하지 못합니다.
자주 보이는 접근성 실패
- 톱니바퀴 아이콘 뒤에 숨겨진 거부 — 다크 패턴과 접근성 실패 동시 발생(아이콘 버튼에 접근 가능한 이름 없음).
- 포커스가 배너에 도달하지 않음 — 시각적 주의를 끌지만 Tab 순서에서 건너뛰어지는 배너.
- 포커스 트랩 없는 모달 배너 — 배너가 상호작용을 차단한다고 주장하면서 사용자가 배경 페이지로 Tab 이동할 수 있는 상태.
- 환경설정 변경 시 `aria-live` 없음 — 화면 읽기 프로그램 사용자가 선택이 저장됐다는 확인을 듣지 못함.
- `lang` 속성 없는 번역된 배너 — 화면 읽기 프로그램이 스페인어 텍스트를 영어 음운으로 발음함.
FlexyConsent가 접근성을 제공하는 방법
FlexyConsent는 기본적으로 WCAG 2.2 AA를 충족합니다:
- 모든 컨트롤은 3:1 시각적 포커스 표시기와 함께 키보드로 조작 가능합니다.
- `aria-labelledby` 와 `aria-describedby` 를 갖춘 적절한 `role="dialog"`.
- 선택적 배너에 대한 Escape-to-dismiss가 있는 포커스 트랩.
- 거부 포함 모든 텍스트 요소에 4.5:1+ 대비.
- 아랍어, 히브리어, 페르시아어 및 우르두어 로케일에 대한 자동 RTL 전환.
- 정확한 화면 읽기 프로그램 발음을 위해 번역별로 설정된 `lang` 속성.
- 400%에서도 사용 가능한 줌 허용 레이아웃.