색 대비 실패는 웹에서 가장 흔한 단일 접근성 위반 사항으로, 대부분의 웹사이트에 영향을 미칩니다. 이 가이드는 WCAG가 정확히 무엇을 요구하는지, 올바른 도구로 색 대비 실패를 어떻게 찾는지, 그리고 브랜드의 시각적 정체성을 훼손하지 않으면서 CSS에서 이를 어떻게 수정할 수 있는지를 단계별로 설명합니다.

시력이 낮은 방문자가 휴대폰 밝기를 최대로 올린 채 햇빛이 쏟아지는 카페에 앉아 당신의 웹사이트에 접속했다고 상상해 보세요. 연한 회색 본문 텍스트가 흰색 배경 위에 놓여 있다면, 당신이 얼마나 공들여 문장을 다듬었는지와 상관없이 그 사람은 내용을 읽을 수 없습니다. 이 상황은 가정이 아닙니다. 2026년 초 기준 상위 100만 개 홈 페이지의 83.9%에서 저대비 텍스트가 감지되었고, 이는 7년 연속 웹에서 가장 흔히 발견된 접근성 실패 유형이 되었으며, 문제를 가진 각 홈 페이지는 평균 34개의 개별 사례를 포함하고 있습니다.

생각보다 훨씬 중요한 색 대비

대부분의 사람들은 대비 문제는 완전히 시각장애가 있거나 스크린 리더를 사용하는 사용자에게만 영향을 준다고 생각합니다. 실제로는 훨씬 더 광범위합니다. 전 세계적으로 약 3억 명이 어떤 형태로든 색각 이상을 가지고 있으며, 저가형 모니터를 쓰는 사람, 노안이 온 사람, 밝은 야외에서 화면을 보는 사람 등 훨씬 더 많은 사람들이 낮은 대비를 일상적인 불편으로 겪고 있습니다. 저시력은 전맹보다 훨씬 흔합니다. 시력을 완전히 잃은 사람보다 저시력을 가진 사람이 거의 세 배 더 많습니다.

WCAG 대비 임계값에 대한 연구는 이를 구체적으로 보여 줍니다. 일반 텍스트에 대한 최소 대비 비율 4.5:1은 대략 20/40에 해당하는 시력을 가진 사람이 일반적으로 겪는 대비 민감도 손실을 보정하도록 보정된 값입니다. 20/40은 80대 사람들에게 흔히 보고되는 시력입니다. WCAG의 더 엄격한 7:1 Level AAA 임계값도 마찬가지 방식으로 보정되었습니다. 이는 보조 기술을 사용하지 않는 저시력 사용자, 즉 20/80에 해당하는 시력을 가진 사람들의 대비 민감도 손실을 보정하는 것을 목표로 합니다.

법적·비즈니스적 결과도 매우 현실적입니다. 미국에서는 2024년에 ADA 디지털 접근성 소송이 4,605건에 달했으며, 유럽 접근성 법(European Accessibility Act)은 2025년 6월 발효되어 광범위한 상업용 웹사이트와 앱에 의무 준수 의무를 확장했습니다. 색 대비 실패는 탐지 가능하고 문서화되며, 소송에서 일상적으로 인용됩니다. 컴플라이언스 담당자에게 이것은 “있으면 좋은 것”이 아니라 반드시 해결해야 할 우선순위가 됩니다.

마지막으로, 접근 가능한 대비는 그 자체로 좋은 디자인입니다. 고대비 텍스트는 모든 사람에게 더 쉽게 스캔할 수 있고, 인지 부하를 줄이며, 전반적인 읽기 속도를 향상시킵니다. 즉, 컴플라이언스 의무이자 동시에 비즈니스 성과 개선이기도 합니다.

실제로 알아야 할 WCAG 대비 규칙

WCAG 2는 대비를 두 색 사이의 지각된 휘도 차이를 측정한 값으로 정의합니다. 이 공식은 전경색과 배경색의 상대적인 밝기를 비교하고, 그 결과를 1:1(차이 없음 — 흰색 위에 흰색)에서 21:1(최대 차이 — 흰색 위에 검은색)까지의 비율로 표현합니다. 이 값을 직접 계산할 필요는 없습니다. 핵심은 어떤 비율이 요구되는지, 그리고 언제 적용되는지를 이해하는 것입니다.

WCAG 2.x Level AA — 대부분의 법과 접근성 표준에서 참조하는 수준 — 에서는 요구 사항이 다음과 같이 나뉩니다.

