[접근성연구·저시력] 우리 본문은 충분히 또렷한가

대비 점검 관점

〈디지털 접근성 연구 031〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞의 두 편에서 우리는 4.5대 1이라는 최소선의 의미(029)와, 낮은 대비가 현실에서 어떻게 나타나는지(030)를 살펴봤다. 이제 남은 질문은 가장 실용적인 것이다. 우리 화면의 본문은 충분히 또렷한가? 이 질문에 "그런 것 같다"가 아니라 "재 보니 이렇다"로 답하는 방법을 정리하는 것이 이번 편의 목적이다.

이번 편은 'C 점검' 관점이다. 대비 점검은 접근성 점검 중에서도 비교적 명확한 축에 든다. 색값만 알면 숫자가 나오고, 그 숫자를 기준과 비교하면 되기 때문이다. 그러나 '명확하다'와 '쉽다'는 다르다. 어디를 재야 하는지, 무엇을 놓치기 쉬운지, 숫자가 통과해도 왜 여전히 흐릿할 수 있는지를 알아야 점검이 헛돌지 않는다. 누구나 따라 할 수 있는 대비 점검 동선을, 함정과 함께 정리한다.

1. 점검 전에 — 무엇을 재는가

대비 점검의 대상은 '글자' 하나가 아니다. 화면에는 재 봐야 할 자리가 여럿 있고, 이를 미리 목록으로 잡아 두면 빠뜨리지 않는다.

1-1. 텍스트 대비 (1.4.3)

가장 기본은 글자와 그 바로 뒤 배경 사이의 대비다. 본문, 제목, 보조 텍스트, 링크, 버튼 안의 글자 — 사용자가 읽어야 하는 모든 글자가 대상이다. 본문 같은 작은 글자는 4.5대 1, 큰 글자(대략 18pt↑ 또는 굵은 14pt↑)는 3대 1이 최소선이다(WCAG 1.4.3, 원문 확인 권장). 점검할 때는 '제일 옅은 글자'부터 보는 것이 효율적이다. 보조 텍스트와 플레이스홀더가 보통 가장 위태롭다.

1-2. 비텍스트 대비 (1.4.11)

글자가 아닌 요소도 본다. 입력 칸의 테두리, 버튼의 경계, 아이콘, 토글, 그리고 초점 표시 — 이런 UI 구성요소는 인접 색과 3대 1이 최소선이다(WCAG 1.4.11, 원문 확인 권장). "어디를 눌러야 하는지 보이는가"가 이 점검의 질문이다.

1-3. 상태 표시

같은 버튼도 기본·호버·초점·비활성 상태에서 색이 달라진다. 한 상태만 재고 끝내면, 다른 상태에서 대비가 깨지는 것을 놓친다. 특히 비활성 상태는 일부러 흐리게 하므로, 어디까지 흐려도 되는지를 함께 본다.

재 봐야 할 자리를 유형별로 정리하면, 점검을 시작할 때 빠뜨리는 곳이 줄어든다.

점검 대상	무엇을 재는가	최소선	관련 항목
본문·작은 글자	글자 ↔ 바로 뒤 배경	4.5대 1	1.4.3
큰 글자(18pt↑/굵은14pt↑)	글자 ↔ 배경	3대 1	1.4.3
테두리·아이콘·초점	UI 요소 ↔ 인접 색	3대 1	1.4.11
상태별(호버/초점/비활성)	각 상태의 색 조합	상태마다 별도	1.4.3·1.4.11

(인용) 위 최소선은 WCAG 1.4.3·1.4.11에 근거한다. 구체 수치·큰 글자 정의는 버전에 따라 달라질 수 있어 원문 확인을 권한다.

2. 점검 동선 — 재는 순서

이제 실제로 재 보는 순서를 정리한다. 도구를 쓰는 방법과 눈으로 보는 방법을 함께 둔다. 어느 하나만으로는 충분하지 않기 때문이다.

2-1. 1단계 — 색값을 확인한다

먼저 점검할 글자와 배경의 색값을 알아야 한다. 브라우저 개발자 도구의 요소 검사로 글자색(color)과 배경색(background-color)을 확인하거나, 화면에서 색을 집는 스포이드(color picker) 도구로 두 색을 딴다. 이때 주의할 점은, 글자 바로 뒤의 '실제' 배경색을 따야 한다는 것이다. 반투명 색이 겹쳐 있으면 보이는 색과 코드값이 다를 수 있다.

