아무것도 설치하지 않고 색상 대비를 감사하는 방법

색상 대비 감사는 종종 전문적인 접근성 작업처럼 다뤄집니다. 디자인 파일을 열고, 플러그인을 설치하고, 스크린샷을 내보내고, 보고서를 실행하고, 브랜드 색상에 대해 논쟁하는 식입니다. 유용할 수는 있지만, 대부분의 팀이 시작해야 할 지점은 아닙니다.

프로덕션 웹사이트에서 가장 빠르고 신뢰할 수 있는 감사는 보통 이미 열어 둔 브라우저에서 이루어집니다. 최신 브라우저 DevTools는 계산된 색상을 검사하고, 대비 비율을 보여 주며, 상태별 스타일을 드러내고, 자동 보고서가 놓치는 까다로운 사례를 테스트하는 데 도움을 줍니다.

이 가이드는 아무것도 설치하지 않는다는 전제를 둡니다. 브라우저 확장 프로그램도, 디자인 플러그인도, 유료 감사 도구도 없습니다. 필요한 것은 페이지, 브라우저, 그리고 간단한 방법뿐입니다.

실제로 필요한 대비 규칙

대부분의 웹 작업에서 WCAG 대비는 몇 가지 기준으로 요약됩니다.

• 일반 텍스트: 배경 대비 최소 4.5:1.
• 큰 텍스트: 최소 3:1. WCAG는 이를 대략 24 CSS 픽셀, 또는 굵은 글꼴일 경우 약 18.66 CSS 픽셀로 정의합니다.
• UI 컴포넌트와 그래픽 객체: 의미 있는 경계, 아이콘, 상태, 인터페이스 이해에 필요한 차트의 일부는 최소 3:1.
• 향상된 대비: 기준선을 넘어서는 것을 목표로 한다면 일반 텍스트는 7:1, 큰 텍스트는 4.5:1.

비활성 컨트롤, 장식 요소, 로고 같은 예외가 있습니다. 이런 예외는 신중하게 사용하세요. “브랜드의 일부”라는 말은 예외가 아니라 디자인 제약입니다.

또한 대비는 접근 가능한 색상 사용의 한 부분일 뿐이라는 점을 기억하세요. 빨간색 오류 상태가 충분한 대비를 갖고 있더라도 텍스트, 아이콘 레이블, 프로그래밍 방식의 표시가 없다면 빨간색과 주변 색상을 구분하지 못하는 사용자에게는 여전히 실패할 수 있습니다.

디자인 파일이 아니라 렌더링된 페이지에서 시작하세요

디자인 파일은 유용하지만, CSS 오버라이드, 불투명도, hover 상태, 브라우저 글꼴 렌더링, 사용자 확대/축소, 다크 모드, 상속된 스타일, CMS 콘텐츠, 마케팅 임베드 같은 모든 실제 변수를 포함하지는 않습니다.

사용자가 받는 그대로의 페이지를 감사하세요.

최신 데스크톱 브라우저에서 페이지를 엽니다. Chrome, Edge, Firefox, Safari 모두 유용한 검사 도구를 갖추고 있습니다. 정확한 레이블은 다르지만 워크플로는 같습니다.

1. 텍스트나 UI 요소를 마우스 오른쪽 버튼으로 클릭합니다.
2. Inspect를 선택합니다.
3. 계산된 color와 background-color를 찾습니다.
4. 브라우저의 색상 견본이나 접근성 패널을 사용해 대비 비율을 읽습니다.
5. 통과, 실패, 불확실한 항목을 기록합니다.

Chromium 기반 브라우저에서는 색상 선택기가 텍스트에 대한 대비 비율과 WCAG 통과/실패 안내를 보여 주는 경우가 많습니다. Firefox DevTools도 접근성 정보와 색상 도구를 제공합니다. Safari의 Web Inspector는 계산된 스타일과 접근성 정보를 보여 줄 수 있지만, 워크플로는 약간 다릅니다.

핵심은 특정 브라우저가 아닙니다. 핵심은 누군가 그 컴포넌트가 사용한다고 생각하는 값이 아니라 계산된 결과를 읽는 것입니다.

