빨강은 실패, 초록은 성공… 그런데 둘이 같아 보인다면?

KRDS DS-006 — 색약자(특히 적록색맹과 청색맹 사용자)를 고려하여 색상을 사용하고 있다.

0. 들어가며 — 20명 중 1명이 보는 다른 세상

화면에서 우리는 색으로 너무 많은 것을 말합니다. 빨강은 오류, 초록은 성공, 파랑은 링크, 회색은 비활성. 입력칸이 빨갛게 변하면 “여기 잘못됐어요”라는 뜻이고, 그래프의 빨간 선과 초록 선은 서로 다른 데이터를 의미합니다. 우리는 이 색의 언어를 너무 당연하게 여깁니다.

그런데 전체 남성의 약 8%, 즉 12~13명 중 1명은 이 색들을 우리와 다르게 봅니다. 특히 빨강과 초록을 구분하기 어려운 사람이 많습니다. 이들에게 “빨강 버튼을 누르세요”나 “초록색이면 정상입니다”는 안내는, 정보가 아니라 수수께끼입니다.

DS-006은 바로 이 사람들을 위한 규칙입니다. 핵심 메시지는 간단합니다 — 색만으로 정보를 전달하지 말라. 색은 보조 수단으로 쓰되, 아이콘·텍스트·패턴·위치 같은 색이 아닌 단서를 함께 제공하라는 것입니다. 이번 편은 색각이상이 정확히 무엇인지, 어디서 가장 많이 문제가 터지는지, 그리고 어떻게 하면 ’모두가 읽을 수 있는 색 사용’이 되는지를 끝까지 다룹니다.

1. 규칙 원문 — 두 토막

DS-006 (디자인 스타일 > 색상) “① 색약자(특히 적록색맹과 청색맹 사용자)를 고려하여 ② 색상을 사용하고 있다.”

① “색약자(적록색맹과 청색맹 사용자)를 고려하여”

색각이상(색약·색맹)을 가진 사용자를 염두에 두라는 뜻입니다. 괄호 안에 두 유형을 콕 집었습니다 — 적록색맹(빨강·초록 계열 구분이 어려움)과 청색맹(파랑·노랑 계열 구분이 어려움). 특히 적록 계열은 색각이상자의 절대다수가 겪는 유형이라 먼저 언급됩니다.

② “색상을 사용하고 있다”

색을 ’쓰지 말라’가 아닙니다. 색은 여전히 강력하고 유용한 도구입니다. 다만 색약자도 정보를 놓치지 않도록 색을 사용하는 방식을 설계하라는 뜻입니다. 즉 색에 더해 다른 단서를 함께 제공하고, 헷갈리는 색 조합을 피하는 것 — 이게 ’고려하여 사용’의 실체입니다.

정리: 색을 쓰되, 색을 못 구분하는 사람도 정보를 얻을 수 있게 설계하라. 이게 DS-006입니다.

2. 색각이상이란 무엇인가 — 8%의 사용자

누가, 얼마나

색각이상(Color Vision Deficiency, CVD)은 전 세계 남성의 약 8%, 여성의 약 0.5% 에게 나타납니다. 남성 12~13명 중 1명꼴이니 결코 드문 일이 아닙니다. 30명 규모의 사무실이라면 한두 명, 수만 명이 쓰는 공공 사이트라면 수천 명이 색을 다르게 보는 사용자입니다.

무엇이 안 보이나 — 세 가지 유형

색각이상은 흔히 ’색맹’이라 부르지만, 실제로는 색이 완전히 안 보이는 게 아니라 특정 색을 구분하기 어려운 경우가 대부분입니다. 크게 세 유형입니다.

유형	영문	어려운 구분	비고
적색맹/적색약	Protanopia/Protanomaly	빨강 계열 인식 약함	적록 혼동
녹색맹/녹색약	Deuteranopia/Deuteranomaly	초록 계열 인식 약함	가장 흔함, 적록 혼동
청색맹/청색약	Tritanopia/Tritanomaly	파랑·노랑 계열 구분 약함	상대적으로 드묾

