색상 대비 자동 측정 — WCAG 명도대비 공식을 ViewCheck가 코드로 구현한 방법

4.5:1이라는 숫자 뒤에 숨어 있는 수학과 인간의 눈, 그리고 우리가 아직 완전히 풀지 못한 것들

---

들어가며 — "이 텍스트 색, 괜찮은 거 맞아요?"

공공 웹사이트를 운영하다 보면 이런 장면을 자주 만난다. 디자이너가 새로운 색상 팔레트를 들고 온다. 옅은 회색 배경에 조금 더 짙은 회색 글씨. 스크린상에서는 꽤 세련돼 보인다. 그런데 담당자는 묻는다. "이 텍스트 색, 접근성 기준에 맞는 거 맞아요?"

디자이너는 눈으로 보기엔 충분히 구분된다고 생각한다. 하지만 '충분히'의 기준이 어디서 오는지 아는 사람은 드물다. 사람 눈의 감각은 절대적인 도구가 아니다. 동일한 두 색을 놓고도 조명 조건, 모니터 캘리브레이션, 개인의 시력 상태, 나이, 심지어 그날의 피로도에 따라 다르게 지각한다. 그래서 '눈에 보이면 됐지'는 접근성의 논리가 될 수 없다.

WCAG가 제시한 해답은 수학이다. 두 색의 명도 차이를 공식으로 계산하고, 그 비율이 특정 수치를 넘으면 '충분한 대비'로 인정한다. 4.5:1이라는 숫자가 그 임계값이다. 이 숫자는 감이 아니라 계산에서 나온다. 그리고 계산이 있다면, 자동화가 가능하다.

ViewCheck가 색상 대비 자동 측정을 도입한 건 이 논리에서 출발했다. 공공 웹사이트에는 텍스트가 수천 개다. 한 페이지 안에서도 본문, 제목, 링크, 버튼 레이블, 라벨, 안내 문구, 에러 메시지 — 이 모든 텍스트 요소의 색상 대비를 사람이 일일이 측정하는 건 물리적으로 불가능하다. 게다가 사이트 전체라면 수십 페이지에 걸쳐 반복된다. 자동화가 없으면 현실적인 품질 관리는 어렵다.

다만 솔직히 말해두고 싶다. 색상 대비 자동 측정은 생각보다 복잡한 문제다. 공식 자체는 단순해 보이지만, 실제 웹 환경에서 그것을 정확하게 적용하려면 생각지 못한 엣지 케이스가 계속 튀어나온다. 이 글은 우리가 무엇을 구현했고, 어디서 막혔으며, 아직도 어떤 부분이 도전 과제로 남아 있는지를 솔직하게 들려주는 글이다.

---

1.4.3 대비(최소) — WCAG가 4.5:1을 정한 이유

세계적으로 가장 많이 쓰이는 접근성 기준인 WCAG(Web Content Accessibility Guidelines)는 현재 2.2 버전까지 발행되어 있다. 이 안에서 색상 대비를 직접 다루는 항목은 두 가지다.

첫째는 SC 1.4.3 대비(최소) — 준수등급 AA다. W3C WAI의 공식 문서에 따르면, "텍스트와 텍스트 이미지의 시각적 표현은 배경에 대해 최소 4.5:1의 대비율을 가져야 한다. 다만 큰 텍스트는 3:1로 완화한다"고 규정한다(W3C, Understanding WCAG SC 1.4.3, w3.org/WAI/WCAG21/Understanding/contrast-minimum.html). 여기서 '큰 텍스트'란 일반 굵기로 18포인트(약 24px) 이상이거나, 굵은 글씨체로 14포인트(약 18.66px) 이상인 텍스트를 뜻한다.

왜 하필 4.5:1인가? WCAG 기술 문서는 이 값이 "시력이 20/80 정도로 저하된 사람이 색 보정 렌즈 없이도 텍스트를 읽을 수 있는 수준"을 근거로 한다고 밝힌다. 법적 저시력의 경계가 대략 20/200 시력인데, 20/80은 그보다는 낫지만 일반 시력(20/20)보다는 훨씬 낮은 수준이다. 다시 말해, 4.5:1은 적잖은 수의 저시력 사용자를 포용하는 최소선으로 설정된 것이다. "최소"라는 단어가 이름에 붙은 이유이기도 하다.

큰 텍스트에 3:1을 적용하는 건 이유가 있다. 글자가 크면 같은 명도 차이라도 우리 눈이 더 잘 구분한다. 글자의 선폭(stroke width)이 넓어지면 배경과의 경계가 더 뚜렷하게 인식되기 때문이다. 따라서 동일한 색상 조합이더라도, 18pt 이상의 큰 제목에는 3:1만 돼도 충분하고, 소형 본문 텍스트에는 4.5:1이 필요하다.

둘째는 SC 1.4.6 대비(강화) — 준수등급 AAA다. 이건 같은 규칙을 더 높은 기준으로 적용한다. 일반 텍스트 7:1, 큰 텍스트 4.5:1이다. AAA는 권장 수준이지 의무는 아니지만, 시각적으로 취약한 사용자를 더 폭넓게 수용하기 위한 지향점이다.

그리고 WCAG 2.1에서 새로 추가된 것이 SC 1.4.11 비텍스트 대비 — 준수등급 AA다. 텍스트가 아닌 UI 구성요소(버튼 테두리, 입력창 외곽선, 체크박스 표시, 슬라이더 핸들, 탭 인디케이터 등)와 그래픽 요소에도 최소 3:1 대비를 요구한다(W3C WAI, Understanding WCAG SC 1.4.11, w3.org/WAI/WCAG21/Understanding/non-text-contrast.html). 이 항목이 추가되기 전에는 텍스트 대비만 검사해도 됐지만, 이제는 버튼의 테두리 색과 배경색 사이의 대비도 점검 대상이 된다.

한국에서는 이 기준이 **KWCAG 2.2(한국형 웹 콘텐츠 접근성 지침 2.2)**로 번역·반영되어 있다. 공식 KWCAG 2.2 문서에 따르면 "모든 텍스트의 명도대비는 4.5:1 이상을 유지하여 제공"하도록 규정하고 있다(a11ykr.github.io/kwcag22). WCAG의 AA 수준을 그대로 국내 기준으로 채택한 것이다.

