WCAG 1.4.6: 대비 (향상됨)

이 규칙의 의미

WCAG 1.4.6 대비(향상)는 지침 1.4(식별 가능) 아래의 AAA 레벨 성공 기준입니다. 이 기준은 텍스트 및 텍스트 이미지의 시각적 표현이 배경과 최소 7:1의 명도 대비 비율을 갖도록 요구합니다. 큰 텍스트의 경우 — 보통 굵기에서는 최소 18pt(약 24px), 굵은 글꼴에서는 최소 14pt(약 18.67px)로 정의되며 — 요구되는 대비 비율은 최소 4.5:1입니다. 이는 일반 텍스트에 4.5:1, 큰 텍스트에 3:1만 요구하는 AA 레벨 기준 1.4.3보다 상당히 강화된 요구사항입니다.

대비 비율은 WCAG 명세에서 정의한 두 색상의 상대 휘도를 사용해 계산됩니다. 이 공식은 전경색과 배경색의 선형화된 RGB 값을 고려하여 1:1(대비 없음, 동일한 색상)에서 21:1(최대 대비, 흰 바탕의 검정 또는 검정 바탕의 흰색)까지의 비율을 산출합니다.

이 기준은 인터페이스에 렌더링되는 모든 텍스트에 적용되며, 이미지 안의 텍스트, 텍스트를 포함한 아이콘, 렌더링 결과에 접근 가능한 canvas 요소에 렌더링된 텍스트를 포함합니다. 제목, 본문 텍스트, 레이블, 의미 있는 정보를 전달하는 입력 필드의 플레이스홀더 텍스트, 버튼 라벨, 링크 텍스트, 내비게이션 항목 및 화면에 보이는 기타 모든 텍스트 콘텐츠에 영향을 미칩니다.

WCAG 1.4.6은 기준 1.4.3과 동일한 공식 예외를 공유합니다. 다음 항목들은 요구사항에서 명시적으로 제외됩니다.

• 부수적인 텍스트(Incidental text): 순수하게 장식용인 텍스트 또는 텍스트 이미지, 누구에게도 보이지 않는 텍스트, 또는 다른 중요한 시각적 콘텐츠를 포함하는 그림의 일부인 텍스트. 예를 들어, 장식용으로 사용된 사진의 배경에 보이는 텍스트가 이에 해당합니다.
• 로고타입(Logotypes): 로고나 브랜드 이름의 일부인 텍스트는 대비 요구사항이 없습니다. 이는 회사 로고의 워드마크 부분에만 적용되며, 인접한 본문 텍스트나 UI 레이블에는 적용되지 않습니다.
• 비활성 사용자 인터페이스 구성요소: 비활성화된 폼 컨트롤, 비활성 버튼 또는 현재 조작할 수 없는 기타 인터페이스 요소 안의 텍스트는 예외입니다. 다만 이 예외는 제한적으로 적용해야 합니다 — 비활성 UI 역시 존재를 전달할 수 있을 만큼은 지각 가능해야 합니다.

이 기준을 통과한다는 것은 명시적으로 예외로 분류되지 않은 모든 텍스트 콘텐츠 인스턴스가 7:1(또는 큰 텍스트의 경우 4.5:1) 대비 비율을 충족하거나 초과함을 의미합니다. 예외가 아닌 텍스트 중 하나라도 이 임계값을 조금이라도 밑돌면 실패가 됩니다. 대비는 지원되는 모든 상태 — hover, focus, active, visited — 에서 유지되어야 하며, 이 기준은 각 상태에서 렌더링된 표현에 적용됩니다.

중요한 이유

세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있습니다. 이 중 수억 명은 백내장, 녹내장, 황반변성, 다양한 형태의 색각 이상 등 색을 구분하거나 저대비 텍스트를 인지하는 능력을 직접적으로 저하시키는 질환을 겪고 있습니다. 이 인구에게 4.5:1이라는 AA 대비 임계값만 충족하는 인터페이스는 여전히 읽기와 이해에 상당한 장벽을 만들 수 있습니다.