KRDS도 이를 명시합니다 — 적록색맹·적록색약(적색·녹색)이 색각이상자의 약 99%, 그리고 청색맹·청색약 (청색·녹색·황색)이 일부입니다. 즉 ’빨강과 초록의 혼동’이 색각이상의 절대다수라는 것이 핵심입니다. 그래서 DS-006도, 실무 설계도 적록 조합을 가장 경계합니다.

색약자에게 화면은 어떻게 보일까

적록색맹 사용자에게는 빨강과 초록이 비슷한 탁한 갈색·황토색 톤으로 보일 수 있습니다. 그래서 “빨간 경고 메시지”와 “초록 정상 표시”가 거의 같은 색으로 보입니다. 신호등이 헷갈리고, 빨간 펜으로 표시한 정답·오답이 구분되지 않으며, 빨강/초록으로 그린 그래프가 한 덩어리로 뭉쳐 보입니다. 우리가 ’명백하다’고 여기는 색 구분이, 이들에게는 존재하지 않는 셈입니다.

왜 남성에게 압도적으로 많을까

8% 남성 vs 0.5% 여성. 이 큰 차이에는 분명한 이유가 있습니다. 색을 감지하는 유전자 중 적록 관련 유전자가 X 염색체에 있고, 이것이 열성으로 유전되기 때문입니다. 남성은 X 염색체가 하나뿐이라, 그 하나에 문제가 있으면 곧바로 색각이상이 나타납니다. 반면 여성은 X 염색체가 둘이라, 둘 다 문제가 있어야 색각이상이 나타나므로 훨씬 드뭅니다. 그래서 색각이상은 남성에게 압도적으로 흔한 특성이 됩니다.

이 사실이 디자인에 주는 함의는 중요합니다 — 색각이상은 사고나 질병으로 ‘드물게 생기는’ 것이 아니라, 상당수 남성이 태어날 때부터 가지고 있는 흔한 특성입니다. 다시 말해, 우리 사이트를 쓰는 남성 사용자 열두어 명 중 한 명은 언제나 색을 다르게 보고 있습니다. 이건 가능성의 문제가 아니라 통계적 확실성입니다.

본인도 모르는 경우가 많다

또 하나 중요한 점 — 색각이상자 상당수는 자신이 색약이라는 사실조차 정확히 모르거나, 알아도 굳이 밝히지 않습니다. 어릴 때부터 그렇게 봐 왔기에 ’내가 보는 게 정상’이라 여기는 경우가 많고, 일상에서는 큰 불편 없이 적응해 살아갑니다. 그래서 “우리 사이트 이용자 중에 색약자가 있나요?”라고 물으면 데이터상으로는 잡히지 않지만, 실제로는 분명히 존재합니다. 보이지 않는다고 없는 게 아니라, 드러나지 않을 뿐 늘 거기 있는 사용자입니다. DS-006이 ’특정 민원이 들어와서’가 아니라 ’기본 설계 원칙’으로 다뤄져야 하는 이유입니다.

3. 핵심 원칙 — “색에만 의존하지 말라” (WCAG 1.4.1)

DS-006의 바탕에는 국제 웹 접근성의 가장 유명한 원칙 중 하나가 있습니다 — WCAG 성공기준 1.4.1 ‘색의 사용(Use of Color)’.

“색이 정보를 전달하거나, 행동을 지시하거나, 응답을 유도하거나, 시각 요소를 구분하는 유일한 수단이 되어서는 안 된다.”

핵심 단어는 ‘유일한(only)’ 입니다. 색을 쓰는 것 자체는 전혀 문제가 아닙니다. 문제는 색’만’으로 정보를 전달할 때입니다. 색이 안 보여도 정보가 전달되도록, 색 + 다른 단서를 함께 제공해야 합니다.

그 ’다른 단서’는 네 가지가 대표적입니다.

텍스트 — “오류: 이메일 형식이 올바르지 않습니다” 같은 명시적 문구

아이콘 — ⚠️ 경고, ✓ 성공, ✕ 오류 같은 형태 단서

패턴/모양 — 그래프 선을 실선/점선/굵기로 구분, 영역에 빗금 패턴

위치/라벨 — 범례를 직접 항목 옆에 붙이기, 순서로 구분

