흰 바탕의 회색 글씨는 충분히 진할까: 색상 대비를 숫자로 확인하기

색 이름 대신 실제 글자색과 배경색을 가져옵니다

디자인 파일에 “중간 회색”이라고 적혀 있어도 구현된 페이지가 같은 색을 쓰는지는 별도 문제입니다. 상위 요소의 투명도, 반투명 카드, 사진 배경, 비활성 상태가 더해지면 최종 조합이 달라집니다. 먼저 검사할 문장의 위치와 상태를 정하고 브라우저에 적용된 글자색·배경색을 확인합니다. 화면 전체를 한 색 조합으로 대표시키지 않는 것이 중요합니다.

아래 계산기는 불투명한 sRGB 색 두 개만 받습니다. 흰 배경과 #777777 글자를 기본 예제로 사용하며, 반투명도나 그라데이션, 배경 사진의 위치 변화는 계산하지 않습니다. 입력 범위를 제한한 이유는 복잡한 배경을 단색으로 가정해 통과라고 표시하지 않기 위해서입니다. 실제 배경이 여러 색이라면 가장 불리한 위치와 각 표시 상태를 따로 확인해야 합니다.

4.5:1과 3:1은 어떤 글자에 적용하는지부터 구분합니다

WCAG 2.2의 최소 대비 기준은 일반적인 글자에 4.5:1, 큰 글자에 3:1이라는 문턱을 둡니다. 큰 글자는 단순히 제목 요소라는 뜻이 아닙니다. 기준에서는 18pt 또는 굵은 14pt 등을 설명하며, 문자 체계에 해당하는 크기와 실제 글꼴 특성도 고려합니다. 이 계산기는 글꼴을 분석하지 않으므로 일반 글자 기준과 큰 글자 기준의 결과를 둘 다 보여 줍니다.참고: W3C · WCAG 2.2: Contrast (Minimum)

예를 들어 h1으로 표시한 문장도 CSS에서 아주 작게 줄였다면 큰 글자라는 이름만으로 낮은 기준을 적용할 수 없습니다. 반대로 굵기만 숫자 700으로 설정했다고 모든 글꼴에서 같은 획 두께를 보장하지도 않습니다. 실제 크기와 굵기를 기록하고, 불확실할 때는 일반 글자 기준을 만족하도록 색을 정하는 편이 관리하기 쉽습니다.

두 색을 밝기 값으로 바꾼 뒤 비율을 구합니다

계산에는 각 색의 빨강·초록·파랑 값을 사용합니다. 0~255 값을 0~1로 바꾼 뒤 sRGB의 비선형 값을 선형 값으로 변환하고, 정해진 가중치로 상대 휘도를 구합니다. 밝은 색의 휘도에 0.05를 더한 값을 어두운 색의 휘도에 0.05를 더한 값으로 나누면 대비가 됩니다. 색 이름의 인상이나 채도만 비교하는 계산은 아닙니다.참고: W3C WAI · Understanding SC 1.4.3: Contrast (Minimum)

대비 = (밝은 색의 상대 휘도 + 0.05) / (어두운 색의 상대 휘도 + 0.05)

계산기의 화면에는 비율을 보기 편하게 소수점 셋째 자리까지 표시하지만 통과 여부는 반올림 전 값으로 비교합니다. 두 값이 화면에서는 비슷해 보여도 문턱을 사이에 두고 결과가 달라질 수 있습니다. 이 때문에 결과표에는 표시 숫자만 복사하기보다 검사한 두 색과 적용한 기준도 함께 남겨야 합니다.

흰 바탕의 #777777과 #767676을 비교해 봅니다

흰 배경에서 #777777은 약 4.478:1, #767676은 약 4.542:1입니다. 화면을 얼핏 보면 비슷한 회색이지만 일반 글자의 4.5:1 문턱에서는 결과가 달라집니다. 이는 두 색의 정의로부터 계산한 예제 값이며, 어느 회색이 모든 화면에서 편하게 읽힌다는 사용자 실험 결과는 아닙니다.

브랜드 색이 기준에 미치지 못한다면 글자 크기만 키우는 방법부터 택하지 않습니다. 배경과 글자 중 어떤 색을 바꿀 수 있는지, 강조색을 아이콘이나 테두리처럼 다른 역할로 옮길 수 있는지 검토합니다. 본문 전체의 색을 바꾸기 어렵다면 가장 중요한 안내·가격·오류 문장부터 검사하되, 나머지 본문을 검증 완료로 표시하지 않습니다.

글자는 읽혀도 버튼과 상태를 구분하지 못할 수 있습니다

