잘 보이는 화면 하나로는 부족하다

KRDS DS-005 — 일반 모드와 선명한 화면 모드를 색상 팔레트에 제공하고 있다.

0. 들어가며 — 4.5:1로도 안 보이는 사람들

2편(DS-002)에서 우리는 명도 대비 4.5:1을 ’본문의 합격선’이라고 배웠습니다. 그런데 여기 불편한 진실이 하나 있습니다.

그 4.5:1로도 글자를 읽지 못하는 사람들이 있습니다.

중증 저시력, 심한 노안, 광과민(빛에 예민한 눈), 백내장이 진행된 어르신 — 이들에게는 ’기준을 통과한 일반 화면’조차 흐릿합니다. WCAG의 최소 기준은 ’대부분’을 위한 것이지 ’모두’를 위한 것은 아닙니다.

그래서 KRDS는 한 가지를 더 요구합니다 — 일반 모드만 만들지 말고, 대비를 훨씬 더 강하게 키운 ’선명한 화면 모드’를 함께 제공하라. 그게 DS-005입니다. 이번 편은 이 ’선명한 화면 모드’가 정확히 무엇인지, 흔히 혼동하는 다크모드와 어떻게 다른지, 그리고 왜 ’나중에 필터 씌우기’가 아니라 ’팔레트에 미리 설계’해야 하는지를 끝까지 짚습니다. 접근성의 가장 깊은 층을 다루는 편입니다.

1. 규칙 원문 — 세 토막

DS-005 (디자인 스타일 > 색상) “① 일반 모드와 ② 선명한 화면 모드를 ③ 색상 팔레트에 제공하고 있다.”

① “일반 모드”

대다수 사용자가 보는 표준 색상 모드입니다. 1~4편에서 다룬 그 팔레트 — 밝은 배경에 적당히 진한 텍스트, 4.5:1 본문 대비를 충족하는 일반적인 화면입니다.

② “선명한 화면 모드”

대비를 최대로 끌어올린 별도의 색상 세트입니다. 저시력·고령·광과민 사용자가 글자와 요소를 또렷이 인식할 수 있도록, 일반 모드보다 훨씬 강한 명도 대비를 적용합니다. 핵심 단어는 ‘선명’ — 화면 전체의 또렷함을 극대화한다는 뜻입니다.

③ “색상 팔레트에 제공”

가장 중요한 조항입니다. 선명한 화면 모드를 그때그때 즉흥적으로 만드는 게 아니라, 팔레트 차원에서 미리 색 세트를 정의해 둔다는 뜻입니다. 즉 우리 디자인 시스템 안에 ‘일반용 색’과 ’선명한 화면용 색’ 두 벌이 준비돼 있어야 합니다.

정리: 일반용 색 세트 + 고대비용 색 세트, 두 벌을 팔레트에 갖춰라. 이게 DS-005의 전부입니다.

2. ’선명한 화면 모드’란 무엇인가 — 고대비 모드의 정체

선명한 화면 모드는 업계 용어로 고대비 모드(High Contrast Mode) 에 해당합니다. 일반 화면이 ‘읽을 만한’ 수준이라면, 고대비 모드는 ‘최대한 또렷한’ 수준입니다.

KRDS는 이 모드의 대비 기준을 일반 모드보다 훨씬 높게 잡습니다. 2편의 매직 넘버를 다시 떠올려 보면, 일반 모드 본문은 단계 차 50(=4.5:1)이 기준이지만, 선명한 화면 모드 본문은 단계 차 90(=약 15:1) 까지 요구합니다. 15:1은 거의 흰 바탕에 검은 글씨에 가까운, 극단적으로 또렷한 대비입니다.

구분	일반 모드	선명한 화면 모드
일반 텍스트 대비	매직넘버 40 이상(3:1)	매직넘버 70 이상(7:1)
본문 텍스트 대비	매직넘버 50 이상(4.5:1)	매직넘버 90 이상(약 15:1)
설계 목적	보편적 가독성	시각 접근성 극대화

