색 대비와 웹 접근성: WCAG 공식의 출처, 한계, 그리고 각국 법 기준

연한 회색 글씨는 디자인 시안에서는 세련돼 보입니다. 그런데 같은 화면을 햇빛 아래 휴대폰으로 보거나, 밝기를 낮춘 노트북으로 보거나, 예순이 넘은 부모님이 보면 이야기가 달라집니다. 색 대비는 장애인만을 위한 배려가 아니라, 나쁜 조건에서 화면을 보는 모든 사람의 읽기 속도와 오독률에 영향을 주는 문제입니다.

이 글은 대비 기준이 어떻게 만들어졌는지, 그 숫자가 어디까지 믿을 만한지, 각국 법이 실제로 무엇을 요구하는지, 그리고 팔레트를 짤 때 어디서 자주 걸리는지를 다룹니다. 계산 자체는 명도 대비 검사기에서 바로 해 볼 수 있습니다.

대비가 부족하면 누가 불편한가

가장 먼저 떠오르는 것은 저시력인이지만, 영향을 받는 사람은 훨씬 넓습니다.

나이 든 눈. 수정체가 노랗게 흐려지고 동공이 작아지면서 망막에 닿는 빛이 줄어듭니다. 시력표상 시력이 괜찮아도 대비 감도는 떨어지기 때문에, 연한 회색 본문이 가장 먼저 읽기 힘들어집니다.
나쁜 화면 조건. 야외의 반사광, 절전 모드로 어두워진 화면, 값싼 모니터의 좁은 명암비는 화면 위의 모든 대비를 줄입니다. WCAG 공식에 들어 있는 0.05라는 상수가 바로 이런 주변광 반사를 흉내 낸 값입니다.
색각 이상. 북유럽계 남성의 약 8%, 여성의 약 0.5%가 적록 색각 이상이고, 동아시아 남성은 4~7% 정도로 보고됩니다. 한 반 30명 남학생 중 한두 명 꼴입니다. 이들은 밝기 대비는 정상적으로 느끼지만, 빨강·초록처럼 색조로만 구분한 정보를 놓칩니다.

대비 기준은 결국 「조건이 나쁠 때도 읽히는가」를 숫자 하나로 대신 확인하는 장치입니다.

4.5:1은 어디서 왔나

WCAG 2.0이 2008년에 대비 기준을 정할 때 출발점은 인쇄물이 아니라 모니터였습니다. 공식은 sRGB 색공간의 감마를 풀어 실제 빛의 양(상대 휘도)을 구하고, 두 휘도의 비를 재는 방식입니다. W3C 해설서가 밝힌 근거는 이렇습니다.

ISO 9241-3(사무용 디스플레이 인간공학 표준)은 정상 시력 사용자에게 최소 3:1의 휘도 대비를 권했습니다.
시력 20/40(소수 시력 약 0.5)인 사람은 대비 감도가 대략 1.5배 떨어진다고 보고, 3 × 1.5 = 4.5를 일반 텍스트의 AA 기준으로 삼았습니다. 20/40은 많은 나라에서 운전면허 시력 기준 근처이고, 노년층에서 흔한 수준입니다.
20/80 정도의 저시력을 감안한 값이 AAA의 7:1입니다.
글자가 크면 획이 굵어져 같은 대비에서도 더 잘 읽히므로, 18pt 또는 굵은 14pt 이상은 한 단계 낮은 3:1(AA)을 적용합니다.

WCAG 2.1(2018)에서는 글자가 아닌 요소, 즉 입력창 테두리·아이콘·포커스 표시에도 3:1을 요구하는 1.4.11 기준이 추가됐습니다. 흰 배경에 연회색 테두리만 있는 입력창이 여기서 자주 걸립니다.

한 가지 기억할 점은, 이 숫자들이 대규모 가독성 실험으로 하나하나 검증된 값이 아니라 기존 표준과 시력 데이터를 조합해 정한 「합의된 문턱」이라는 것입니다. 그래서 4.49와 4.51 사이에 실제 가독성의 절벽이 있는 것은 아닙니다. 다만 규정은 문턱을 반올림하지 않으므로, 감사(audit)에서는 4.49가 불합격입니다.

공식에 대한 비판과 APCA

WCAG 2 공식은 단순하다는 장점 덕에 20년 가까이 쓰였지만, 알려진 약점이 있습니다.

극성을 구분하지 않는다. 흰 바탕에 회색 글씨와 회색 바탕에 흰 글씨가 같은 점수를 받습니다. 실제로는 어두운 배경의 밝은 글씨가 번져 보이는 등 체감이 다릅니다.
어두운 색 쌍을 과대평가한다. 짙은 남색 위의 짙은 회색처럼 탁해 보이는 조합이 통과하는 반면, 선명한 주황 바탕의 흰 글씨처럼 실제로 잘 읽히는 조합은 떨어지는 사례가 자주 지적됩니다.
글꼴 굵기와 크기를 두 단계로만 본다. 얇은 웹폰트 300 두께 16px과 굵은 700 두께 16px이 같은 기준을 받습니다.