이 기준에서 요구하는 7:1 비율은 노화된 눈과 일반적인 저시력 상태에서 나타나는 대비 민감도 감소를 반영하도록 특별히 보정된 값입니다. 시각 과학 연구에 따르면, 중등도 수준의 대비 민감도 감소(교정 렌즈를 사용한 20/80 시력에 해당하는 정도)를 가진 사람은 체감 대비가 약 3분의 1 수준으로 감소할 수 있습니다. 7:1로 설계된 대비 비율은 이러한 지각적 감소를 거친 후에도 약 2.3:1의 체감 대비를 제공하며, 이는 텍스트가 읽을 수 있게 되는 최소 임계값에 근접한 수준입니다. 이러한 여유가 없다면, 해당 사용자는 콘텐츠를 전혀 읽지 못할 수도 있습니다.

현실적인 상황을 하나 생각해 봅시다. 68세의 은행 고객이 맑은 오후, 햇빛이 노트북 화면에 반사되는 환경에서 온라인으로 금융 업무를 처리하고 있습니다. 의학적으로는 시력이 정상이라 하더라도, 눈부심과 노화에 따라 자연스럽게 감소한 대비 민감도 때문에 흰 배경 위의 중간 회색 텍스트는 완전히 읽을 수 없게 될 수 있습니다. 일반적인 조건에서 7:1 대비를 달성한 디자인은 이러한 상황에서도 여전히 사용 가능하지만, 겨우 4.5:1을 넘긴 디자인은 그렇지 못합니다.

장애와 직접 관련된 영향뿐 아니라, 고대비 텍스트는 최적이 아닌 읽기 환경에 있는 사실상 모든 사용자에게 이점을 제공합니다. 예를 들어 밝은 야외 햇빛, 백라이트가 약해진 노후된 화면, 단색 e-ink 디스플레이, 회의실의 저품질 프로젝터 등이 이에 해당합니다. 따라서 강화된 대비 요구사항은 접근성 향상일 뿐 아니라 전반적인 사용성 향상으로도 볼 수 있습니다.

검색 엔진 최적화(SEO) 관점에서 보면, 고대비 텍스트는 더 깔끔하고 구조화된 타이포그래피 계층과 상관관계를 보이는 경향이 있습니다. 검색 엔진이 대비를 직접 측정하지는 않지만, AAA 대비 기준을 충족하기 위해 요구되는 디자인 규율은 일반적으로 더 강한 시각적 계층 구조와 더 나은 가독성 점수를 가진 페이지를 만들어냅니다. 이는 이탈률 감소와 체류 시간 증가로 이어지며, 이러한 신호는 간접적으로 SEO 성능에 도움이 됩니다.

관련 Axe-core 규칙

• color-contrast-enhanced: WCAG 1.4.6과 연관된 기본 axe-core 규칙입니다. 이 규칙은 DOM 내 모든 텍스트 노드의 계산된 전경색과 배경색을 평가하고 WCAG 휘도 공식을 사용해 대비 비율을 계산합니다. 대비 비율이 일반 크기 텍스트의 경우 7:1 미만이거나, 큰 텍스트(계산된 font-size와 font-weight로 정의됨)의 경우 4.5:1 미만인 텍스트 요소를 모두 표시합니다. 이 규칙은 실제 측정된 비율, 요구되는 비율, 문제의 요소를 보고하여 수정 작업을 단순화합니다. 또한 WCAG가 정의한 것과 동일한 크기 기준 — 보통 굵기 18pt(24px), 굵은 글꼴 14pt(18.67px) — 을 사용해 일반 텍스트와 큰 텍스트를 구분합니다.
• 수동 테스트가 필요한 한계점: color-contrast-enhanced와 같은 자동화 규칙은 여러 중요한 상황에서 대비 실패를 감지할 수 없습니다. <canvas> 요소 안에 렌더링된 텍스트는 DOM 기반 스캐너에서 보이지 않으므로 수동 시각 검사가 필요합니다. 그라디언트나 사진 배경 위에 올려진 텍스트는 특히 어려운 과제입니다. 텍스트 뒤에 위치한 그라디언트나 이미지의 어느 부분이냐에 따라 텍스트의 각 글자마다 대비 비율이 달라지기 때문입니다. 자동화 도구는 보통 단일 배경색만 샘플링하거나, 이런 경우에는 결론을 내리지 못하는 결과를 보고합니다. hover나 focus 시 색이 변하는 텍스트는 각 상호작용 상태에서 수동으로 테스트해야 하며, 자동 스캔은 일반적으로 기본 렌더링 상태만 캡처합니다. 또한 JavaScript를 통해 런타임에 해석되는 CSS 커스텀 프로퍼티에 대비가 의존하는 텍스트는 정적 스캔 중에는 평가되지 않을 수 있습니다.