일반 텍스트(본문, 레이블, 18pt 미만 또는 14pt 볼드 미만의 UI 텍스트): 배경과 최소 4.5:1 대비 비율.
큰 텍스트(최소 18pt / 24px, 또는 14pt / ~18.66px 볼드): 최소 대비 비율 3:1. 글자가 커질수록 본질적으로 구분이 쉬워지므로, 더 완화된 임계값이 정당화된다는 논리입니다.
비텍스트 UI 구성 요소 및 정보 그래픽(WCAG 2.1에서 도입된 성공 기준 1.4.11): 인접 색과 최소 3:1 대비 비율. 이는 폼 입력 테두리, 포커스 인디케이터, 아이콘만 있는 버튼, 데이터를 이해하는 데 필요한 차트 요소 등을 포함합니다.

Level AAA에서는 기준이 더 높습니다. 일반 텍스트는 7:1, 큰 텍스트는 4.5:1입니다. Level AAA 전체가 의무화되는 경우는 드물지만, 텍스트가 많은 페이지나 읽기 정확도가 중요한 사용자 인터페이스에서는 디자인 목표로 삼을 가치가 있습니다.

중요한 뉘앙스: WCAG는 “큰 텍스트”를 CSS 값이 아니라 브라우저에 렌더링된 실제 크기로 정의합니다. 1.2rem으로 설정된 폰트는 사용자의 브라우저 기본 폰트 크기에 따라 큰 텍스트에 해당할 수도 있고 아닐 수도 있습니다. 애매하다면 4.5:1 임계값을 적용하고, 도구를 사용해 실제 렌더링 크기를 확인하세요.

일부 요소는 대비 요구 사항에서 명시적으로 제외됩니다. 순수 장식용 이미지, 비활성 폼 컨트롤, 로고, 실제 사진은 성공 기준 1.4.3의 적용 대상이 아닙니다. 이 예외는 합리적입니다. 워터마크 배경이나 제품 사진이 내비게이션 레이블과 같은 임계값을 강제로 맞춰야 할 이유는 없습니다. 하지만 팀들은 종종 이 예외를 잘못 적용해 게으른 디자인 선택을 정당화하곤 합니다. 페이지 내용을 이해하는 데 필수적인 이미지나 그래픽이라면 여전히 3:1 비텍스트 대비 요구 사항을 충족해야 합니다.

또 하나 주목할 만한 중요한 규칙이 있습니다. WCAG 1.4.1(색 사용)입니다. 링크를 주변 본문 텍스트와 색만으로 구분한다면 — 밑줄도, 두께 차이도, 다른 시각적 단서도 없이 — 그 링크는 표준 4.5:1 텍스트-배경 대비 비율을 충족하는 것 외에, 인접 본문 텍스트와 3:1 대비 비율을 달성해야 합니다. 이 세 가지 요구 사항을 동시에 만족시키는 것은 실제로 까다롭습니다. 가장 간단한 해결책은 링크 밑줄을 유지하는 것입니다.

대비 실패를 테스트하는 방법

대비 테스트는 접근성 작업 중 도구 친화성이 가장 높은 부분 중 하나입니다. 기본 계산이 수학적이고 결정론적이기 때문에, 자동화 도구가 다른 많은 접근성 문제와 달리 신뢰성 있게 잡아낼 수 있습니다. 그렇다고 해도 자동화가 부족한 모서리 사례들이 있으며, 전체 테스트 스택을 이해하면 훨씬 더 철저한 감사가 가능합니다.

1단계: 자동 페이지 스캔 실행

WAVE(WebAIM 웹 접근성 평가 도구)와 axe DevTools는 가장 널리 사용되는 브라우저 기반 스캐너 두 가지입니다. 둘 다 Chrome과 Firefox 확장 프로그램으로 제공됩니다. 이 도구들은 렌더링된 DOM을 스캔합니다. 즉, CSS와 JavaScript가 적용된 후 브라우저가 실제로 색을 그리는 방식대로 색을 평가하고, WCAG AA 대비 임계값을 충족하지 못하는 텍스트 요소를 표시합니다. Axe DevTools는 더 나아가 각 문제의 심각도를 보고하고, 관련 WCAG 성공 기준과 연결하며, 수정 가이드를 제공합니다. 엔터프라이즈 팀의 경우 axe-core를 CI/CD 파이프라인에 직접 통합해 배포 전에 대비 회귀를 잡을 수 있습니다.