이 원칙은 색약자만을 위한 게 아닙니다. 흑백 인쇄, 화면 밝기를 낮춘 환경, 햇빛 아래 화면에서도 똑같이 도움이 됩니다. “색이 사라져도 작동하는 화면” 은 결국 모두에게 더 견고한 화면입니다.

네 가지 단서를 조금 더 깊이

‘색 외의 단서’ 네 가지는 그냥 아무거나 붙이면 되는 게 아니라, 각자 잘 맞는 자리가 있습니다.

텍스트는 가장 확실하고 모호함이 없는 단서입니다. “오류”, “필수”, “처리 완료” 같은 말은 오해의 여지가 없습니다. 다만 공간을 차지하므로, 좁은 영역(배지, 작은 아이콘 버튼)에서는 부담이 될 수 있습니다. 그럴 때는 화면에 안 보이더라도 보조기기는 읽을 수 있는 형태(스크린리더용 숨김 텍스트)로라도 정보를 남겨야 합니다.

아이콘은 형태로 의미를 전달합니다. ⚠️(경고)·✓(성공)·✕(오류)처럼 널리 통용되는 형태는 직관적이고 공간 효율도 좋습니다. 다만 아이콘 자체의 의미가 모호하면 오히려 혼란을 주므로, 관습적이고 명확한 형태를 써야 하고 중요한 경우엔 텍스트를 곁들이는 게 안전합니다.

패턴/모양은 특히 데이터 시각화에서 빛을 발합니다. 같은 영역도 빗금·점·격자 패턴으로 구분하면 색 없이도 구별됩니다. 그래프 선을 실선·점선·일점쇄선으로, 데이터 점을 원·삼각형·사각형 마커로 구분하는 식입니다. 색약자뿐 아니라 흑백 출력에서도 그대로 작동합니다.

위치/순서/라벨은 가장 우아한 해법일 때가 많습니다. 범례를 따로 두지 않고 데이터 옆에 직접 라벨을 붙이면, 색을 대조할 필요 자체가 사라집니다. 항목을 의미 있는 순서로 배치하는 것도 색에 의존하지 않는 구분 방법입니다.

좋은 설계는 이 네 가지 중 상황에 맞는 것을 골라, 색 위에 한 겹 더 얹는 것입니다. 모든 곳에 텍스트를 도배하라는 게 아니라, 정보가 색에만 실리지 않도록 적절한 ’두 번째 채널’을 마련하라는 뜻입니다.

4. 가장 많이 터지는 곳 — 색 단독 의존의 함정

실무에서 DS-006 위반은 거의 정해진 자리에서 나옵니다. 우리 사이트에 해당하는 게 있는지 떠올려 보세요.

함정 ① 폼 입력 오류 — ‘빨간 테두리만’

가장 흔합니다. 입력값이 잘못되면 입력칸을 빨간 테두리로만 표시하는 경우. 적록색맹 사용자는 그 빨강을 인식하지 못해 “어디가 잘못됐는지” 모릅니다. → 빨간 테두리 + 오류 아이콘 + 텍스트 메시지를 함께 줘야 합니다.

함정 ② 그래프·차트 — ‘색 범례만’

통계 사이트의 단골 문제입니다. 여러 데이터 계열을 색으로만 구분하고, 범례도 색 점으로만 표시하는 경우. 색약자에게는 선들이 뒤엉켜 보입니다. → 선을 실선/점선/굵기/마커 모양으로 구분하고, 범례를 선 끝에 직접 라벨로 붙이면 해결됩니다.

함정 ③ 상태 표시 — ‘빨강/초록 점만’

“운영중(초록)·중단(빨강)” 같은 상태 점(dot)만으로 표현하는 경우. → 점 + 텍스트 라벨(“운영중”) 또는 아이콘(●/■/▲ 모양 구분)을 함께.

함정 ④ 링크 — ‘색만으로 본문과 구분’

본문 속 링크를 파란색만으로 구분하는 경우. 색약자나 흑백 환경에서는 어디가 링크인지 모릅니다. → 밑줄을 함께 제공하는 것이 가장 안전합니다.

함정 ⑤ 필수 입력 표시 — ‘빨간 별표 색’

