보이는데 왜 안 보인다고 하지?

KRDS DS-002 — 명도 대비를 준수하고 있다.

0. 들어가며 — “저는 잘 보이는데요?”

웹사이트 점검에서 “명도 대비 미준수”가 나오면, 담당자에게서 가장 자주 나오는 반응이 이겁니다.

“제 모니터에서는 잘 보이는데요?”

여기에 함정이 있습니다. 잘 보이는 사람의 기준으로 만든 화면은, 잘 안 보이는 사람을 배제합니다. 젊고 시력 좋은 사람이 좋은 모니터로, 실내 조명에서 보는 연한 회색 글씨는 — 고령자가, 저가형 노트북으로, 햇빛 비치는 야외에서 보면 그냥 안 보입니다.

명도 대비는 “예쁘냐 안 예쁘냐”가 아니라 “보이느냐 안 보이느냐” 의 문제입니다. 그리고 공공서비스에서 ’안 보인다’는 건 곧 ‘그 국민은 서비스를 못 쓴다’ 는 뜻입니다. 846개 중 두 번째 규칙이 명도 대비인 이유 — 색을 다루기 시작하면 즉시 따라오는 책임이기 때문입니다.

이번 편은 1편(색상 팔레트)에서 잠깐 등장한 ‘매직 넘버’와 ’WCAG 4.5:1’ 을 본격적으로 파헤칩니다. 명도 대비가 정확히 무엇이고, 어떻게 계산되며, 어디서 가장 많이 깨지는지 — 끝까지 정리합니다.

1. 규칙 원문 — 짧지만 무거운 한 문장

DS-002 (디자인 스타일 > 색상) “명도 대비를 준수하고 있다.”

겨우 한 문장입니다. 그런데 이 짧은 문장이 사이트의 거의 모든 글자와 거의 모든 버튼에 적용됩니다. 하나씩 뜯어봅시다.

“명도 대비(Contrast)”

두 색이 밝기 차이로 얼마나 또렷하게 구분되는가를 수치로 나타낸 것입니다. 글자색과 배경색, 버튼색과 그 위 글자색, 입력칸 테두리와 그 주변색 — 이렇게 ‘겹쳐 보이는 두 색의 관계’ 를 봅니다.

핵심은 ’색이 다르다’와 ’대비가 충분하다’는 다르다는 점입니다. 빨강과 초록은 색은 완전히 다르지만 밝기(명도)는 비슷해서, 겹쳐 놓으면 의외로 잘 안 구분됩니다. 명도 대비는 색상(hue)이 아니라 밝기 차이를 봅니다.

“준수하고 있다”

여기서 ’준수’의 기준선이 바로 WCAG(웹 콘텐츠 접근성 지침) 와 그 한국판인 KWCAG(한국형 웹 접근성 지침) 입니다. 막연히 “충분히”가 아니라 숫자로 정해진 기준(본문 4.5:1 등)을 넘느냐로 판정됩니다. 다음 섹션에서 이 숫자의 정체를 밝힙니다.

2. 왜 중요한가 — ’한 명의 국민’까지 닿기 위해

(1) 접근성 — 이건 권리의 문제다

대한민국 남성의 약 8%는 색각 이상을 갖고 있고, 고령 인구는 빠르게 늘고 있습니다. 백내장·노안이 오면 대비 감도가 크게 떨어집니다. 명도 대비가 부족한 화면은 이들에게 ‘읽을 수 없는 화면’ 입니다.

공공서비스는 상업 서비스와 다릅니다. 사용자가 “불편하면 안 쓰면 그만”인 게 아니라, 그 사이트를 써야만 민원을 처리하고 권리를 행사할 수 있습니다. 그래서 명도 대비 미준수는 단순 불편이 아니라 서비스 접근 자체의 차단입니다.

(2) 환경 — 모니터는 다 다르다

같은 색이라도 보는 환경이 천차만별입니다.

야외 햇빛 아래 스마트폰

밝기 낮춘 저가형 모니터

블루라이트 필터로 누렇게 변한 화면

오래되어 색이 바랜 디스플레이

명도 대비를 넉넉히 확보해 두면 이 모든 열악한 환경에서도 글자가 살아남습니다. “내 모니터에서 잘 보임”은 기준이 될 수 없는 이유입니다.

(3) 법적 기준 — 만들면 좋은 게 아니라 지켜야 하는 것