Google Lighthouse는 Chrome DevTools에 내장되어 있으며, 접근성 감사의 일부로 대비 검사도 수행합니다. 대부분의 개발자 워크플로에 이미 포함되어 있다는 점에서 특히 유용한 1차 점검 도구입니다. 다만 axe-core 규칙의 일부만 사용하므로, 전체 axe DevTools 확장만큼 포괄적이지는 않습니다.

중요한 한계점 하나: 자동 스캐너는 그라디언트 배경, 배경 이미지, 반투명 레이어, 복잡한 CSS 스태킹이 적용된 요소 위의 텍스트 대비를 신뢰성 있게 평가할 수 없습니다. 이런 경우에는 수동 검사가 필요합니다.

2단계: Chrome DevTools 색 선택기를 사용한 타깃 검사

Chrome DevTools에서 어떤 요소든 Styles 패널을 열고 색 값 옆의 색 견본을 클릭하면, 해당 요소의 계산된 배경색에 대한 현재 대비 비율을 보여 주는 내장 색 선택기가 실행됩니다. 대비가 실패할 경우 DevTools는 자동 수정 기능을 제공합니다. 가장 가까운 AA 및 AAA 통과 색을 제시해, 클릭 한 번으로 준수하는 값을 채택할 수 있게 해 줍니다. 이는 개발 중 빠른 반복에 매우 유용합니다. DevTools에는 Rendering 패널 아래에 시각 결함 에뮬레이터도 포함되어 있어, 흐릿한 시야, 적색약(protanopia), 녹색약(deuteranopia), 전색맹(achromatopsia) 등 상태를 시뮬레이션해 색각 이상 사용자가 팔레트를 어떻게 경험하는지 정성적으로 느껴볼 수 있습니다.

3단계: 전용 검사기로 특정 색 쌍 테스트

아직 구현되기 전 Figma 디자인 리뷰처럼, 개별 색 조합을 독립적으로 검증할 때는 WebAIM Contrast Checker(webaim.org/resources/contrastchecker)가 업계 표준입니다. 전경과 배경의 hex 값을 입력하면, 즉시 대비 비율과 일반 및 큰 텍스트 크기에 대한 AA·AAA 통과/실패 여부를 반환합니다. Windows와 macOS용 데스크톱 애플리케이션인 Colour Contrast Analyser(CCA)도 마찬가지로 유용하며, 반투명 전경, 브라우저뿐 아니라 어떤 애플리케이션에서든 화면 상의 색을 스포이트로 찍어 복잡한 사례를 처리할 수 있습니다.

4단계: 실제 맥락에서 테스트 — 다크 모드, 호버 상태, 포커스 인디케이터

많은 팀이 이 단계에서 실수를 합니다. 기본 라이트 테마에서 통과한 색 쌍이 다크 모드에서는 완전히 실패할 수 있습니다. 흰 배경에서 생생해 보이는 브랜드 포인트 색은 어두운 배경에서는 탁해지거나 눈부시게 보이기 쉽습니다. 모든 인터랙티브 상태 — hover, focus, active, visited — 는 새로운 대비 실패의 잠재적 원인입니다. 마찬가지로, 키보드 사용자가 컨트롤로 탭 이동할 때 나타나는 포커스 인디케이터(가시적인 윤곽선)는 WCAG 2.1 성공 기준 1.4.11에 따라 인접 색과 3:1 대비를 달성해야 합니다. 출시 전에는 항상 두 테마를 모두 테스트하세요. 다크 모드는 보기 좋다는 이유만으로 자동으로 접근 가능한 것이 아닙니다.

가장 흔한 대비 실패 유형 — 그리고 해결 방법

감사에서 가장 자주 나타나는 실패 패턴을 이해하면 수정 작업의 우선순위를 정할 수 있습니다. 대부분의 대비 문제는 예측 가능한 몇 가지 범주에 속합니다.

흰 배경 위의 회색 본문 텍스트

#767676이나 #999999 같은 중간 회색을 흰 배경 위에 사용하는 패턴은 현대 플랫 디자인에서 매우 흔합니다. 보정된 모니터를 사용하는 디자이너에게는 가볍고 세련되게 느껴집니다. 하지만 이 색들은 자주 4.5:1 임계값을 통과하지 못하고, 저시력 사용자에게는 보이지 않습니다. 해결책은 보통 간단한 색 값 변경입니다. #767676(4.54:1로 간신히 통과)를 #595959로 바꾸면 7.0:1 대비 비율을 얻을 수 있고, 대부분의 시력이 좋은 사용자에게는 차이가 거의 느껴지지 않으면서 가독성은 크게 향상됩니다.