이 차이가 의미하는 바는 분명합니다. 선명한 화면 모드는 ’조금 더 진하게’가 아니라, 대비 기준 자체를 한 단계 끌어올린 별도의 세계입니다. 그래서 색을 새로 계산해 두지 않으면 만들 수 없고, DS-005가 “팔레트에 제공하라”고 못 박은 것입니다.

어떤 사람에게 이 모드가 필요한가 — 구체적인 장면

추상적인 ’저시력’이라는 단어 뒤에는 다양한 사람이 있습니다. 몇 장면을 떠올려 봅시다.

일흔이 넘은 어르신이 있습니다. 백내장 수술 전이라 세상이 뿌옇게 보입니다. 일반 화면의 연회색 안내문은 물론이고, 4.5:1을 통과한 본문 글자조차 흐릿하게 번져 보입니다. 그런데 선명한 화면 모드로 바꾸자, 검은 바탕에 거의 흰 글자가 또렷이 떠오릅니다. 비로소 글자가 ‘읽힙니다’. 이 어르신에게 선명한 화면 모드는 ’더 편한 옵션’이 아니라, 서비스에 들어가는 유일한 문입니다.

편두통과 빛 과민(광과민)을 가진 직장인도 있습니다. 어떤 색 조합은 눈을 아프게 하고 두통을 유발합니다. 이 사람에게는 절제된 색과 강한 대비의 화면이 오히려 편합니다. 또 시력에 큰 문제가 없어도, 한낮 야외에서 햇빛에 반사된 화면을 봐야 하는 현장 근무자에게도 고대비는 큰 도움이 됩니다. 선명한 화면 모드의 수혜자는 생각보다 넓습니다.

이들의 공통점은 — 일반 모드가 ’나쁘게 만들어져서’가 아니라, 일반 모드만으로는 닿지 않는 영역에 있다는 것입니다. 일반 모드를 아무리 잘 만들어도 이 사람들에게는 부족합니다. 그래서 ’더 잘 만든 하나의 화면’이 아니라 ’대비를 극대화한 두 번째 화면’이 필요한 것입니다. DS-005는 이 두 번째 화면을 선택이 아닌 기본 제공으로 끌어올린 규칙입니다.

3. 다크모드와는 다르다 — 가장 흔한 오해

여기서 반드시 짚어야 할 오해가 있습니다. “선명한 화면 모드 = 다크모드 아닌가요?” 아닙니다. 둘은 목적도 설계도 완전히 다릅니다. 이걸 혼동하면 DS-005를 잘못 구현하게 됩니다.

목적이 다르다

다크모드 — 어두운 환경에서 눈의 피로를 줄이고, 미적 대안을 제공하는 것이 목적. 한밤중에 침대에서 폰을 볼 때 편하라고 만든 것입니다. ‘편안함’ 이 키워드.

선명한 화면 모드(고대비) — 저시력 사용자가 읽을 수 있게 만드는 것이 목적. ‘접근성’ 이 키워드.

색 구성이 다르다

다크모드 — 주로 회색조와 차분한(muted) 색을 씁니다. 순흑·순백을 피하고 부드러운 톤으로 눈을 편하게 합니다. 대비는 적당합니다.

선명한 화면 모드 — 순흑·순백에 가까운 극단적 대비와 제한된 색을 씁니다. 부드러움이 아니라 또렷함이 목표라, 색을 절제하고 대비를 극대화합니다.

결정적 차이 — “다크모드 제공”은 “접근성 충족”이 아니다

이게 핵심입니다. 다크모드를 제공한다고 해서 저시력 사용자의 접근성이 해결되는 게 아닙니다. 다크모드의 부드러운 회색 텍스트는 여전히 저시력자에게 흐릴 수 있습니다. 접근성은 ’대비를 충분히 높였느냐’의 문제이지, ’배경이 어두우냐’의 문제가 아닙니다.

흥미롭게도 KRDS의 선명한 화면 모드는 어두운 바탕에 밝은 글자를 씁니다. 배경 단계가 일반 모드와 반대로 흐릅니다.

영역(깊이)	일반 모드 (밝은 바탕)	선명한 화면 모드 (어두운 바탕)
배경 elevation	Gray10 → Gray0 → Gray5 → Gray0 (밝아짐)	Gray90 → Gray100 → Gray95 → Gray90 (어두운 바탕, 점차 밝아짐)