테스트 방법

1. axe DevTools를 사용한 자동 스캔: axe DevTools 브라우저 확장 프로그램(Chrome 또는 Firefox)을 설치합니다. 대상 페이지를 연 뒤 확장 프로그램을 활성화하고 전체 페이지 스캔을 실행합니다. 결과 패널에서 규칙 ID color-contrast-enhanced로 필터링하거나 이슈 목록에서 "enhanced"를 검색합니다. 표시된 각 요소에 대해 패널은 요소, 실제 대비 비율, 요구되는 비율을 보여줍니다. 명확한 통과/실패가 아니라 검토 필요로 보고된 요소를 기록해 두십시오. 이들은 보통 계산된 배경을 해석할 수 없어 수동 검증이 필요한 경우입니다.
2. Lighthouse를 사용한 자동 스캔: Chrome DevTools를 열고 Lighthouse 탭으로 이동한 뒤 접근성 감사(audit)를 실행합니다. Lighthouse는 내부적으로 axe-core를 사용하므로 동일한 color-contrast-enhanced 위반 사항을 표시합니다. 보고서는 이를 Accessibility 섹션 아래에 묶어 보여주며, 각 실패 요소로 연결되는 링크를 제공합니다. Lighthouse는 페이지의 기본 상태만 감사하며 hover나 focus와 같은 상호작용 상태는 테스트하지 않는다는 점에 유의하십시오.
3. 수동 색상 샘플링: 브라우저 개발자 도구의 컬러 피커나 TPGi의 Colour Contrast Analyser와 같은 전용 도구를 사용해 텍스트 요소의 전경색과 배경색을 수동으로 샘플링합니다. 이는 특히 이미지, 그라디언트, 반투명 배경 위의 텍스트에서 중요합니다. 배경이 변하는 텍스트의 여러 지점을 샘플링하고, 샘플링한 모든 지점에서 최소 대비 비율이 일반 텍스트는 7:1, 큰 텍스트는 4.5:1을 충족하는지 확인합니다.
4. 상호작용 상태 테스트: 브라우저 DevTools를 사용해 요소를 hover, focus, active, visited 상태로 강제 전환합니다(Chrome DevTools의 :hov 패널 또는 이에 상응하는 기능 사용). 각 상태에서 대비 검사를 다시 실행하여 CSS 의사 클래스에 의해 적용되는 색상 변경이 대비 실패를 유발하지 않는지 확인합니다. 링크의 방문 상태, 버튼의 hover 상태, 폼 필드의 focus 표시 등에 특히 주의를 기울이십시오.
5. 스크린 리더 검증(NVDA + Firefox): 스크린 리더는 대비를 직접 테스트하지 않지만, NVDA로 텍스트에 접근할 수 있는지 확인하면 해당 텍스트가 대체 텍스트 없는 텍스트 이미지가 아니라 DOM 상의 실제 텍스트임을 확인할 수 있습니다. Firefox를 실행하고 NVDA를 켠 뒤 읽기 커서를 사용해 페이지를 탐색합니다. NVDA가 읽지 못하는 텍스트는 텍스트 이미지인지 조사하고, 그렇다면 이미지 수준에서 대비 테스트가 필요합니다.
6. 스크린 리더 검증(VoiceOver + macOS의 Safari): Command+F5로 VoiceOver를 활성화하고 VO+오른쪽 화살표로 페이지를 탐색합니다. NVDA와 마찬가지로, VoiceOver가 건너뛰거나 잘못 읽는 텍스트는 비표준 텍스트 렌더링을 의미할 수 있으며, 수동 대비 검사가 필요합니다.
7. 그레이스케일 시뮬레이션: 운영체제의 접근성 설정(Windows, macOS, iOS, Android에서 사용 가능)을 통해 그레이스케일 디스플레이 모드를 활성화합니다. 이 모드는 모든 색상 정보를 제거하여 대비 차이를 즉시 드러냅니다. 그레이스케일 모드에서 읽기 어려워지는 텍스트는 거의 확실히 강화된 대비 요구사항을 충족하지 못합니다.