행정안전부 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25.)은 이 KWCAG를 접근성 영역의 기준으로 준용한다. 공공 웹사이트는 결국 이 지침을 따라야 하고, 그 안에 색상 대비 요건도 포함된다(mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636). 즉, 4.5:1은 공공 웹 담당자에게 선택이 아니라 의무에 가깝다.

---

상대 휘도(Relative Luminance) — 공식의 심장

4.5:1이 '비율'이라면, 비율의 분자와 분모를 어떻게 구하는가? 그 답이 상대 휘도(Relative Luminance) 공식이다.

W3C가 WCAG에서 정의한 상대 휘도 공식은 다음과 같다(W3C, Relative luminance definition, w3.org/WAI/GL/wiki/Relative_luminance):

L = 0.2126 × R + 0.7152 × G + 0.0722 × B

여기서 R, G, B 각각은 먼저 감마 보정(sRGB 변환)을 거쳐야 한다:

RsRGB = R_8bit / 255

if RsRGB <= 0.04045:
    R = RsRGB / 12.92
else:
    R = ((RsRGB + 0.055) / 1.055) ^ 2.4

G, B도 동일한 방식으로 처리한다.

이 공식은 어디서 왔는가? ITU-R BT.709 색공간 표준의 휘도 계수를 가져온 것이다. 0.2126(적색), 0.7152(녹색), 0.0722(청색)이라는 가중치는 인간의 눈이 세 가지 기본색에 얼마나 민감한지를 반영한다. 녹색에 가장 큰 가중치(71.52%)가 붙은 이유는, 우리 눈의 추상세포(cones)가 녹색 파장에 가장 민감하게 반응하기 때문이다. 파란색에는 겨우 7.22%만 부여됐다.

감마 보정이 왜 필요한가? 컴퓨터 화면의 RGB 값(0~255)은 물리적 빛의 강도와 선형 관계가 아니다. 같은 크기의 숫자 차이가 밝은 영역에서는 눈에 덜 보이고, 어두운 영역에서는 더 도드라진다. 이 비선형성을 보정하기 위해 sRGB 감마 변환을 적용하는 것이다. 2021년 이전에는 임계값을 0.03928로 썼지만, 지금은 0.04045로 수정되어 있다. 실제 계산 결과에는 거의 차이가 없다는 게 W3C의 설명이다.

두 색의 상대 휘도 L1(밝은 색)과 L2(어두운 색)를 구했다면, 대비율은:

대비율 = (L1 + 0.05) / (L2 + 0.05)