명도 대비는 KWCAG(한국형 웹 콘텐츠 접근성 지침)의 명시적 검사 항목이며, 공공 웹사이트 품질관리의 접근성 영역 핵심입니다. KRDS가 DS-002로 이를 못 박은 것도 같은 맥락입니다. “디자인 권고”가 아니라 접근성 의무에 가깝습니다.

특히 공공기관은 「장애인차별금지 및 권리구제 등에 관한 법률(장애인차별금지법)」의 적용을 받습니다. 웹 접근성 미준수는 단순 품질 문제를 넘어 차별 이슈로 번질 수 있는 영역입니다. 실제로 해외에서는 명도 대비를 포함한 접근성 미준수로 공공·민간 기관이 소송·시정명령을 받은 사례가 다수 있습니다. 명도 대비를 “나중에 챙길 디테일”로 미루기 어려운 이유입니다.

결론: 명도 대비는 디자인의 마지막 단계에 ’검수’하는 항목이 아니라, 색을 고르는 첫 순간부터 전제되어야 하는 제약 조건입니다. 그리고 1편에서 본 것처럼, KRDS 팔레트를 매직 넘버 규칙대로 쓰면 이 제약이 자동으로 충족됩니다.

3. 명도 대비란 정확히 무엇인가 — 1:1부터 21:1까지

겁먹을 필요 없습니다. 개념만 잡으면 됩니다.

대비비(Contrast Ratio)라는 숫자

두 색의 대비는 X : 1 형태의 숫자로 표현됩니다.

1 : 1 — 두 색의 밝기가 완전히 같음 (예: 흰 바탕에 흰 글씨 = 안 보임)

21 : 1 — 가능한 최대 대비 (순흑 글씨 + 순백 배경)

숫자가 클수록 또렷합니다. WCAG는 이 숫자에 합격선을 그어 둡니다.

WCAG 합격선 (이 표가 핵심입니다)

대상	Level AA (기본)	Level AAA (강화)
본문 텍스트 (작은 글씨)	4.5 : 1	7 : 1
큰 글씨 (18pt↑ / 14pt 굵게↑)	3 : 1	4.5 : 1
UI 요소·아이콘 (비텍스트)	3 : 1	—

공공 웹은 일반적으로 AA 준수가 기준입니다. 즉 본문은 4.5:1, 큰 글씨는 3:1만 기억하면 80%는 끝납니다.

그 숫자는 어떻게 나오나 (안 어렵습니다)

원리만 짚고 갑니다. 컴퓨터는 두 색의 상대 밝기(relative luminance) 를 계산한 뒤, 아래 공식에 넣습니다.

대비비 = (밝은 색의 밝기 + 0.05) ÷ (어두운 색의 밝기 + 0.05)

여기서 ’밝기’는 단순 평균이 아니라, 사람 눈이 초록에 가장 민감하고 파랑에 둔감한 점을 반영한 가중 공식을 씁니다.

밝기(L) = 0.2126 × R + 0.7152 × G + 0.0722 × B (각 채널을 sRGB 보정한 값)

→ 외울 필요는 전혀 없습니다. 핵심은 “사람이 손으로 어림할 게 아니라, 정해진 공식으로 계산되는 객관적 수치” 라는 점. 그래서 명도 대비는 자동 점검에 가장 적합한 항목 중 하나입니다.

숫자로 보는 실제 예 — ‘회색의 합격선’