대비 조정을 위해 더 직관적인 색 모델인 HSL을 사용할 때는, 선택한 색조(hue)와 채도(saturation)는 그대로 유지한 채 밝기(Lightness)만 수정하면 대비 비율을 바꿀 수 있습니다. 흰 배경에서는 밝기 값을 낮추면 텍스트가 어두워져 대비가 개선되고, 어두운 배경에서는 밝기 값을 높이면 텍스트가 밝아집니다. 밝기 2–5 퍼센트포인트 정도의 작은 변화만으로도 실패 상태에서 명확한 AA 통과로 옮겨 갈 수 있으며, 디자인이 눈에 띄게 달라지지 않습니다.

/* 변경 전: WCAG AA 실패(흰색에서 비율 약 3.9:1) */
.body-text {
  color: #888888;
}

/* 변경 후: WCAG AA와 AAA 모두 통과(흰색에서 비율 약 7.0:1) */
.body-text {
  color: #595959;
}

폼 필드의 플레이스홀더 텍스트

브라우저 기본 스타일로 렌더링되는 플레이스홀더 텍스트 — 보통 #AAAAAA나 #BBBBBB 정도의 연한 회색 — 는 흰색 입력 배경에서 거의 항상 WCAG AA를 통과하지 못합니다. 많은 디자이너가 사용자 입력 내용과 시각적으로 구분하기 위해 의도적으로 플레이스홀더 대비를 낮게 유지하지만, 이는 허용되는 예외가 아닙니다. 플레이스홀더 텍스트는 사용자 인터페이스 텍스트이며 4.5:1 기준을 충족해야 합니다. 더 어두운 색을 사용하고, 밝기 대신 이탤릭 스타일, 위치, 애니메이션 등을 시각적 구분 수단으로 활용하세요.

::placeholder {
  /* 실패: #AAAAAA는 흰색에서 약 2.3:1 */
  color: #AAAAAA;
}

::placeholder {
  /* 통과: #767676은 흰색에서 약 4.54:1 */
  color: #767676;
  font-style: italic; /* 대체 시각적 단서 */
}

중간 톤 브랜드 색 위의 흰색 또는 밝은 텍스트

HSL의 밝기 5–6 범위에 있는 중간 채도 브랜드 색 — 흔한 파란색, 초록색, 보라색 — 은 그 위에 올린 흰색 텍스트에 충분한 대비를 제공하지 못하는 경우가 많습니다. 로고에서는 멋져 보이는 선명한 브랜드 블루가 흰색과의 대비 비율이 2.8:1에 불과해, 본문 텍스트에 필요한 최소 4.5:1에 한참 못 미칠 수 있습니다. 해결책은 배경색을 더 어둡게(디자인 시스템에서 브랜드 색을 800 또는 900 토큰으로 내리기), 해당 배경에서는 어두운 텍스트를 사용하기, 또는 그 중간 톤 색을 대비 규칙이 적용되지 않는 순수 장식 요소에만 사용하는 것입니다.

배경 이미지나 그라디언트 위의 텍스트

사진이나 그라디언트 위에 직접 올린 텍스트는 배경 휘도가 균일하지 않기 때문에 가장 까다로운 사례 중 하나입니다. 이미지의 다른 부분마다 대비 비율이 달라지기 때문입니다. 가장 신뢰할 수 있는 해결책은 CSS로 반투명 어두운(또는 밝은) 오버레이를 적용하는 것입니다. 이미지는 아래에 그대로 보이도록 가상 요소(pseudo-element)로 오버레이를 적용합니다. 대략 50–60% 불투명도의 검은 오버레이는 경계선에 있는 흰 텍스트 대비를 안정적인 AAA 수준으로 끌어올리는 데 보통 충분합니다.

.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff;
}

비활성 상태 및 보조 UI 요소

WCAG는 비활성 UI 구성 요소를 대비 요구 사항에서 명시적으로 제외합니다. 비활성 버튼은 4.5:1을 충족할 필요가 없습니다. 하지만 많은 팀이 이 예외를 실제로 비활성 상태가 아닌 보조 텍스트, 캡션, 도움말 텍스트, 레이블 등에 과도하게 적용합니다. 사용자가 이해하거나 행동하는 데 필요한 정보를 전달하는 요소라면, 시각적 계층과 상관없이 해당 대비 기준을 충족해야 합니다. 디자인 시스템의 중립 색 스케일에 있는 모든 색을, 실제로 사용되는 배경과 조합해 확인하세요.