먼저 작은 감사 목록을 만드세요

지칠 때까지 임의의 텍스트를 검사하지 마세요. 패턴의 짧은 인벤토리를 만드세요.

• 메인 페이지 배경 위의 본문 텍스트.
• 약한 텍스트, 캡션, 메타데이터, 플레이스홀더.
• 일반, hover, visited, focus 상태의 링크.
• 기본, 보조, 파괴적 동작 버튼.
• 폼 레이블, 도움말 텍스트, 오류 및 성공 메시지.
• 내비게이션 항목, 브레드크럼, 탭.
• 카드, 배지, pill, 태그.
• 의미를 전달하는 아이콘.
• 차트, 지도, 진행 막대, 상태 색상.
• 이미지, 비디오, 그라디언트, 반투명 오버레이 위의 텍스트.

이 정도면 일반적인 사이트에서 대부분의 실패를 찾기에 충분합니다. 또한 감사를 일회성 픽셀이 아니라 컴포넌트에 연결해 줍니다.

감사에 버튼이 포함된다면 대비 확인을 접근 가능한 웹 버튼 체크리스트의 기본 항목과 함께 보세요. 버튼 대비 문제는 누락된 포커스 상태, 불명확한 레이블, 깨진 키보드 동작 옆에 있는 경우가 많습니다.

DevTools에서 텍스트 대비를 검사하세요

단색 배경 위의 일반 텍스트라면 브라우저가 보통 대비를 계산해 줄 수 있습니다.

요소를 검사하고 color 속성을 찾습니다. 색상 견본에서 색상 선택기를 엽니다. 브라우저가 배경을 판단할 수 있다면 대비 비율을 보여 줍니다. 일부 도구는 색상 선택기 안에 해당 색상이 3:1, 4.5:1, 7:1을 통과하는 지점을 나타내는 선도 그려 줍니다.

브라우저가 실패를 보고하면, 반대로 입증할 수 있을 때까지 믿으세요. 통과를 보고하더라도 판단은 여전히 필요합니다. 작고 가는 글자, 품질이 낮은 디스플레이, 강한 안티앨리어싱, 복잡한 배경은 기술적으로 통과하는 텍스트도 약하게 느껴지게 만들 수 있습니다.

실용적인 규칙은 이렇습니다. 본문 텍스트가 4.55:1로 겨우 통과한다면 축하하지 마세요. 더 여유를 주세요. 대비 요구사항은 최소 기준이지 이상적인 목표가 아닙니다.

타이포그래피도 중요합니다. 더 크고 명확한 타입 시스템은 색상 조정을 시작하기 전부터 피로를 줄여 줍니다. 대비를 통과했는데도 페이지를 읽기 어렵게 느껴진다면, 읽기 쉬운 타입을 위한 실용 가이드처럼 더 넓은 가독성 관점으로 줄 길이, 크기, 굵기, 간격을 다시 살펴보세요.

불투명도를 포함해 실제 배경을 확인하세요

많은 대비 실수는 보이는 배경이 선언된 배경이 아니기 때문에 발생합니다.

흔한 함정은 다음과 같습니다.

• 반투명 카드 안의 텍스트.
• opacity가 적용된 부모 위의 텍스트.
• rgba() 또는 color-mix()를 사용하는 오버레이.
• 제목 뒤의 그라디언트.
• 텍스트 영역 전반에서 달라지는 배경 이미지.
• 다크 모드에서 바뀌는 테마 변수.

DevTools가 대비를 확신 있게 계산할 수 없다면, 렌더링된 전경색과 배경색을 수동으로 식별하세요. 계산된 스타일 패널을 사용하거나, 레이어를 일시적으로 비활성화하거나, 브라우저가 지원한다면 내장 색상 선택기로 보이는 색상을 샘플링하세요.

