색상 변환·대비 검사

이 도구가 하는 일

늘 하나로 귀결되는 두 가지 일입니다. 색이 있는데 다른 표기로 필요하다 — 디자인 파일은 하나를 말하고 스타일시트는 다른 것을 원한다. 그리고 두 색이 있는데 첫째의 텍스트가 둘째 위에서 읽히는지 알아야 한다. 그래서 이 페이지는 두 색을 받아 각각을 모든 형식으로 한꺼번에 보이고 둘 사이의 대비를 측정합니다.

모두 브라우저 안에서 돕니다. 아직 공개되지 않은 브랜드 팔레트에 관해 변환을 위해 서버로 갈 것은 아무것도 없습니다.

다섯 표기

어느 것이든 붙여넣을 수 있고, 모두 돌아옵니다:

• HEX — 3, 4, 6, 8자리. 짧은 형태는 각 자리를 두 겹으로 하므로 #f0a은 #ff00aa을 뜻합니다. 4자리와 8자리는 마지막 위치에 알파를 지닙니다.
• RGB — 세 채널을 숫자나 퍼센트로. rgb(59, 130, 246)도 rgb(59 130 246 / 50%)도 받습니다. 이 도구가 되쓰는 것은 쉼표 형식입니다. 주변 대부분의 코드가 아직 그것을 쓰기 때문입니다.
• HSL — 색상을 도로, 다음으로 채도와 명도를 퍼센트로. 색상은 감기므로 480과 -120은 유효하고 120과 240을 뜻합니다.
• OKLCH — 명도, 채도, 색상을 지각적으로 균일한 공간으로. 명도는 62.8%로도 0.628로도 쓸 수 있습니다.
• CSS 이름 — 148개 모두로, rebeccapurple과 각 회색의 두 철자를 포함합니다. 이름은 정확히 맞을 때만 출력에 보입니다.

알아 둘 만한 별난 점 하나: HEX, RGB, OKLCH는 모두 왕복을 바뀌지 않고 살아남지만 HSL은 꼭 그렇지는 않습니다. 사람이 실제로 읽는 정밀도 — 정수 도, 소수 한 자리 퍼센트 — 로 표시되고, 그것으로는 1670만 sRGB 색 전부를 지정하기에 모자랍니다. HEX를 HSL로 바꿨다 되돌리면 채널이 하나 움직일 수 있습니다. 대안은 hsl(217.22, 91.19%, 59.8%) 같은 출력인데 아무도 붙여넣고 싶지 않습니다. 오차는 눈이 볼 수 있는 것을 훨씬 밑돕니다.

OKLCH가 존재하는 이유

HSL은 명도를 기술하는 것처럼 보이지만 그렇지 않습니다. 그 명도 수는 빛이 아니라 수의 성질입니다. 순수한 노랑과 순수한 파랑은 HSL에서 둘 다 명도 50%입니다:

yellow  #ffff00   hsl 명도 50%    oklch 명도 96.8%
blue    #0000ff   hsl 명도 50%    oklch 명도 45.2%

노랑이 이 둘 중 밝은 쪽이라는 것은 누구나 알 수 있고, OKLCH는 그렇게 말합니다. 이것은 학문적인 이야기가 아닙니다: HSL 명도를 일정하게 두고 색상을 돌려 만든 팔레트가 몹시 들쭉날쭉해 보이는 색 집합을 내는 이유이고, OKLCH에서 같은 수법이 가족처럼 보이는 집합을 내는 이유입니다. OKLCH에서 같은 명도의 두 색이 같은 배경에 대해 대개 비슷한 대비를 갖는 이유이기도 합니다 — HSL이 전혀 약속할 수 없는 것입니다.

남은 두 수는 채도 — 대충 얼마나 색이 진한지, 회색의 0에서 — 와 도로 된 색상입니다. HSL 채도와 달리 채도는 무언가의 퍼센트가 아니라, 쓸 수 있는 최댓값이 명도와 색상 둘 다에 달렸습니다.

색을 보일 수 없을 때

OKLCH는 보통 화면이 낼 수 있는 것보다 많은 색을 기술할 수 있습니다. 채도 0.4에서 명도 70%를 청하면 원리적으로는 있고 sRGB 어디에도 없는 초록을 이름 붙인 것입니다. 이 도구는 그런 색을 범위 안으로 눌러 담고, 조용히 다른 것을 돌려주는 대신 sRGB 밖으로 표시합니다.

