그 디자인은 틀렸다. WCAG2 명도 대비
3:1, 4.5:1 이 익숙한 명암대비가 사실은 틀렸다면?
4.5:1, 3:1과 같은 명암비를 들어본 적 있나요? 혹은 이를 나의 디자인에 반영해 본 적이 있나요?
프로덕트 디자이너/UIUX디자이너라면 한 번쯤은 으레 화면을 그린 다음 플러그인을 통해 명암대비 확인을 해 보았을 것입니다. 구글의 Material 디자인 시스템, IBM의 Carbon 디자인 시스템, 우버의 Base 등 저명한 디자인 시스템 역시 3:1, 4.5:1이라는 명암대비에 따라 색상 팔레트를 구성해 놓았습니다.
Material.io 제공 - 색상 팔레트를 제작해주는 Color Tool, LEARN MORE를 누르면 WCAG2 문서로 이동합니다.
IBM의 Carbon design system 문서, 색상 팔레트 구성시 WCAG2 기준을 준수하였음을 확인할 수 있습니다.또한, 이 논리로 색상 팔레트를 구성해주는 Leonardo나 colorbox와 같은 SaaS도 있지요.
실제로 저는 프로덕트를 만들 때 도움을 많이 받았었는데요. 클릭 몇 번으로 체계화된 색상 팔레트를 뽑아낼 수 있으니까요. 각 화면에 3과 4.5라는 숫자가 보이시나요? 두 서비스 역시 WCAG2를 기반으로 제작되었습니다.
Adobe의 Nate Baldwin이 제작한 Leonardo
Coinbase의 Kevyn Arnott이 제작한 Colobox그런데 이런 명암대비가 근원적으로 문제가 있다는 사실 알고 계셨나요?
github에는 꽤 오래전부터 이 WCAG2의 명암대비 체계에 문제를 제기한 사람이 있었습니다.
들어가기에 앞서, 자주 나오게 될 용어인 WCAG와 W3C에 대해 알아보겠습니다.
WCAG란 Web Content Accessibility Guidelines의 약자로 W3C(World Wide Web Consortium)에서 제작된 규칙입니다. W3C은 월드 와이드 웹을 개발한, 팀 버너스리가 1994년도에 웹이 진화해야 할 방향을 합의하기 위해 만든 컨소시엄으로서 웹 콘텐츠 접근성 가이드라인인 WCAG뿐 아니라 SVG 벡터 이미지 포맷, HTML5 표준안 CSS 문법 등을 확정하는 곳입니다. 웹서비스를 다루는 직군이라면, 근간이 되는 모든 규칙을 만들어나가는 곳이기 때문에 공식 사이트를 방문해서 새로 업데이트되는 부분과 내가 잘 모르지만 살펴봐야 하는 부분 등을 찾아본다면 꽤 큰 도움을 받을 수 있습니다.
예를 들어, 폰트의 관심이 많은 저는 최근 CSS Snapshot의 CSS Fonts Module Level 4라는 문서를 참고하여, font-variant-position, font-language-override 과 같은 새로 추가된 속성들의 의의와 사용법 등을 익히게 되었습니다. 기회가 된다면 웹 타이포그래피에 대한 글에서 상세한 내용을 전달드리고 싶네요.
각설하고, 문제를 제기한 사람은 Myndex로, 그는 현재 할리우드에서 영상 제작/컬러리스트/VFX 엔지니어로 일하고 있다고 밝히며, WCAG의 현재 기준이 개선되어야 한다고 주장합니다.
3:1, 4.5:1 두 가지 기준으로 명암대비를 규정하는 것은 사람 눈이 실제로 색을 인지하는 과정에 비해 너무도 단순하고, 현재 일반적으로 사용하는 LED/LCD 디스플레이 환경에 대응하지 못한다는 것이 그 이유입니다. 대표적으로 다음의 이미지를 살펴볼까요? 파란색 버튼 그룹의 경우 오른쪽이 명암대비에 부합하지만, 실제 눈으로 보았을 때는 왼쪽 버튼의 글씨가 더 눈에 잘 띄게 됩니다. 짙은 회색 버튼 그룹의 경우 왼쪽 버튼의 글씨가 확연히 눈에 띄지만 두 명암대비는 근소한 차이를 보입니다.
Myndex는 웹 페이지를 만들어 위의 버튼그룹과 비슷한 사례를 나열해두었습니다.
http://myndex.com/WEB/W3Contrastissue
그리고, 다음과 같은 점들이 개선되어야 한다고 주장하였습니다.
1. 사람 눈이 색상과 명도를 바라보는 원리를 따르는 기준이어야 할 것.
2. 지나치게 높은 명암대비에 대한 기준도 마련할 것 - 너무 높은 대비는 읽는데 오히려 자극되고 이는 방해 요소가 됨
3. 밝은 배경에 어두운 글씨, 어두운 배경에 밝은 글씨 두 상태 모두 고려하는 기준이어야 함
4. 접근성을 위해서라면 폰트 크기의 중요성을 강조할 것.
5. 여러 가이드라인에 대해 업데이트를 요구할 것
5는 내용이 복잡해 간단하게 설명드리면, Myndex가 3:1과 4.5:1이 나오게 된 기원을 따지다 보니, W3C가 WCAG2를 만들기 위해 참고하였던 ANSI-HFES-100-1988, sRGB Working Draft 1996, ISO-9241-3이라는 세 가지 가이드라인을 접하게 됩니다. 이는 모두 20년이 훌쩍 넘은 오래된 가이드라인으로, CRT 모니터 환경에서나 통용되었던 이야기라고 합니다. 특히, sRGB Working Draft 1996 문서의 디스플레이 휘도는 80 nit로 CRT기준입니다. 현재 사람들은 120 nit~160 nit사이에 익숙해져 있으며, 어떤 모바일 기기는 1200 nit까지도 표현한다 합니다. 따라서 이런 기준 들은 요즘 모니터 명암대비를 고려하여 업데이트되어야 합니다.
혹시 이 CRT모니터에 윈도우 98 뜨는게 마치 엊그제 같다면, 우리는 동년배이러한 주장은 처음 Myndex가 글을 올렸던 github뿐만 아니라 디자인 트위터에서도 소소하게 퍼져 디자이너와 개발자에게 눈길을 끌게 됩니다. 이후 많은 사람이 이 문제에 공감하여 결국, 새로 개편될 WCAG3에 Myndex의 프로포절인 APCA(Advanced Perceptual Contrast Algorithm)가 반영됩니다.
WCAG3에서 채택된 APCA에서는 어떻게 명암대비가 바뀌게 될까요?
지난 WCAG2에 비해 가장 큰 차이점은 새롭게 개편된 점수 체계입니다. 3:1, 혹은 4.5:1등의 비율 체계는 105점 만점 기준의 점수제로 변환됩니다. 높은 점수일수록 높은 명암대비를 보인다는 뜻입니다.
점수와 그에 상응하는 뜻을 간략하게 살펴보면,
15점은 텍스트가 아닌 그래픽 요소의 최소 권고 명암대비입니다.
30점은 어떤 크기의 텍스트든 이 아래로 떨어지면 안 되는 최소 권고 명암대비입니다.
45점은 큰 디스플레이 텍스트(36px/Normal)의 최소 권고 명암대비이며,
60점은 본문 텍스트(24px/Normal)가 아닌 곳의 최소 권고 명암대비입니다.
75점은 큰 본문(18px/Normal)에 권고 명암대비입니다.
90점은 일반적인 본문에 최소 권고 명암대비입니다.
새로운 기준은 글꼴 크기와 굵기 모두를 고려합니다. 위에 기준점수는 글꼴 크기와 굵기에 따라 다르게 표현됩니다. 아래를 참조하면, #ffffff배경에 #6d6 d6d 텍스트 점수가 75점이라면, 글꼴 굵기에 따라 권고 최소 글꼴 크기가 다르게 나타납니다.
또한 글씨와 배경의 색이 반전된다면 점수를 계산하는 방식이 달라집니다.
APCA 명암대비는 사람 눈이 보는 방식과 조금 더 맞닿아있습니다. 사람은 색상(Hue)과 명도(lightness)의 변화를 선형적으로 인지하지 않습니다. 색상과 명도의 변화를 선형적으로 인지하지 않는다는 말이 잘 와닿지 않을 텐데요.
아래의 이미지를 살펴보겠습니다. 언젠가는 한 번쯤 접해봤을 에드워드 아델슨의 체커보드 그림자 이미지인데요, 동색 착시의 대표적인 이미지로 흔히 눈과 뇌의 부정확성을 환기하는 이미지로 많이 쓰입니다.
그러나 이러한 사람 눈의 ‘부정확한 인식’ 때문에 역설적으로 APCA가 필요한 것입니다. 그동안 WCAG2에서는 기계적인 계산으로만 명암대비 규칙을 정했기 때문에 눈과 뇌에서 인식하는 주변 환경에 따른 ‘착시’와 같은 요소를 고려하지 못한 것이지요.
왼쪽 끝과 오른쪽 끝이 다른 색처럼 보이시나요? 중앙에 놓인 직사각형은 그라데이션이 아니라 단색입니다.이런 발전은, 아래와 같이 WCAG2에서는 해결할 수 없었던 다양한 명암대비의 문제들을 해결합니다. 디자이너들 사이에서 말이 많았던 대표적인 주황색 배경에 흰색 텍스트 버튼 또한 APCA에서는 좋은 점수로 통과합니다.
웹 접근성은 디자이너가 서비스를 만들 때, 반드시 고려해야 할 사항입니다. 저시력자와 고 연령자, 색약인 사용자도 어느 정도 포용할 수 있기 때문이지요. 이를 고려한 색상 팔레트를 따로 만든다면 굉장히 오랜 기간이 소요되기 때문에 다양한 플러그인이나 미리 만들어진 색상 팔레트로 대체하는 경우가 대부분일 것입니다. 이런 니즈를 바탕으로 한 명암대비 확인 툴도 많고요.
그렇기에 이토록 많은 사람이 널리 사용하고 있는 과거의 명도 대비 기준에 대해서 의문을 제기하고 더 나아가 이에 대한 해결책을 제시한 Myndex에 경외감이 들었습니다. 마치 통용되는 언어처럼 대다수가 쓰고 있는 상황에서 이런 결함이 있다는 것을 알리기 쉬운 일이 아니니까요.(돈을 받는 일도 아니고요.) 그는 만 3년 동안 끊임없이 숱한 논문을 보며 이의를 제기하는 댓글에 대항하기 위해(...) 뒷받침 근거를 찾고 결국 W3C에서 이를 해결하게 합니다. 참고로 말씀드리면 W3C는 그들이 다루는 많은 표준규격이 끊임없이 개선/확장되기에 매우 많은 이슈들이 논의되며, 정식으로 채택되기까지 6단계의 기나긴 과정을 거치게 됩니다. 글을 꼼꼼하게 읽은 독자라면 느끼셨겠지만, 결과적으로 Myndex가 처음 문제를 제기하고 난 해결책이 거의 그대로 받아들여집니다.(다른 가이드라인을 건드리는 건 논외로 하자고요. 또 다른 일이니까요.) 이 것은 명암대비 문제를 해결하는데 그의 영향력이 절대적이었다는 것을 뜻합니다.
APCA는 이제 시작입니다. 지금까지 설명드렸던 변화될 모습은 논의 중인 사항의 일부로 완벽한 확정이 아닙니다. (제가 글을 게시한 시점에서 이틀 전에도 규정이 수정되었습니다.) 아래와 같이 이 새로운 기준을 담은 색상 팔레트 제작 툴도 하나둘씩 나오고 있는데요. 아래의 링크로 확인해보실 수 있습니다. 또한 처음 Myndex 문제를 제기한 github페이지를 보시면 APCA와 연관된 여러 다른 이슈 페이지들이 생겨나고 있습니다. 흥미롭다고 생각하시는 분들은 참여하시어 직접 표준화에 기여를 해 보아도 좋을 것 같습니다.
https://accessiblepalette.com/
accessiblepalette.com
참고자료
https://github.com/w3c/wcag/issues/695 - 이 모든 것의 시작!
https://github.com/Myndex/SAPC-APCA/blob/master/documentation/WhyAPCA.md#why-the-new-contrast-method-apca - Myndex는 같이 이를 연구하고 개진해나갈 사람을 구하고 있습니다.
https://typefully.com/u/DanHollick/t/sle13GMW2Brp - APCA 규격을 정리한 프로덕트 디자이너 Dan Hollick의 글