이미지 위의 텍스트는 이미지에서 가장 보기 좋은 부분을 샘플링하지 마세요. 텍스트 뒤에 올 수 있는 그럴듯한 최악의 영역을 샘플링하세요. 이미지가 CMS 업로드, 캐러셀, 반응형 크롭을 통해 바뀐다면 이는 안정적인 대비 시스템이 아닙니다. 이미지와 관계없이 텍스트를 보호하는 신뢰할 수 있는 오버레이, 텍스트 그림자, 단색 컨테이너, 그라디언트 처리를 추가하세요.

좋은 이미지 오버레이 시스템은 지루합니다. 같은 오버레이 강도, 예측 가능한 크롭 영역, 밝은 사진에서도 충분한 대비. 지루해도 괜찮습니다. 사용자는 읽으려고 하는 것입니다.

상태를 잊지 마세요

정적 스크린샷은 많은 대비 실패를 놓칩니다. 브라우저에서 상호작용 상태를 직접 감사하세요.

DevTools에서 다음과 같은 의사 클래스를 강제로 적용합니다.

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

그런 다음 계산된 색상을 다시 검사합니다.

포커스 표시기는 특별한 주의가 필요합니다. WCAG 2.2는 포커스 외형에 대한 기대치를 강화했으며, 밝은 회색 카드 위의 옅은 파란색 외곽선은 여전히 흔한 실패 사례입니다. 포커스 표시기는 인접 색상 대비 충분한 대비와 눈에 띌 만큼의 충분한 면적을 가져야 합니다.

비활성 컨트롤의 경우 WCAG 대비 규칙은 비활성 컴포넌트에 대한 예외를 둡니다. 그렇다고 비활성 컨트롤이 기본적으로 읽기 어려워도 된다는 뜻은 아닙니다. 비활성 상태가 유용한 정보를 전달한다면 읽을 수 있어야 합니다. 그렇지 않다면 애초에 표시되어야 하는지 검토하세요.

Lighthouse를 사용하되, 판단을 맡기지는 마세요

Lighthouse 같은 브라우저 감사는 일부 대비 실패를 빠르게 잡아낼 수 있습니다. 브라우저가 제공한다면 내장 감사를 실행한 뒤, 결과를 출발점으로 다루세요.

자동 검사는 계산된 대비 실패가 명확한 텍스트 노드를 찾는 데 능숙합니다. 반면 다음에는 약합니다.

• 이미지 안에 포함된 텍스트.
• Canvas로 렌더링된 레이블.
• SVG의 예외적인 사례.
• hover에서만 발생하는 실패.
• 포커스 표시기 품질.
• 색상 관계가 의미를 전달하는 차트.
• 인증, 메뉴, 폼 단계 뒤에 숨은 컴포넌트.

보고서가 초록색으로 나오더라도 대표 컴포넌트를 여전히 검사해야 합니다. 보고서가 빨간색으로 나오면 당황하지 말고 사용자 영향에 따라 실패를 분류하세요. 같은 원칙은 일반적으로 성능 및 접근성 보고서에도 적용됩니다. 도구 출력을 판결이 아니라 증거로 읽으세요. 우리는 당황하지 않고 Lighthouse 보고서를 읽는 방법에서도 이런 관점을 사용하며, 여기에도 깔끔하게 적용됩니다.

비텍스트 대비도 감사하세요

텍스트가 대부분의 관심을 받지만, WCAG는 인터페이스를 이해하거나 조작하는 데 필요한 비텍스트 콘텐츠도 다룹니다.

최소한 다음 사례를 확인하세요.

• 페이지 배경 대비 input 테두리.
• checkbox 및 radio 외곽선.
• Toggle 상태.
• 아이콘 전용 버튼.
• 오류 아이콘 및 경고 기호.
• 차트 선, 막대, 레이블.
• 진행 표시기.
• 선택된 탭 또는 활성 내비게이션 표시기.

목표는 보통 인접 색상 대비 3:1입니다. 예를 들어 흰색 배경 위의 밝은 회색 input 테두리는 거의 보이지 않을 수 있습니다. 파스텔 톤 선 다섯 개가 있는 차트는 우아해 보이면서도 사용할 수 없을 수 있습니다.