경고는 눌러 담기가 실제로 얻는 색을 바꿀 때만 나타납니다. 그 구별은 들리는 것보다 중요합니다. sRGB 빨강은 색 영역 경계 바로 위에 있어, 그것에 대해 공개된 OKLCH 값은 소수 넷째 자리로 반올림하면 엄밀히는 아주 살짝 밖에 떨어집니다 — 만분의 2쯤으로, 같은 바이트에 떨어지고 눈에 보이지 않습니다. 그것에 경고하면 경고를 무시하도록 길들이게 됩니다. 광색역 팔레트의 색은 온전한 단계만큼 벗어납니다: Tailwind v4 blue-500은 파랑 채널에서 가능한 255 중 261을 청하고, sRGB 화면에서 그것은 정말로 청한 색이 아닙니다.

대비와 세 기준

대비율은 두 색의 상대 휘도를 비교합니다. 동일한 두 색의 1:1에서 흰 바탕에 검정의 21:1까지 가고, 그것을 넘는 것은 없습니다. WCAG 2.1은 세 기준을 정하고, 그것들은 서로 바꿔 쓸 수 없습니다:

• 본문 텍스트에는 4.5:1 — 18pt 미만, 또는 굵게 14pt 미만입니다. 사람이 색이 "대비에 미달한다"고 말할 때 뜻하는 것이 이것입니다.
• 큰 텍스트에는 3:1 — 18pt 이상, 또는 굵게 14pt 이상입니다. 큰 글자꼴이 스스로 더 많은 신호를 나르므로 문턱이 낮습니다.
• 컨트롤과 그래픽에는 3:1 — 입력의 테두리, 셀렉트의 화살표, 차트의 막대입니다. WCAG 2.1에서 더해졌고 널리 빠뜨려집니다. 사람이 텍스트는 확인하면서 그 둘레의 상자는 결코 확인하지 않기 때문입니다.

AAA는 앞의 둘을 7:1과 4.5:1로 올립니다. 본문에서 노려볼 만하고 브랜드 팔레트에서 맞추기는 정말 어렵습니다. 규제와 감사가 요구하는 것은 AA입니다.

그 규칙의 포인트 크기는 픽셀이 아니라 CSS 포인트입니다: 기본 설정에서 18pt는 24px, 14pt는 약 18.7px입니다. 20px 제목이 큰 텍스트에 든다고 여기기 쉽지만, 들지 않습니다.

반투명 색

불투명한 배경 위의 반투명 텍스트는 흠 없이 잘 정의된 대비율을 갖습니다: 브라우저가 칠하기 전에 두 색을 섞고, 이 도구도 그렇게 합니다. 불투명도 60%의 회색 텍스트는 착지하면 그저 더 밝은 회색이고, 착지한 것으로 측정됩니다. 알파 채널을 무시하는 도구는 누군가 보는 색이 아니라 당신이 쓴 색의 비율을 보고하고, 늘 그것을 과대평가합니다 — 당신에게 유리하게 틀리는 접근성 검사기는 없느니만 못합니다.

반투명 배경은 다른 상황이고, 이 도구는 그것을 거부합니다. 비쳐 보이는 것은 아래에 있는 것에 달렸고, 그것은 이 페이지의 두 색이 답할 수 있는 것이 아닙니다. 배경을 실제로 합성되는 색으로 풀어 그것을 측정하세요.

비율이 말해 주지 않는 것

통과하는 비율은 바닥이지 판정이 아닙니다. 그것이 덮지 않는 세 가지:

• 색각 특성. 동일한 휘도의 빨강과 초록은 1:1에 가까운 대비율을 갖고 누구에게나 구별되지 않습니다 — 하지만 두 색이 비율을 통과해도 여전히 두 상태를 가르는 유일한 것일 수 있고, 그것은 둘을 구별하지 못하는 사람에게 실패합니다. 결코 색상만으로 의미를 나르지 마세요.
• 가는 글씨. 공식은 획 두께에 대해 아무것도 모릅니다. 4.5:1의 극세 두께가 4:1의 보통 두께보다 읽기 어려울 수 있습니다.
• 공식 그 자체. WCAG 2 대비는 어두운 배경 위 밝은 텍스트에 야박하다고 알려져 있어, 읽히는 느낌보다 높은 비율을 보고합니다. WCAG 3을 위해 초안된 APCA는 이것을 더 잘 모델링합니다 — 하지만 규범이 아니고, 아직 어떤 감사도 받아들이지 않으며, 어긋나는 두 점수를 보여도 아무에게도 도움이 안 됩니다. 그래서 여기서 논하고 위에는 표시하지 않습니다.

자신의 코드와 결과를 비교하는 사람을 위한 구현 참고 하나: 휘도 공식은 문턱 0.03928을 쓰는데, 이는 현행 sRGB 정의의 0.04045와 아주 살짝 다릅니다. WCAG가 옛 값을 인용하므로 여기서 쓰는 것은 그 값입니다. 사양에 맞추는 것이 내부적으로 깔끔한 것보다 중요하고, 그 차이가 통과를 미달로 바꾸는 일은 결코 없습니다.