수정 방법

밝은 배경의 본문 텍스트 — 잘못된 예

<!-- Fails 1.4.6: #767676 on #ffffff yields approximately 4.54:1,
     which passes AA (1.4.3) but falls far short of the 7:1 AAA requirement -->
<p style='color: #767676; background-color: #ffffff;'>
  Please review our terms and conditions before proceeding.
</p>

밝은 배경의 본문 텍스트 — 올바른 예

<!-- Passes 1.4.6: #595959 on #ffffff yields approximately 7.0:1,
     meeting the enhanced contrast requirement for normal-weight body text -->
<p style='color: #595959; background-color: #ffffff;'>
  Please review our terms and conditions before proceeding.
</p>

브랜드 배경 위의 색상 헤딩 — 잘못된 예

<!-- Fails 1.4.6: brand blue #4A90D9 on white #ffffff yields approximately 3.0:1.
     Even though this is a heading and may appear large, bold headings at
     common web sizes (e.g. 20px bold) may not qualify as WCAG "large text"
     depending on rendering, and 3.0:1 fails even the large-text 4.5:1 threshold -->
<h2 style='color: #4A90D9; background-color: #ffffff;'>
  Welcome to Our Services
</h2>

브랜드 배경 위의 색상 헤딩 — 올바른 예

<!-- Passes 1.4.6: dark navy #1A3A5C on white #ffffff yields approximately 12.6:1.
     Exceeds the 7:1 requirement for normal text and comfortably surpasses
     the 4.5:1 large-text requirement. Brand identity is preserved through
     the use of a darker shade within the same hue family. -->
<h2 style='color: #1A3A5C; background-color: #ffffff;'>
  Welcome to Our Services
</h2>

그라디언트 배경 위의 텍스트 — 잘못된 예

<!-- Fails 1.4.6: The gradient transitions from a dark color that provides
     adequate contrast on the left to a light color that provides insufficient
     contrast on the right. Text spanning the full width will fail at some point. -->
<div style='background: linear-gradient(to right, #1a1a1a, #cccccc); padding: 20px;'>
  <p style='color: #ffffff;'>Create your account today and get started.</p>
</div>

그라디언트 배경 위의 텍스트 — 올바른 예

<!-- Passes 1.4.6: A semi-transparent dark overlay behind the text ensures
     that foreground text maintains at least 7:1 contrast regardless of
     the underlying gradient value at any point beneath the text block. -->
<div style='background: linear-gradient(to right, #1a1a1a, #cccccc); padding: 20px;'>
  <p style='color: #ffffff; background-color: rgba(0,0,0,0.75); padding: 8px 12px; display: inline-block;'>
    Create your account today and get started.
  </p>
</div>

폼 입력의 플레이스홀더 텍스트 — 잘못된 예

<!-- Fails 1.4.6: default browser placeholder styling is typically around
     #aaaaaa on white, yielding approximately 2.32:1. If placeholder text
     conveys meaningful information (e.g. format hints), it must meet contrast requirements. -->
<input type='text' placeholder='DD/MM/YYYY' style='background: #ffffff;'>

폼 입력의 플레이스홀더 텍스트 — 올바른 예