“빨간색 항목은 필수입니다”라는 안내. 빨강이 안 보이면 어느 게 필수인지 모릅니다. → 별표(*) 기호 자체와 “필수” 텍스트를 함께.

다섯 함정의 공통 구조: “색 하나에 정보를 통째로 실었다” 는 것. 해법도 하나입니다 — 그 정보를 색이 아닌 단서에도 똑같이 실어라.

공공 영역에서 특히 위험한 장면들

공공서비스에는 이 함정이 더 치명적으로 작동하는 영역이 있습니다. 정보의 정확한 전달이 곧 권리·안전과 직결되기 때문입니다.

대표적인 것이 통계·데이터 시각화입니다. 통계청, 각종 공공데이터 포털, 정책 대시보드는 색으로 구분된 그래프와 지도를 쏟아냅니다. 인구 분포 지도를 빨강~초록 그라데이션으로 칠하면, 적록색맹 사용자는 어느 지역이 높고 낮은지 읽지 못합니다. 정책 판단의 근거가 되는 데이터가, 누군가에게는 통째로 가려지는 것입니다. 이런 경우 색만이 아니라 수치 라벨, 패턴, 명도 단계를 함께 써야 모두가 읽을 수 있습니다.

민원·신청 처리 상태도 위험합니다. “접수(노랑)·처리중(파랑)·완료(초록)·반려(빨강)”를 색 점으로만 표시하면, 색약자는 자기 민원이 어떤 상태인지 확신하지 못합니다. 신청이 반려됐는데 완료된 줄 알고 기다리는 일이 벌어질 수 있습니다. 상태에는 반드시 텍스트 라벨이 따라붙어야 합니다.

노선도·안내도 역시 마찬가지입니다. 지하철 노선도처럼 색으로 노선을 구분하는 안내는, 색약자에게 매우 어렵습니다. 그래서 잘 설계된 노선도는 색에 더해 노선 번호, 역 이름, 굵기 같은 단서를 함께 제공합니다.

이 장면들의 공통점은 — 공공 정보일수록 “못 읽으면 곤란한” 정도가 크다는 것입니다. 쇼핑몰에서 색 구분을 놓치면 다른 상품을 보면 그만이지만, 공공서비스에서 상태나 데이터를 잘못 읽으면 권리 행사에 실패하거나 잘못된 판단을 합니다. 그래서 DS-006은 공공 영역에서 특히 무겁게 다뤄져야 합니다.

5. KRDS의 색약 고려 원칙

KRDS는 색약 대응을 위해 구체적인 설계 지침을 제시합니다. 크게 세 가지입니다.

(1) 색상 외에 텍스트·아이콘으로 보완

앞서 본 WCAG 1.4.1과 같은 원칙입니다. 정보를 색에만 싣지 말고 텍스트와 아이콘으로 이중 표시하라는 것. KRDS 컴포넌트(긴급 공지, 오류 메시지 등)가 색과 아이콘과 텍스트를 한 세트로 제공하는 이유가 여기 있습니다.

(2) 헷갈리는 색 조합 회피

특히 적색과 녹색을 직접 대비시키는 조합을 피하라고 권합니다. 적록색맹이 색각이상의 99%를 차지하기 때문입니다. 빨강/초록을 나란히 두어 구분하게 하는 디자인은 가장 위험한 선택입니다.

(3) 명도 차이로 보완

색상(빨강이냐 초록이냐)이 아니라 명도(밝기) 에 차이를 두면, 색약자도 구분할 수 있습니다. 색각이상은 ‘색상’ 구분이 어려운 것이지 ‘밝기’ 구분은 대체로 정상이기 때문입니다. 그래서 두 요소를 구분해야 한다면 색만 다르게 하지 말고 밝기도 다르게 하라는 것입니다. (이건 2편의 명도 대비와 곧장 연결됩니다.)

(4) 색맹 시뮬레이터로 검증

마지막으로 KRDS는 색맹 시뮬레이터로 결과를 검증하라고 권합니다. 디자인을 색약자의 시야로 변환해 보여주는 도구로, 색에만 의존한 부분이 있는지 한눈에 드러납니다.

