WCAG 1.4.11: 비텍스트 대비

이 규칙의 의미

WCAG 1.4.11 비텍스트 대비(Non-text Contrast)는 WCAG 2.1에서 도입되어 WCAG 2.2로 이어지는 레벨 AA 기준이다. 이 기준은 다음 두 가지 범주의 콘텐츠와 그에 인접한 색상 사이에 최소 3:1의 대비 비율을 요구한다.

• 사용자 인터페이스(UI) 구성 요소: 텍스트 입력, 체크박스, 라디오 버튼, 토글 스위치, 드롭다운 메뉴, 버튼 등과 같은 인터랙티브 컨트롤을 식별하는 시각적 경계 또는 표시 요소. 구성 요소 자체와 모든 시각적 상태 변화(예: hover, focus, 선택됨, 오류 상태)를 모두 포함한다.
• 그래픽 객체: 콘텐츠를 이해하는 데 필요한 아이콘, 차트, 다이어그램 및 기타 의미 있는 이미지의 일부. 정보를 전달하는 그래픽의 각 부분은 주변 색상에 대해 3:1 기준을 충족해야 한다.

대비 비율은 전경 요소와 그에 바로 인접한 색상(일반적으로 배경색, 테두리 색 또는 차트의 인접 구역) 사이에서 측정된다. 계산에는 WCAG 1.4.3에서 정의된 동일한 상대 휘도 공식이 사용되지만, 비텍스트 요소는 약간 낮은 대비로도 식별 가능하므로 임계값은 4.5:1이 아닌 3:1이다.

통과란 UI 구성 요소를 식별하거나 그래픽에서 정보를 전달하는 모든 시각적 표시가 최소 3:1의 대비 비율을 달성하는 경우를 의미한다. 실패는 테두리, 아이콘의 선(stroke), 차트 구간, 상태 표시 등이 이 비율보다 낮아지고, 그 시각적 정보 없이는 구성 요소나 그래픽을 식별하거나 이해할 수 없는 경우에 발생한다.

WCAG 명세는 몇 가지 중요한 예외를 정의한다.

• 비활성 구성 요소: 비활성화되어 상호작용이 불가능한 UI 구성 요소는 예외이다. 클릭할 수 없는 회색 처리된 버튼은 대비 요구 사항을 충족할 필요가 없다.
• 사용자 에이전트가 제어하는 표현: 시각적 표현이 브라우저의 기본 스타일에 전적으로 의해 결정되고(작성자의 CSS로 재정의되지 않은) 있는 구성 요소는 예외이다. 이 경우 책임은 브라우저 벤더에게 있다.
• 본질적 또는 장식적 그래픽: 특정한 표현 방식이 전달되는 정보에 본질적인 그래픽(예: 국가를 나타내는 국기) 또는 순수하게 장식적인 그래픽은 예외이다. 로고 역시 일반적으로 이 조항에 따라 예외로 간주된다.
• 텍스트: 텍스트와 텍스트 이미지(Images of text)는 이미 1.4.3과 1.4.6에 의해 다루어지므로 1.4.11의 적용 대상이 아니다.

포커스 표시자는 WCAG 2.2에서 특히 중요한 요소이다. 기준 2.4.11(포커스 외형, Focus Appearance)은 포커스 가시성에 대한 더 엄격한 요구 사항을 추가하지만, 1.4.11은 여전히 커스텀 포커스 링과 배경 사이의 대비에 적용된다. 포커스 표시자로 사용되는 커스텀 outline 또는 box-shadow는 이 기준을 독립적으로 충족하기 위해 인접 색상에 대해 3:1 대비를 달성해야 한다.

중요한 이유