<!-- Passes 1.4.6: Override the default placeholder color to achieve 7:1 contrast.
     Also adds a visible label as best practice, since placeholders disappear on input. -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' placeholder='DD/MM/YYYY'
  style='background: #ffffff; color: #000000;'>
<style>
  input::placeholder {
    color: #595959; /* approximately 7.0:1 on white — meets AAA */
  }
</style>

자주 발생하는 실수

• AAA 임계값을 확인하지 않고 AA를 통과하는 색상 조합에만 의존하는 경우: 많은 디자이너가 흰색 배경에 흔히 쓰이는 중간 회색 #767676을 사용합니다. 이 조합은 약 4.54:1로 1.4.3을 통과하지만 1.4.6에서는 크게 실패합니다. 항상 4.5:1이 아니라 7:1 목표 대비를 기준으로 검증해야 합니다.
• 큰 텍스트 예외를 지나치게 넓게 적용하는 경우: 큰 텍스트 예외(7:1 대신 4.5:1)는 보통 굵기 18pt(24px) 이상 또는 굵은 글꼴 14pt(18.67px) 이상인 텍스트에만 적용됩니다. 20px 보통 굵기 텍스트는 여기에 해당하지 않으며 여전히 7:1을 충족해야 합니다.
• 상호작용 상태에서의 대비를 무시하는 경우: 시각적 어포던스를 만들기 위해 hover 시 더 밝은 색을 적용하면서, hover 상태에서도 7:1을 유지하는지 확인하지 않는 경우입니다. 예를 들어, hover 시 버튼 배경을 더 어둡게 하고 텍스트를 흰색으로 유지하는 것은 여전히 통과할 수 있지만, hover 시 텍스트를 더 밝게 만드는 것은 자주 실패를 유발합니다.
• CSS 커스텀 프로퍼티 체인을 간과하는 경우: 텍스트 색상을 전역으로 설정된 --color-primary를 사용하는 var(--color-primary)로 정의해 놓고, 컴포넌트 범위에서 이를 재정의하면서 대비를 다시 검증하지 않는 경우입니다. 실제 렌더링되는 색상은 전역 토큰 값과 다를 수 있으며, 특정 컴포넌트 문맥에서 실패 비율을 만들 수 있습니다.
• 비활성 상태 예외를 디자인 면허처럼 사용하는 경우: 비활성 UI 예외를 근거로 비활성 요소를 1:1 대비(보이지 않는 텍스트)로 스타일링하여 사용자가 해당 필드의 존재를 전혀 알 수 없게 만드는 경우입니다. 비활성 요소는 7:1 요구사항에서 예외일 수는 있지만, 여전히 시각적으로 인지 가능해야 합니다.
• 이미지나 비디오 위에 렌더링된 텍스트를 테스트하지 않는 경우: 히어로 이미지나 비디오 배경 위에 텍스트를 직접 배치하고, 텍스트가 지나가는 이미지의 가장 밝은 부분이 아니라 평균 색상만 기준으로 대비를 확인하는 경우입니다. 최소 대비는 평균이 아니라 텍스트 아래의 모든 픽셀에서 유지되어야 합니다.
• 대비 수정 사항을 데스크톱 브레이크포인트에만 적용하는 경우: 반응형 디자인에서 모바일 브레이크포인트에 다른 배경색을 사용하는 경우 — 예를 들어 데스크톱에서는 흰색 배경을 사용하다가 모바일에서는 연한 베이지 카드 배경으로 전환하는 경우 — 데스크톱 테스트에서는 없던 새로운 대비 실패가 작은 화면에서 발생할 수 있습니다.
• 포커스 표시 상태의 텍스트 대비를 잊는 경우: 커스텀 포커스 링이나 포커스 상태에서 포커스된 요소의 배경과 텍스트 색상이 모두 변경되는 경우, 포커스 상태의 새로운 텍스트-배경 조합은 기본 상태와 무관하게 독립적으로 7:1 비율을 충족해야 합니다.
• 로고 예외가 인접한 설명 텍스트에도 확장된다고 가정하는 경우: 브랜드 로고와 같은 타이포그래피 블록 안에 태그라인이나 제품 설명을 배치하고, 전체 블록에 로고 예외를 적용하려는 경우입니다. 예외는 로고 자체의 필수적인 일부인 텍스트에만 엄격히 적용되며, 주변 카피에는 적용되지 않습니다.
• CSS 프레임워크 오버라이드 이후 대비를 검증하지 않는 경우: 서드파티 컴포넌트 라이브러리나 CSS 프레임워크를 도입하면서 텍스트 색상을 7:1 미만 값으로 리셋하거나 오버라이드하고, 이를 감사 없이 그대로 배포하는 경우입니다. 프레임워크 기본값은 거의 AAA 대비 기준에 맞춰져 있지 않습니다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 활동하는 광범위한 기관과 조직에 대해 의무적인 디지털 접근성 요구사항을 수립합니다. 이 대통령령은 WCAG 2.2 AA 레벨 준수를 기본 표준으로 요구합니다. 적용 대상에는 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 의료 기관, 가입자 200,000명 이상인 통신 회사, 여행사, 민간 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받은 사립 학교가 포함됩니다.