이런 문제를 해결하려고 Andrew Somers가 제안한 것이 APCA(Accessible Perceptual Contrast Algorithm)입니다. 지각 모델을 바탕으로 밝은 글씨/어두운 글씨를 다르게 계산하고, 결과(Lc 값)를 글꼴 크기·굵기 표와 함께 해석합니다.

여기서 흔한 오해가 생깁니다. 「WCAG 3는 APCA를 쓴다」는 설명이 많이 돌아다니지만, 사실과 다릅니다. APCA는 WCAG 3 초안에 탐색적 내용으로 들어갔다가 2023년 7월 작업 초안에서 빠졌고, 현재 WCAG 3 초안은 대비 알고리즘을 정하지 않은 상태입니다. WCAG 3 자체도 아직 권고안이 아니며 확정까지는 수년이 더 걸릴 것으로 보입니다. 따라서 지금 법적 의무나 계약 조건을 판단할 때 기준은 WCAG 2.x뿐입니다. APCA는 디자인 단계에서 「공식은 통과했지만 정말 읽기 편한가」를 한 번 더 점검하는 보조 도구로 쓰는 것이 안전합니다.

각국 법은 무엇을 요구하나

대비 기준 자체는 대부분 WCAG를 그대로 가져오고, 차이는 「누구에게 의무가 있는가」에 있습니다.

한국

「장애인차별금지 및 권리구제 등에 관한 법률」은 웹사이트를 통한 정보 접근에서 장애인을 차별하지 않도록 정하고 있고, 기술 기준으로는 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2(KS X OT0003:2022, 2022년 12월 개정)가 쓰입니다. 4개 원칙, 14개 지침, 33개 검사 항목으로 구성되며, 명도 대비 항목은 「텍스트 콘텐츠와 배경 간의 명도 대비는 4.5 대 1 이상」을 요구하고 큰 글자(18pt, 굵은 14pt 이상)와 확대 가능한 콘텐츠는 3:1을 허용합니다. WCAG 2.x의 AA와 사실상 같은 숫자입니다. 공공기관 사이트의 웹 접근성 품질마크 심사도 이 지침을 기준으로 합니다.

일본

기술 기준은 JIS X 8341-3:2016입니다. 이 규격은 WCAG 2.0(국제표준 ISO/IEC 40500:2012)과 일치하도록 개정되어, 대비 기준도 WCAG 2.0 AA와 같습니다. 총무성의 「みんなの公共サイト運用ガイドライン」은 국가·지방 공공기관에 이 규격의 AA 적합을 목표로 하고 정기적으로 시험·공개하도록 권합니다. 또한 개정 장애인차별해소법이 2024년 4월부터 시행되어 민간 사업자에게도 「합리적 배려」 제공이 의무화되었는데, 이것이 곧바로 모든 민간 웹사이트의 JIS 적합 의무를 뜻하지는 않습니다. 웹 접근성은 사전 환경 정비(노력 의무)로 다뤄집니다.

유럽연합

유럽 접근성법(European Accessibility Act, 지침 2019/882) 이 2025년 6월 28일부터 적용되기 시작했습니다. 전자상거래, 은행 서비스, 전자책, 교통 서비스 등 소비자 대상 제품·서비스가 대상이며, 초소기업(직원 10명 미만이면서 연 매출 또는 대차대조표 총액 200만 유로 이하)의 서비스는 예외입니다. 적합성 판단에 쓰이는 조화 표준은 EN 301 549이고, 웹 부분은 WCAG 2.1 AA를 그대로 포함합니다. 공공기관은 그보다 앞서 웹 접근성 지침(2016/2102)의 적용을 받아 왔습니다.

미국

연방 기관은 재활법 508조를 따르며, 2017년 개정된 508 기준이 WCAG 2.0 AA를 참조합니다. 주·지방 정부에는 법무부가 2024년 4월 ADA Title II 최종 규칙을 공포해 WCAG 2.1 AA를 기술 기준으로 정했습니다. 원래 준수 기한은 2026년(인구 5만 이상)과 2027년이었으나, 2026년 4월 잠정 최종 규칙으로 각각 2027년 4월, 2028년 4월로 1년씩 연기되었습니다. 민간 기업(Title III)에는 아직 명시적인 웹 기술 기준 규칙이 없지만, 법원 소송에서 WCAG가 사실상의 잣대로 쓰이는 일이 많습니다.

정리하면, 어느 나라를 대상으로 하든 「본문 4.5:1, 큰 글자와 UI 요소 3:1」을 지키면 대비 항목에서는 문제가 생기지 않습니다.

팔레트를 짤 때 자주 걸리는 곳

기준을 아는 것과 실제 제품에서 지키는 것은 다릅니다. 감사에서 반복적으로 나오는 지점은 다음과 같습니다.