디자인 시스템에 대비를 내장하기

개별 대비 실패를 사후적으로 고치는 방식은 느리고 오류가 발생하기 쉽습니다. 더 지속 가능한 접근 방식은 대비 준수를 디자인 시스템에 내장해, 접근 가능한 색 조합이 기본 출력이 되도록 만드는 것입니다.

기초는 적절히 계조된 토큰 스케일입니다. 팔레트의 각 색은 표준 배경색에 대해 미리 계산된 대비 비율이 문서화되어 있어야 합니다. 합리적인 관례는 토큰을 대비 성능으로 라벨링하는 것입니다. 예를 들어 --color-text-primary 토큰은 항상 --color-surface-default에서 AA를 통과해야 하며, 이 보장은 문서화되고, 테스트되며, 강제되어야 합니다. 디자이너가 텍스트 색을 지정하기 위해 토큰을 선택할 때마다, 매번 수동 검사를 하지 않아도 최소 기준을 충족한다는 점을 신뢰할 수 있어야 합니다.

CSS 커스텀 프로퍼티를 사용하면 이 작업이 특히 수월해집니다. 전체 팔레트를 변수로 정의하고, 미디어 쿼리를 사용해 다크 모드에서 이를 교체하면, 어떤 색 쌍도 하드코딩하지 않고 대비 준수 관리를 한 곳에 모을 수 있습니다.

:root {
  --color-surface-default: #ffffff;
  --color-text-primary: #1a1a1a;   /* ~16:1 on white */
  --color-text-secondary: #595959; /* ~7.0:1 on white */
  --color-text-subtle: #767676;    /* ~4.54:1 on white */
  --color-accent: #0052cc;         /* ~8.0:1 on white */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-default: #121212;
    --color-text-primary: #ededed;   /* ~14.5:1 on #121212 */
    --color-text-secondary: #c0c0c0; /* ~9.4:1 on #121212 */
    --color-text-subtle: #909090;    /* ~5.1:1 on #121212 */
    --color-accent: #6fa8ff;         /* ~6.5:1 on #121212 */
  }
}