겉모습만 보면 “어두운 배경 = 다크모드”로 착각하기 쉽지만, 목적은 미감이 아니라 대비 극대화입니다. 어두운 바탕에 거의 흰 글자를 얹으면 15:1에 가까운 대비가 나오기 때문입니다. 같은 어두운 화면이라도 ‘편안하려고’가 아니라 ’또렷하려고’ 만든 것 — 이 차이를 이해하는 게 DS-005의 핵심입니다.

4. 왜 ’팔레트에 제공’이 핵심인가 — 사후 필터의 함정

DS-005에서 가장 자주 잘못 구현하는 지점이 바로 이것입니다. 많은 사이트가 고대비를 ‘사후 필터’ 로 처리하려 합니다. 즉 일반 화면에 CSS 필터(filter: contrast(1.5) 같은)를 덧씌워 대비를 강제로 높이는 방식입니다. 이건 DS-005가 요구하는 게 아닙니다.

사후 필터에는 치명적 문제가 있습니다.

색이 깨진다 — 전체 대비를 일괄로 올리면 의도한 색 관계가 망가집니다. 강조색이 튀거나, 미묘한 구분이 사라지거나, 이미지가 이상해집니다.

부분 제어가 안 된다 — “본문은 15:1로, 아이콘은 7:1로” 같은 세밀한 조정이 불가능합니다.

예측 불가능 — 필터 결과가 색마다 제각각이라 일관성이 깨집니다.

그래서 DS-005는 ‘팔레트에 미리 제공’ 을 요구합니다. 일반 모드 색 세트와 별도로, 선명한 화면 모드용 색 세트를 처음부터 설계해 토큰으로 정의해 두라는 것입니다. 사용자가 모드를 전환하면 화면이 필터를 씌우는 게 아니라, 미리 준비된 다른 색 세트로 통째로 교체됩니다. 그래야 모든 요소의 대비가 의도대로 정확히 보장됩니다.

이건 3·4편에서 본 원리의 연장입니다 — 접근성은 사후 처리가 아니라 사전 설계로 해결한다. 선명한 화면 모드도 마찬가지로, ‘만들어 둔 화면에 나중에 덧씌우는 것’이 아니라 ’처음부터 두 벌의 팔레트를 설계하는 것’ 입니다.

조금 더 구체적으로 비교해 봅시다. 사후 필터 방식에서는, 예를 들어 연한 파란 알림 박스에 대비 필터를 씌우면 그 파랑이 형광색처럼 튀거나, 반대로 칙칙하게 죽어버립니다. 본문 글자만 또렷하게 만들고 싶었는데 배경 이미지·아이콘·강조색까지 전부 함께 일그러집니다. 결과적으로 “대비는 올라갔지만 화면은 망가진” 상태가 됩니다. 사용자는 또렷해진 글자를 얻는 대신 깨진 색 관계를 떠안습니다.

반면 색 세트를 미리 설계한 방식에서는, 같은 알림 박스가 선명한 화면 모드용으로 따로 지정된 색(예: 어두운 바탕에 어울리는 또렷한 파랑과 충분히 밝은 텍스트)으로 통째로 교체됩니다. 본문은 본문대로 15:1을, 아이콘은 아이콘대로 충분한 대비를, 강조색은 강조색대로 의도된 또렷함을 갖습니다. 각 요소가 개별적으로 설계됐기 때문입니다. 모드를 전환해도 화면이 깨지지 않고, 단지 ’또렷한 버전’으로 바뀝니다.

이 차이는 결국 ’대충 밝기만 올린 화면’과 ’저시력 사용자를 위해 정교하게 다시 그린 화면’의 차이입니다. 전자는 생색내기에 그치고, 후자만이 실제로 그 사람을 화면 안으로 들입니다. DS-005가 “필터”가 아니라 “팔레트 제공”이라는 표현을 쓴 데는 이런 무게가 담겨 있습니다.

5. 누가 이 모드를 쓰는가 — 숫자로 보는 필요성

“고대비 모드, 정말 쓰는 사람이 있나?”라는 의문이 들 수 있습니다. 데이터를 봅시다.