6. 명도 대비와의 깊은 연결 — ‘밝기는 살아 있다’

DS-006을 제대로 이해하는 열쇠가 여기 있습니다. 색각이상자는 색상(hue) 구분이 어렵지만, 명도(밝기) 구분은 대체로 정상입니다. 이 사실이 모든 해법의 토대입니다.

빨강과 초록이 같아 보이는 사람도, 밝은 것과 어두운 것은 또렷이 구분합니다. 그래서 2편(명도 대비)을 잘 지킨 화면은 자동으로 색약 친화적이 됩니다. 글자와 배경의 밝기 차이가 충분하면, 색이 안 보여도 글자는 읽히니까요.

반대로 위험한 건 ‘명도는 비슷한데 색상만 다른’ 조합입니다. 비슷한 밝기의 빨강과 초록을 나란히 두면, 색약자에게는 거의 같은 색 덩어리로 보입니다. 그래서 색약 대응의 실전 요령은 — 색으로 구분하려거든, 명도도 함께 다르게 하라. 색상에 더해 밝기 차이라는 ’두 번째 채널’을 두는 것입니다.

이 관점에서 보면 색상 규칙들이 하나로 꿰어집니다. DS-002(명도 대비)·DS-005(선명한 화면 모드)· DS-006(색약 고려)은 표면적으로 다른 주제 같지만, 모두 “색상 하나에 의존하지 말고 명도와 다른 단서를 활용하라” 는 같은 철학을 공유합니다. 접근성은 결국 ’여러 채널로 같은 정보를 전달하는 것’입니다.

7. 실전 — Before / After

Case 1. 폼 오류 표시

<!-- ❌ Before: 빨간 테두리 '만'으로 오류 표시 --> <input class="error" style="border-color:red"> <!-- ✅ After: 색 + 아이콘 + 텍스트 --> <input class="error" aria-invalid="true" aria-describedby="err1"> <p id="err1" class="error-msg">⚠️ 올바른 이메일 형식이 아닙니다</p>

Case 2. 차트 데이터 구분

❌ Before: 빨간 선 vs 초록 선 (색만 다름) ✅ After: 실선(●마커) vs 점선(■마커) + 선 끝에 직접 라벨 → 색이 안 보여도 선 모양·마커·라벨로 구분

Case 3. 본문 링크

/* ❌ Before: 색만으로 링크 구분 */ a { color: var(--primary-50); } /* ✅ After: 색 + 밑줄 */ a { color: var(--primary-60); text-decoration: underline; }

Case 4. 상태 표시

❌ Before: ● (초록 점) ● (빨강 점) ✅ After: ● 운영중 ▲ 점검중 (점 + 텍스트 라벨 + 모양 구분)

정비 우선순위

① 폼 오류(가장 빈번·치명적) → ② 차트·통계 → ③ 링크 밑줄 → ④ 상태/배지 → ⑤ 필수 입력 표시

8. 무엇을 점검하나

DS-006은 “색이 정보의 유일한 수단인 지점” 을 찾아냅니다.

색 단독 의존 검출 — 폼 오류, 상태, 차트, 링크 등에서 색 외의 단서(텍스트·아이콘·패턴·밑줄)가 함께 있는지.

적록 조합 탐지 — 정보 구분에 적색-녹색을 직접 대비시키는 위험 조합이 있는지.

명도 차이 확인 — 색으로 구분하는 요소들이 밝기 차이도 갖는지.

시뮬레이션 검증 — 색약 시야로 변환했을 때 정보가 유지되는지.

일부는 자동 검출(링크 밑줄 유무, 오류 텍스트 동반 여부 등)이 가능하고, 일부(차트의 의미 구분 등)는 색맹 시뮬레이터를 통한 육안 검증이 함께 필요합니다.

9. 누가 담당하나

역할	책임
기획 / UX	정보를 ’색 외의 단서’로도 전달하도록 설계 — 이 항목의 핵심
디자이너	적록 조합 회피, 명도 차이 부여, 아이콘·패턴 디자인
퍼블리셔/개발	링크 밑줄, 오류 텍스트·아이콘 마크업 구현

