A guide to designing accessible, WCAG-compliant focus indicators를 바탕으로 작성되었습니다.
안녕하세요, 빅픽처 인터랙티브 개발팀 프론트엔드(FrontEnd) 챕터 소속 박성렬입니다. 이번에는 웹 표준과 포커스 표시기에 대해서 알아보도록 하겠습니다.
우리 사이에 낯선 사람들이 삽니다. 같은 공기를 마시고 같은 공간에 사는 것은 분명합니다. 하지만 우리와는 다른 방식으로 살아갑니다. 이들이 인터넷을 사용하는 모습도 다릅니다. 머릿속에 당장 떠오르는 웹페이지는 당연히 마우스로 조작해야 하고 그렇지 않으면 응당 손가락으로라도 터치해야 합니다. 그러나 이 낯선 사람들은 마우스도 손가락도 사용할 수가 없습니다.
그러나 낯선 존재는 분명히 곁에 숨쉬며 살아있습니다. 복지부에 따르면 2020년 기준 우리나라의 장애인 수는 전체 인구 대비 5.1%에 달합니다. 손을 쓰지 못하거나, 마우스 커서를 보지 못하는 장애인의 비율로 볼 수도 있습니다. 장애인 또는 일반적이지 않은 환경에서도 웹을 편리하게 사용하도록 하는 것을 웹 접근성이라고 합니다. 웹 접근성을 준비하는 사이트는 많지 않습니다. 굳이 비율을 따져보지 않더라도 실무에서 접근성을 생각해 보며 계획한 적은 거의 없는 것 같습니다.(제 경험이 부족한 탓일 수도 있습니다)
💰경제성에 의거한 선택이라고 보기는 어렵습니다. 우리의 태도는 이상할만큼 비논리적입니다. 우리나라의 경우 마이크로소프트가 2020년 8월 인터넷 익스플로러(이하 IE)의 지원을 종료했음에도 불구하고 여전히 IE환경에서만 제공되는 사이트가 존재하는데 그 점유율이 4%입니다.
모수가 다르기 때문에 정확한 비율은 아닐지라도, 5.1%에 대해서는 침묵하고 4%에 대해서는 두려워 합니다. 개인적인 경험상 웹 표준을 위해 IE를 공개적으로 포기하려고 하면 낯설어 할 개발자가 매우 많았지만 웹 접근성을 고려하며 개발하겠다는 경우는 거의 없었습니다.
그러나 꼭 이러한 기능들이 장애인만을 위한 것도 아닙니다. 마우스나 모니터가 고장나서 익숙하지 않은 인터넷을 사용해야하는 경험이 살다가 한 번쯤은 발생하기 마련입니다. 어쩌면 우리가 그 낯선 사람들의 처지에 놓이게 될 수도 있는 것입니다.
포커스 표시기
한없이 비논리적인 우리의 패중에 "포커스 표시기(focus indicator)"가 섞여있습니다.
여기서 포커스(focus)를 집중과 같은 우리말로 표현하지 않은 것은, 입력 도구가 가진 하나의 상태를 뜻하는 별도의 용어이기 때문입니다.
💡 포커스 표시기란 마우스 없이 인터넷을 사용하기 위해 필요한 일종의 "선택 표시기"입니다.
당장 구글에 들어가서 텍스트 입력창을 클릭하고 탭(⌨️Tab)키를 두 번 누르면 아래 있는 버튼이 포커스 상태가 되면서 포커스 표시기가 나타납니다.
이 때 버튼 주변에 실선으로 표시되는 포커스 표시기가 현재 버튼이 포커싱(선택)되었다는 것을 알려줍니다. 환경에 따라 실선의 색은 약간씩 다를 수 있습니다.
위의 영상은 포커스 표시기를 사용하여 웹을 브라우징하는 모습입니다. 이처럼 포커스 표시기를 이용하면 마우스가 없이도 페이지를 탐색할 수 있습니다.
언제 볼 수 있나요? 무슨 뜻인가요?
포커스 표시기는 다음과 같은 상황에서 등장합니다.
- 인터랙션이 가능한 항목을 한 번이라도 클릭했을 경우(버튼, 입력창 등)
- 탭을 눌러서 현재 포커스의 순서를 이동시켰을 경우.
- Shift+Tab을 눌러 포커스의 순서를 역순으로 이동시켰을 경우.
- 코드로 강제로 포커스를 변경했을 경우→기획에서 포커스가 일어날 상황을 정해줄 수 있습니다.
포커스 표시기는 이런 의미로 사용됩니다.
- 마지막 입력이 일어난 곳
- 지금 키를 누르면 입력이 시작되는 곳
그래서 포커스 표시기를 보면 지금 키를 입력했을 때 어떤 입력도구가 작동할지 마우스 커서가 없어도 바로 알 수 있습니다.
포커스 표시기 가이드라인
포커스 표시기는 웹 컨텐츠 접근성 가이드라인(Web Content Accessibility Guidelines, 이하 WCAG)이라고 하는 웹 표준에서도 당당히 언급되고 있습니다.
WCAG는 웹의 표준을 담당하는 기구인 W3C(World Wide Web Consortium)에서 관리하고 있습니다. W3C는 MIT, 아마존 등 이름을 들으면 알 만한 여러개의 기업과 대학 등 조직이 뭉쳐서 운영하는 일종의 연속체(Consortium)입니다. 즉 WCAG는 공신력을 지녔다고 볼 수 있는 단체가 운영하는 단체에서 만들어낸 가이드라인입니다. 그리고 이 가이드라인은 이름에서 알 수 있듯이 웹 사용을 최대한 편리하게 하는데 초점이 있습니다.
웹 접근성을 개선하기 위해 모두가 따라야하는 웹의 기본 규칙 중 한 목차를 포커스 표시기가 차지하고 있습니다. 다행히 브라우저에서는 이 기능을 기본으로 지원합니다. 다만 구현에 있어 우리가 좀더 구체적으로 설정해야하는 것들이 있습니다.
포커스 표시기의 차이
포커스는 한 번에 한 개의 요소에만 부여될 수 있습니다. 그래서 한 눈에 알아볼 수 있어야 합니다.
WCAG에 의하면 포커스 표시기 색상은 최소 3:1의 명암비(Contrast ratio)를 이루어야 저시력자도 쉽게 파악할 수 있다고 합니다.
포커스 표시기의 기본 색상 및 형태는 대체로 아래와 같이 스타일이 없는 상태에서의 기본 UI를 바탕으로 설정되어 있습니다.
문제는 버튼과 포커스 표시기의 형태가 제각각일 경우가 많다는 것입니다.
- OS에 따라서: 맥의 경우 포커스 표시기 색상을 사용자가 강제로 변경할 수 있습니다.
- 웹 사이트에 따라서: 디자인에 따라서 기본 포커스 색상이 잘 보이지 않을 수 있습니다
- 브라우저에 따라서: 브라우저마다 기본 포커스 색상이 다를 수 있습니다.
기본 포커스 표시기의 디자인이 사이트에서 지정한 입력 영역의 색상과 충분한 대비를 이루지 못하면 포커스가 구분하기 어렵게 되어버립니다. 따라서 디자인이 바뀌었다면 포커스 표시기의 스타일도 바꿔 줄 필요가 있습니다.
또한 포커스 표시기의 기본 형태는 브라우저별로 약간씩 다르게 표기됩니다.
여기서는 차이가 별로 심하지 않습니다. 그러나 약간이라도 디자인이 달라지면 이야기는 복잡해집니다.
예를 들어 배경이 ⬛검정색인 경우를 상상할 수 있습니다.
- 파이어폭스는 기본 포커스 표시기가 검정색이기 때문에 시력에 문제가 없는 사용자도 거의 분간이 어렵습니다. 명암비가 3:1은 커녕 1:1에 근접하기 때문입니다.
- 크롬과 엣지는 흰 색을 추가하여 어느 정도 보완을 해주고 있습니다.
- 사파리나 파이어폭스는 전혀 보완이 없어 보기가 불편합니다.
이처럼 포커스 표시기가 닿는 곳의 색이 기본 바탕 색인 흰색이 아니라면, 거의 대부분 별도의 스타일 보완을 해주는 편이 좋습니다.
물론 이 와중에도 언급드린 것과 같이 적절한 명암비를 선택해야 합니다.
선택한 색이 명암비로 적절한지 확인하려면 구글에 명암비 확인도구(contrast ratio checker)를 검색합니다. 구글에 검색하니 아래 사이트를 찾을 수 있었습니다. 두 가지 색을 입력하고 명암비를 수치로 확인합니다.
사용하고자 하는 색을 찾았다면 적용해야 합니다. 아래는 CSS를 통하여 포커스 형태를 바꾸는 예시입니다.
:focus {
// 기존의 포커스 표시기 색상을 무효화한다.
outline: none;
// ...다른 포커스 표시기 색상을 추가한다.
border: 1px solid red;
box-shadow: // ...
}
코드는 프론트엔드만 보세요!👀
디자인 때문이 아니라면 왜 바꾸나요?
앞서 말했듯이 국내에서 WCAG를 준수하는 기업은 매우 드물다고 봐도 무방한 것도 사실입니다. 우리나라는 일본과 더불어, 세계적인 웹 표준과 괴리가 많아 웹 갈라파고스화가 매우 심한 지역입니다. 약간만 관심을 준다면 편의성을 개선하면서 브랜드(BI) 컬러를 다시 한 번 강조할 수 있는 좋은 기회이기도 합니다. 장님의 나라에서는 외눈박이가 왕이라는 말도 있으니까요. 특히 테크와 긱(geek)한 이미지를 노리는 회사라면 포커스 표시기가 아주 좋은 브랜딩 도구가 될 수 있습니다.
포커스 표시기 가이드라인 세부사항
포커스 표시기의 형태가 왜 바뀌어야 하는지, 그리고 기본적인 명암비를 이해했다면 추가로 확인할 사항이 있습니다.
최소영역(Minimum Area)
포커스 표시기는 다양한 형태로 만들 수 있습니다. 반드시 네모일 필요는 없습니다. 다만 이 경우에도 명암비와 마찬가지로 눈에 띌 수 있도록 충분한 영역을 확보해야 합니다. 이 때 프론트엔드와 디자인의 역할이 각각 다릅니다.
최소 영역 - 디자인
디자인의 경우 WCAG의 최소 요건을 만족하면 됩니다.
WCAG 최소 영역은 아래의 크기를 만족해야 한다
- 외곽선 형태일 경우: 포커스 되지 않은 컴포넌트의 둘레에서 1픽셀 굵기 이상
- (컴포넌트의 형태와 무관한)자유 도형일 경우: 컴포넌트의 영역(네모 형태)의 가장 짧은 면에서 최소 4픽셀 이상의 너비를 가지고, 굵기는 최소 2픽셀 이상이어야 함.
위의 그림들은 WCAG에서 직접 가져온 이미지들입니다. 가장 아래의 예시에서 볼 수 있듯이, 규칙은 생각보다 강압적이지 않습니다. 접근성을 위한 최소 요건만 만족할 수 있다면, 예술적인 자율성에 대해서는 아무런 간섭도 하지 않습니다.
WCAG에 따르면 극단적으로 이질적인 형태의 포커스 표시기도 얼마든지 사용 가능합니다. 물론 사용자가 쉽게 인식할 수 있도록 일반적인 포커스 표시기의 형태(박스 모양)를 따라간다면 더 좋겠지만요.
최소 영역 - 프론트엔드(또는 퍼블리싱)
프론트엔드의 경우 컴포넌트 설계 단계에서 주의해야 합니다. css를 통하여 포커스 영역을 표시하려면 특정한 DOM 구조를 만족해야 합니다.
<!-- ❌포커스를 제대로 표기할 수 없는 마크업 -->
<div>
<button>버튼 영역</button>
</div>
<!-- ✅포커스를 제대로 표기할 수 있는 마크업 -->
<button>
<div>버튼 영역</div>
</button>
포커스가 나타날 영역에서 button 과 같이 &:focus 의사(pseudo) 선택자를 가질 수 있는 DOM 요소로 최상단을 감싸주어야 합니다. 일반적으로 의사 선택자를 가질 수 있는 DOM 요소는 아래와 같습니다.
<a />
<button />
<input />
<select />
<textarea />
<iframe />
[contentEditable=true]
이러한 DOM요소를 사용하는 이유는 선택자를 사용해야 하는데, 자식 영역의 형태에 따라 부모 영역의 스타일을 변경할 수는 없기 때문입니다.
button:focus div {
/* ...포커스 표시기 스타일... */
}
div button:focus {
/* 이 경우 div에 스타일을 줄 수 없습니다 */
}
포커스의 영역을 별도로 지정하지 않고 잘못된 DOM 구조를 설정하여 아래와 같이 컴포넌트의 외형과 일치하지 않는 포커스 스타일이 나오는 경우가 잦습니다.
예시
아마존의 경우 상단 바에서는 아마존의 기본 BI 컬러 스키마에 맞게 포커스 표시기로 진한 노란색을 사용하고 있습니다.
상품소개란에서는 상품소개란 컬러 스키마에 맞게 포커스 표시기의 색상이 청록색으로 바뀝니다.
각 화면마다 색상은 잘 맞추었으나 형태는 생각보다 약간 이질적입니다. 아마존이 대기업으로 화면마다 분업화가 이루어져있다보니 충분히 의사소통이 되지 않아서 생긴 현상으로 보입니다.
차선책
이 같은 가이드라인을 준수하기 어렵다면, WCAG 가이드라인을 준수(보통은 구글에서 web accessibility compliant UI toolkit 등으로 검색합니다)하는 UI 툴킷을 개조하여 사용하는 것도 좋은 방법입니다.
이러한 툴킷들은 속성이나 테마에 맞추어 자동으로 가장 알맞은 포커스 표시기를 보여줍니다. 또한 포커스 표시기를 표현하기 어려운 컴포넌트도 사전에 구현하고 있어서 곯머리를 앓을 일이 훨씬 적습니다. 한 예로 제가 자주 사용하는 툴킷인 Chakra UI의 경우도 웹 접근성을 염두에 두고 만들어져 있습니다.
마치며
다시 정리해보면, 가이드라인을 준수하는 포커스 표시기를 사용할 때 분명한 이점이 있습니다.
- 마우스 없이도 사이트의 기능을 전부 활용할 수 있다
- 저시력자가 사이트를 좀더 편리하게 활용할 수 있다
- 사이트에 대해 좀더 정밀한 브랜딩을 할 수 있다
반면 이러한 포커스 표시기를 꼭 구현해야 하는지에 대해서는 자신있게 말하기 어렵습니다. 우리가 해야만 하는 웹 개발의 어두운 면이기도 합니다.
포커스 표시기는 우리의 간지러운 부분입니다. 제가 소개해드렸던 많은 개선점들과 마찬가지라고 할 수 있습니다. 외면하고 관심을 가지지 않은 채로 빨래더미가 켜켜이 쌓인 기억의 빨래바구니에 넣어놓고 신경을 끄는 편이 더 편리하고 간단합니다. 포커스 표시기가 고장난 채로 있더라도 사이트는 아무 일도 없던 것처럼 잘 돌아갈 겁니다. 그리고 우리는 다시 간지러워지기 전까지는 어디가 간지러웠는지도 잊어버립니다.
중요한 것은 어디가 간지러운지를 알고 있는 것입니다. 모든 부위에서 장인정신을 발휘하여 억지로 빠른 개발과 애자일을 무너뜨릴 필요는 없습니다. 팔이 닿지 않는 곳까지 관절을 구기면서 긁을 필요가 없다는 말이죠. 그러나 낯선 사람들은 우리가 좋든 싫든 여전히 우리 사이에 살아 숨쉬고 있고, 우리가 예상하지 못한 어느 순간에 등장할 것입니다. 그 때 놀라지 않으려면 미리 알아두는 것도 좋지 않을까 싶어서 소개해 드렸습니다. 낯선 사람들은 생각보다 가까이에 살고 있으니까요.
붙임
예전에 기술공유로 전달드린 적이 있는 내용이지만, 미국에서는 이미 미국 내 장애인 차별 금지법(Americans with Disabilities Act, 이하 ADA)이 적용되어 이로 인한 재판과 벌금 선고까지 이어진 선례가 있습니다.⚖ 2018년 벌어진 원고 서스턴 대 피고 미드베일 법인(Thurston v. Midvale Corporation) 판례입니다.
서스턴씨는 시각장애인입니다. 미드베일이라는 법인이 운영하는 식당에 웹사이트를 통해 주문하려고 시도했으나 접근성이 부족하여 주문을 할 수 없었습니다. 대신 웹사이트에 있는 전화번호로 전화 주문을 하려 하였으나 이 과정에서 불편함을 느껴 ADA법에 위반된다며 고소를 진행했습니다. 법원은 식당 웹사이트가 WCAG2.0의 최소기준을 충족하지 못했다며 서스턴씨의 손을 들어주었고, 미드베일은 항소하였으나 대법원은 2심에서 항소를 기각하고 미드베일사에게 4,000달러의 보상금을 지급하라고 선고했습니다.
이 판결문은 pdf형태로 인터넷에서 열람이 가능(영문)합니다.
법적으로는 우리나라 역시 장애인차별금지 및 권리구제 등에 관한 법률로 정보통신에서 장애인을 차별하지 않는 정당한 편의제공에 대한 의무가 있음을 명시하고 있습니다. 그러나 관습을 따져보자면 웹 표준을 지키지 않는 우리나라에서는 이러한 사례가 바로 적용되기 어려워 보입니다.
따라서 지금은 급하게 대처할 의무는 없습니다. 하지만 법적으로 좋은 판례가 없고, 경제성에 위반된다고 해서 고개를 돌리는 것도 꺼림칙하기는 하네요.😬
'레벨업의 테크노트' 카테고리의 다른 글
[프론트엔드/디자인]디자인이 프론트엔드와 figma로 대화하는 법 (0) | 2022.01.14 |
---|---|
[프론트엔드] ClientOnly 컴포넌드 개발 여행 (0) | 2022.01.12 |
[프론트엔드]Vue build time 최적화 해보기 feat.Vite - 2탄 (1) | 2022.01.11 |
블로그 사이트 재구성하기 2 - 개발하기 (0) | 2022.01.11 |
블로그 사이트 재구성하기 1 - 기획과 디자인 (0) | 2022.01.11 |
댓글