2-2. 2단계 — 대비비를 계산한다

두 색값을 대비비 계산 도구에 넣으면 비율과 AA/AAA 통과 여부가 나온다. 여러 공개 도구(브라우저 확장, 웹 기반 검사기 등)가 이 기능을 제공한다. 결과를 '통과/미달'로만 적지 말고, **실제 비율값(예: 3.8대 1)**을 함께 기록하는 것이 좋다. 4.4와 2.0은 같은 '미달'이어도 시급함이 다르기 때문이다.

2-3. 3단계 — 회색조로 바꿔 본다

화면을 회색조(grayscale)로 전환해 본다. 색상이 사라지고 밝기만 남으면, 색에 기대 구분하던 정보가 밝기만으로도 구분되는지가 드러난다. 회색조에서 글자가 배경에 녹아 사라진다면, 그것은 대비가 부족하다는 직관적 신호다. 이 보기는 정밀 측정은 아니지만, 숫자가 놓치는 '실제로 읽히는가'를 사람 눈으로 확인하는 데 유용하다.

2-4. 4단계 — 저시력 조건에 가깝게 본다

화면 밝기를 낮추거나, 흐림(blur) 필터를 가볍게 씌우거나, 화면을 멀리서 본다. 저시력·노안·야외 조건을 흉내 내는 것이다. 실내 밝은 화면에서 충분했던 대비가 이 조건에서 무너진다면, 점검 기록에 '환경 의존' 메모를 더한다.

2-5. 5단계 — 옅은 자리부터 훑는다

마지막으로, 측정하지 않은 자리 중 '옅어 보이는 곳'을 눈으로 훑으며 1~4단계를 반복한다. 보조 텍스트, 플레이스홀더, 비활성 항목, 옅은 경계선 — 030편에서 본 함정의 자리들이 우선 대상이다.

다섯 단계를 한눈에 정리하면 다음과 같다. 도구와 눈을 번갈아 쓰는 것이 핵심이다.

단계	하는 일	수단	보는 것
1 색값 확인	글자·배경 색값 추출	개발자 도구·스포이드	'실제' 배경색
2 대비비 계산	비율·AA/AAA 판정	대비 계산 도구	실측 비율값
3 회색조 보기	밝기만으로 구분되나	회색조 전환	녹아 사라지는지
4 저시력 모사	밝기↓·흐림·먼 거리	필터·환경 조절	환경 의존 여부
5 옅은 자리 훑기	함정 자리 반복 점검	1~4 반복	보조·플레이스홀더

(관점) 1·2단계는 '숫자', 3·4단계는 '눈'이다. 숫자만으로도 눈만으로도 부족하다. 둘을 겹쳐야 '재 보니 이렇다'와 '실제로 읽히는가'가 함께 남는다.

3. 점검에서 빠지기 쉬운 함정

대비 점검은 명확해 보이지만, 잘못 재면 엉뚱한 결론에 이른다. 자주 빠지는 함정을 알아 두면 기록의 정확도가 올라간다.

3-1. 배경을 잘못 따는 함정

가장 흔한 실수다. 글자 뒤에 그라데이션이나 사진, 반투명 오버레이가 있으면, 화면에 보이는 배경색과 실제 코드값이 다르다. 또 글자가 놓인 위치마다 배경 밝기가 다르면 대비비도 자리마다 달라진다. 사진 위 흰 글자는 가장 어두운 지점과 가장 밝은 지점 모두에서 재 보는 것이 안전하다.

3-2. 숫자만 보고 끝내는 함정

4.5대 1을 넘었다고 해서 반드시 읽기 편한 것은 아니다(029편에서 본 한계다). 가는 글꼴, 작은 자간, 어수선한 배경은 측정값과 별개로 가독을 떨어뜨린다. 숫자가 통과해도 회색조·흐림 보기에서 흐릿하다면, 그 신호를 함께 기록한다.

3-3. 한 화면만 보고 일반화하는 함정