브랜드 색을 버튼 배경에 그대로 쓸 때. 밝은 초록·주황·하늘색 브랜드 색은 흰 글씨와 4.5:1이 거의 나오지 않습니다. 이때 선택지는 셋입니다. 버튼 글씨를 검정 계열로 바꾸거나, 버튼용으로 명도만 낮춘 「진한 브랜드 색」을 따로 두거나, 글씨를 큰 텍스트 기준(굵게 18.5px 이상)으로 키워 3:1을 적용하는 것입니다. 색조와 채도를 유지한 채 명도만 조절하는 방법은 명도 대비 검사기의 추천 기능이 그대로 보여 줍니다.

보조 텍스트와 플레이스홀더. 날짜, 캡션, 입력창 안내 문구는 「덜 중요하니까」 연하게 처리되기 쉽지만, 기준에는 예외가 없습니다. 흰 바탕에서 통과하는 가장 밝은 회색은 #767676 근처입니다. 이보다 연한 회색을 쓰고 싶다면 글씨 크기를 키우는 수밖에 없습니다.

상태 변화. 호버, 포커스, 선택, 오류 상태마다 색이 바뀌면 각각의 조합을 모두 확인해야 합니다. 특히 포커스 링은 1.4.11 기준으로 주변 배경과 3:1이 필요합니다. 비활성(disabled) 요소는 예외지만, 「비활성처럼 보이는 활성 버튼」은 예외가 아닙니다.

다크 모드. 라이트 모드 팔레트를 반전하면 끝나는 게 아닙니다. 순수한 검정 배경에 순수한 흰 글씨(21:1)는 오히려 번져 보인다는 불만이 많아, 많은 디자인 시스템이 #121212 같은 짙은 회색 배경과 살짝 낮춘 흰색을 씁니다. 이 경우에도 4.5:1은 넉넉히 넘기 때문에 기준 문제는 없고, 오히려 채도 높은 강조색이 짙은 배경에서 대비가 부족해지는 경우를 조심해야 합니다.

이미지 위 글씨. 배너 사진 위 문구는 사진의 가장 밝은 부분(또는 가장 어두운 부분)에서 대비를 재야 합니다. 반투명 검정 오버레이를 깔면 해결되는 경우가 많습니다. 실제로 합성된 색을 알고 싶다면 스크린숏을 찍어 색상 추출기로 글자 뒤 배경 픽셀을 뽑아 보면 됩니다.

색만으로 정보를 전달할 때. 그래프 범례를 빨강·초록으로만 구분하거나, 필수 입력 항목을 빨간 테두리로만 표시하는 것은 대비비와 무관하게 WCAG 1.4.1 위반입니다. 아이콘, 텍스트 레이블, 선 모양(실선·점선)을 함께 쓰세요.

디자인 토큰으로 관리하기

대비 문제는 한 번 고쳐도 새 화면을 만들 때마다 다시 생깁니다. 근본적인 해결책은 색 조합을 개별 화면이 아니라 토큰 단계에서 검증하는 것입니다.

배경 토큰(예: surface, surface-muted, brand)과 전경 토큰(text, text-muted, on-brand)을 나눕니다.
허용되는 조합을 표로 만들고, 각 칸에 대비비를 적어 둡니다. 4.5 미만인 칸은 「큰 텍스트 전용」이나 「사용 금지」로 표시합니다.
HSL보다 OKLCH처럼 지각적으로 균일한 색공간에서 명도 단계를 만들면, 색조가 달라도 같은 단계끼리 대비가 비슷하게 나옵니다. HSL의 명도 50%는 노랑과 파랑에서 체감 밝기가 전혀 다르기 때문입니다. 색공간 간 변환은 색상 변환기에서 해 볼 수 있습니다.

이렇게 해 두면 개발자가 새 컴포넌트를 만들 때 「이 조합 괜찮나」를 매번 계산할 필요 없이 표만 보면 됩니다.

흔한 오해 몇 가지

「AAA를 목표로 해야 한다.」 W3C도 AAA를 사이트 전체의 일반적 목표로 권하지 않습니다. 본문 7:1은 브랜드 표현을 크게 제약합니다. 대부분의 법은 AA를 요구합니다.
「자동 검사 도구가 통과하면 끝이다.」 자동 도구는 CSS에 선언된 색만 봅니다. 이미지 속 글씨, 그러데이션 위 글씨, 호버 상태는 놓치기 쉽습니다.
「대비만 높으면 색각 이상 사용자도 괜찮다.」 대비비는 배경과 글자 사이의 밝기 차이일 뿐입니다. 서로 다른 두 데이터 색이 구별되는지는 따로 확인해야 합니다.
「APCA가 새 기준이다.」 앞서 본 것처럼 아직 어떤 표준에도 확정되지 않았습니다.

대비 기준은 완벽한 가독성 모델이 아니라, 최소한의 안전선을 모두가 같은 방식으로 재기 위한 약속입니다. 그 선을 넘긴 뒤에도 실제 기기에서, 밝은 곳과 어두운 곳에서 직접 읽어 보는 것이 가장 좋은 확인 방법입니다.