저시력 사용자의 약 30%가 윈도우 고대비 모드를 사용합니다. 소수가 아니라, 저시력 인구의 3분의 1입니다.

전체 기기의 약 4%가 고대비 모드를 켜고 있다는 조사도 있습니다.

광과민(photosensitivity) 사용자, 편두통·뇌전증 관련으로 강한 빛/낮은 대비에 불편을 겪는 사람들도 사용합니다.

여기에 한국의 특수성을 더해야 합니다. 대한민국은 빠르게 고령화하고 있고, 공공서비스의 핵심 이용자에 고령층 비중이 높습니다. 노안과 백내장은 대비 감도를 크게 떨어뜨립니다. 즉 정부·공공 사이트일수록 선명한 화면 모드의 수요가 민간 서비스보다 더 높습니다. 복지·민원·건강 관련 서비스라면 더욱 그렇습니다.

한 명의 어르신이 복지 급여를 신청하려는데 일반 화면이 흐려서 못 읽는다면, 선명한 화면 모드는 그 사람에게 ’편의 기능’이 아니라 ‘서비스를 쓸 수 있느냐 없느냐’ 의 문제입니다. DS-005는 그 한 명을 위한 규칙입니다.

고령사회라는 구조적 이유

대한민국은 이미 65세 이상 인구 비중이 높은 고령사회에 진입했고, 이 비율은 계속 올라갑니다. 나이가 들면 누구에게나 노안이 오고, 수정체가 탁해지며, 대비를 구분하는 능력이 떨어집니다. 이건 특정 장애를 가진 소수의 이야기가 아니라 모든 사람이 결국 통과하는 길입니다. 오늘 일반 화면을 편하게 보는 디자이너도 30년 뒤엔 선명한 화면 모드가 필요해집니다.

그런데 공공서비스의 이용자 구성을 보면 고령층 비중이 민간 서비스보다 높은 경우가 많습니다. 연금, 복지, 보건, 세금, 민원 — 이런 서비스는 본질적으로 전 연령, 특히 어르신이 자주 찾는 영역입니다. 즉 공공서비스는 구조적으로 ’잘 안 보이는 사용자’의 비중이 높은 서비스입니다. 민간 쇼핑몰이 젊은 사용자를 주 타깃으로 삼고 고대비를 후순위로 미룰 수 있는 것과 달리, 공공서비스에서 선명한 화면 모드는 핵심 사용자층을 위한 필수 기능에 가깝습니다.

여기에 비용 관점을 더하면 더 분명해집니다. 선명한 화면 모드가 없어서 어르신이 온라인 신청에 실패하면, 그 사람은 결국 전화 상담이나 직접 방문으로 돌아옵니다. 디지털로 처리됐어야 할 일이 오프라인 행정 비용으로 되돌아오는 것이죠. 접근성은 ‘약자를 위한 배려’ 차원을 넘어 행정 효율의 문제이기도 합니다. 한 번 잘 설계해 둔 선명한 화면 모드는, 두고두고 그 비용을 줄여 줍니다.

6. OS 설정을 존중하라 — 기술적 핵심

선명한 화면 모드를 제대로 제공하려면 한 가지 기술 원칙을 알아야 합니다 — 사용자의 OS 설정을 존중하라.

많은 사용자는 이미 자신의 기기(윈도우·맥·모바일) 차원에서 고대비/대비 설정을 켜 둡니다. 웹은 이를 감지할 수 있는 표준 도구를 갖고 있습니다.

prefers-contrast — 사용자가 더 높은 대비를 원하는지 감지하는 CSS 미디어 쿼리.

forced-colors — 윈도우 고대비 모드 등 ‘강제 색상’ 환경을 감지.

prefers-color-scheme — 라이트/다크 선호 감지(이건 다크모드용으로, 고대비와는 별개).

핵심 매너는 “사용자가 이미 정한 환경을 마음대로 덮어쓰지 말 것” 입니다. 사용자가 OS에서 고대비를 켰는데 사이트가 자기 색을 강제로 우겨넣으면, 그 사용자는 더 불편해집니다. 좋은 구현은 ① 사이트 자체에 선명한 화면 모드 전환 기능을 제공하면서, ② 동시에 OS의 고대비 설정도 감지해 자연스럽게 반응하는 것입니다.

