WCAG 성공 기준 · Level A
WCAG 1.4.1: 색 사용
WCAG 1.4.1은 정보 전달, 동작 표시, 반응 유도, 시각적 요소 구분에 있어 색상이 결코 유일한 수단이 되어서는 안 된다고 요구합니다. 이 기준은 색상 차이를 인지할 수 없는 사용자(색각 이상이나 저시력을 가진 사람들을 포함하여)도 모든 콘텐츠와 기능에 여전히 접근할 수 있도록 보장합니다.
- Level A
- Wcag
- Wcag 2 2 a
- 지각 가능
- 접근성
이 규칙의 의미
WCAG 1.4.1 색 사용은 인지 가능(Perceivable) 원칙 아래의 레벨 A 기준이다. 이 기준은 정보 전달, 동작 표시, 반응 유도, 시각적 요소 구분에 있어 색이 유일한 시각적 수단으로 사용되어서는 안 된다고 규정한다. 여기서 핵심 단어는 "유일한(only)"이다. 색 사용이 금지되는 것은 아니지만, 항상 텍스트 레이블, 패턴, 모양, 테두리, 아이콘, 타이포그래피 처리 등 최소 한 가지 이상의 추가 시각적 단서와 함께 사용되어야 하며, 사용자가 색 차이를 인지할 수 있는지 여부와 관계없이 동일한 정보에 접근할 수 있어야 한다.
이 기준은 매우 다양한 인터페이스 요소를 포괄한다. 오류를 표시하기 위해 빨간색으로만 변하는 폼 입력은, 빨간색이 유일한 표시라면 이 기준을 충족하지 못한다. 데이터 시리즈를 구분하기 위해 색만 사용하는 차트와 그래프도 이 기준을 충족하지 못한다. 본문 텍스트 블록 안에서 밑줄, 볼드, 기타 색 이외의 구분 요소 없이 색만 다르게 스타일링된 링크 역시 이 기준을 충족하지 못한다. 내비게이션 상태, 상태 배지, 진행 표시, 필수 필드 표시, 인터랙티브 어포던스 등도 모두 범위에 포함된다.
기준을 충족하는 구현은 색과 함께 최소 한 가지 이상의 비색(非色) 메커니즘을 제공한다. 예를 들어, 빨간색 테두리로 표시된 오류 필드에 오류 아이콘과 설명 텍스트 레이블을 함께 제공하는 경우, 서로 다른 색과 패턴 채우기를 모두 사용하는 파이 차트, 본문 텍스트 안에서 색이 다를 뿐 아니라 밑줄도 있는 링크 등이 있다. 기준을 충족하지 못하는 구현은 색 변화에만 의존하며, 동일한 의미를 전달하는 모양, 테두리, 패턴, 레이블, 텍스트 차이가 존재하지 않는다.
WCAG 명세에는 중요한 범위 설명이 있다. 이 기준은 정보를 전달하는 시각적 수단으로서의 색에만 구체적으로 적용된다. 모든 색을 제거할 것을 요구하지 않으며, 명도 대비 비율은 다루지 않는다. 대비 비율은 1.4.3과 1.4.11에서 다룬다. 또한 색이 정보적 의미를 갖지 않는 로고나 장식용 이미지에는 적용되지 않는다. 이 기준은 사용자가 둘 이상의 색을 구분할 수 없을 때 정보나 기능에 대한 접근을 잃게 되는 상황에만 엄격하게 적용된다.
왜 중요한가
전 세계적으로 약 3억 명이 어떤 형태로든 색각 이상(색맹)을 가지고 있으며, 세계보건기구(WHO)에 따르면 22억 명이 근거리 또는 원거리 시력 손상을 가지고 있다. 북유럽계 인구의 경우 색맹은 남성 약 12명 중 1명, 여성 약 200명 중 1명에게 영향을 미치며, 이는 100명으로 구성된 일반적인 사용자 집단에서 대략 5–8명 정도가 빨간색과 초록색을 신뢰할 수 있게 구분하지 못한다는 의미이다. 빨간색과 초록색은 인터페이스에서 성공과 실패를 구분하는 데 가장 흔히 사용되는 색 조합 중 하나다.
제2색맹(Deuteranopia)이나 제1색맹(Protanopia)과 같은 적록색맹을 가진 사용자에게, 유효하지 않은 필드를 빨간색으로만 강조하는 폼은 오류 표시로서 사실상 보이지 않는 것과 같다. 이들은 폼을 제출한 뒤 눈에 띄는 변화가 없다고 느끼고, 시스템이 고장 났다고 생각하거나 제출이 정상적으로 처리되었다고 결론 내린다. 이는 사소한 불편이 아니라, 금융 거래 실패, 의료 예약 누락, 정부 서비스 신청 실패, 전자상거래 결제 완료 불가 등으로 이어질 수 있다.
고대비 디스플레이나 사용자 지정 색 구성표에 의존하는 저시력 사용자는 시스템 수준의 색 재정의 기능을 활성화해 두었을 수 있다. 이런 환경에서는 작성자가 지정한 색이 완전히 대체될 수 있으며, 이 경우 사용자가 색을 인지할 수 있는지 여부와 관계없이 색만으로 제공되는 단서는 의미를 잃는다. 마찬가지로 문서를 흑백으로 인쇄하거나 단색 e-ink 디스플레이에서 콘텐츠에 접근하는 사용자도 모든 색 구분을 잃게 된다.
장애를 넘어, 이 기준은 더 넓은 사용자층에 이익을 준다. 강한 햇빛 아래 야외에서 모바일을 사용하는 사용자, 색 재현력이 떨어지는 저품질 화면을 사용하는 사용자, 나이가 들면서 자연스럽게 색 지각 능력이 저하되는 고령 사용자 등이 그 예다. 접근 가능한 색 사용은 간접적으로 SEO에도 도움이 된다. 이 기준을 충족하기 위해 추가되는 설명 텍스트 레이블은 검색 엔진이 인덱싱할 수 있는 추가 의미 정보를 제공하기 때문이다. 사용성 측면에서 볼 때, 색과 함께 제공되는 명시적인 텍스트 레이블과 시각적 단서는 인터페이스의 의미를 중복·강화하여 모든 사용자의 인지 부담을 줄여 준다.
관련 Axe-core 규칙
WCAG 1.4.1은 색이 정보 전달의 유일한 수단으로 사용되는지 여부를 자동화 도구가 신뢰할 수 있게 판단할 수 없기 때문에 수동 테스트가 필요하다. 이는 의미론적이면서 시각적인 판단이다. 자동화 도구는 두 요소의 색이 다르다는 사실은 감지할 수 있지만, 그 색이 유일한 구분 요소인지, 또는 그 색 차이가 전달하는 정보가 다른 메커니즘으로도 전달되는지 여부는 판단할 수 없다. 이를 판단하려면 도구가 디자인 의도와 전체 시각적 렌더링 맥락을 이해해야 한다.
- 수동 테스트 필요 — 링크 색 구분: Axe-core는 본문 텍스트 내의 링크가 주변의 비링크 텍스트와 색 이외의 수단으로 구분 가능한지 자동으로 검증할 수 없다. 사람 테스트 담당자가 페이지를 시각적으로 검사하여, 문단 내에 인라인으로 나타나는 링크에 밑줄, 볼드, 눈에 보이는 아이콘 등 색 이외의 추가 단서가 있는지 확인해야 한다. 자동화 도구는 링크의 존재는 감지할 수 있지만, 그 시각적 표현이 색조 차이에만 의존하는지는 알 수 없다.
- 수동 테스트 필요 — 폼 오류 상태: 폼 필드가 오류 상태에 들어갈 때, 자동화 도구는 빨간색 테두리나 배경과 같은 시각적 변화가 오류를 나타내는 유일한 표시인지, 아니면 오류 아이콘, 텍스트 메시지, 기타 비색 단서가 함께 제공되는지 판단할 수 없다. 테스트 담당자가 폼과 상호작용하여 검증 오류를 발생시키고, 오류가 시각적으로 어떻게 전달되는지 확인해야 한다.
- 수동 테스트 필요 — 데이터 시각화: 색을 사용해 범주, 데이터 시리즈, 영역을 구분하는 차트, 그래프, 지도, 다이어그램은 1.4.1 준수 여부를 자동으로 평가할 수 없다. 사람 테스트 담당자가 패턴, 레이블, 텍스처 등이 색으로 구분된 요소를 차별화하기 위해 함께 제공되는지 평가해야 한다.
- 수동 테스트 필요 — 상태 표시: 온라인/오프라인 표시나 주문 상태 레이블과 같은 배지, 태그, 상태 표시가 색에만 의존해 상태를 전달하는 경우 자동으로 탐지할 수 없다. 테스트 담당자는 각 상태가 텍스트 레이블, 아이콘, 모양 변화 등으로도 전달되는지 확인해야 한다.
테스트 방법
- 자동 스캔 기준선: 페이지에서 axe DevTools, Lighthouse, 또는 Accsible 접근성 검사기를 실행한다. 이 도구들은 1.4.1 위반을 직접 표시하지는 않지만, 색만 사용되는 경우와 상관관계가 있는 대체 텍스트 누락, 대비 부족, 폼 레이블 누락 등의 관련 문제를 찾아낼 수 있다. 표시된 문제를 기록하고 수동 점검의 출발점으로 사용한다. axe DevTools에서는 브라우저 확장 프로그램을 열고 "Analyze"를 클릭한 뒤, 위반 목록뿐 아니라 "Needs Review" 범주도 함께 검토한다. 일부 색 관련 문제가 이 범주에 표시될 수 있다.
- 그레이스케일 시뮬레이션: 브라우저 확장 프로그램이나 운영체제의 접근성 기능을 사용해 페이지를 그레이스케일(채도 0)로 본다. macOS에서는 시스템 설정 > 손쉬운 사용 > 디스플레이로 이동해 "그레이스케일 사용"을 활성화한다. Windows에서는 설정 > 접근성 > 색 필터로 이동해 "그레이스케일"을 선택한다. 또는 브라우저 DevTools를 사용할 수 있다. Chrome에서 DevTools를 열고 Ctrl+Shift+P(또는 Mac에서는 Cmd+Shift+P)를 누른 뒤 "Emulate vision deficiencies"를 입력하고 "Achromatopsia"를 선택한다. 그레이스케일 상태에서 모든 인터랙티브 요소, 상태 표시, 폼 필드, 차트, 링크를 검토하고, 색 없이도 모든 정보가 이해 가능한지 확인한다.
- 색맹 시뮬레이션: Chrome DevTools의 시각 장애 에뮬레이터(위와 동일한 경로)를 사용해 Deuteranopia, Protanopia, Tritanopia를 시뮬레이션한다. 각 시뮬레이션에 대해, 오류가 있는 폼 제출, 차트에서 데이터 해석, 활성/비활성 상태 간 내비게이션 등 모든 사용자 흐름을 따라가며 정보 손실이 없는지 확인한다. Coblis Color Blindness Simulator나 Colour Oracle(데스크톱 애플리케이션)과 같은 도구를 사용해 전체 화면에 색맹을 시뮬레이션할 수도 있다.
- 본문 텍스트 내 링크 — 수동 점검: 내비게이션 메뉴나 독립된 링크 목록이 아닌, 본문 문단 안에 나타나는 모든 하이퍼링크를 식별한다. 각 링크에 대해, 최소 한 가지 이상의 비색 메커니즘으로 주변 비링크 텍스트와 시각적으로 구분되는지 확인한다. 가장 일반적인 허용 메커니즘은 밑줄이다. 링크가 색 차이에만 의존한다면 이는 실패다.
- 폼 검증 — 수동 점검: 키보드 내비게이션(Tab으로 포커스 이동, Enter 또는 Space로 컨트롤 활성화)을 사용해 폼을 작성하면서 일부 필수 필드를 의도적으로 비워 두거나 잘못된 데이터를 입력한다. 폼을 제출한 뒤, 오류가 어떻게 전달되는지 시각적으로 검사한다. 오류 표시가 색만으로 제공되지 않는지 확인해야 하며, 각 오류에는 색 변화와 함께 눈에 보이는 텍스트 설명, 아이콘 또는 둘 다가 있어야 한다.
- 스크린 리더 검증(NVDA + Firefox): Firefox에서 NVDA를 실행한 상태로 페이지를 연다. 가상 커서를 사용해 모든 폼 필드, 차트, 상태 표시를 탐색한다. 스크린 리더가 오류 메시지, 상태 레이블, 데이터 설명을 읽어 주는지 확인한다. 이는 프로그램적 계층을 검증하는 것이며, 시각적 색맹 사용자를 위한 1.4.1의 시각적 요구 사항을 대체하지는 못한다.
- 차트 및 그래프 검토: 각 데이터 시각화에 대해, 색을 의도적으로 무시하고 모양, 패턴, 텍스트 레이블만으로 데이터를 해석해 본다. 색 없이 시각화를 해석할 수 없다면 실패다. 텍스트 기반 대안(데이터 테이블, 패턴이 포함된 범례, 직접 데이터 레이블)이 제공되는지 확인한다.
수정 방법
본문 텍스트 내 인라인 링크 — 잘못된 예
<!-- Link is distinguishable from surrounding text only by color.
A user with color blindness cannot identify it as a link. -->
<p>
Please review our
<a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
before continuing.
</p>
본문 텍스트 내 인라인 링크 — 올바른 예
<!-- Link is underlined in addition to being a different color.
The underline provides a non-color visual cue that identifies it as a link. -->
<p>
Please review our
<a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
before continuing.
</p>
폼 오류 상태 — 잘못된 예
<!-- Error is communicated only by a red border.
A color-blind user cannot distinguish this from a normal field. -->
<label for='email'>Email address</label>
<input
type='email'
id='email'
name='email'
class='input-error'
aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->
폼 오류 상태 — 올바른 예
<!-- Error is communicated by a red border AND a visible error icon AND a text message.
The text message is also linked via aria-describedby for assistive technology. -->
<label for='email'>Email address</label>
<input
type='email'
id='email'
name='email'
class='input-error'
aria-describedby='email-error'
aria-invalid='true'
/>
<p id='email-error' class='error-message'>
<svg aria-hidden='true' focusable='false' class='error-icon'>
<!-- error icon SVG path data -->
</svg>
Please enter a valid email address.
</p>
색만 사용하는 차트 범례 — 잘못된 예
<!-- Bar chart where categories are differentiated by fill color alone.
Users with color blindness cannot distinguish the categories. -->
<svg role='img' aria-label='Quarterly sales by region'>
<rect x='10' y='50' width='40' height='100' fill='#e63946' />
<rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
<rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
<li><span class='swatch red'></span> North</li>
<li><span class='swatch green'></span> South</li>
<li><span class='swatch yellow'></span> West</li>
</ul>
색만 사용하는 차트 범례 — 올바른 예
<!-- Bars use both distinct colors AND distinct pattern fills (via SVG patterns).
Legend items include a text label. An accessible data table is also provided. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
<defs>
<pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
<line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
</pattern>
<pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
<circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
</pattern>
<pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
<rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
</pattern>
</defs>
<rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
<rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
<rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
<li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
<li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
<li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
<caption>Quarterly sales by region (data table)</caption>
<thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
<tbody>
<tr><td>North</td><td>100</td></tr>
<tr><td>South</td><td>130</td></tr>
<tr><td>West</td><td>80</td></tr>
</tbody>
</table>
상태 배지 — 잘못된 예
<!-- Order status communicated only by background color.
"Pending" (yellow), "Shipped" (blue), and "Delivered" (green) are
visually identical to many color-blind users. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>
상태 배지 — 올바른 예
<!-- Status is communicated by color AND a visible text label.
The text label is the primary conveyor of meaning. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>
자주 발생하는 실수
- 본문 인라인 링크에서 밑줄을 제거하고 색에만 의존하는 경우: 본문 문단 안의 앵커 요소에
text-decoration: none을 설정하는 것은 가장 흔한 1.4.1 실패 사례 중 하나다. 밑줄은 링크를 위한 기본 비색 단서이며, 볼드나 아이콘 같은 다른 비색 구분 요소를 추가하지 않은 채 밑줄을 제거하면, 해당 링크가 주변의 다른 색 텍스트 안에 나타날 때 즉시 실패가 된다. - 추가 아이콘이나 텍스트 없이 통과/실패 상태에 빨간색/초록색 쌍을 사용하는 경우: 실패에는 빨간색, 성공에는 초록색을 사용하는 것은 문화적으로 직관적이지만, 바로 그 가장 흔한 색맹 유형인 제2색맹과 제1색맹 사용자에게는 접근 가능하지 않다. 항상 이 색들과 뚜렷이 구분되는 아이콘(체크 표시와 X 표시)과 명시적인 텍스트 레이블("Valid"와 "Error")을 함께 사용해야 한다.
- 필수 폼 필드를 색만 다른 별표로 표시하는 경우: 필드 레이블 옆의 빨간색 별표(*)는 별표 자체에 범례나 눈에 보이는 텍스트 설명이 없다면 색을 통해서만 필수 상태를 전달한다. 해결책은 폼 근처에 "*는 필수 필드를 의미합니다"와 같은 눈에 보이는 설명을 포함해, 별표 자체가 색을 넘어선 의미를 갖도록 하는 것이다.
- 내비게이션 메뉴에서 색만 다른 활성/선택 상태를 사용하는 경우: 현재 활성화된 내비게이션 항목을 텍스트나 배경색만 바꾸어 강조하고, 글꼴 두께 변경, 밑줄 추가, 테두리 표시 추가 등을 하지 않으면, 색맹 사용자는 자신이 어느 페이지에 있는지 알 수 없다.
- 레이블을 추가하지 않고 색만 반복하는 차트 툴팁: 일부 차트 라이브러리는 데이터 시리즈와 동일한 색 견본만 보여 주고 시리즈 이름에 대한 텍스트 레이블은 제공하지 않는 툴팁을 표시한다. 툴팁이 데이터 구분이 이루어지는 유일한 위치이고, 그 툴팁이 색 견본에만 의존한다면 이는 실패다.
- 색만 바뀌는 진행 단계 표시: 다단계 폼 위저드는 종종 완료된 단계를 초록색 배경, 앞으로의 단계를 회색 배경으로 스타일링한다. 색 변화에 "Completed", "Current", "Upcoming"과 같은 텍스트나 체크 아이콘이 동반되지 않으면, 단계 상태는 색만으로 전달되는 것이다.
- 입력 검증 상태를 표시하기 위해 플레이스홀더 텍스트 색에 의존하는 경우: 플레이스홀더 텍스트 색을 변경(예: 오류 시 빨간색으로 변경)하는 것은 색만의 단서일 뿐 아니라, 플레이스홀더 텍스트가 레이블이나 오류 메시지를 대체할 수 없다는 추가적인 이유로도 접근 가능하지 않다. 검증 상태는 지속적으로 보이는 오류 메시지 요소를 통해 전달되어야 한다.
- ARIA 레이블만으로 1.4.1을 충족한다고 가정하는 경우: 요소에
aria-label이나aria-describedby를 추가하면 스크린 리더 사용자에게 정보가 제공되지만, 1.4.1은 시각적 기준이다. 이 기준은 색맹 시각 사용자에게 비색 시각 단서를 요구하며, 단순한 프로그램적 텍스트 대체만으로는 충분하지 않다. 둘 다 필요하지만, ARIA만으로는 1.4.1을 통과할 수 없다. - 테이블 행이나 셀을 교차 배경색만으로 구분하는 경우: 교차 행 색(지브라 스트라이프)은 일반적으로 장식적이며 그 자체로 1.4.1 문제는 아니다. 그러나 배경색만으로 특정 행이나 셀을 그룹화하거나 범주화하거나 정보적으로 구분하는 테이블은, 동일한 그룹화나 구분을 전달하는 텍스트 레이블, 아이콘, 헤더를 제공해야 한다.
- 색만의 단서를 "단지 장식"이라며 예외로 취급하는 경우: 개발자는 때때로 색이 있는 상태 점이나 색이 있는 범주 레이블이 장식적이지 정보적이지 않다고 주장한다. 그러나 색을 제거하거나 그레이스케일로 볼 때 사용자가 인터페이스를 이해하거나 사용하는 데 필요한 정보를 잃게 된다면, 그 색은 정의상 정보적이며 1.4.1을 준수해야 한다.
터키 접근성 규정과의 관계
2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 WCAG 2.2와 정렬된 의무적인 웹 및 모바일 접근성 요구 사항을 수립한다. WCAG 1.4.1 색 사용은 레벨 A 기준으로, 이 대통령령에서 의무적인 기본 준수 수준에 해당한다.
대통령령은 공공 기관에 대해 WCAG 2.2 레벨 A 준수를 1년 이내에, 민간 부문에 대해서는 2년 이내에 달성할 것을 의무화한다. 다음 범주의 조직이 명시적으로 포함된다. 공공 기관 및 정부 부처, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교.
이들 기관의 경우 WCAG 1.4.1을 준수하지 않는 것은 규정 위반에 해당한다. 실질적으로, 폼 오류를 표시하기 위해 색만 사용하는 웹 포털을 운영하는 터키 공공 기관이나, 온라인 뱅킹 인터페이스에서 거래 상태를 색만 다른 상태 표시로 나타내는 은행은 대통령령 요구 사항을 위반하게 된다. 터키에서 규모가 크고 빠르게 성장하는 전자상거래 플랫폼은 색으로 구분된 상품 재고 표시, 프로모션 배지, 장바구니 오류 메시지를 흔히 사용하는데, 이들 모두는 대통령령 요구 사항에 따라 비색 대안을 제공해야 한다.
1.4.1 준수는 정부 서비스, 뱅킹, 전자상거래에 모바일 기기를 통해 접근하는 사용자 기반이 큰 터키 환경에서 특히 중요하다. 모바일에서는 화면 품질과 주변 조명 조건 때문에 색이 유일한 정보 전달 수단으로서 신뢰도가 더욱 떨어지기 때문이다. 대통령령의 적용을 받는 조직은 디지털 자산 전반에서 정보 전달 수단으로 사용되는 모든 색 사용을 점검하고, 색으로 구분된 상태와 함께 텍스트 레이블과 아이콘 단서를 추가하는 작업을 우선순위에 두며, 1.4.1을 자동 접근성 스캐닝 파이프라인과 구조화된 수동 테스트 프로토콜 모두에 포함시켜 준수 프로그램의 일부로 삼을 것이 권장된다.
