글자색을 브라우저가 고른다 — contrast-color()
배경색에 따라 글자를 검정으로 할지 흰색으로 할지 고민하던 일을, 이제 브라우저가 대신 계산한다. CSS의 contrast-color() 함수가 크롬 147·엣지 147·파이어폭스 146·사파리 26에 모두 실리며 'Baseline 신규 지원'에 올랐다. 색 하나만 넘기면 그 위에서 가장 대비가 큰 흑 또는 백을 돌려주는, 접근성을 겨냥한 함수다. 다크 모드·사용자 테마·동적 색상처럼 배경이 런타임에 바뀌는 UI에서 특히 쓸모가 크다.
"크롬 147이 contrast-color()를 출시하면서, 이 접근성 기능이 모든 주요 엔진에서 쓸 수 있는 Baseline 신규 기능이 됐다."web.dev
무슨 일인가
contrast-color()는 대비를 '검사'하는 게 아니라, 주어진 색 위에서 검정과 흰색 중 대비가 높은 쪽으로 곧장 '해석'된다. 예전 이름은 color-contrast()였고 CSS Color Module Level 5에 정의돼 있다. 사용법은 color: contrast-color(var(--bg))처럼 단순하다. 다만 아직은 흑·백 두 값만 반환하고 임의의 대비 비율을 지정하는 문법은 표준에서 빠져, 미묘한 색 조정이 필요한 디자인에는 손이 더 간다. WCAG 2.x의 명도 대비를 기준으로 삼을지, 차세대 APCA를 따를지도 아직 정리 중인 영역이다.
여러 시각
편리함 뒤에는 '흑백만 돌려준다'는 한계를 둘러싼 논쟁이 있다.
- CSS-Tricks(대체 구현) — 사파리·파이어폭스가 없던 시절부터, OKLCH 상대 색상 문법으로
oklch(from var(--bg) round(1.21 - L) 0 0)한 줄이면 흑백 판정을 흉내 낼 수 있다고 정리한다. WCAG 명도 공식을 CSS로 옮기는 대신 인지 명도(L)를 쓰는, APCA에 더 가까운 접근이다. - CSS-Tricks(비판) — Andy Clarke는 순수 흑백의 대비가 "너무 높아 오히려 읽기 불편하다"고 지적한다. 기술적으로 접근성을 통과해도 실제 가독성은 나빠질 수 있다는 것. 오프화이트나 반투명 같은 선택지를 못 주는 게 이 함수의 약점이다.
왜 중요한가
색 대비는 접근성 감사에서 가장 흔히 걸리는 항목이고, 지금까지는 디자이너·개발자가 조합마다 수동으로 맞춰 왔다. contrast-color()는 그 유지보수 부담을 브라우저로 넘긴다. 사용자가 배경색을 고르는 테마 기능이나, 데이터로 색이 정해지는 차트·태그처럼 '빌드 시점에 색을 알 수 없는' 경우에 값을 미리 계산할 필요가 사라진다. 다만 법적 기준인 WCAG 2.0과 실제 가독성(APCA) 사이의 간극이 남아 있어, 자동화가 곧 '최선의 가독성'을 뜻하지는 않는다.
실무 적용
- 사용자·데이터로 배경이 정해지는 배지·태그·버튼의 글자색은 contrast-color()로 두어 조합별 하드코딩을 없앤다.
- 구버전 사파리·파이어폭스를 커버해야 하면 @supports로 감싸고, OKLCH round() 한 줄을 폴백으로 둔다.
- 흑백 대비가 과할 땐 color-mix()로 결과를 배경과 살짝 섞어 눈이 편한 준-검정/준-흰색을 만든다.
Kenny의 관점
이 함수의 진짜 가치는 접근성을 '사후 감사'에서 '설계 기본값'으로 끌어내린다는 데 있다. 예전엔 색 조합이 늘 때마다 대비를 다시 검사했지만, 이제 규칙을 한 번 선언하면 브라우저가 지켜 준다. 다만 나는 이걸 만능으로 보지 않는다 — Andy Clarke의 지적처럼 '통과'와 '읽기 편함'은 다르다. contrast-color()로 안전선을 깔되, 브랜드 색과 가독성의 균형은 여전히 사람이 조율하는 게 좋은 프런트엔드의 태도다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — web.dev ↗