웹 접근성 명도 대비 기준 비교 — AA 4.5:1·AAA 7:1·UI 3:1과 Tailwind 팔레트 실측표

버튼에 bg-blue-500을 깔고 흰 글씨를 올렸다. 화면상으로는 아무 문제가 없어 보인다. 그런데 이 조합의 실제 명도 대비비는 3.76:1이고, WCAG AA가 본문 텍스트에 요구하는 4.5:1에는 미달이다. 접근성 검사에서 잡히는 색 관련 위반은 대부분 이렇게 "한 단계 밝은 색"에서 나온다. 기준이 몇 개이고 각각 몇 대 몇인지, 그리고 자주 쓰는 팔레트가 정확히 어디서 탈락하는지를 실측값으로 정리했다.

기준은 하나가 아니다 — 세 갈래 비교

W3C가 2023년 10월 권고안으로 확정한 WCAG 2.2는 대비 요구를 세 개의 성공기준으로 나눠 둔다. "4.5:1"만 알고 있으면 버튼 테두리나 아이콘 검사에서 어긋난다.

국내 기준도 숫자는 같다. 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2 — 국가표준 KS X OT0003 — 역시 명도 대비 4.5:1을 요구하며 큰 글씨·로고·비활성 요소를 예외로 두고, 과학기술정보통신부 소관 웹 접근성 품질인증 심사가 이 지침을 따른다. 결국 본문 4.5:1 / 큰 글씨 3:1 / UI 요소 3:1 세 숫자면 실무는 커버된다.

"큰 글씨"의 경계는 24px과 18.66px

기준을 3:1로 낮춰주는 큰 텍스트(large scale text) 정의가 pt로 쓰여 있어 CSS와 어긋나기 쉽다. WCAG는 18pt 이상, 또는 14pt 이상이면서 굵은(bold, 700) 텍스트를 큰 텍스트로 보는데 px로 환산하면 각각 24px, 18.66px이다.

따라서 24px 제목은 3:1만 넘으면 되지만 20px 제목은 여전히 4.5:1을 요구하고, 19px font-weight: 600은 bold(700) 미달이라 큰 텍스트로 인정되지 않는다. pt·px·rem 환산은 CSS 단위 비교 정리의 표를 보면 빠르다.

흰 배경 회색 텍스트, 어디서 탈락하나

보조 설명을 회색으로 흐리게 처리하는 건 거의 모든 UI가 하는 일이고, 정확히 그래서 가장 많이 탈락한다. 순회색(R=G=B)을 흰 배경에 올렸을 때의 경계값은 다음과 같다.

#777과 #767676은 눈으로 구별되지 않는데 한쪽만 통과한다. 이 두 값과 AAA 경계인 #595959만 기억해도 회색 톤 결정은 계산 없이 끝난다.

Tailwind v4 기본 팔레트 실측 — 등급별 통과선