같은 옅은 회색이 사이트 전체에서 반복된다. 한 화면에서 미달이 나오면, 그것은 그 화면만의 문제가 아니라 색 체계 차원의 문제일 가능성이 크다. 반대로 한 화면이 통과했다고 사이트 전체가 안전한 것도 아니다. 점검은 대표 화면 여럿을 표본으로 보는 것이 좋다.

3-4. 큰 글자 예외를 오용하는 함정

"큰 글자는 3대 1이면 된다"는 예외를, 작은 본문에까지 적용해 버리는 실수다. 큰 텍스트의 기준(대략 18pt↑ 또는 굵은 14pt↑)을 정확히 확인하지 않으면, 본문을 큰 글자로 착각해 미달을 통과로 잘못 적을 수 있다. 글자 크기·굵기를 함께 확인하는 습관이 안전하다.

네 가지 함정과, 각각을 피하는 점검 습관을 표로 둔다.

함정	잘못된 결론	피하는 습관
배경 오인	보이는 색으로 잘못 측정	'실제' 배경색 추출·여러 지점 측정
숫자만 신뢰	통과했으니 또렷하다 단정	회색조·흐림 보기 병행
한 화면 일반화	표본 하나로 전체 판단	대표 화면 여럿 표본
큰 글자 예외 오용	본문에 3대 1 적용	크기·굵기 함께 확인

(관찰) 네 함정 모두 '재는 행위'가 아니라 '재는 대상·범위·해석'에서 생긴다. 도구가 정확해도 무엇을 어떻게 재느냐가 어긋나면 기록이 틀어진다.

4. 점검 결과를 어떻게 적을 것인가

대비 점검의 결과는 다시 찾을 수 있게 적어야 가치가 있다. '여기 흐림'이 아니라, 누가 봐도 같은 자리를 다시 잴 수 있게 기록한다.

어디서: 어느 화면의 어느 요소(예: 신청 화면 도움말 텍스트)인가
무엇을: 글자색·배경색의 색값은 무엇인가
얼마나: 대비비 실측값(예: 3.4대 1)과 기준(4.5대 1) 비교
어떤 유형: 텍스트(1.4.3) / 비텍스트(1.4.11) / 상태별 중 무엇인가
보조 신호: 회색조·흐림 보기에서 어떻게 보였는가

이렇게 적힌 기록은 '평가표'가 아니라 '다시 찾아가는 지도'다. 우리는 대비 점검의 목적이 화면을 합격·불합격으로 가르는 데 있다고 보지 않는다. 옅어서 누군가가 읽지 못하는 자리를 찾아, 그 자리를 다시 확인할 수 있게 남겨 두는 것 — 그것이 점검이 하는 일이다.

5. 점검을 일회성으로 두지 않기

대비는 한 번 맞춰 두면 끝나는 값이 아니다. 디자인이 개편되거나, 새 컴포넌트가 추가되거나, 다크 모드가 도입되면 대비는 다시 흔들린다. 그래서 점검을 '한 번의 검사'가 아니라 '되풀이되는 확인'으로 두는 관점이 필요하다.

특히 색을 코드 안에서 토큰(예: 본문색·보조색·경계색 변수)으로 관리하면, 그 토큰들의 대비비를 한 번 정해 둔 뒤 화면 전체에 일관되게 적용할 수 있다. 새 화면이 그 토큰을 쓰는 한, 대비는 자동으로 보장된다. 029·030편에서 '색 체계'를 거듭 언급한 것이 이 때문이다. 개별 색을 그때그때 고치는 점검보다, 색 체계의 대비를 한 번 바로잡는 점검이 오래 간다.

일회성 점검과 되풀이되는 점검의 차이를 정리하면 다음과 같다.

구분	일회성 점검	되풀이되는 점검
대상	그 화면의 그 색	색 토큰 체계
개편 후	다시 깨질 수 있음	토큰 쓰면 자동 유지
다크 모드	별도 재점검 필요	토큰 세트로 함께 관리
비용	매번 반복	한 번 정하면 오래 감

(관점) 대비 점검의 종착지는 '이 화면을 고쳤다'가 아니라 '다음 화면도 자동으로 또렷하다'이다. 색을 토큰으로 다루면 점검은 한 번의 검사에서 지속되는 보장으로 바뀐다.