차트에서는 대비만으로 충분하지 않습니다. 정보가 색상에만 의존하지 않도록 레이블, 패턴, 선 스타일, 직접 주석, 간격을 사용하세요. 이는 색각 이상 사용자, 저시력 사용자, 빛 반사가 심한 환경에서 보는 사람, 문서 속 스크린샷을 읽는 누구에게나 도움이 됩니다.

개발자가 사용할 수 있는 형식으로 결과를 기록하세요

유용한 대비 감사는 “일부 회색이 실패한다”고 말하지 않습니다. 컴포넌트, 상태, 현재 값, 기대 기준, 제안된 수정안을 식별합니다.

간결한 형식이 잘 작동합니다.

| 컴포넌트 | 상태 | 전경 | 배경 | 비율 | 목표 | 결과 | 제안 수정안 | |---|---:|---:|---:|---:|---:|---|---| | 카드 메타데이터 | 기본 | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | 실패 | --color-text-muted-strong 사용 | | 기본 버튼 | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | 통과 | 유지 | | Input 테두리 | 기본 | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | 실패 | 테두리 토큰을 더 어둡게 조정 |

사이트에 디자인 토큰이 있다면 수정안을 토큰에 연결하세요. 실제 문제가 약한 토큰 하나라면, 개별 컴포넌트 스무 개를 패치하지 마세요.

최소 기준보다 약간 더 강하게 수정하세요

대비 실패는 나쁘게 고치기 쉬운 경우가 많습니다. 팀은 검사기가 4.51:1이라고 말할 때까지 색상을 살짝 조정한 뒤 넘어갑니다. 그러면 글꼴 렌더링, 투명도, 브라우저 차이, 테마, 이미지 변동, 향후 브랜드 수정에 대한 여유가 없습니다.

더 편안한 목표를 선호하세요.

• 본문 텍스트: 가능하다면 7:1에 가깝게.
• 약한 텍스트: 실제 콘텐츠라면 여전히 4.5:1 이상.
• UI 테두리와 아이콘: 3:1을 넉넉히 넘도록.
• 이미지 위의 텍스트: 이미지별 추측이 아니라 제어된 오버레이 사용.

웹은 저가 노트북, 어두운 휴대폰, 밝은 보도, 색이 입혀진 모니터, 오래된 디스플레이에서 보입니다. 최소 준수는 편안한 읽기와 같지 않습니다.

<!-- tool-cta:start -->

💡 이것을 시도해 보세요: DevTools에서 가져온 대비 쌍을 확인할 때 Color Converter는 hex, RGB 및 HSL 간 변환을 도와 값이 감사 메모와 일치하도록 합니다.

<!-- tool-cta:end -->

무설치 대비 감사 체크리스트

빠르지만 신뢰할 수 있는 감사를 해야 할 때 이 순서를 사용하세요.

1. 최신 브라우저에서 프로덕션 페이지를 엽니다.
2. 주요 텍스트, UI, 상태 패턴을 나열합니다.
3. DevTools에서 계산된 전경색과 배경색을 검사합니다.
4. 내장 색상 선택기나 접근성 패널을 사용해 대비를 읽습니다.
5. hover, focus, active, visited, invalid 상태를 강제로 적용합니다.
6. 이미지와 그라디언트 위의 텍스트를 그럴듯한 최악의 배경 대비로 확인합니다.
7. 비텍스트 UI 부분을 3:1 요구사항에 맞춰 확인합니다.
8. 내장 자동 감사를 전체 감사가 아니라 안전망으로 실행합니다.
9. 실패를 컴포넌트와 토큰별로 기록합니다.
10. 기준을 간신히 넘기는 것이 아니라 여유를 두고 수정합니다.

이 정도면 스택에 또 다른 도구를 추가하지 않고도 대부분의 대비 문제를 잡아낼 수 있습니다. 더 고급 감사도 여전히 필요할 때가 있습니다. 특히 대규모 디자인 시스템, 규제 대상 제품, 복잡한 데이터 시각화에서는 그렇습니다. 하지만 많은 웹사이트에서는 브라우저가 이미 필요한 증거를 제공합니다. 어려운 부분은 그것을 사용할 만큼 충분히 체계적으로 접근하는 것입니다.