Tailwind CSS v4는 기본 팔레트를 oklch로 정의한다. 아래는 v4.1 theme.css의 정의값을 sRGB로 변환한 뒤 WCAG 상대 휘도 공식으로 대비비를 계산한 결과다. 흰 배경과 다크 배경(gray-900 = #101828)을 나란히 놓았다.

(✓ = 본문 AA 4.5:1 이상, ✓✓ = AAA 7:1 이상, ✗ = 본문 AA 미달)

읽을 규칙은 세 줄이다. 첫째, 흰 배경 본문에 쓸 수 있는 최소 등급은 회색 500, 파랑 600, 빨강 600, 초록 700이다. 둘째, 가장 위험한 색은 초록과 노랑이다 — "완료·성공"을 green-500으로 표시하면 2.22:1로 기준의 절반도 못 채운다. 셋째, 할인율이나 오류 메시지처럼 빨강 강조가 많은 화면은 red-500(3.81:1)이 아니라 red-600부터 시작해야 한다. 핫딜 특가 목록처럼 할인율이 빽빽한 화면에서 자주 걸리는 지점이다.

버튼은 방향이 반대다. 배경에 색을 깔고 흰 글씨를 올리므로 bg-blue-500 + 흰 텍스트는 3.76:1로 미달이고, 한 단계 내린 bg-blue-600은 5.25:1로 통과한다. 초록 버튼은 green-700(4.95:1)까지 내려가야 흰 라벨을 얹을 수 있다.

라이트에서 통과한 색이 다크에서 떨어진다

위 표의 두 열을 나란히 보면 대부분의 토큰에서 ✓와 ✗가 뒤집힌다. blue-600은 흰 배경에서 5.25:1로 통과하지만 다크 배경에서 3.38:1로 떨어지고, 다크에서 6.73:1인 blue-400은 흰 배경에서 2.64:1로 실패한다. gray-500도 4.84:1 → 3.67:1로 역전된다.

다크 모드는 같은 토큰을 재활용할 수 없고, 등급을 2단계쯤 밝은 쪽으로 옮긴 별도 매핑이 필요하다. 의미 기반 CSS 변수(--text-muted, --accent)를 두고 라이트·다크에 각각 다른 등급을 대입하는 방식이 관리 비용이 가장 낮다. 배경을 순검정까지 내리면 수치는 더 벌지만 잔상(halation)으로 장문 가독성이 나빠져, #101828처럼 어두운 남색을 쓰는 팔레트가 많다.

그래서 어디까지 맞출까

숫자를 많이 읽는 화면일수록 기준을 넉넉히 잡는 편이 낫다. 자취 생활 계산기처럼 결과값에 단위·주석이 붙는 UI에서 보조 텍스트를 gray-400(2.60:1)으로 흐려놓으면 해석에 필요한 정보가 읽히지 않는다. 다만 AAA를 전면 적용하면 쓸 수 있는 색의 폭이 크게 줄어드니, 본문은 AA를 확실히 넘기고 핵심 수치만 AAA로 올리는 절충이 현실적이다. 후보 색의 톤을 바꿔가며 비교할 때는 색상 도구로 변환값과 팔레트를 뽑아두면 되고, 그림자·단위 같은 다른 CSS 실무 주제는 kimgoon 생활정보 가이드에 모아 두었다.

자주 묻는 질문

대비비를 직접 계산하려면 어떻게 하나요? 각 채널값을 0~1로 정규화한 뒤 0.03928 이하면 12.92로 나누고, 초과하면 ((c+0.055)/1.055)^2.4로 선형화합니다. 이 값을 0.2126·0.7152·0.0722로 가중합해 상대 휘도 L을 구하고, (밝은쪽 L+0.05)/(어두운쪽 L+0.05)에 넣으면 대비비가 나옵니다. #767676은 L=0.1811이므로 흰색(L=1)과의 대비가 1.05÷0.2311 = 4.54:1입니다.

플레이스홀더나 비활성 버튼도 4.5:1을 맞춰야 하나요? 비활성(disabled) 상태의 UI 컴포넌트와 그 안의 텍스트는 WCAG 1.4.3의 예외라 대비 요구가 없습니다. 반면 입력 필드의 플레이스홀더는 비활성 요소가 아니라 화면에 표시되는 텍스트로 보므로 4.5:1이 요구된다는 해석이 통용됩니다. 플레이스홀더를 gray-400(2.60:1)으로 두는 관행이 검사에서 자주 걸리는 이유입니다.

로고나 브랜드 색은 예외인가요? 로고·워드마크의 일부인 텍스트는 면제됩니다. 다만 브랜드 색을 본문 텍스트나 버튼 라벨에 그대로 쓰는 순간 면제가 사라지므로, 브랜드 색이 밝은 계열이면 텍스트용으로 한두 단계 어두운 변형을 따로 정의해 두는 편이 안전합니다.

노란 배경에 흰 글씨는 왜 항상 실패하나요? 상대 휘도 공식에서 녹색 채널 가중치가 0.7152로 압도적이고, 노랑은 R·G가 모두 높아 휘도가 흰색에 가깝습니다. yellow-400(#FDC700)은 흰색과 1.57:1뿐이지만 검정과는 11.28:1입니다. 노랑·연두·하늘색 배경에는 흰 글씨 대신 검정 계열을 올리는 것이 정답입니다.

WCAG 3.0의 APCA로 기준이 바뀌나요? WCAG 3.0은 아직 W3C 초안(Working Draft) 단계이고, 거기서 논의되는 APCA는 글자 크기·굵기까지 반영하는 다른 계산 방식입니다. 확정 시점이 정해지지 않았으므로 지금은 WCAG 2.2의 4.5:1 체계로 맞추고 3.0은 권고안 확정 후 재검토하는 편이 안전합니다.

관련 가이드

tools.kimgoon.kr

색상 도구로 HEX·RGB·HSL 변환하기

tools.kimgoon.kr

디자인·CSS 가이드 더 보기

tools.kimgoon.kr

HEX·RGB·HSL 차이와 색 선택 팁

kimgoon.kr

kimgoon 생활정보 가이드

tools.kimgoon.kr

CSS 단위 px·rem·em 비교

hotdeal.kimgoon.kr

핫딜 특가 목록 보기