5-1. 반론과 한계

점검 동선이 명확하다고 해서 모든 흐림을 잡아내는 것은 아니다. 아래 반론을 함께 적어 균형을 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
"숫자만 맞추면 끝 아닌가"	측정 통과≠읽기 편함	회색조·흐림 보기 병행
"표본 몇 개로 사이트 전체를?"	표본은 일부일 뿐	대표 화면 다양화·반복
"도구마다 결과가 다르다"	계산 방식 차이 존재	같은 도구로 일관 측정

(한계) 이 글은 특정 사이트를 평가하지 않는다. 누구나 따라 할 수 있는 점검 동선을 정리했을 뿐, 합격·불합격 판정은 실제 화면과 맥락을 본 뒤의 몫이다.

5-2. ViewCheck의 관점 — 사람과 도구의 분담

대비 점검에서, 자동 점검이 잘하는 자리와 사람이 봐야 하는 자리는 다음과 같이 나뉜다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
텍스트 대비비	색값 추출 → 4.5/3대 1 계산	통과해도 가독이 떨어지는지
비텍스트 대비	테두리·아이콘 3대 1 점검	실제로 눌러야 할 곳이 보이는지
상태별 색	호버·초점·비활성 색 비교	비활성 흐림이 과한지
색 토큰 체계	같은 옅은 색 반복 탐지	토큰 위계 설계가 맞는지

(관점) 도구는 '재는 일'을 빠짐없이 대신하지만, '재는 대상과 범위를 정하는 일', '숫자가 통과해도 흐릿한지 판단하는 일'은 사람의 몫이다. 측정은 동선을 따라가고, 해석은 맥락을 따라간다.

한 장 요약

점검 단계	하는 일	함정
색값 확인	글자색·배경색 추출	반투명·그라데이션 배경 오인
대비비 계산	도구로 비율·AA/AAA 확인	실측값 안 적고 통과/미달만 기록
회색조 보기	밝기만으로 구분되는지	측정만 믿고 생략
저시력 조건	밝기↓·흐림·먼 거리	좋은 환경에서만 점검
옅은 자리 훑기	보조·플레이스홀더·경계	본문만 재고 끝냄

맺으며

"우리 본문은 충분히 또렷한가"라는 질문에, 우리는 느낌이 아니라 측정으로 답하려 했다. 색값을 따고, 비율을 재고, 회색조로 바꿔 보고, 저시력 조건에 가깝게 확인하는 — 이 동선은 누구나 따라 할 수 있다. 어렵지 않지만, 하지 않으면 가장 잘 보이는 사람의 눈이 기준이 된다.

대비 점검은 접근성에서 비교적 명확한 영역이다. 숫자가 나오고, 기준이 있고, 다시 확인할 수 있다. 그래서 우리는 이 점검을 출발점으로 삼기를 권한다. 명확한 곳에서 먼저 또렷함을 확보하면, 그 위에 글꼴·배경·환경이라는 덜 명확한 판단을 더할 수 있다. 다음 편부터는 대비를 넘어, 화면을 '소리로 읽는' 사용자 — 스크린리더를 쓰는 사람 — 에게 화면이 어떻게 전달되는지를 살펴본다.

다음 편 예고 (032): 032편은 'A 기준연구' 관점입니다. 화면을 보지 못하고 소리로 듣는 사용자에게, 이미지는 어떻게 전달될까요. 이미지를 한 줄로 설명하는 대체텍스트(alt)가 무엇이고, 무엇을 담아야 하는지를 기준 연구의 시선으로 정리합니다.

참고한 공개 자료(출처):

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast (원문 확인 권장)
W3C, Understanding WCAG 2.1 — Understanding Contrast (Minimum) / Non-text Contrast
한국웹접근성 관련 지침(KWCAG) — 명도 대비 관련 항목 (원문 확인 권장)
행정안전부, 「전자정부 웹사이트 품질관리 지침」 — 접근성 영역 (고시 원문 확인 권장)

※ 위 자료의 구체 조항·수치는 인용 시점과 버전에 따라 달라질 수 있어, 실제 적용 전 원문 확인이 안전합니다. 본 글은 연구·관점 정리이며 특정 기관의 평가가 아닙니다.