0.05라는 상수를 더하는 이유는 완전한 검정(L=0)이 분모에 올 때 무한대가 나오는 것을 막고, 실제 디스플레이에서 완전한 검정이 존재하지 않는다는 현실을 반영하기 위해서다. 순수 흰색(#FFFFFF)과 순수 검정(#000000)의 대비율은 이 공식으로 계산하면 21:1이 나온다. 이것이 이론적 최댓값이다.

WebAIM의 콘트라스트 체커는 이 공식을 그대로 구현한 대표적인 도구다(webaim.org/resources/contrastchecker). 색상 코드 두 개를 입력하면 즉시 대비율과 AA/AAA 통과 여부를 알려준다. 단순해 보이지만, 이 계산이 수천 개의 텍스트 요소에 걸쳐 자동으로 수행된다면 수작업과는 차원이 다른 커버리지가 나온다.

---

ViewCheck가 이 공식을 실제로 적용하는 방법

이론은 명확하다. 그런데 실제 웹사이트에 적용하면 문제가 복잡해진다.

ViewCheck는 Playwright를 이용해 페이지를 로드하고, 각 텍스트 요소의 color와 background-color CSS 속성을 Computed Style로 읽는다. Computed Style이란 브라우저가 최종적으로 계산한 스타일 값 — CSS 상속, 캐스케이딩, 미디어 쿼리가 모두 반영된 최종 결과다.

이렇게 읽은 색상값은 rgb(24, 24, 24) 같은 형태다. 이 값에서 R, G, B 정수를 파싱하고, 위에서 설명한 상대 휘도 공식에 대입한다. 전경색과 배경색 각각의 휘도를 구한 뒤 대비율을 계산하고, 4.5:1 미달이면 미통과로 분류한다.

그런데 여기서 첫 번째 현실 문제가 나온다: 투명도(opacity)와 알파 채널이다.

rgba(0, 0, 0, 0.5) 같은 반투명 텍스트가 있다. 이 경우 배경색과 실제로 혼합된 '보이는 색'이 텍스트의 실효 색상이다. CSS opacity 속성도 마찬가지다. 순수한 RGB값만 읽어서는 안 된다. 반드시 실제로 렌더링된 색상을 고려해야 한다.

두 번째 문제는 배경이 단일색이 아닌 경우다. 텍스트 뒤에 이미지, 그라디언트, 패턴이 깔린 경우 어떤 색을 배경으로 봐야 하는가? 공식은 두 단색 간의 계산을 전제하는데, 실제 배경이 여러 색이면 대표값을 어떻게 정하느냐가 문제가 된다. 이 케이스는 DOM에서 CSS만 읽어서는 해결이 어렵고, 실제 픽셀 데이터를 분석해야 한다.

세 번째는 동적으로 변하는 색상이다. 버튼이 hover 상태일 때, 체크박스가 선택 상태일 때, 링크에 포커스가 들어갈 때 — 이 상태별로 색상이 바뀌면 각 상태의 대비율도 검사해야 한다. SC 1.4.11 비텍스트 대비 항목에서는 특히 "모든 인터랙티브 상태(hover, focus, active)의 대비를 확인하라"고 명시한다(W3C WAI, Understanding WCAG SC 1.4.11). 정적 DOM 스냅샷으로는 이런 동적 상태를 포착하는 데 한계가 있다.

현재 ViewCheck는 정적 Computed Style 기반의 색상 대비 계산을 구현하고 있다. 투명도 처리는 일부 케이스에서 적용하고 있지만, 복잡한 배경이나 다중 레이어 케이스는 아직 완전히 해결된 상태가 아니다. 솔직히 말해서, "자동 측정"이라는 표현이 모든 케이스를 완벽히 커버한다는 의미는 아니다. 자동화가 잘 잡는 케이스가 있고, 도구의 특성상 놓치는 케이스도 있다. 그 경계를 명확히 아는 것이 실무에서 중요하다.

---

왜 색각이상과 저시력 사용자를 함께 봐야 하는가

색상 대비 기준이 존재하는 이유는 크게 두 종류의 시각적 특성을 가진 사용자를 위해서다: 저시력(Low Vision) 사용자와 색각이상(Color Vision Deficiency) 사용자.

먼저 색각이상의 규모를 보자. 전 세계적으로 약 3억 명이 어떤 형태로든 색각이상을 가지고 있다고 추정된다. 성별로 보면 남성의 약 8%, 여성의 약 0.5%가 적록색각이상(red-green color vision deficiency)을 갖는다(colorblind.io, Color Blindness Statistics). 더 세부적으로 보면 deuteranopia(녹색원추세포 부재)는 남성의 약 1.2%, protanopia(적색원추세포 부재)는 약 1%에서 나타난다. 북유럽계 남성은 최대 1011%까지 보고된다. 아시아계 남성은 약 45% 수준이다.

한국 인구로 환산해 보면, 남성 약 2,600만 명 기준 8%면 약 208만 명이 어느 정도 색각이상을 갖는 것이다. 이건 결코 작은 수가 아니다.

색각이상 사용자에게 색상 대비가 왜 중요한가? 이들은 특정 색 조합을 구분하지 못한다. 빨간 글씨와 초록 배경의 조합은 색각이상자에게는 두 색이 동일하게 보일 수 있다. 그런데 이 조합도 명도 대비율이 충분하다면 — 즉 한 색이 다른 색보다 훨씬 밝거나 어둡다면 — 색을 구분하지 못해도 밝기 차이로 텍스트를 인식할 수 있다. WCAG의 상대 휘도 기반 대비율 계산이 명도(밝기) 차이를 측정하는 이유가 여기에 있다. 색을 구분 못해도 밝기 차이가 충분하면 읽을 수 있다.

저시력 사용자의 경우는 또 다르다. 이들은 색을 구분하더라도 전반적으로 시야가 흐릿하거나 선명도가 낮다. 화면을 확대해서 보거나, 고대비 모드를 활성화하거나, 특수 안경을 사용한다. 대비가 낮은 텍스트는 이들에게 말 그대로 읽기 불가능한 수준이 될 수 있다.

미국 워싱턴 대학교 접근성 센터의 자료는 이렇게 정리한다: "충분한 명도 대비는 저시력, 색각이상, 기타 시각 장애를 가진 사람이 콘텐츠를 읽고 상호작용할 수 있도록 보장한다"(Washington University Accessibility, 2025). 한편 NN/g(Nielsen Norman Group)는 시각적 접근성 개선 항목 중 색상 대비를 핵심 요소로 꼽으며, 접근성이 낮은 화면은 장애 여부와 관계없이 모든 사용자의 인지 부하를 높인다는 점을 강조한다(nngroup.com, Visual Treatments that Improve Accessibility).

여기서 중요한 포인트가 있다. 색상 대비는 장애인만을 위한 게 아니다. 밝은 야외 햇빛 아래서 화면을 보는 상황, 오래 화면을 보아 눈이 피로한 상태, 작은 글씨를 읽는 고령 사용자 — 이 모든 상황에서 충분한 명도 대비는 가독성을 높인다. 접근성 기준이 '장애인을 위한 특수 요구사항'이 아니라 '모두를 위한 품질 기준'이라는 관점이 여기서 성립한다.

---

공공 웹에서 색상 대비 위반이 그렇게 흔한 이유

현장에서 분석을 해보면, 색상 대비 위반은 생각보다 훨씬 빈번하다. 왜일까?

첫째, 디자인 과정에서 대비 검사가 습관화되어 있지 않다. 많은 디자이너들이 Figma나 Photoshop에서 작업할 때 눈으로 보기에 예쁜 색상 조합을 선택한다. 4.5:1이라는 수치를 머릿속에 두고 작업하는 습관이 있는 디자이너는 아직 많지 않다. 실제로 접근성 체커를 돌려보면 "아, 이게 틀린다고?" 하는 반응을 자주 듣는다.

둘째, 공공 웹에는 '브랜드 컬러'라는 강한 제약이 있다. 기관 고유의 색상(예: 특정 보라색, 연두색, 밝은 하늘색)이 로고나 테마로 이미 정해져 있는 경우, 그 색을 텍스트나 버튼에 사용하면 배경색과의 대비가 부족한 경우가 생긴다. 브랜드 아이덴티티와 접근성 사이에서 실무자들은 갈등한다.

셋째, 회색 계열 텍스트의 함정. 최근 트렌드는 순수한 검정(#000000) 대신 부드러운 회색(#767676, #999999 등)으로 텍스트를 표현하는 것이다. 흰 배경에 #767676은 대략 4.48:1인데, 4.5:1 기준에서 아슬아슬하게 실패한다. 세련되어 보이는 회색 텍스트가 접근성 위반인 케이스를 우리는 실제 분석에서 매우 자주 발견한다.

넷째, 반응형 디자인의 맹점. 데스크톱에서는 충분한 폰트 크기로 큰 텍스트(3:1) 기준을 적용할 수 있지만, 모바일에서 폰트 크기가 줄어들면 이 텍스트가 일반 텍스트 기준(4.5:1)의 적용 대상이 된다. 뷰포트에 따라 적용 기준이 달라질 수 있는데, 모든 뷰포트를 대상으로 검사하지 않으면 놓치게 된다.

다섯째, 상태 변화에 따른 대비 문제. 기본 상태에서는 대비가 충분하지만, hover나 focus 상태에서 배경색이 밝아지거나 텍스트 색이 옅어지면 해당 상태에서 대비가 무너질 수 있다. 버튼에 커서를 올릴 때 배경이 밝아지는 hover 효과가 그 대표적인 예다.

---

axe-core와 ViewCheck — 자동화 도구의 한계와 커버리지

ViewCheck가 색상 대비 자동 검사에 활용하는 핵심 도구 중 하나가 axe-core다. Deque Systems가 개발하고 오픈소스로 제공하는 이 접근성 엔진은 현재 30억 회 이상 npm 다운로드를 기록했으며, Google Lighthouse, Microsoft Accessibility Insights, Rocket Validator 등 수십 개의 도구에 내장되어 있다(github.com/dequelabs/axe-core, W3C WAI ACT 구현 목록).

axe-core의 color-contrast 규칙은 WCAG SC 1.4.3 공식을 직접 구현한다. 페이지의 가시적인 텍스트 노드를 순회하며 각 요소의 Computed Style에서 색상을 읽고, 상대 휘도 공식을 적용해 대비율을 계산한다. 색상 형식 변환에는 colorjs.io 라이브러리를 활용한다고 밝히고 있다(Deque University, axe-core color-contrast rule).

그런데 axe-core 스스로도 한계를 인정한다. 평균적으로 WCAG 이슈의 약 57%를 자동으로 발견할 수 있고, 나머지는 "incomplete"(불완전 — 확인 필요)로 반환하거나 놓친다. 색상 대비 항목도 마찬가지다. 배경이 단일색이 아닌 경우(이미지, 그라디언트, 반투명 오버레이 등)에는 "incomplete"로 반환해 수동 확인을 요청한다.

ViewCheck는 axe-core의 결과를 받아 KRDS 846규칙 체계에 매핑하는 방식으로 활용한다. axe-core가 color-contrast 위반으로 플래그를 세운 요소는 KRDS DS(Design System) 카테고리의 색상 관련 규칙 — 예를 들어 텍스트 색상 명도대비 항목 — 에 연결되어 결과로 출력된다. 이 매핑 테이블은 지속적으로 업데이트 중이며, 아직 완벽하지 않다.

한편 axe-core가 잡지 못하는 케이스, 예를 들어 CSS 클래스로 특수하게 구현된 비표준 UI 컴포넌트의 경계선 색상이나 이미지 위 텍스트의 대비 — 이런 건 DOM 기반 분석만으로는 포착이 어렵다. 이 영역에서 ViewCheck의 KRDScan Engine이 보완 역할을 한다. 스크린샷 기반의 Vision AI로 시각적으로 문제가 있어 보이는 텍스트-배경 조합을 감지하는 시도를 하고 있다. 다만 이건 아직 실험적인 단계이고, "자동으로 완벽하게 잡는다"고 말하기는 시기상조다.

---

대비율 4.49:1 — 반올림 금지의 함정

색상 대비 검사를 하다 보면 아주 미묘한 지점에서 논쟁이 생긴다. 계산 결과가 4.49:1이 나왔다. 이게 4.5:1 기준을 통과하는가?

W3C는 이에 대해 명확한 입장을 가지고 있다. "임계값과 비교할 때 계산된 값을 반올림해서는 안 된다. 예를 들어 4.499:1은 4.5:1 기준을 충족하지 않는다"(W3C, Understanding WCAG SC 1.4.3). 반올림해서 4.5가 되더라도, 실제 값이 미만이라면 실패다.

이 원칙이 실무에서 중요한 이유가 있다. 자동화 도구마다 부동소수점 계산 방식이 조금씩 다르고, 색상 파싱 방식의 미세한 차이로 계산 결과가 달라질 수 있다. 어떤 도구에서는 통과, 다른 도구에서는 미통과가 나오는 케이스가 존재한다. 기준 자체는 명확하지만, 구현 세부 사항에서 차이가 생기는 것이다.

ViewCheck가 채택한 원칙은 엄격한 쪽이다. 4.5:1 미만이면 미통과로 처리한다. 4.499:1도, 4.4999:1도 마찬가지다. 보수적으로 적용하는 이유는 간단하다. '아슬아슬하게 통과'라고 판단했는데 실제로는 저시력 사용자가 읽지 못한다면, 그건 도구의 판정이 잘못된 것이다. 접근성은 경계선을 넘는 게 아니라 실제 사용 가능성을 보장하는 것이기 때문이다.

또 한 가지: 일부 컬러 프로파일이나 HDR 디스플레이 환경에서는 sRGB 가정이 깨지는 케이스가 있다. WCAG 상대 휘도 공식은 sRGB 색공간을 전제로 한다. 미래에는 더 넓은 색역(P3, Rec. 2020 등)을 고려해야 할 수도 있다. 이 부분은 우리도 현재 진행형으로 추적하고 있는 연구 과제다.

---

KRDS에서 색상 대비가 차지하는 위치 — DS 카테고리 120개 규칙

ViewCheck의 KRDS 분석은 846개 규칙을 4개 카테고리(DS 120개 / CP 446개 / BP 108개 / SP 172개)로 분류한다. 색상 대비는 이 중 DS(Design System) 카테고리에 속한다.

DS 카테고리는 "디자인 스타일" — 색상, 타이포그래피, 간격, 레이아웃 등 KRDS의 시각적 기본 언어를 담당하는 120개 규칙의 집합이다. 이 안에는 색상 토큰 채택 여부, 특정 컴포넌트의 배경색과 텍스트색이 KRDS 디자인 토큰에서 정의한 값을 사용하는지, 그리고 색상 대비율이 기준을 충족하는지가 포함된다.

KRDS 디자인 시스템은 색상 토큰을 체계적으로 정의하고 있다. ViewCheck가 실제 분석을 통해 확인한 토큰 규모는 색상 토큰 약 586개, 전체 디자인 토큰 약 768개다(인터넷에서 떠도는 1,082개와는 다르며, 우리 실측 기준이다). 이 토큰들은 의미 기반으로 구성되어 있다 — 예를 들어 primary-text-color, background-default, interactive-focus 같은 식으로. 디자인 토큰을 정해진 용도에 맞게 사용했다면, 그 색상 조합은 KRDS 설계 시 접근성을 고려해 정의된 것이다.

문제는 실제 공공 웹사이트들이 KRDS 토큰을 얼마나 실제로 채택하고 있느냐다. 우리 분석에서 많은 사이트들이 KRDS 토큰을 선언하지 않고 자체적인 색상 값을 직접 CSS에 하드코딩하는 경우를 발견한다. 이 경우 KRDS 토큰 채택률이 낮게 나오고, 대비율 준수 여부도 개별적으로 검사해야 한다.

또한 DS 규칙 중 일부는 실제 DOM만으로는 판정이 어려운 케이스가 있다. 예를 들어 배경 이미지 위의 텍스트 대비, 복잡한 레이어 구조의 색상 합성, SVG 내부 텍스트 요소의 대비 등이다. 이런 케이스를 위해 시각적 분석(KRDScan Vision AI)의 보완이 필요한데, 이 부분은 아직 R&D 단계다. "완전히 자동화됐다"고 말하지 못하는 이유 중 하나가 바로 이것이다.

---

APCA — 다음 세대 대비 알고리즘은 왜 나왔나

WCAG 2.x의 대비율 공식이 표준으로 자리 잡았지만, 이 공식에 대한 비판도 오래전부터 있었다. 그 대안으로 등장한 것이 **APCA(Advanced Perceptual Contrast Algorithm, 고급 지각 대비 알고리즘)**다.

APCA의 공식 문서(git.apcacontrast.com)는 이렇게 설명한다. 기존 WCAG 2.x 방식은 두 색을 단순히 대비율로 비교하지만, 실제 가독성은 대비율만으로 결정되지 않는다. **폰트 크기, 폰트 굵기, 전경-배경의 방향성(밝은 배경에 어두운 텍스트 vs. 어두운 배경에 밝은 텍스트)**이 모두 가독성에 영향을 미친다. 기존 공식은 이 요소들을 고려하지 않는다.

예를 들어, 기존 WCAG 공식에서는 흰 배경에 검은 글씨와 검은 배경에 흰 글씨의 대비율이 동일하게 21:1이다. 그러나 실제 가독성 실험에서는 이 두 케이스의 가독성이 다르게 나타난다. 어두운 배경 위의 텍스트는 같은 대비율이라도 더 눈부심이 적고 읽기 쉬운 경우가 있다는 것이다.

APCA는 이를 보완하기 위해 Lc(Lightness contrast) 값이라는 새로운 척도를 도입한다. Lc 0에서 Lc 105+ 범위로 표현되며, 폰트 크기와 굵기에 따른 최소 Lc 값 매트릭스를 제공한다. 예를 들어 본문 텍스트는 Lc 75 이상을 최소로, 이상적으로는 Lc 90을 권장한다(APCA, APCA in a Nutshell, git.apcacontrast.com/documentation/APCA_in_a_Nutshell.html).

APCA는 현재 WCAG 3.0의 후보 대비 측정 방법으로 검토 중이다. 아직 최종 확정된 표준은 아니다. 일부 도구들은 이미 APCA 계산을 선택적으로 제공하지만, 법적·규정상 요건으로 쓰이는 건 여전히 WCAG 2.x의 4.5:1 기준이다.

ViewCheck는 현재 WCAG 2.2 SC 1.4.3 기준(4.5:1)을 기본으로 적용한다. APCA는 참고 지표로 관심을 두고 있지만, 아직 공식 표준이 아니기 때문에 KRDS 846규칙의 판정에 공식 반영하지는 않은 상태다. WCAG 3.0이 확정되어 APCA가 표준으로 채택된다면, 그때 반영하는 방향으로 보고 있다. 이런 표준의 변화를 언제든 반영할 수 있도록, 우리는 판정 로직을 하드코딩이 아니라 데이터 기반으로 관리하려는 이유도 있다.

---

실험: 실제 공공 웹사이트에서 색상 대비 위반은 얼마나 나오나

이론과 표준 이야기를 했으니, 실제로 어떤 결과가 나오는지 살펴보자.

ViewCheck로 국내 공공 웹사이트들을 분석해보면, 색상 대비 관련 DS 규칙 위반이 생각보다 많이 나온다. 구체적인 통계는 분석 대상 사이트마다 크게 다르기 때문에 단일 수치로 일반화하기 어렵지만, 우리가 분석한 케이스들에서 반복적으로 나오는 패턴들이 있다.

패턴 1: 아이콘 레이블과 회색 소형 텍스트. 푸터 영역의 주소, 저작권 텍스트, 메뉴 하위 설명 텍스트 — 이런 "덜 중요하다"고 여겨지는 텍스트에 연한 회색을 쓰는 케이스가 많다. 이 회색 텍스트들이 대비율 기준에 미달하는 경우가 빈번하다.

패턴 2: 컬러 배경 위의 화이트 텍스트. 기관 브랜드 색상(예: 특정 파란색 혹은 초록색) 배경 위에 흰 텍스트를 올리는 배너나 버튼이 많다. 밝은 계열의 브랜드 색상은 흰색과의 대비율이 낮아 문제가 된다. 진한 네이비 위의 흰 텍스트는 괜찮지만, 하늘색 계열 위의 흰 텍스트는 위험하다.

패턴 3: 링크 텍스트. 본문 텍스트는 대비가 충분하지만, 링크(anchor)를 표현하는 색상이 배경에 대해 대비 부족인 경우가 있다. 특히 파란색 계열로 링크를 표현하는데 배경도 연한 색인 경우에 나타난다.

패턴 4: 테이블 헤더 셀의 배경 + 텍스트 조합. 표의 헤더에 중간 강도의 컬러를 배경으로 쓰고 어두운 텍스트를 올리는 경우, 계산해보면 대비율이 애매한 경우가 있다.

이런 위반들을 수작업으로 페이지마다 검사하는 것은 현실적으로 불가능에 가깝다. 자동화 도구의 가치가 바로 여기에 있다. 완벽하지는 않아도, 수천 개의 텍스트 요소 중 명백히 기준에 미달하는 케이스를 빠르게 추려내는 역할을 해준다. 그 목록을 기반으로 담당자가 우선순위를 정해 수정할 수 있다.

---

비텍스트 대비 — 버튼 테두리와 입력창도 검사 대상

WCAG 2.1부터 추가된 SC 1.4.11(비텍스트 대비)은 많은 웹 담당자들이 아직 잘 인식하지 못하는 항목이다. "텍스트 말고 UI 컴포넌트 자체에도 대비 요구사항이 있다"는 사실이 생소한 경우가 많다.

구체적으로 어떤 케이스를 봐야 하는가? Deque University의 WCAG 1.4.11 자료를 정리하면 다음과 같다(dequeuniversity.com/resources/wcag2.1/1.4.11-non-text-contrast):

• 입력 필드(input)의 테두리: 흰 배경 위에 연한 회색 테두리의 입력창 — 테두리와 배경 사이의 대비가 3:1을 넘어야 한다.
• 버튼의 테두리(또는 fill): 버튼의 외형을 구분해주는 시각적 요소(테두리나 배경색)가 주변 배경과 3:1 이상의 대비를 가져야 한다.
• 체크박스, 라디오버튼의 테두리: 선택 UI의 외곽선이 배경에 대해 충분한 대비를 가져야 한다.
• 포커스 인디케이터: 키보드 탐색 시 나타나는 포커스 링이 주변 색에 대해 3:1 이상이어야 한다 (이건 SC 2.4.11/2.4.13에서도 별도 규정).
• 차트나 그래프의 데이터 요소: 정보를 전달하기 위해 꼭 필요한 그래픽 요소도 해당한다.

단, 예외도 있다. 비활성화(disabled) 상태의 컴포넌트, 순수하게 장식적인 그래픽 요소, 브라우저나 OS가 제어하는 기본 UI 요소 등은 예외다(W3C WAI, Understanding WCAG SC 1.4.11).

ViewCheck의 현재 구현에서 1.4.11 검사는 일부 요소에 대해 적용 중이지만, 모든 케이스를 완전히 커버한다고는 말하기 어렵다. 특히 포커스 인디케이터 대비 검사는 동적 상태를 요구하기 때문에 자동화가 까다롭다. 이 영역은 앞으로 지속적으로 개선할 과제로 남아 있다.

---

"해당 없음(N/A)"이 나오는 케이스 — 자동화의 솔직한 한계

KRDS 846규칙 분석에서 색상 관련 항목들이 N/A(해당 없음 또는 판정 불가)로 분류되는 경우가 있다. 왜인가?

첫째, 해당 컴포넌트가 페이지에 존재하지 않는 경우다. KRDS CP 규칙 중에는 특정 컴포넌트(예: 모달 창, 캐러셀, 특정 유형의 입력 필드)의 색상 대비를 검사하는 항목이 있다. 해당 컴포넌트가 없는 페이지에서는 그 규칙은 적용 불가이므로 N/A가 맞다.

둘째, DOM으로 정확한 색상을 파악할 수 없는 경우다. 배경이 CSS background-image로 설정되어 있거나, Canvas 엘리먼트로 렌더링되거나, SVG의 복잡한 레이어 구조 안에 있는 텍스트는 Computed Style만으로는 실제 배경색을 알 수 없다. 이 경우 도구가 "불완전(incomplete)" 또는 N/A로 반환한다.

셋째, JavaScript로 동적 생성된 요소가 분석 시점에 DOM에 존재하지 않는 경우다. SPA(싱글 페이지 앱) 형태로 동작하는 일부 공공 웹사이트에서는 특정 인터랙션 이후에만 나타나는 요소들이 있는데, 이 요소들의 색상은 Playwright가 페이지를 로드한 시점의 DOM 스냅샷에서는 보이지 않는다.

이런 N/A 케이스를 무조건 "문제 없음"으로 해석하면 안 된다. N/A는 "검사 못 함"이지 "통과"가 아니다. ViewCheck의 결과에서 N/A 항목은 "자동 검사 불가 — 수동 확인 필요"로 이해해야 한다.

이 점을 우리는 결과 보고 시 명시하려고 한다. N/A 비율이 높을수록, 해당 사이트에 대한 자동화 검사의 커버리지가 낮다는 의미이기도 하다. 단순히 점수만 보는 것이 아니라, 어떤 항목이 왜 N/A인지를 함께 살펴봐야 실질적인 품질을 이해할 수 있다.

색상 대비 항목의 N/A는 ViewCheck가 앞으로 줄여나가려는 주요 목표 중 하나다. KRDScan Vision AI를 통한 시각적 분석 보완이 가장 유력한 방향이다. 스크린샷 픽셀 데이터를 분석해 배경색을 추출하고, 그 위의 텍스트와의 대비를 계산하는 방식이다. 이게 잘 작동하면 DOM 기반 검사의 사각지대를 상당히 줄일 수 있다. 하지만 현재는 실험 단계이고, "잘 작동한다"는 걸 검증하는 데 시간이 필요하다.

---

고령 사용자와 공공 웹 — 색상 대비가 특히 중요한 이유

공공 웹의 사용자층을 생각하면, 색상 대비 접근성은 더욱 중요한 의미를 갖는다.

일반 소비자 서비스와 달리, 공공 웹은 사회 전 계층을 이용자로 전제한다. 민원 처리, 보조금 신청, 의료 정보 확인, 복지 서비스 안내 — 이런 서비스는 노인, 장애인, 디지털 소외 계층이 이용할 수밖에 없는 경우가 많다. 그리고 이 중 많은 분이 시각적으로 취약한 상황에 있다.

고령 사용자의 시각적 특성을 생각해보자. 나이가 들면 수정체가 노랗게 변하면서 색 구분 능력이 떨어진다. 특히 파란색과 보라색 계열을 구분하기 어려워진다. 동공 크기도 줄어들어 같은 화면이라도 더 어둡게 보인다. 이는 사실상 색각이상과 유사한 효과를 낸다. 65세 이상 고령 인구가 이미 상당한 비율을 차지하는 한국 사회에서, 이들을 위한 색상 대비 설계는 선택이 아니라 기본값이어야 한다.

American Foundation for the Blind(AFB)의 저시력 접근성 리포트에서는 디지털 환경에서 저시력 사용자를 위한 핵심 지원 요소로 고대비(high contrast), 텍스트 크기 조절, 적절한 간격을 꼽는다(AFB Accessworld, Enhancing Digital Accessibility for Users with Low Vision, 2024년 겨울호). 이 중 고대비는 다른 무엇보다 기본적인 요소로, 사이트 자체가 처음부터 충분한 대비를 제공한다면 사용자가 별도로 고대비 모드를 켜지 않아도 된다.

반대로 생각해보면, 공공 웹사이트가 기본 상태에서 색상 대비 기준을 충족하지 못한다면, 해당 서비스는 이용자 중 일부를 처음부터 배제하는 셈이다. 그리고 그 '일부'에 민원 처리, 보조금 신청이 가장 절실한 사람들이 포함되어 있다는 사실이 공공 웹 접근성의 당위성을 말해준다.

---

색상 대비와 브랜드 아이덴티티의 충돌 — 실무 딜레마

실무에서 담당자들이 가장 많이 맞닥뜨리는 질문 중 하나가 이것이다: "우리 기관 로고 컬러가 이 색인데, 이걸 버튼이나 텍스트에 쓰면 대비가 안 맞아요. 어떻게 해야 해요?"

이 질문에는 쉬운 답이 없다. 기관 아이덴티티는 중요하고, 색상은 그 아이덴티티의 핵심이다. 그런데 그 색상이 접근성 기준을 충족하지 못한다면, 어떤 선택을 해야 하는가?

가능한 접근 방향 몇 가지를 정리해본다.

방법 1: 유사 색조에서 더 어두운 버전 사용. 동일한 색상 계열에서 채도를 유지하면서 명도를 낮추면 대비율이 개선된다. 예를 들어 하늘색(#56B4E9)이 흰 배경에서 대비 부족이라면, 같은 파란색 계열이지만 더 진한 파란색(#0072B2)으로 대체하는 식이다. 시각적으로 '같은 색 계열'처럼 보이면서 기준을 충족한다.

방법 2: 텍스트와 아이콘에는 고대비 버전, 배경과 강조에만 브랜드 컬러 사용. 브랜드 컬러를 큰 배경 면적이나 이미지에는 쓰되, 텍스트와 중요한 UI 요소에는 고대비 색상을 사용하는 전략이다. 브랜드 컬러의 존재감은 유지하면서 가독성을 확보할 수 있다.

방법 3: 세부 유형에 따른 예외 적용. 장식적인 용도(decorative)의 텍스트, 비활성 UI, 로고 자체 텍스트는 WCAG 예외 대상이다. 모든 색상에 4.5:1을 적용하는 것이 아니라, 정보 전달 역할을 하는 텍스트와 UI에만 엄격하게 적용하고 나머지는 유연하게 처리할 수 있다.

어느 방법이 맞는지는 기관마다 다르고, 이 결정을 도구가 대신해줄 수는 없다. ViewCheck가 할 수 있는 것은 어떤 요소가 현재 기준에 미달하는지를 명확히 보여주는 것이다. 수정 방향에 대한 제안도 함께 제공하지만, 최종 결정은 담당자와 디자이너가 함께 해야 한다. 우리 도구는 그 논의의 시작점을 만들어 주는 역할이다.

---

자동화가 잡을 수 있는 것과 없는 것 — 솔직한 정리

이 편에서 여러 이야기를 했는데, 정리해보면 이렇게 된다.

자동화(ViewCheck + axe-core)가 잘 잡는 것:

• 단일 색 배경 위 단일 색 텍스트의 대비율 계산
• 명백히 낮은 대비(예: 연한 회색 텍스트 on 흰 배경)
• 대량의 텍스트 요소를 빠르게 스캔하는 것
• 여러 페이지에 걸쳐 반복적으로 나타나는 패턴 감지

자동화가 어려운 것:

• 이미지/그라디언트/패턴 배경 위 텍스트의 대비
• 반투명 레이어가 복수로 쌓인 복잡한 구조
• 동적 상태(hover, focus, active, loading)에서만 나타나는 대비 문제
• SVG 내부의 텍스트 요소
• JavaScript 렌더링으로 나중에 생성되는 요소
• 인쇄 스타일시트 적용 후의 대비

이 한계들을 솔직하게 공개하는 이유가 있다. 도구가 "다 잡았다"고 말하면, 사용자는 도구가 통과 판정한 항목은 진짜 다 괜찮다고 믿게 된다. 그런데 자동화의 커버리지에는 한계가 있고, 그 한계 안에서 놓친 것들은 여전히 현장에서 수동으로 확인해야 한다. 도구는 인력을 없애주는 게 아니라, 가장 중요한 것에 인력을 집중할 수 있게 해주는 보조 수단이다.

그래서 ViewCheck의 색상 대비 분석 결과는 항상 두 가지를 함께 보여주려 한다: 자동으로 감지된 위반 목록 + 자동 검사 범위 밖이어서 수동 확인이 필요한 케이스 목록. 두 번째 목록도 결과의 일부라고 생각하기 때문이다.

---

개선 로드맵 — 색상 대비 분석을 더 잘하려면

마지막으로, 우리가 색상 대비 분석 기능을 어떤 방향으로 발전시켜 나가려 하는지 이야기하겠다. 구체적인 일정을 약속하는 게 아니라, 현재 고민하고 실험 중인 방향의 공유다.

방향 1: 픽셀 기반 배경 색상 추출. 스크린샷 이미지에서 각 텍스트 요소의 좌표를 알면, 그 뒤에 있는 픽셀들의 색상을 직접 추출할 수 있다. 이를 텍스트 색상과 비교하면 이미지 배경이나 그라디언트 위의 텍스트 대비도 계산 가능해진다. 계산량이 많아 성능 최적화가 필요한 부분이다.

방향 2: 동적 상태 시뮬레이션. Playwright로 hover, focus 상태를 시뮬레이션하고, 각 상태에서의 색상을 수집해 대비를 계산하는 방법이다. 모든 인터랙티브 요소를 커버하려면 상당한 시간이 소요되는 작업이지만, 특히 버튼과 링크의 상태별 대비는 꼭 검사해야 할 항목이다.

방향 3: APCA 병행 제공. 현재 WCAG 2.2 기준 결과만 제공하는데, 향후 WCAG 3.0 준비 차원에서 APCA Lc 값을 참고 지표로 함께 제공하는 것을 검토하고 있다. 강제 기준이 아닌 "이 색상 조합의 APCA 값은 Lc 65입니다. 본문 텍스트 최소 권고값 Lc 75에 미달합니다" 식의 참고 정보를 주는 방식이다.

방향 4: 색상 토큰 매핑과 연동. KRDS가 정의한 색상 토큰을 사이트가 실제로 사용하고 있는지 체크하고, 토큰을 사용하지 않고 임의 색상을 하드코딩한 경우에는 해당 색상 조합의 대비율을 별도로 검사하는 로직을 정교화하는 것이다.

이 중 어느 것이 먼저 구현될지는 확실하지 않다. 각각 기술적 난이도와 필요한 검증 수준이 다르기 때문이다. 다만 방향은 명확하다: 자동화가 커버하는 범위를 넓히되, 커버하지 못하는 영역을 솔직하게 드러내는 것.

---

마무리 — 4.5:1이라는 숫자를 다시 보며

처음에 "이 텍스트 색, 괜찮은 거 맞아요?"라는 질문으로 시작했다. 이 글을 다 읽고 나면, 그 질문에 "4.5:1을 계산해 보면 됩니다"라고 답할 수 있다. 하지만 동시에 그 계산이 생각보다 복잡하고, 자동화 도구가 전부를 해결해 주지는 않는다는 것도 알게 됐을 것이다.

색상 대비는 수식으로 정의되지만, 그 수식이 보호하는 건 사람의 눈과 경험이다. 저시력을 가진 분, 나이 들어 눈이 흐려진 분, 색각이상을 가진 분 — 이들이 공공 서비스를 이용하다가 "이 텍스트가 안 보여서 신청을 못 했다"는 상황이 없도록 하는 것이 이 기준의 목적이다.

ViewCheck가 색상 대비 자동 측정을 실험하는 건 그 목적에 작은 기여를 하기 위해서다. 아직 완전하지 않고, 해결해야 할 케이스들이 더 많다. 그래도 계산을 자동화한다는 것 자체가 — 수천 개의 텍스트 요소를 수초 안에 스캔하고 기준에 미달하는 것들을 추려내는 것이 — 이전에는 사실상 불가능했던 커버리지를 만들어 낸다는 점에서 의미가 있다고 생각한다.

4.5:1이라는 숫자는 기억하기 쉬운 표준이다. 그런데 그 숫자 뒤에는 W3C의 시각 과학 연구, 저시력 커뮤니티의 오랜 요구, 그리고 공공 서비스가 모두를 위해 존재해야 한다는 원칙이 쌓여 있다. 자동화 도구가 그 숫자를 계산해 주는 것은 편리한 일이지만, 그 숫자가 왜 중요한지를 이해하는 것이 더 중요하다.

다음 편에서는 접근성의 또 다른 축, 키보드 내비게이션과 포커스 인디케이터 자동 검사에 대한 이야기를 이어갈 예정이다.

---

참고문헌

국내

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」, 행정안전부고시 제2025-46호, 2025.6.25. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
2. 한국형 웹 콘텐츠 접근성 지침 2.2 (KWCAG 2.2), 공식 문서. https://a11ykr.github.io/kwcag22/
3. 서울특별시, 정보통신접근성 및 웹 표준 준수 가이드 안내. https://news.seoul.go.kr/gov/archives/47485

해외

4. W3C WAI, Understanding Success Criterion 1.4.3: Contrast (Minimum), WCAG 2.1 Understanding Document. https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
5. W3C WAI, Understanding Success Criterion 1.4.11: Non-text Contrast, WCAG 2.1 Understanding Document. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html
6. W3C WAI GL Wiki, Relative luminance. https://www.w3.org/WAI/GL/wiki/Relative_luminance
7. APCA (Accessible Perceptual Contrast Algorithm), APCA in a Nutshell. https://git.apcacontrast.com/documentation/APCA_in_a_Nutshell.html
8. APCA, Why APCA as a New Contrast Method? https://git.apcacontrast.com/documentation/WhyAPCA.html
9. WebAIM, Contrast Checker. https://webaim.org/resources/contrastchecker/
10. WebAIM, Contrast and Color Accessibility — Understanding WCAG 2 Contrast and Color Requirements. https://webaim.org/articles/contrast/
11. Deque University, Understanding WCAG SC 1.4.11: Non-text Contrast. https://dequeuniversity.com/resources/wcag2.1/1.4.11-non-text-contrast
12. Deque Systems, axe-core GitHub. https://github.com/dequelabs/axe-core
13. W3C WAI, Axe-core ACT Implementation. https://www.w3.org/WAI/standards-guidelines/act/implementations/axe-core/
14. colorblind.io, Color Blindness Statistics: Prevalence by Gender, Type & Region. https://colorblind.io/learn/statistics
15. University of Washington Accessibility, Color Contrast: Why It Matters for Web Accessibility, 2025. https://www.washington.edu/accessibility/2025/11/06/color-contrast/
16. American Foundation for the Blind (AFB), Enhancing Digital Accessibility for Users with Low Vision, Accessworld, Winter 2024. https://afb.org/aw/winter2024/low-vision-accessibility
17. Nielsen Norman Group, Visual Treatments that Improve Accessibility. https://www.nngroup.com/articles/visual-treatments-accessibility/
18. accessibility-test.org, Color Contrast in WCAG 2.2 — Testing and Fixes That Actually Work. https://accessibility-test.org/blog/support/advanced-guides/color-contrast-in-wcag-2-2-testing-and-fixes-that-actually-work/

---