위 다크 모드 토큰 값을 주목해 보세요. 흰 배경에서 AA를 통과하는 색이 어두운 배경에서는 실패하는 경우가 많고, 그 반대도 마찬가지입니다. 다크 모드를 설계할 때 라이트 모드 값을 단순히 반전하는 것은 피하세요. 순수한 흰색 텍스트를 순수한 검정(#000000) 위에 올리면 일부 사용자에게는 고대비 극단에서 발생하는 시각적 번짐(halation) 현상을 일으킬 수 있습니다. #121212 배경에 #ededed 텍스트는 여전히 훌륭한 대비를 제공하면서도 더 편안한 조합입니다.

자동 대비 테스트를 컴포넌트 파이프라인에 통합할 수도 있습니다. axe-core 같은 라이브러리는 Jest나 Playwright 테스트에서 호출해 대비 실패를 표준 테스트 스위트의 일부로 표시할 수 있으며, 외부 감사 시점이 아니라 도입되는 즉시 회귀를 잡아낼 수 있습니다.

자동 도구가 잡지 못하는 것들 — 그리고 대처 방법

자동 스캔은 강력한 출발점이지만, 분명한 한계가 있습니다. 전체 접근성 기준을 고려하면 자동 테스트는 잠재적인 WCAG 위반의 약 20~30% 정도만 탐지할 수 있는 경우가 많습니다. 색 대비는 그중에서도 비교적 잘 탐지되는 범주이긴 합니다. 그럼에도 불구하고 여러 대비 실패 시나리오가 자동 도구를 자주 빠져나갑니다.

그라디언트와 배경 이미지 위의 텍스트가 가장 흔한 블라인드 스폿입니다. Axe와 WAVE는 전경과 배경이 단일 결정론적 색 값을 가질 때 색 조합을 식별할 수 있습니다. 배경이 CSS 그라디언트나 JPEG 사진인 경우, 도구는 의미 있는 비율을 계산하지 못하고 해당 항목을 명확한 실패가 아닌 “검토 필요”로 표시하는 경우가 많습니다. 이런 사례는 사람의 검토가 필요하며, 이상적으로는 Colour Contrast Analyser 같은 픽셀 단위 스포이트 도구를 사용해 겹치는 영역의 여러 지점에서 실제 전경·배경 값을 샘플링해야 합니다.

반투명 및 합성 색도 비슷한 문제를 만듭니다. 초록색 페이지 배경 위에 렌더링된 파란 버튼, 그 위의 흰 버튼 레이블처럼 세 가지 색 레이어가 겹치는 경우, 계산된 대비는 세 레이어 모두에 의존합니다. DOM 기반 도구는 이 값을 항상 정확히 계산하지 못합니다. 알파 값을 수동으로 평탄화하거나, 화면 캡처 기반 도구를 사용해 렌더링된 픽셀 색을 샘플링하세요.

동적으로 생성되는 상태 — JavaScript로 구동되는 툴팁, 모달 다이얼로그, 드롭다운 메뉴, 오류 메시지 — 는 즉석에서 렌더링되며, 자동 스캔이 실행될 때 화면에 보이지 않을 수 있습니다. 스크립트로 제어 가능한 도구(Playwright 테스트에서의 axe-core 등)는 이런 상태로 이동해 평가할 수 있지만, 그 커버리지를 구성하려면 의도적인 노력이 필요합니다. 이를 QA 워크플로에 포함하고, 새로운 색 조합을 도입하는 모든 새 컴포넌트에 대해 대비를 “완료 정의”에 포함시키세요.

마지막으로, WCAG의 수학적 대비 공식은 잘 확립되어 있지만, 지각된 가독성을 완벽하게 대변하지는 못합니다. 이 공식은 폰트 두께, 자간, 안티앨리어싱을 고려하지 않습니다. 4.5:1 대비를 가진 얇은 두께의 서체는 같은 비율의 굵은 서체보다 읽기 어렵게 느껴집니다. WCAG 임계값을 최적화 목표가 아니라 “최소 기준”으로 취급하세요. 가능한 한 7:1을 목표로 하고, 실제 저시력 사용자를 대상으로 사용자 테스트를 진행해 색 선택이 현실 세계에서 잘 작동하는지 검증하세요.

핵심 요약

색 대비는 웹에서 가장 흔한 접근성 실패입니다. 2026년 기준 상위 100만 개 홈 페이지의 83.9%에서 저대비 텍스트가 발견되었습니다. 조직의 접근성 프로그램이 얼마나 성숙하든, 대비는 지금도 미해결 문제가 있을 가능성이 가장 높은 영역이며, 동시에 가장 고치기 쉬운 영역 중 하나입니다.
당신의 콘텐츠에 적용되는 임계값을 이해하세요. WCAG AA는 일반 텍스트에 4.5:1, 큰 텍스트(18pt+ 또는 14pt+ 볼드)에 3:1, 입력 테두리나 아이콘만 있는 컨트롤 같은 비텍스트 UI 구성 요소에 3:1을 요구합니다. 이 기준은 인터페이스가 라이트 모드인지 다크 모드인지와 상관없이 적용됩니다.
레이어별로 테스트하세요: 자동 스캔, DevTools 검사, 독립 검사기, 수동 리뷰. 전체 페이지를 빠르게 스캔하기 위해 axe DevTools나 WAVE를 실행하고, 빠른 반복을 위해 Chrome DevTools의 내장 색 선택기를 사용하며, 특정 색 쌍을 검증하기 위해 WebAIM Contrast Checker나 CCA를 사용하고, 자동 도구가 신뢰성 있게 평가할 수 없는 그라디언트, 이미지, 동적 상태는 수동으로 검사하세요.
컴포넌트 수준이 아니라 디자인 시스템 수준에서 대비를 해결하세요. 미리 검증된 대비 비율을 가진 토큰 스케일을 구축하고, 어떤 텍스트 토큰이 어떤 서피스 토큰에서 통과하는지 문서화하며, CI의 자동 테스트를 통해 준수를 강제하세요. 이렇게 하면 프로덕션에 도달하기 전에 전체 범주의 실패를 제거할 수 있습니다.
WCAG를 목표가 아니라 최소 기준으로 취급하세요. 4.54:1은 간신히 통과하는 수준일 뿐이며, 여전히 많은 사용자가 어려움을 겪습니다. 타이포그래피, 가독성, 브랜드가 허용하는 범위에서 7:1에 가깝게 밀어 올리고, 폰트 두께, 크기, 자간을 추가 레버로 활용해 “기술적으로만 준수”하는 것이 아니라 실제로 편안하게 읽을 수 있는 텍스트를 만드세요.

웹 디자인에서의 색 대비: 대비 실패를 테스트하고 수정하는 방법