DS-006은 색 선택만의 문제가 아니라 ‘정보를 어떻게 전달할 것인가’ 라는 기획·UX 차원의 문제입니다. 그래서 디자이너 혼자 풀 수 없고, 정보 구조를 설계하는 기획 단계부터 색 외 단서를 함께 계획해야 합니다.

10. 우리 사이트에 해당될까?

적용 대상

기관 유형	DS-006 적용
중앙행정기관(대표)	✅ 필수
중앙행정기관(운영)	✅ 필수
공공기관	✅ 필수
지방자치단체	✅ 필수

색으로 상태·구분·정보를 전달하는 모든 사이트 = 전부 해당. 폼이 있고(오류 표시), 링크가 있고, 상태나 통계를 색으로 표현한다면 — 사실상 모든 사이트가 DS-006 점검 대상입니다.

예외(N/A)

색으로 정보를 전달하는 부분이 전혀 없다면 해당 요소는 예외가 될 수 있지만, 현실적으로 링크·폼·상태 중 하나도 없는 사이트는 드뭅니다. 즉 대부분의 사이트에서 판정되는 규칙입니다.

11. 단계별 개선 방법

폼 오류부터 — 모든 오류 표시에 색 + 아이콘 + 텍스트 메시지 3종 세트 적용.

링크에 밑줄 — 본문 내 링크는 색만이 아니라 밑줄로도 구분.

차트 손보기 — 데이터 계열을 선 모양·마커·패턴으로 구분, 범례 직접 라벨링.

상태·배지 라벨링 — 색 점에 텍스트/모양 추가.

적록 조합 점검 — 적색-녹색을 직접 비교시키는 곳을 찾아 명도 차이를 주거나 다른 색으로 교체.

시뮬레이터 검증 — 색맹 시뮬레이터로 전체 화면을 변환해 최종 확인.

12. 30초 자가진단 + FAQ

✅ 30초 자가진단

폼 오류를 빨간 테두리 ‘만’ 으로 표시하지 않나요? (아이콘·텍스트 동반?)

본문 링크에 밑줄이 있나요, 아니면 색만으로 구분하나요?

그래프 데이터를 색 말고도 선 모양·마커로 구분하나요?

“빨간 항목은 필수” 같은 색 의존 안내가 있지 않나요?

화면을 흑백으로 바꿔도 모든 정보가 전달되나요?

❓ FAQ

Q1. 빨강·초록을 아예 쓰면 안 되나요? 아닙니다. 색은 써도 됩니다. 다만 빨강·초록을 정보 구분의 ‘유일한’ 수단으로 쓰지 마세요. 오류는 빨강 + 아이콘 + 텍스트, 성공은 초록 + 아이콘 + 텍스트처럼 다른 단서를 함께 주면 됩니다.

Q2. 색맹 시뮬레이터는 어디서 쓰나요? 브라우저 확장 프로그램이나 디자인 도구의 색각이상 미리보기 기능, 온라인 CVD 시뮬레이터 등이 있습니다. 디자인을 적록색맹·청색맹 시야로 변환해, 색에만 의존한 곳을 찾을 수 있습니다.

Q3. 흑백으로 바꿔보라는 게 무슨 뜻인가요? 가장 간단한 자가 테스트입니다. 화면을 회색조(grayscale)로 바꿨을 때도 모든 정보가 구분되면, 색에 의존하지 않는다는 뜻입니다. 흑백에서 정보가 사라지면 그게 바로 색 단독 의존 지점입니다.

Q4. 링크에 밑줄을 꼭 넣어야 하나요? 디자인이 답답해 보여요. 본문 속(문장 안) 링크는 밑줄을 강력히 권장합니다. 색만으로는 색약자·흑백 환경에서 링크를 못 찾기 때문입니다. 다만 메뉴·버튼처럼 위치·형태로 명백히 구분되는 링크는 밑줄이 없어도 됩니다. 맥락에 따라 판단하세요.

Q5. 명도 차이를 주라는 게 구체적으로 뭔가요? 두 요소를 색으로 구분할 때, 색상만 다르게 하지 말고 밝기도 다르게 하라는 뜻입니다. 예: 빨강과 초록을 나란히 두는 대신, 진한 색과 연한 색으로 밝기 차이를 함께 주면 색약자도 구분할 수 있습니다.