이 부분은 DS-005(팔레트에 두 모드 제공)와 짝을 이루는 구현 차원의 이야기입니다. 팔레트가 준비돼 있어야(DS-005), 이 미디어 쿼리에 맞춰 색 세트를 갈아끼울 수 있습니다.

정작 필요한 사람이 ‘찾을 수 있어야’ 한다

선명한 화면 모드를 아무리 잘 만들어도, 그게 필요한 사람이 켜는 법을 모르면 무용지물입니다. 여기에 역설이 있습니다 — 이 기능을 가장 필요로 하는 사람이, 화면이 흐려서 전환 버튼을 못 찾는 상황입니다.

그래서 전환 기능의 ’발견 가능성(discoverability)’이 중요합니다. 전환 버튼은 화면 깊숙한 설정 메뉴 안이 아니라, 모든 페이지의 잘 보이는 위치(보통 헤더 상단의 접근성 도구 영역)에 일관되게 있어야 합니다. 아이콘만 덩그러니 두지 말고 명확한 라벨(“선명한 화면 모드”)을 함께 제공하고, 그 버튼 자체도 일반 모드에서 충분한 대비를 가져야 합니다. 정작 그 버튼이 흐릿하면 본말이 전도됩니다.

또 하나, 사용자가 한 번 선명한 화면 모드를 켜면 그 선택을 기억해야 합니다. 페이지를 옮길 때마다, 다음 날 다시 방문할 때마다 일반 모드로 되돌아가 매번 다시 켜야 한다면, 그 사람은 결국 사이트를 포기합니다. 선택 상태를 저장해 두는 것은 작은 구현이지만 사용 경험을 크게 좌우합니다.

마지막으로, 이상적인 구현은 OS 설정과 사이트 설정을 함께 존중하는 것입니다. 사용자가 OS 차원에서 이미 고대비를 켜 뒀다면 사이트도 처음부터 선명한 화면 모드로 시작하고, 그러면서도 사이트 안에서 따로 끄고 켤 여지를 남겨 두는 식입니다. “사용자가 정한 환경을 존중하되, 추가 선택권은 제공한다” — 이 균형이 좋은 접근성 구현의 핵심입니다.

7. 해외 표준은 어떻게 다루나

고대비 접근성은 한국만의 요구가 아니라 국제적으로 확립된 영역입니다.

Windows 고대비 모드 / forced-colors — 운영체제 차원에서 색을 강제 치환하는 기능. 웹은 forced-colors 미디어 쿼리로 이에 대응하도록 표준화되고 있습니다.

WCAG — 1.4.3(대비 최소), 1.4.11(비텍스트 대비)에 더해, 사용자 맞춤 대비를 보장하는 방향을 강조합니다.

주요 디자인 시스템 — 성숙한 디자인 시스템들은 고대비/forced-colors 대응을 기본 요건으로 포함합니다.

그리고 거듭 강조되는 국제 공통의 메시지가 있습니다 — “다크모드를 제공한다고 WCAG 대비 요건이 충족되는 것은 아니다.” 다크모드는 미적 선택이고, 접근성은 대비의 문제입니다. KRDS가 ’다크모드’가 아니라 ’선명한 화면 모드’라는 이름을 쓰고, 그 기준을 매직넘버 90(15:1)까지 끌어올린 것은 이 구분을 분명히 한 것입니다.

8. 무엇을 점검하나

DS-005는 팔레트에 두 모드의 색 세트가 갖춰져 있느냐를 봅니다.

두 모드 색 세트의 존재 — 일반 모드 색과 선명한 화면 모드 색이 각각 별도로 정의돼 있는가.

고대비 기준 충족 — 선명한 화면 모드 색 세트가 강화된 대비(예: 본문 15:1)를 만족하는가.

사후 필터가 아닌가 — 단순히 filter로 대비를 올리는 임시방편이 아니라, 색 세트로 설계됐는가.

(연계) 전환·OS 대응 — 모드 전환 기능과 prefers-contrast/forced-colors 대응이 있는가.