WCAG 1.4.6 대비(향상)는 AAA 레벨 기준이므로 대통령령에 따른 의무 요구사항은 아닙니다. 법적으로 요구되는 AA 레벨만을 달성한 조직은, 기준 1.4.3에서 정의한 일반 텍스트 4.5:1 AA 임계값을 충족하는 한, 7:1 강화 대비 요구사항을 생략하더라도 대통령령을 위반한 것이 아닙니다.

그러나 대비에서 AAA 준수에 도달하는 것은 최소한의 법적 준수를 훨씬 넘어서는 포괄적 디자인에 대한 의미 있는 의지를 보여줍니다. 장애 여부와 관계없이 모든 시민을 대상으로 가장 넓은 봉사 의무를 지는 공공 기관의 경우, 강화된 대비 기준을 자발적으로 채택하는 것은 진정한 보편적 접근에 대한 헌신을 나타냅니다. 환자가 이미 신체적 또는 인지적 스트레스를 받고 있거나, 밝은 임상 조명과 같은 까다로운 환경에서 디지털 시스템과 상호작용할 수 있는 의료 기관과 병원은 최소 대비 임계값을 초과해야 할 실질적인 이유가 특히 강합니다. 마찬가지로, 고객층에 고령 사용자가 점점 더 많이 포함되는 은행 및 금융 서비스 제공자는 AAA 대비 준수가 전달하는 신뢰성과 사용자 신뢰에서 큰 이점을 얻을 수 있습니다.

ISO 30071-1 인증, 유럽 EN 301 549 정렬, 또는 접근성 성숙도를 평가하는 국제 조달 프로세스를 추구하는 조직은 AAA 레벨 대비 준수가 자사의 입지를 강화하는 것을 확인하게 될 것입니다. 전 세계적으로, 그리고 특히 터키에서 디지털 접근성 집행이 성숙해짐에 따라, 현재 AAA 레벨에 있는 기준들이 후속 규제 업데이트에서 의무 기준으로 이동해 온 역사가 있습니다. 지금 강화된 대비를 도입하는 것은 조직이 향후 요구사항보다 한발 앞서 나가도록 하며, 나중에 수정하는 데 드는 비용을 줄여 줍니다.

Accsible 오버레이 SDK를 사용하는 조직의 경우, 플랫폼의 대비 조정 도구는 위젯 수준에서 고대비 모드를 적용할 수 있도록 도와주어, 게시된 디자인의 대비 수준과 개별 사용자의 요구 사이의 격차를 메우는 보완 레이어를 제공합니다. 이는 소스 코드 수준에서 기준을 충족하는 것을 대체하지는 않지만, 강화된 대비가 필요하지만 아직 완전한 AAA 준수에 도달하지 못한 사이트를 방문하는 사용자에게 의미 있는 런타임 지원을 제공합니다.