추상적이니 실제 색으로 확인해 봅시다. 흰 배경(#FFFFFF) 위에 놓인 회색 글씨들의 대비비입니다.

글자색	흰 배경 대비비	본문 4.5:1	큰글씨 3:1
#949494 (밝은 회색)	약 2.9 : 1	❌ 불합격	❌ 불합격
#959595	약 3.0 : 1	❌ 불합격	✅ 합격
#767676 (회색)	약 4.54 : 1	✅ 합격	✅ 합격
#595959 (진회색)	약 7.0 : 1	✅ 합격(AAA)	✅ 합격

흥미로운 지점 — #767676이 흰 배경에서 본문 합격선(4.5:1)을 겨우 넘는 ‘마지노선 회색’ 입니다. 디자이너가 흔히 쓰는 #999(약 2.85:1)나 #888은 본문으로는 불합격입니다. “연한 회색 본문”이 위반 1순위인 이유가 숫자로 드러납니다. 즉 흰 배경 본문 회색은 최소 #767676보다 진해야 합니다.

4. KRDS ‘매직 넘버’ — 계산 없이 대비 맞추기

1편에서 예고한 KRDS의 영리한 장치, 매직 넘버(Magic Number) 가 여기서 진가를 발휘합니다.

KRDS 팔레트는 색마다 0~100의 명도 단계를 갖습니다. 매직 넘버는 두 색의 단계 차이만으로 대비비를 바로 알 수 있게 한 약속입니다.

두 색의 매직넘버 차이	보장되는 대비비	용도
40	3 : 1	큰 글씨·UI 요소 (AA)
50	4.5 : 1	본문 텍스트 (AA) ← 가장 중요
70	7 : 1	본문 강화 (AAA)
90	15 : 1	선명한 화면 모드 본문

실전 사용법

예를 들어 배경이 Gray-5(아주 연한 회색)라면,

본문 글자는 매직넘버 차이가 50 이상인 단계 → Gray-55 이상의 진한 색을 골라야 4.5:1 충족

큰 제목은 차이 40 이상 → Gray-45 이상이면 3:1 충족

즉 “이 글자가 4.5:1을 넘나?”를 계산기로 두드릴 필요 없이, 팔레트 단계 숫자만 빼면 됩니다. 이것이 1편에서 말한 “팔레트를 쓰면 접근성이 자동 보장된다” 의 구체적 메커니즘입니다.

DS-001과 DS-002의 관계: DS-001(팔레트 우선 사용)을 지키면 DS-002(명도 대비)는 저절로 충족되기 쉽습니다. 반대로 팔레트를 무시하고 임의 색을 쓰면, 대비 계산을 일일이 해야 하고 십중팔구 어딘가에서 깨집니다. 두 규칙은 한 몸입니다.

국내외 표준은 어떻게 다룰까 — 같은 목적, 같은 숫자

명도 대비는 전 세계가 똑같은 기준(WCAG) 을 공유합니다. 다만 ’팔레트로 대비를 보장하는 방식’은 시스템마다 표현이 다릅니다.

시스템	명도 대비 접근	기준
🇰🇷 KRDS	매직 넘버(단계 차 40/50/70/90)로 대비를 사전 보장	WCAG AA(본문 4.5:1)
🇺🇸 USWDS	색 등급(grade) 0~100. 등급 차가 클수록 대비 ↑. “magnitude”로 토큰 간 대비를 표기	WCAG AA/AAA
🇬🇧 GOV.UK	팔레트 자체를 WCAG 충족하도록 구성, 임의 조합 자제	WCAG 2.2 1.4.3 AA
🇰🇷 KWCAG	한국형 웹접근성 지침의 명시적 검사 항목	명도 대비 4.5:1(본문)

핵심은 동일합니다 — “개별 색을 그때그때 대비 검사하지 말고, 대비가 보장되는 팔레트 체계 안에서 색을 고르라.” KRDS의 매직 넘버는 그 체계를 숫자 빼기 한 번으로 가능하게 만든, 꽤 영리한 한국식 해법입니다. 국제 표준을 따르되 실무를 더 쉽게 만든 것이죠.

5. 큰 글씨는 기준이 다르다 — ‘18pt의 함정’

명도 대비에서 자주 틀리는 부분이 ‘큰 글씨 예외’ 입니다. 큰 글씨는 본문보다 느슨한 3:1만 넘으면 됩니다. 그런데 “큰 글씨”의 기준이 모호해서 실수가 납니다.

구분	기준 (point)	환산 (CSS px, 대략)
큰 글씨 (일반)	18pt 이상	약 24px 이상
큰 글씨 (굵게)	14pt 이상	약 18.5px 이상

(point→px 환산: 1pt ≈ 1.333px)

자주 하는 실수

“제목이니까 큰 글씨겠지” 하고 넘겼는데 실제론 16px → 본문 기준(4.5:1) 적용 대상이라 미준수

굵게 처리했으니 14pt 기준일 거라 생각했는데, 가는(thin) 폰트라 실제 굵기가 부족

반응형에서 모바일일 때 글자가 작아지면서 “큰 글씨”가 “본문”으로 바뀜 → 기준이 올라감

실무 팁: 헷갈리면 그냥 본문 기준(4.5:1)으로 통일하는 게 안전합니다. 큰 글씨 예외(3:1)는 “최소한 이건 넘어야 한다”는 하한선이지, 권장이 아닙니다.

6. 텍스트만이 아니다 — ‘비텍스트 대비’(WCAG 1.4.11)

명도 대비를 ’글자색’만의 문제로 아는 경우가 많은데, 2018년 WCAG 2.1부터 비텍스트 요소도 대상이 됐습니다(성공기준 1.4.11). 공공 웹 점검에서 점점 비중이 커지는 부분입니다.

무엇이 대상인가

UI 요소와 의미 있는 그래픽이 인접한 색과 3:1 이상 대비를 가져야 합니다.

입력 폼 테두리 — 흰 배경에 아주 연한 회색 테두리 = 입력칸인지 인식 불가 → 위반

버튼 경계 — 배경과 구분 안 되는 ‘ghost button’(투명 버튼) → 위반

체크박스·라디오·토글 — 선택 가능한 컨트롤임을 알 수 있어야 함

아이콘 — 글자 없이 아이콘만으로 기능을 표현하면, 그 아이콘이 또렷해야 함

그래프 선·차트 요소 — 내용 이해에 필요한 부분

상태(state)도 봐야 한다

가장 놓치기 쉬운 부분입니다. 컨트롤은 여러 상태를 갖습니다.

기본(default) / 마우스 올림(hover) / 키보드 초점(focus) / 선택됨(selected) / 오류(error)

WCAG는 이 상태들을 식별하는 데 필요한 시각 정보도 3:1을 요구합니다. 특히 키보드 초점 표시(focus ring) 가 연해서 안 보이면, 키보드만 쓰는 사용자는 “지금 어디에 있는지” 알 수 없습니다.

예외 — 비활성(disabled)

단, 비활성 상태(지금 누를 수 없는 회색 처리된 버튼)는 이 기준에서 제외됩니다. 의도적으로 흐리게 한 것이므로 대비 미달이어도 위반이 아닙니다. (이건 뒤의 ‘예외 N/A’ 판단과 연결됩니다.)

참고 데이터: 닐슨노먼그룹 연구에 따르면, 시각적 대비가 부족하면 사용자가 버튼·상호작용 요소를 인지하지 못하는 비율이 40% 더 높아진다고 합니다. 비텍스트 대비는 ’미관’이 아니라 ’사용 가능성’의 문제입니다.

7. 현장에서 가장 많이 깨지는 곳 — 위반 패턴 7

실제 점검에서 DS-002 위반은 거의 정해진 자리에서 나옵니다.

연회색 본문/안내문구 — “부가 설명은 연하게”라는 디자인 관행. #999 회색 글씨가 흰 배경에서 2.8:1 정도 → 본문 4.5:1 미달의 1순위.

플레이스홀더(placeholder) — 입력칸 안내문구를 연하게 처리. 게다가 사용자가 정보를 입력하면 사라지므로, 안내 의존도가 높을수록 위험.

고스트 버튼(ghost button) — 테두리만 있고 배경 투명한 버튼. 배경과 테두리 대비가 약하면 ’버튼인지’조차 모름 (1.4.11 위반).

컬러 버튼 위의 글자 — 밝은 색 버튼에 흰 글씨, 연한 색 버튼에 회색 글씨. 버튼색-글자색 대비 누락.

비활성과 활성의 혼동 — 활성 버튼이 너무 연해서 비활성처럼 보임 (역으로 비활성이 활성처럼 보이는 경우도).

이미지·그라데이션 위 텍스트 — 배경 사진/배너 위 글자. 배경이 밝은 곳·어두운 곳을 오가서 일부 구간에서 대비 붕괴.

focus 표시 약함 — 키보드 초점 테두리가 연하거나 아예 제거됨(outline: none). 접근성 치명상.

7개의 공통점: “본문 색 하나만의 문제가 아니다” 라는 것. 명도 대비는 텍스트·UI·상태·이미지 위까지 전방위로 봐야 합니다.

왜 이 위반은 사라지지 않을까 — 미감과 접근성의 긴장

명도 대비 위반은 ‘몰라서’ 보다 ‘더 예뻐 보여서’ 생기는 경우가 더 많습니다. 여기에 이 규칙의 진짜 어려움이 있습니다.

디자이너의 시각에서 연한 회색은 매력적입니다. 진한 검정 글씨로 가득 찬 화면은 답답하고 촌스러워 보이고, 연회색으로 위계를 주면 화면이 세련되고 여백이 살아납니다. 그래서 “부가 설명은 연하게”, “안내문은 흐리게”, “플레이스홀더는 은은하게”가 자연스러운 디자인 관행이 됩니다. 트렌디한 민간 서비스일수록 이 경향이 강합니다.

문제는 그 ’세련됨’의 기준이 시력 좋은 젊은 디자이너의 눈 이라는 점입니다. 같은 연회색이 누군가에게는 ’우아한 위계’이고, 누군가에게는 ’읽을 수 없는 흐릿함’입니다. 공공서비스는 후자의 사람까지 포함해야 하므로, 민간 트렌드를 그대로 따라가면 안 됩니다.

구체적인 장면을 떠올려 봅시다. 70대 어르신이 복지 급여를 신청합니다. 입력칸 아래에 회색 글씨로 “※ 주민등록상 주소를 입력하세요”라는 중요한 안내가 있습니다. 그런데 그 회색이 너무 연해서 어르신은 읽지 못합니다. 엉뚱한 주소를 넣고, 신청은 반려되고, 다시 기관에 전화를 겁니다 — 행정 비용도 늘고, 국민은 좌절합니다. 연회색 글씨 하나가 만든 연쇄입니다.

그래서 명도 대비를 지키는 핵심 태도는 기술이 아니라 관점의 전환입니다. “내 눈에 예쁜가”가 아니라 “가장 안 보이는 사용자도 읽을 수 있는가” 를 기준으로 삼는 것. 세련됨은 그다음입니다. 그리고 앞서 봤듯, 위계 표현은 연회색이 아니라 충분히 진한 회색의 단계 차이(매직 넘버) 로도 얼마든지 우아하게 만들 수 있습니다. 접근성과 미감은 사실 충돌하지 않습니다 — 충돌한다고 착각할 뿐입니다.

8. 무엇을 어떻게 점검하나

자동 점검의 원리

색 쌍 추출 — 페이지의 모든 텍스트에 대해 (글자색, 실제 배경색) 쌍을 수집합니다. ’실제 배경색’이 중요한데, 부모 요소·이미지·투명도까지 고려해 눈에 실제로 보이는 배경을 계산해야 합니다.

대비비 계산 — 각 쌍을 3섹션의 공식으로 계산.

기준 적용 — 글자 크기·굵기를 보고 4.5:1 / 3:1 중 어느 기준인지 판정.

비텍스트 점검 — 입력칸 테두리·버튼 경계·아이콘 등 UI 요소를 인접색과 3:1로 대조.

위반 리포트 — 어느 요소가 몇 :1로 미달인지, 어떤 색을 어떻게 바꾸면 통과인지 제시.

’실제 배경색’을 알아내는 게 생각보다 어렵다

명도 대비 자동 점검에서 가장 까다로운 부분이 “이 글자의 진짜 배경색이 무엇인가” 입니다. 글자색은 CSS에 명확히 적혀 있지만, 배경은 그렇게 단순하지 않습니다.

투명 배경 중첩 — 글자가 놓인 요소의 배경이 transparent면, 그 부모의 부모의… 배경까지 거슬러 올라가 실제로 비치는 색을 찾아야 합니다.

반투명(alpha) 겹침 — rgba(0,0,0,0.5) 같은 반투명 배경이 깔리면, 아래 색과 섞인 합성 색으로 계산해야 합니다.

배경 이미지·그라데이션 — 사진이나 그라데이션 위 글자는 배경색이 위치마다 다릅니다. 가장 밝은 지점과 가장 어두운 지점 모두에서 대비를 확인해야 진짜 안전합니다.

상태에 따른 변화 — hover하면 배경색이 바뀌는 버튼은, 기본·hover 두 배경 모두에서 글자 대비를 봐야 합니다.

그래서 “단순히 두 HEX 값을 넣어 계산”하는 수준을 넘어, 렌더링된 화면에서 실제로 보이는 색을 추출해야 정확합니다. 좋은 자동 점검 도구와 대충 만든 도구의 차이가 바로 여기서 갈립니다. 손으로 점검할 때도 마찬가지로, ‘어떤 배경 위의 글자인지’ 를 먼저 정확히 짚는 것이 출발점입니다.

직접 확인하려면

브라우저 개발자도구(F12) → 요소의 color / background-color 확인

무료 도구: WebAIM Contrast Checker, Stark, Colour Contrast Analyser 등에 두 색을 넣으면 대비비가 바로 나옴

⚠️ 주의: 대부분의 자동 도구는 기본(default) 상태만 검사합니다. hover·focus·선택·오류 상태는 수동으로도 확인해야 빠짐없이 점검됩니다.

9. 누가 담당하나 — ’상태’까지 책임지는 협업

단계	담당	핵심 책임
색 조합 설계	디자이너	글자색·배경색·버튼색을 매직넘버 기준 충족하게 선택
상태별 색 정의	디자이너 + 퍼블리셔	hover/focus/selected/error/disabled 각 상태 대비 확보
구현	퍼블리셔/프론트 개발	outline:none으로 focus 지우지 않기, placeholder 대비 확인
반응형 검증	프론트 개발	모바일에서 글자 작아질 때 기준 변동 확인

가장 자주 새는 지점은 ‘상태’ 입니다. 시안에는 기본 상태만 그려지는 경우가 많아, hover·focus·error의 대비가 누락된 채 개발됩니다. 상태별 색을 시안 단계에서 함께 정의하는 것이 핵심입니다.

10. 우리 사이트에 해당될까? — 적용 대상과 예외

적용 대상 — 전 기관, 전 페이지

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

글자와 UI가 있는 모든 사이트 = 전부 해당. 브랜드색을 쓰든 안 쓰든, 그 색이 글자·버튼에 닿는 순간 대비 기준을 지켜야 합니다. 명도 대비는 기관 유형과 무관하게 가장 보편적으로 적용되는 규칙입니다.

예외(N/A)가 되는 경우

DS-002는 거의 예외가 없습니다. 다만 개별 요소 단위에서 WCAG가 명시한 예외는 있습니다.

비활성(disabled) 컨트롤 — 의도적 흐림은 위반 아님

순수 장식(decorative) 요소 — 정보를 전달하지 않는 장식 텍스트/그래픽

로고·브랜드 마크 안의 글자 — 대비 기준 면제

즉 “우리 사이트는 명도 대비 점검 대상이 아님”은 성립하지 않습니다. 개별 요소 중 일부만 예외일 뿐, 사이트 전체는 항상 대상입니다.

11. 단계별 개선 방법 — Before / After

Case 1. 연회색 본문 살리기

/* ❌ Before: #999 회색 본문 → 흰 배경 대비 약 2.8:1 (미달) */ .desc { color: #999999; background: #ffffff; } /* ✅ After: 매직넘버 50 이상 단계로 (대비 4.5:1↑) */ .desc { color: var(--gray-60); background: var(--gray-0); } /* 예: #595959 → 약 7:1 */

Case 2. 고스트 버튼에 경계 부여

/* ❌ Before: 흰 배경에 연한 테두리 → 버튼 인식 불가 (1.4.11 위반) */ .btn-ghost { background: #fff; border: 1px solid #eee; color: #6cf; } /* ✅ After: 테두리·글자색을 3:1↑ 확보 */ .btn-ghost { background: #fff; border: 1px solid var(--primary-50); /* 배경과 3:1↑ */ color: var(--primary-60); /* 글자 4.5:1↑ */ }

Case 3. focus 표시 복원 (절대 지우지 말 것)

/* ❌ Before: 디자인상 거슬린다고 초점 테두리 제거 → 키보드 사용자 길 잃음 */ :focus { outline: none; } /* ✅ After: 또렷한 초점 표시 (3:1↑) */ :focus-visible { outline: 2px solid var(--primary-50); outline-offset: 2px; }

정비 우선순위

① 본문·핵심 안내 텍스트 → ② focus 표시 → ③ 입력 폼 테두리/버튼 경계 → ④ 상태별(hover/error) 색 → ⑤ 이미지 위 텍스트

12. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 본문에 #999 같은 연회색 글씨가 흰 배경 위에 있지 않나요? (가장 흔한 위반)

□ 입력칸을 클릭하지 않고도 “여기가 입력칸”임을 알 수 있나요? (테두리 대비)

□ 키보드 Tab으로 이동할 때 지금 어디 있는지 또렷이 보이나요? (focus)

□ 컬러 버튼 위 글자가 햇빛 아래서도 읽힐 만큼 또렷한가요?

□ 배너 사진 위 글자가 밝은 배경 구간에서도 안 묻히나요?

❓ FAQ

Q1. 우리 브랜드색이 연한 색인데, 그럼 못 쓰나요? 연한 브랜드색을 큰 배경이나 포인트로는 쓸 수 있습니다. 다만 그 위에 글자를 얹을 때는 글자색을 충분히 진하게(또는 밝게) 해서 대비를 확보해야 합니다. “브랜드색 금지”가 아니라 “글자 대비 확보”입니다.

Q2. 4.5:1과 3:1, 둘 중 뭘 기준으로 하나요? 본문(작은 글씨)은 4.5:1, 큰 글씨(18pt↑ 또는 14pt 굵게↑ ≈ 24px/18.5px)는 3:1입니다. 헷갈리면 전부 4.5:1로 통일하면 안전합니다.

Q3. 자동 검사 도구를 돌렸는데 통과했어요. 끝인가요? 대부분의 도구는 기본 상태만 봅니다. hover·focus·선택·오류 상태와, 이미지 위 텍스트는 별도 확인이 필요합니다. “도구 통과 = 완벽”은 아닙니다.

Q4. 비활성 버튼이 대비 미달이라고 나왔어요. 비활성(disabled) 컨트롤은 WCAG 명시 예외입니다. 의도적으로 흐리게 한 것이라면 위반이 아닙니다. 단, 활성 버튼이 비활성처럼 너무 연한 것은 문제입니다.

Q5. focus 테두리가 디자인상 보기 싫은데 꼭 있어야 하나요? 네. 키보드·보조기기 사용자에게는 필수 정보입니다. 제거(outline:none) 대신 브랜드색으로 예쁘게 디자인하세요. :focus-visible을 쓰면 마우스 사용자에겐 안 보이고 키보드 사용자에게만 표시됩니다.

Q6. 다크모드/선명한 화면 모드에서도 같나요? 원칙은 같되 기준이 더 높아집니다. 선명한 화면 모드 본문은 매직넘버 90(약 15:1)까지 요구합니다. 모드별로 대비를 각각 확보해야 합니다.

13. 마무리 — 명도 대비는 ‘배려’가 아니라 ’기본’

명도 대비를 ’접근성을 위한 추가 배려’로 여기는 순간, 그건 늘 우선순위에서 밀립니다. 발상을 바꿔야 합니다.

명도 대비는 “잘 보이게 만드는 옵션”이 아니라, “보이는 화면의 최소 조건”입니다.

그리고 다행히, 이걸 매번 계산할 필요는 없습니다. 1편의 팔레트(DS-001)를 매직 넘버 규칙대로 쓰면, 2편의 명도 대비(DS-002)는 대부분 자동으로 따라옵니다. 두 규칙이 한 몸인 이유입니다.

다음 편에서는 한 걸음 더 들어갑니다. DS-003 — “명도 대비 기준을 고려하여 단계별 색상을 설정하여 색상 팔레트를 구성하고 있다.” 개별 색의 대비를 넘어, 팔레트 전체를 대비가 보장되도록 ‘단계 설계’ 하는 이야기입니다. 오늘의 매직 넘버가 거기서 더 깊어집니다.

다음 편 예고 ▶ 「003. 명도 대비 기준을 고려하여 단계별 색상을 설정하여 색상 팔레트를 구성하고 있다.」

우리 사이트의 명도 대비, 전 페이지를 한 번에 점검하려면? ViewCheck는 사이트의 모든 텍스트-배경 색 쌍과 UI 요소를 자동으로 추출해 대비비를 계산하고, 4.5:1 / 3:1 미달 지점을 요소 단위로 목록화합니다. 비활성 요소는 예외 처리하고, 어떤 색으로 바꾸면 통과하는지까지 함께 제시합니다.

📚 참고 출처

KRDS 색상(Color) 스타일 가이드 (매직 넘버) — https://www.krds.go.kr/html/site/style/style_02.html

WCAG 2.1 Understanding 1.4.3 Contrast (Minimum) — https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

WCAG 2.1 Understanding 1.4.11 Non-text Contrast — https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

WebAIM — Contrast and Color Accessibility — https://webaim.org/articles/contrast/

W3C WCAG Techniques G18 (4.5:1) / G17 (7:1) — https://www.w3.org/TR/WCAG20-TECHS/G18.html