1·2는 팔레트(토큰) 정의를 봐야 정확히 판정됩니다. 운영 화면에서는 ’선명한 화면 모드 전환 기능의 존재 여부’로 1차 판단할 수 있습니다.

9. 누가 담당하나

역할	책임
디자인 시스템 담당 / 디자이너	선명한 화면 모드 색 세트 설계(또는 KRDS 채택)
접근성 담당	고대비 세트가 강화 대비 기준을 충족하는지 검증
프론트 개발	모드 전환 구현 + prefers-contrast/forced-colors 대응

DS-005는 디자인(색 세트 설계)과 개발(전환·OS 대응)이 함께 책임지는 항목입니다. 디자이너가 두 벌의 팔레트를 만들고, 개발자가 그것을 사용자 설정에 맞춰 갈아끼우는 구조입니다.

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

적용 대상

기관 유형	DS-005 적용
중앙행정기관(대표)	✅ KRDS 두 모드 팔레트 채택
중앙행정기관(운영)	✅ 동일(접근성 중요 서비스 특히)
공공기관	✅ 동일
지방자치단체	✅ 동일

특히 민원·복지·건강·고령층 대상 서비스라면 선명한 화면 모드의 중요도가 매우 높습니다. 이용자 특성상 고대비 수요가 크기 때문입니다.

핵심: 채택이냐 설계냐

KRDS 팔레트를 채택하면 → 선명한 화면 모드 색 세트가 이미 포함돼 있습니다. 두 벌이 함께 제공되므로 DS-005의 팔레트 요건은 충족되고, 남는 건 전환 기능 구현입니다.

자체 팔레트를 설계하면 → 일반 세트와 별도로 고대비 세트를 직접 설계해야 합니다. 이건 만만치 않은 작업이라, KRDS 채택의 이점이 가장 큰 항목 중 하나입니다.

예외(N/A)

이 항목은 ’팔레트 제공’이 본질이라 거의 예외가 없습니다. 다만 점검 대상이 디자인 토큰/전환 기능이라, 운영 화면만으로는 부분 판정에 그칠 수 있습니다.

11. 단계별 개선 방법

모드별 토큰으로 색 세트 분리

/* 일반 모드 밝은 바탕 */ :root { --color-bg: var(--gray-0); /* 흰 배경 */ --color-text: var(--gray-60); /* 본문 (대비 ~4.5:1) */ } /* 선명한 화면 모드 어두운 바탕 + 극대화 대비 */ :root[data-mode="high-contrast"] { --color-bg: var(--gray-100); /* 검은 배경 */ --color-text: var(--gray-5); /* 거의 흰 글자 (대비 ~15:1) */ } /* OS 고대비 설정 자동 대응 */ @media (prefers-contrast: more) { :root { /* 고대비 토큰 적용 */ } } @media (forced-colors: active) { /* 시스템 강제 색 존중 임의 색 강요 금지 */ }

구현 체크포인트

일반/선명한 화면 모드 두 색 세트를 토큰으로 분리 정의(필터 ✗).

사용자가 직접 끌 수 있는 전환 버튼 제공(헤더 등 잘 보이는 위치).

OS 설정(prefers-contrast/forced-colors) 자동 감지 후 반응.

선택한 모드를 기억(저장)해 재방문 시 유지.

모드 전환 시 레이아웃은 그대로, 색만 바뀌게.

정비 우선순위

① 선명한 화면 모드 색 세트 정의 → ② 전환 기능 → ③ OS 설정 대응 → ④ 상태 저장

12. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 우리 사이트에 ‘선명한 화면 모드’(고대비) 전환 기능이 있나요?

□ 그 모드가 별도 색 세트인가요, 아니면 단순 필터인가요?

□ 선명한 화면 모드 본문이 극단적으로 또렷한가요(거의 흑백 대비)?

□ 사용자 OS 고대비 설정에 사이트가 반응하나요?

□ “다크모드 있으니 됐다”고 착각하고 있지 않나요?

❓ FAQ

