색상만으로 상태를 전달하면 왜 위험할까

먼저 던질 질문

오류, 성공, 경고 상태는 색상 외에 무엇으로 전달해야 할까

핵심 관점

색상은 빠른 신호지만 의미의 유일한 근거가 될 수 없다. 상태는 색, 텍스트, 아이콘, 위치, 패턴이 함께 전달해야 한다.

다양한 환경에서도 통하는 장면

오류 필드에 빨간색, 오류 아이콘, 구체 메시지를 함께 제공한다. 사용자는 현재 상태를 이해하고, 다음에 무엇을 할 수 있는지 알며, 행동의 결과를 어느 정도 예측할 수 있다.

상태 배지에 색상과 텍스트를 함께 표시한다.

배제나 혼란이 생기는 장면

성공과 실패를 초록/빨강 점만으로 구분한다.

비활성 상태를 낮은 대비 색상만으로 표현해 읽기 어렵다.

접근성 사례와 근거

색상은 의미를 보조해야지 대신하면 안 된다

WCAG의 Use of Color 기준은 색상이 정보 전달의 유일한 수단이 되어서는 안 된다고 설명한다. 빨간색과 초록색만으로 성공과 실패를 구분하면 색각 이상 사용자뿐 아니라 밝은 야외 환경에서도 의미가 흐려질 수 있다.

좋은 상태 표시는 색상, 텍스트, 아이콘, 위치, 패턴을 함께 사용한다. 폼 오류는 빨간 테두리뿐 아니라 오류 문구와 요약 링크가 필요하고, 차트는 색상 외 라벨이나 패턴을 제공해야 한다.

실무 해석

디자인 시스템에서는 red, green 같은 색 이름보다 danger, warning, success, info 같은 의미 기반 토큰을 쓰는 편이 낫다. 색은 상태 전달의 한 재료일 뿐이다.

접근성 판단 기준

• 색 없이도 상태를 구분할 수 있는지 본다
• 텍스트 대비와 상태 대비를 모두 확인한다
• 상태 컴포넌트에 label이 필수인지 확인한다

자주 빠지는 함정

대비 기준만 맞추면 충분하다고 생각하기 쉽다. 하지만 색상 접근성은 읽을 수 있음뿐 아니라 의미를 구분할 수 있음까지 포함한다.

추가로 비교할 접근성 사례

• 상태 배지, 그래프 범례, Form 오류 상태에서 색상 의존 사례를 비교한다
• 색상과 텍스트를 함께 쓰는 좋은 사례를 찾는다
• 다크 모드에서 대비가 깨지는 사례를 모은다

포용성 설계 질문

• 색상 외 단서의 종류를 충분히 제시했는가
• 상태 컴포넌트 API와 연결했는가

출처

• W3C, Web Content Accessibility Guidelines WCAG 2.2: https://www.w3.org/TR/WCAG22/
• Material Design 3, Text fields: https://m3.material.io/components/text-fields/overview
• Microsoft Fluent 2 Design System: https://fluent2.microsoft.design/
• GOV.UK Design System, Error message: https://design-system.service.gov.uk/components/error-message/