13. 마무리 — ‘색은 거들 뿐’

DS-006의 메시지는 한 문장으로 압축됩니다.

색은 정보를 ’강조’할 수는 있어도, 정보를 ’전달하는 유일한 수단’이 되어서는 안 된다.

색은 훌륭한 보조 도구입니다. 빨강은 위험을 직관적으로 알리고, 초록은 안심을 줍니다. 하지만 그 직관은 색을 정상적으로 보는 사람에게만 작동합니다. 20명 중 1명에게는 작동하지 않습니다. 그래서 색은 ’거들 뿐’이어야 합니다 — 진짜 정보는 텍스트·아이콘·형태·위치에 실려 있어야 하고, 색은 그 위에 한 겹 더해지는 강조여야 합니다.

이렇게 설계하면 색약자만 혜택을 보는 게 아닙니다. 흑백으로 출력한 사람, 햇빛 아래 화면을 보는 사람, 밝기를 낮춘 사람 모두가 더 또렷한 화면을 얻습니다. 접근성은 소수를 위한 양보가 아니라, 모두를 위한 견고함입니다.

이 점을 조금 더 음미해 볼 가치가 있습니다. 접근성을 ’특별한 소수를 위한 추가 작업’으로 보면, 그건 늘 예산과 일정에서 밀립니다. “여유 되면 챙기자”는 항목이 되죠. 하지만 색에 의존하지 않는 설계는 그 자체로 더 명확하고 더 견고한 디자인입니다. 오류를 색만이 아니라 아이콘과 문구로도 알리는 화면은, 색을 정상적으로 보는 사람에게도 더 빠르고 분명합니다. 데이터를 색과 패턴과 라벨로 함께 구분한 그래프는, 모두에게 더 읽기 쉽습니다. 즉 DS-006을 지키는 일은 ’색약자를 위해 내 디자인을 희생하는 것’이 아니라, 모두를 위해 내 디자인을 더 좋게 만드는 것입니다.

이것이 ’유니버설 디자인’의 핵심 통찰입니다 — 가장 제약이 많은 사용자를 기준으로 설계하면, 그 해법이 모두에게 이롭다는 것. 휠체어를 위해 만든 경사로가 유모차와 캐리어에도 편한 것처럼, 색약자를 위해 더한 텍스트·아이콘·패턴은 결국 모든 사용자의 경험을 끌어올립니다. 공공서비스가 이 원칙을 앞장서 지켜야 하는 이유도 여기 있습니다 — 공공은 ’평균 사용자’가 아니라 ’모든 국민’을 대상으로 하니까요.

다음 편부터는 색의 ’역할’로 넘어갑니다. DS-007 — “주요 색상을 Primary, Secondary, Gray 색상으로 구분하고 있다.” 지금까지가 ’색을 어떻게 만들고 다루나’였다면, 이제 ’그 색에 어떤 역할을 부여하나’의 이야기입니다.

다음 편 예고 ▶ 「007. 주요 색상을 Primary, Secondary, Gray 색상으로 구분하고 있다.」

우리 사이트가 색에만 의존하고 있는지 확인하려면? ViewCheck는 폼 오류·링크·상태 표시 등에서 색 외의 단서(텍스트·아이콘·밑줄)가 함께 제공되는지, 위험한 적록 조합이 쓰였는지를 점검하고, 색각이상 시야에서 정보가 유지되는지까지 함께 진단합니다.

📚 참고 출처

KRDS 색상(Color) 스타일 가이드 (색약 고려) — https://www.krds.go.kr/html/site/style/style_02.html

WCAG 2.1 Understanding 1.4.1 Use of Color — https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

WebAIM — Visual Disabilities: Color-blindness — https://webaim.org/articles/visual/colorblind

The A11Y Collective — Colour Blindness Accessibility — https://www.a11y-collective.com/blog/color-blind-accessibility-guidelines/ #KRDS, #ViewCheck, #공공웹사이트, #전자정부, #디지털정부, #웹접근성, #디자인시스템, #UIUX, #UI컴포넌트, #KRDS 체크리스트, #웹표준