Q1. 다크모드를 이미 제공하는데, 그걸로 DS-005 충족되나요? 아닙니다. 다크모드는 ’편안함’을 위한 미적 모드이고, 선명한 화면 모드는 ’또렷함’을 위한 접근성 모드입니다. 다크모드의 부드러운 회색 텍스트는 저시력자에게 여전히 흐릴 수 있습니다. 둘은 별개입니다.

Q2. CSS 필터로 대비를 높이면 안 되나요? 권장하지 않습니다. 전체 대비를 일괄로 올리면 색 관계가 깨지고 일관성이 사라집니다. DS-005는 미리 설계된 색 세트를 요구합니다. 필터는 임시방편일 뿐입니다.

Q3. 선명한 화면 모드는 꼭 ’어두운 배경’이어야 하나요? 핵심은 배경색이 아니라 대비 극대화입니다. KRDS는 어두운 바탕+밝은 글자로 15:1을 확보하는 방식을 씁니다. 중요한 건 ’어둡냐’가 아니라 ’또렷하냐’입니다.

Q4. 전환 버튼은 어디에 둬야 하나요? 사용자가 쉽게 찾을 수 있는 곳(헤더 상단, 접근성 도구 모음 등)에 둡니다. 정작 못 보는 사람을 위한 기능이 깊숙이 숨어 있으면 의미가 없습니다. 일관된 위치 제공이 중요합니다(이건 컴포넌트 영역과도 연결됩니다).

Q5. KRDS를 채택하면 선명한 화면 모드도 자동으로 되나요? 색 세트(팔레트)는 KRDS에 포함돼 자동 제공됩니다. 다만 전환 기능과 OS 대응은 구현해야 합니다. 팔레트는 재료이고, 전환은 조립입니다.

13. 마무리 — 접근성은 ’평균’이 아니라 ’끝단’을 본다

DS-005가 던지는 메시지는 묵직합니다.

잘 만든 화면 하나로 ’대부분’을 만족시키는 것과, ’모두’가 쓸 수 있게 하는 것은 다르다.

일반 모드는 평균적 사용자를 위한 것입니다. 하지만 공공서비스의 진짜 시험대는 평균이 아니라 끝단 — 가장 잘 안 보이는 사람, 가장 환경이 열악한 사람입니다. 선명한 화면 모드는 그 끝단을 위한 설계이고, 공공서비스이기에 더더욱 외면할 수 없는 영역입니다. 민간은 ‘안 쓰면 떠나는’ 사용자를 포기할 수 있지만, 공공은 그 한 명의 국민까지 책임져야 하니까요.

그리고 다행히, KRDS를 채택하면 어려운 색 설계는 이미 끝나 있습니다. 남는 건 ‘두 벌의 팔레트를 사용자가 오갈 수 있게 연결하는 일’ 뿐입니다.

다음 편에서는 접근성의 또 다른 축으로 넘어갑니다. DS-006 — “색약자(특히 적록색맹과 청색맹 사용자)를 고려하여 색상을 사용하고 있다.” 대비가 ’밝기’의 문제였다면, 색약은 ’색 구분’의 문제입니다. “색만으로 정보를 전달하지 말라”는 원칙의 깊은 이야기로 들어갑니다.

다음 편 예고 ▶ 「006. 색약자(특히 적록색맹과 청색맹 사용자)를 고려하여 색상을 사용하고 있다.」

우리 사이트가 선명한 화면 모드를 제대로 제공하는지 확인하려면? ViewCheck는 사이트의 모드 전환 기능과 고대비 색 세트 적용 여부, OS 설정(prefers-contrast) 대응, 그리고 선명한 화면 모드에서의 실제 대비비까지 함께 진단합니다.

📚 참고 출처

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

WCAG 2.1 Understanding 1.4.3 / 1.4.11 — https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

The Guide To Windows High Contrast Mode (Smashing Magazine) — https://www.smashingmagazine.com/2022/06/guide-windows-high-contrast-mode/

Offering a Dark Mode Doesn’t Satisfy WCAG Color Contrast (BOIA) — https://www.boia.org/blog/offering-a-dark-mode-doesnt-satisfy-wcag-color-contrast-requirements

Dark Mode for Low Vision (Perkins School for the Blind) — https://www.perkins.org/resource/dark-mode-for-low-vision/