세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있다. 이들 중 상당수 — 중등도에서 중증 시력 손실을 겪는 것으로 추정되는 2억 5,300만 명을 포함해 — 는 화면 읽기 도구를 반드시 사용하지 않더라도 디지털 인터페이스를 인지하고 상호작용하기 위해 충분한 대비에 의존한다. 확대 소프트웨어, 고대비 모드, 혹은 단순히 열악한 조명 환경에서 웹을 이용하는 저시력 사용자는 1.4.11 실패의 직접적인 영향을 가장 많이 받는 집단에 속한다.

실제 상황을 생각해 보자. 녹내장을 가진 사용자가 병원 웹사이트에서 보험 청구서를 작성하고 있다. 폼 필드는 흰색 배경(#ffffff) 위에 연한 회색 테두리(#cccccc)를 사용하고 있으며, 이 조합의 대비 비율은 1.6:1에 불과해 요구되는 3:1에 한참 못 미친다. 사용자는 입력 필드의 시작과 끝을 볼 수 없기 때문에, 필드를 정확히 클릭하거나 폼의 구조를 이해할 수 없다. 결국 폼 작성을 완전히 포기하게 되고, 이는 개인적인 손실일 뿐 아니라 기관에 법적 책임을 초래할 수 있다.

시각 장애뿐 아니라 인지 장애 역시 대비가 낮은 UI 구성 요소를 해석하기 어렵게 만들 수 있다. 주의력 장애나 정보 처리에 어려움이 있는 사용자는 인터랙티브 요소와 비인터랙티브 요소 사이의 강한 시각적 구분에 의존해 페이지 구조를 빠르게 이해한다. 마찬가지로, 떨림이나 운동 장애가 있어 큰 포인터 타깃을 사용하는 사용자도 컨트롤의 경계를 명확히 볼 수 있어야 정확히 조준할 수 있다.

비즈니스 관점에서 보면, 1.4.11을 준수하면 모든 사용자가 비최적 환경 — 모바일 화면의 강한 햇빛, 저품질 모니터, 색 정확도가 떨어지는 오래된 디스플레이 — 에서도 더 쉽게 서비스를 이용할 수 있다. 이는 지원 비용을 줄이고, 도달 가능한 사용자층을 넓히며, 사용성이 떨어져 발생하는 이탈률을 낮춤으로써 간접적으로 SEO를 강화한다. 법적 접근성 의무를 지는 조직의 경우, 레벨 AA에서 이 기준을 충족하지 못하면 직접적인 컴플라이언스 리스크가 된다.

관련 Axe-core 규칙

• color-contrast (부분 적용): axe-core의 color-contrast 규칙은 주로 WCAG 1.4.3에 따른 텍스트 대비를 대상으로 하지만, 특정 상황에서 비텍스트 요소에 대한 부분적인 검사도 수행한다. axe는 구성 요소의 시각적 경계나 배경이 3:1 비율을 충족하지 못하는 것이 프로그래밍적으로 판단 가능한 경우 버튼이나 폼 컨트롤과 같은 UI 구성 요소를 플래그한다. 그러나 비텍스트 요소의 많은 대비 실패는 자동 분석으로는 보이지 않기 때문에, 이 규칙의 1.4.11에 대한 적용 범위는 명시적으로 부분적(partial)으로 표시된다. 예를 들어, SVG 아이콘의 선(stroke)과 배경 사이의 대비나, CSS 의사 요소로 구현된 커스텀 스타일 체크박스의 테두리 대비는 렌더링 컨텍스트 없이는 DOM에서 신뢰할 수 있게 추출할 수 없다. CSS 테두리의 계산된 스타일은 접근성 트리에 존재할 수 있지만, 인접 배경 — 특히 그 배경이 그라디언트, 이미지, 겹치는 요소인 경우 — 은 항상 프로그래밍적으로 계산 가능한 것은 아니다. 이런 이유로 axe는 많은 경우 1.4.11 위반을 color-contrast 규칙 아래에서 needs review 표시와 함께 보고한다. 이는 도구가 잠재적인 문제를 감지했지만, 실제 렌더링된 픽셀을 샘플링하기 위해 색 대비 분석 도구를 사용하고 사람이 직접 요소를 시각적으로 확인해야 함을 의미한다.

자동화 도구는 비텍스트 대비 실패의 일부만 감지할 수 있기 때문에 수동 테스트가 필수적이다. Colour Contrast Analyser(TPGi), 브라우저 DevTools의 컬러 피커, Accessible Colors와 같은 도구를 사용해 렌더링된 인터페이스에서 전경색과 배경색을 직접 샘플링해야 한다. 자동 스캔은 포괄적인 감사가 아니라 1차 점검으로 취급해야 한다.

테스트 방법

1. axe DevTools 또는 Lighthouse로 자동 스캔 실행: axe DevTools 브라우저 확장 프로그램을 설치하고 전체 페이지 스캔을 실행한다. 결과 패널에서 WCAG 1.4.11 태그가 붙은 이슈를 필터링하거나 모든 color-contrast 위반을 검토한다. 비텍스트 대비 카테고리에서 Needs Review로 표시된 항목을 기록하는데, 이 항목들은 수동 후속 조치가 필요하다. Lighthouse(Chrome DevTools > Lighthouse 탭)에서는 접근성(Accessibility) 감사를 실행하고 대비 관련 결과를 검토하되, Lighthouse 역시 비텍스트 요소에 대해서는 부분적인 적용만 한다는 점을 염두에 둔다.
2. 색 대비 분석 도구를 사용한 수동 검사: TPGi Colour Contrast Analyser 데스크톱 애플리케이션을 다운로드해 실행한다. 스포이트 도구를 사용해 각 UI 구성 요소 경계(예: 텍스트 입력의 테두리, 아이콘의 선, 차트 막대의 채움 색)의 전경색을 샘플링한 뒤, 인접 배경색을 샘플링한다. 도구는 계산된 대비 비율을 표시한다. 3:1 미만의 비율은 모두 실패이다. 모든 인터랙티브 폼 컨트롤, 아이콘만 있는 버튼, 포커스 표시자, 데이터 시각화를 체계적으로 점검한다.
3. 키보드 내비게이션 및 포커스 표시자 테스트: 키보드만 사용해 페이지 전체를 Tab 키로 이동한다. 포커스를 받는 각 인터랙티브 요소에 대해 포커스 표시자(링, outline, 배경 변화)가 보이는지 확인한다. 대비 분석 도구를 사용해 포커스 표시자 색상이 요소의 배경에 대해 3:1 대비를 달성하는지 확인한다. NVDA + Firefox, JAWS + Chrome에서 테스트해 요소가 예상 순서대로 포커스를 받고, CSS outline: none으로 인해 시각적 표시가 제거되었는데 동등한 대체 스타일이 제공되지 않은 것은 아닌지 확인한다.
4. 고대비 및 강제 색상 모드에서 테스트: Windows에서 고대비 모드(설정 > 접근성 > 고대비)를 활성화하고 페이지를 다시 로드한다. Chromium 기반 브라우저에서는 DevTools를 열고 Rendering 패널로 이동해 Emulate CSS media feature forced-colors: active 옵션을 활성화한다. UI 구성 요소의 경계가 여전히 보이는지 확인한다. 강제 색상 모드 준수는 1.4.11의 엄격한 요구 사항은 아니지만, 이 모드에서 테스트하면 낮은 대비의 색상 신호에만 의존하는 요소를 드러낼 수 있다.
5. 문맥 속에서 그래픽 객체 확인: 각 차트, 아이콘, 다이어그램, 정보 제공용 이미지에 대해 의미를 전달하는 모든 구간 또는 경로를 식별한다. 그래픽 내부에서 인접 색상(예: 서로 인접한 파이 차트 구간)과 주변 페이지 배경에 대해 스포이트 도구로 색을 샘플링한다. 정보를 전달하는 각 개별 부분은 각각 3:1을 달성해야 한다.
6. 모든 구성 요소 상태 확인: 인터랙티브 요소는 기본, hover, focus, active, 선택됨, 체크됨, 오류, 성공 등 여러 상태를 가진다. 각 상태를 별도로 테스트한다. 기본 상태에서 통과하는 버튼 테두리가 hover 상태에서 대비가 낮은 색으로 바뀌어 실패할 수 있다.

수정 방법

폼 입력 테두리 — 잘못된 예

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

폼 입력 테두리 — 올바른 예

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

아이콘만 있는 버튼 — 잘못된 예

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

아이콘만 있는 버튼 — 올바른 예

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

커스텀 체크박스 — 잘못된 예

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

커스텀 체크박스 — 올바른 예

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

데이터 차트 — 잘못된 예

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

데이터 차트 — 올바른 예

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

자주 발생하는 실수

• 3:1을 충족하지만 저해상도(DPI)에서 보이지 않게 되는 1픽셀 테두리 사용: 색상 자체는 기준을 충족하더라도, 테두리가 저해상도 화면에서 1px에 불과하면 사실상 보이지 않을 수 있다. 경계가 물리적으로 인지 가능하도록 border: 2px solid나 눈에 띄는 box-shadow를 대비를 충족하는 색상과 함께 사용한다.
• 배경이 항상 흰색이라고 가정: 폼 필드나 아이콘이 연한 회색 배경(#f5f5f5)의 카드나 사이드바 안에 있을 경우, 대비는 흰색이 아니라 그 회색에 대해 측정해야 한다. 흰색에서는 통과하는 테두리가 톤이 있는 배경에서는 실패할 수 있다.
• outline: none으로 기본 포커스 outline을 제거하고 동등한 대체를 제공하지 않음: 이는 가장 흔한 1.4.11 실패 중 하나이다. 전역적으로 :focus { outline: none; }을 설정하면 키보드 사용자의 포커스 가시성이 완전히 사라진다. 항상 배경에 대해 최소 3:1 대비를 달성하는 커스텀 포커스 스타일로 대체해야 한다.
• 비활성 상태를 모든 대비 검사를 생략할 구실로 사용하는 것: 비활성 구성 요소는 예외이지만, 개발자가 실제로 disabled 속성이나 aria-disabled='true'를 추가하지 않고 낮은 대비 스타일만으로 요소를 시각적으로 비활성처럼 보이게 만드는 경우가 있다. 비활성처럼 보이지만 여전히 인터랙티브한 요소는 여전히 1.4.11을 통과해야 한다.
• 분리 선 없이 색상만으로 차트 구간을 구분: 인접한 두 차트 구간이 색조(예: 연한 파란색 vs 연한 초록색)만 다르고 대비 비율이 3:1 미만이면 실패할 수 있다. 두 구간 사이에 2px 흰색 또는 어두운 분리 선을 추가하는 것이 신뢰할 수 있는 해결책이다.
• 기본 상태에만 대비 수정 적용 후 hover, focus, 오류, 성공 상태를 잊는 것: 각 인터랙티브 상태는 고유한 시각적 표현을 가진다. 기본 상태에서 통과하는 버튼 테두리가 hover 상태에서 대비가 낮은 색으로 바뀔 수 있다. 모든 상태를 독립적으로 테스트해야 한다.
• 아이콘을 background-image로 임베드하고 CSS 색상에 대비를 의존: HTML에 인라인된 SVG 아이콘은 color와 currentColor에 반응하지만, CSS background-image로 사용되는 아이콘은 CSS로 재색칠할 수 없다. 아이콘 이미지 파일 자체의 대비가 부족하다면, 에셋을 교체하지 않고는 어떤 CSS 수정으로도 문제를 해결할 수 없다.
• 입력 필드의 placeholder 텍스트가 1.4.11의 대상이 아니지만 여전히 규제된다는 점을 잊는 것: placeholder 텍스트는 1.4.11이 아니라 1.4.3(텍스트 대비 4.5:1)에 해당한다. 개발자가 placeholder 텍스트에 3:1 기준을 잘못 적용해, 별도의 1.4.3 실패를 눈치채지 못한 채 만들기도 한다.
• 비준수 중간 색상을 거치는 CSS 트랜지션 사용: 요소가 통과하는 색상에서 시작해 실패하는 중간 색상을 거쳐 다시 통과하는 색상으로 애니메이션될 수 있다. 시작과 끝 상태가 기준을 충족하더라도, 트랜지션 중에는 시각적 구성 요소가 기술적으로 비준수 상태가 된다. prefers-reduced-motion 미디어 쿼리를 신중히 사용하고, 트랜지션이 낮은 대비 상태를 거치지 않도록 한다.
• 프로그레스 바, range 입력, 토글 스위치를 무시: 이러한 커스텀 UI 구성 요소는 1.4.11을 고려하지 않고 스타일링되는 경우가 많다. 프로그레스 바의 채워진 부분은 트랙에 대해 3:1 대비를 가져야 하고, 토글의 노브는 토글 배경에 대해 대비를 가져야 하며, range 입력의 thumb는 트랙에 대해 대비를 가져야 한다.

터키 접근성 규정과의 관계

터키의 2025/10번 대통령 공고(Presidential Circular No. 2025/10)는 2025년 6월 21일 관보(Official Gazette) 제32933호에 게재되었으며, 터키에서 활동하는 광범위한 공공 및 민간 기관에 대해 웹 및 모바일 접근성 의무를 규정한다. 이 공고는 WCAG 2.2를 규범적 기술 표준으로 채택하고 있으며, 레벨 AA 준수가 요구되는 최소 기준이다.

레벨 AA 기준인 WCAG 1.4.11 비텍스트 대비는 따라서 이 공고에 따라 직접적으로 집행 대상이 된다. 규제 대상 조직은 디지털 자산의 모든 UI 구성 요소 경계, 인터랙티브 컨트롤 상태, 의미 있는 그래픽 객체가 3:1 비텍스트 대비 요구 사항을 충족하도록 보장해야 한다.

2025/10번 대통령 공고의 적용 대상에는 모든 수준의 정부 공공 기관과 조직, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 민간 학교가 포함된다. 이들 조직에게 1.4.11을 구현하지 않는 것은 단순한 모범 사례 미준수가 아니라 규제 비준수에 해당한다.

가족사회서비스부가 발급하는 접근성 로고(Erişilebilirlik Logosu)는 준수하는 디지털 서비스에 대한 대외적인 인증 마크 역할을 한다. 이 로고를 획득하고 표시하기 위해서는 조직이 1.4.11을 포함한 모든 적용 가능한 WCAG 2.2 기준에 대해 레벨 AA를 완전히 준수하고 있음을 입증해야 한다. 많은 터키 전자정부 포털, 뱅킹 인터페이스, 의료 관련 폼이 커스텀 스타일의 폼 컨트롤과 데이터 시각화를 광범위하게 사용하고 있기 때문에, 비텍스트 대비는 인증 과정에서 감사자가 특히 중점적으로 평가할 가능성이 높은 기준이다.

Accsible 오버레이 위젯을 사용하는 조직은 오버레이 기술이 사용자가 고대비 테마를 활성화할 수 있게 하는 등 일부 런타임 대비 조정을 보완하는 데 도움을 줄 수 있지만, 1.6:1 테두리 대비로 렌더링되는 폼 입력처럼 구조적인 지속적 실패는 진정한 준수와 Erişilebilirlik Logosu 획득을 위해 소스 코드 수준에서 수정되어야 한다는 점을 인지해야 한다. 소스 수준 수정과 접근성 위젯의 사용자 지향 향상 기능을 결합하는 것이 터키 법 아래에서 가장 방어 가능한 컴플라이언스 전략이다.