흰 배경 위의 어두운 버튼 글자가 잘 보여도 버튼 외곽이 주변과 구분되지 않으면 클릭할 수 있는 영역을 알아보기 어렵습니다. 체크 표시, 선택 상태, 입력창의 경계와 같은 비텍스트 정보는 글자와 별도 관계로 봅니다. W3C의 비텍스트 대비 설명은 필요한 시각 정보와 인접 색의 관계를 다루며, 모든 장식 선에 무조건 같은 판정을 적용하는 방식은 아닙니다.참고: W3C WAI · Understanding SC 1.4.11: Non-text Contrast

오류를 빨간색으로만 구분하는 화면도 대비 숫자 하나로 해결되지 않습니다. “이메일 형식을 확인하세요” 같은 설명과 입력란의 관계가 남아 있어야 합니다. 선택한 탭은 색뿐 아니라 위치, 표시, 프로그램적 상태로도 구별할 수 있어야 합니다. 이 계산기에서 두 색이 통과했다고 이런 상호작용까지 검증된 것으로 넓혀 해석하지 않습니다.

회색 도움말을 실제 페이지에 적용한 뒤에는 확대했을 때 글자가 사라지지 않는지, 글꼴이 바뀐 뒤 줄바꿈이 겹치지 않는지, 초점 표시를 덮지 않는지도 봅니다. 대비는 가독성의 한 축이고 문장 길이·간격·정보 순서도 읽기 경험에 영향을 줍니다. 색상표의 숫자와 렌더링 검사를 함께 남겨야 다음 수정자가 같은 조건을 재현할 수 있습니다.

색상 토큰과 사용 위치를 함께 전달합니다

검사한 색을 “본문 회색 통과”라는 메모로만 남기면 다른 배경에 재사용할 때 조건이 사라집니다. 글자 토큰, 배경 토큰, 용도, 기본·호버·초점 상태와 검사일을 한 행에 적습니다. 특정 조합이 통과했다는 사실을 색 한 개가 언제나 안전하다는 속성으로 바꾸지 않는 것이 핵심입니다.

1. 실제 표시 상태에서 글자색과 배경색을 수집합니다.
2. 불투명 단색인지 확인하고 계산 범위 밖인 배경은 별도 검사로 남깁니다.
3. 원래 비율로 기준을 비교하고 글자 크기·굵기 판단을 기록합니다.
4. 색상 토큰이 바뀌면 연결된 도움말·버튼·오류 상태를 다시 확인합니다.

이 글의 결과는 입력한 색 두 개의 수학적 관계에 한정됩니다. 접근성 인증, 모든 기기에서의 읽기 편의, 사용자 과업 성과를 대신하지 않습니다. 특히 사진·영상 위 글자, 반투명 오버레이, 혼합 모드가 있는 화면은 이 단색 계산기의 결과를 그대로 적용하지 않아야 합니다.

텍스트 명도대비와 상태 변화을 확인한 순서

1. 배경 #FFFFFF를 고정하고 글자색 #777777을 넣습니다. 약 4.478:1과 일반 글자 기준 미충족을 함께 확인합니다.
2. 글자색만 #767676으로 바꾸어 약 4.542:1을 비교합니다. 반올림한 표시값으로 통과 여부를 결정하지 않습니다.
3. 잘못된 색 형식도 입력합니다. 두 불투명색의 계산을 사진 배경·투명도·모든 버튼 상태의 접근성 검증으로 확대하지 않습니다.

텍스트 명도대비와 상태 변화 판단에서 제외한 범위

• 불투명한 sRGB 단색 두 개만 계산합니다.
• 글꼴 크기와 굵기, 배경 사진, 투명도, 혼합 모드는 자동 판정하지 않습니다.
• 색 대비 계산은 사이트 전체 접근성이나 실제 읽기 성과의 인증이 아닙니다.

텍스트 명도대비와 상태 변화에 사용한 원문

원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.

1. Understanding SC 1.4.3: Contrast (Minimum)W3C WAI · 확인 2026-09-03

   대비 문턱, 상대 휘도 계산과 반올림하지 않는 비교 원칙을 참고했습니다.

2. Understanding SC 1.4.11: Non-text ContrastW3C WAI · 확인 2026-09-03

   컨트롤과 필요한 비텍스트 정보의 대비를 글자와 구분했습니다.

3. WCAG 2.2: Contrast (Minimum)W3C · 확인 2026-09-03

   기술 요구사항 원문의 대비 기준과 용어 정의를 함께 참고했습니다.