모두를 위한 디자인
아름다운 기술, 웹 접근성
우리가 만든 서비스를 사용하는 유저는
[볼 수 없는], [들을 수 없는] 유저일 수도 있다.
[색을 판단하기 힘든], [키보드나 마우스 사용이 힘든] 유저일 수도 있다.
[다른 피부색과 억양을 가진], [극단적인 환경에서 일하는] 유저일 수도 있다.
세상에 당연한 건 없다.
정규분포 끝단에 위치한 사용자를 위한 기술을 알아보자.
웹 접근성(Web Accessibility)
Accessibility is the practice of making your websites usable by as many people as possibile.
MDN Web Docs
웹 접근성이란 신체/환경/문화적 차이와 장애 유무에 관계없이 누구나 웹사이트에 접근할 수 있게 기술적 보장한다는 뜻이다. 웹 표준에 속하는 개념이고, 월드 와이드 웹(www)의 창시자 버너스-리 아저씨의 웹 평등성이란 철학에서 시작되었다. 기술적 가이드라인에 대한 자세한 내용은 WCAG 가이드에 나와 있다. 인지, 운용, 이해, 견고, 총 4가지 챕터로 나뉘어있고, 모든 세부 기준은 3단계 적합성으로 분류되어 있다.
너무 공식문서와 규정만 운운하니깐 공감되지 않을 것 같다. 간단한 예를 들어보자.
(위) HTML5의 <button> 태그를 사용, (아래) <a> 태그에 이미지를 넣어 버튼처럼 사용.전맹 사용자가 해당 버튼에 접근했다고 치자, 사용자는 앞을 볼 수 없기 때문에 스크린 리더라는 프로그램을 사용해 화면의 구성을 청각적으로 듣는다. <button> 태그를 사용한 경우는 button이라는 것을 올바르게 전달할 수 있다. 하지만 <a> 태그를 사용한 경우에는 조금 다르다. 이럴 때는 alt 속성을 추가해 해당 요소에 대한 설명을 간략하게 적어야 한다. 그러면 스크린 리더는 내가 입력한 정보를 읽어준다. 버튼에 대한 예시는 정말 다양한 예시 중 하나이다. 웹 접근성은 브라우저의 특성을 반영한 개발적 설계부터 그 안에 들어가는 UI 및 콘텐츠까지 엔지니어, 비엔지니어 입장에서 다각적으로 접근할 수 있다.
다양한 사용자, 환경
다시 한번 강조하지만, 웹 접근성은 단순히 신체적 장애에 대한 문제가 아니다. 어두운, 밝은, 시끄러운, 흔들리는 등 환경적 조건부터 인종, 문화적 차이까지 다양한 내용이 해당된다. 이번 글에서는 신체적 장애와 연관된 접근성을 조명하고자 한다. 실무에서 바로 사용할 수 있는 간단한 Action Plan에 앞서, 네이버 널리에서 소개한 다양한 사용자의 종류 중 몇 가지를 알아보자.
저시력 시각장애
보통 시각장애라고 하면 앞을 완전히 볼 수 없는 전맹 시각장애를 생각하지만 90% 이상은 저시력 장애이다. 아래와 같은 사용자 및 증상이 해당되고, 화면을 크게 확대해서 사용하거나, 고대비 기능(색상 반전)을 이용한다.
양이측 반맹의 시야, 좌우 시야가 제한된다. 출처: 위키피디아* 고령자, 약시자 - 사물이 흐릿하게 보인다. 렌즈, 수술로 시력을 교정할 수 없다.
* 시야장애 - 시야의 일부분만 보인다. 좌우 시야가 비네트 된 것처럼 보이는 '양이측 반맹'이 있다.
* 색각이상 사용자(색약, 색맹) - 색을 한정적으로 구분하거나, 구분하지 못한다.
전맹 시각장애
빛을 지각하지 못하는 시각장애이다. 앞을 전혀 보지 못한다. 상대적으로 청각/촉각 등 다른 감각이 발달한다. 웹의 구조와 보이는 요소, 글씨를 읽어주는 스크린 리더를 이용한다. 컴퓨터의 음성을 점자로 출력해주는 장치를 사용하기도 한다.
손 운동/중증 운동장애
손 및 신체의 여러 부분을 자유롭게 사용할 수 없는 장애를 말한다. 일반적인 마우스나 키보드와 같은 입력장치를 사용하기 힘들다.
헤드 포인터로 물리적 입력을 한다. 출처: assistive tech한 손 키보드나 트랙볼 등 특수한 장치를 사용한다. 몸의 상당 부분이 마비된 중증 운동 장애인은 움직일 수 있는 실체 일부분을 활용한다. 역시 헤드 포인터 등 특수 장비를 이용한다.
청각장애
동영상의 음성, 오디오, 알림과 같은 사운드 콘텐츠 및 피드백을 인식할 수 없다. 자막, 대본(Script) 또는 수화를 통해 정보를 인식한다.
근데 그거 돈 돼?
웹 접근성을 알아보면서 접근성 문제는 ESG와 비슷한 입장이라는 생각이 들었다. 둘의 공통점은 대다수 법률상, 윤리상의 이유로 실천되고 있다는 점, 1차원적인 시각으로 보면 단기 이윤 창출에 도움이 되지 않는다는 점이다.
출처 : How to escape from the start-up 'valley of death'기업의 주된 목적은 탄생부터 소멸까지 '생존'이다. 법률상 이유와 마케팅, SEO(검색엔진 최적화) 등의 이유로 일정 수준 이상의 기업은 웹 접근성을 지키지만, 스타트업과 같이 시간도 리소스도 한정적인 상황에서 이를 지키기란 어려운 것이 현실이다. 하지만 알고 있는 것과 모르는 것은 차이가 크다고 생각한다. 이에, 너무 당연하다고 생각할 수 있겠지만, 웹 접근성을 처음 접하는 사람도 있을 테니 제품에 바로 반영할 수 있는 몇 가지 기초적인 Action Plan을 소개하고자 한다.
어떤 걸 할 수 있을까?
몇 가지 간단한 예를 들어 어떻게 서비스의 접근성을 높일 수 있는지 생각해보자.
색각이상을 위한 정보표시
토스, 토스 증권의 그래프가 모범사례라고 생각한다. 아래는 원본 막대, 파이 그래프와 그것을 제1색각이상(적색맹/Protanopia), 제2색각이상(녹색약/Deuteranopia)사용자 시점에서 봤을 때의 예시이다.
색약, 색맹과 같은 색각이상은 전 세계 인구 중 약 8%가 해당되는 흔한 증상이다. 적록색맹 사용자에게는 파란색이 보라색으로 보이고 갈색, 빨간색, 노란색이 모두 비슷한 갈색으로 보인다. 따라서 정보를 색으로 전달/구분할 때는 색각이상 사용자도 구분할 수 있는 색을 사용해야 한다. 색이 다양하게 쓰이는 지하철 노선도를 개편한 네이버의 디자인 사례도 훌륭한 예시이다. Photoshop의 View > Proof Setup에서 설정을 변경하여 빠르게 확인할 수 있다.
색 이외의 보조수단 사용
UI Validation은 유효성 검사에 대한 결괏값을 나타내는 방식이다. TextField에 정보를 잘 못 입력했다고 가정해보자.
A는 아무 피드백이 없는 상태이다. 사용자는 뭐가 잘못되었는지 모른다. B는 빨간색으로 무언가 틀렸다는 것을 말해준다. 하지만 색각이상 사용자라면 A ~ D 모두 회색으로 보일 것이다. C는 HelpText를 통해 문자로 무엇이 잘못되었는지 설명해준다. D는 SnackBar/Toaster 컴포넌트를 이용해 문자/색상 외 동적 피드백을 전달한다.
같은 맥락으로 NavigationBar가 있겠다. 색상과 서체 두께(Weight)와 함께 메뉴 밑 작은 막대로 활성 메뉴에 대한 시각/모션 피드백을 동시에 전달하면 효과적이다. 이처럼 단순히 색으로 정보 및 변경사항을 전달하는 데는 한계가 있다. 이럴 때는 보조수단을 적극적으로 사용하자.
Contrast Ratio
명도 대비... 디자이너가 추구하는 미적 가치와 가장 많이 충돌하는 기준이 아닐까 싶다. WCAG 2.0 가이드라인에서 AA 기준으로는 일반 텍스트는 4.5:1, 큰 텍스트는 3:1을 최소기준으로 잡고 있다. Contrast Ratio Checker를 이용해 간편하게 비율을 확인할 수 있다. Figma의 Contrast라는 플러그인을 사용하는 것도 좋다.
사실 가이드라인은 권장 사항이기 때문에 무조건 따를 필요는 없다. 실제로 4.5:1을 맞추면 굉장히 투박한 디자인이 나온다. 디자이너는 섬세한 계조를 사용한 화면을 원할 것이고, 음.. 정답은 없다. 가독성과 가시성에 영향을 주는 것은 색 말고도 크기, 자간, 행간, 레이아웃 등 여러 요소가 있으니, 그것들을 현명하게 조율하는 방법이 최선인 것 같다. 사실 디자이너 사이에서도 쉽게 의견을 조율하기 어려운 주제이다.
더 생각해보기
* 컴포넌트의 Disabled 상태에서 명도 대비를 준수하였을 때 오히려 사용자가 헷갈리지 않을까?
* 우리 서비스의 주 고객 연령층은 20~35세이다. 그들이 예쁘다고 느끼는 작은 텍스트, 밀도 높은 컴포넌트를 사용하는 게 옳지 않은가? 왜 2% 미만의 고객을 생각해야 하는가?
* 업데이트가 느린 가이드라인은 트렌드를 반영하지 못한다. 이미 사용자는 충분한 학습과 경험이 있다. 과한 배려가 아닐까?
* 다크 모드와 같이 대비(Contrast)에 대한 모드도 실험적으로 제작할 수 있지 않을까?
* Native App이라면 서체 크기를 지원하는 기능은 어떨까?
Safe Area, Touch Area
Desktop환경보다는 Mobile환경에 해당되는 내용이다.
출처 : Apple Developer, Remain Style Guide노치(Notch) 디자인이 발달하며 디스플레이의 상하좌우로 정보표시는 가능하지만, 접근은 불가능한 영역이 생겼다. Apple Developer에서는 이 부분을 Margin 영역으로 보고 Safe Area를 보장하라고 말한다. 또한, 터치 제스처의 영역을 Material Design에서는 48dp, HIG에서는 44pt로 권장하고 있다. 이는 권장 기준이고 컴포넌트의 크기, 기능의 복잡도에 따라 터치 영역은 섬세하게 지정해야 한다.
접근성(Accessibility)
사실 접근성이란 웹에만 해당되는 이야기는 아니다. 건축, HCI, 공간 디자인 등 다양한 영역에 해당되며, 인종/성 평등, 교육의 수준, 법률분쟁 등 여러 사례가 존재한다. 구글 AIUX 팀의 사례처럼 인종과 기성 문화의 스테레오 타입과 같은 레거시 문화가 접근성을 저해하는 경우도 있고, WWDC21의 Accessibility by design 세션처럼 하드웨어적인 접근성을 보장하려는 노력도 있다.
한 명의 서비스를 만드는 직업인으로서의 책임감과 의무를 운운하고 싶지는 않다. 하지만, 앞서 말했듯이 인지하고 있는 것과 아닌 것은 차이가 있다고 생각한다. 분명 매출과 지표에 임팩트를 크게 낼 수 있는 요소들은 아니다. 하지만 빛이 잘 들어오지 않는 영역까지 신경 쓸 때, 더 진정성 있는, 완성도 있는 개발/기획/디자인이 나오지 않을까 싶다.
불가능이 아닌 가능을, 고정관념이 아닌 다양성을 이야기해보자.
참고자료
Material Deisgn - Google
2021 Google I/O - Google
Human Interface Guidelines - Apple
WWDC21 - Apple
Web Content Accessibility Guidelines(WCAG) - W3C
Remain Style Guide - Remain
NULI(널리) - Naver
What is Accessibility - MDN
