접근성

화면을 만드는 사람은 대개 자기와 비슷한 사람을 떠올리며 만듭니다. 시력이 좋고, 오른손에 마우스를 쥐고 있고, 조용한 사무실의 큰 모니터 앞에 앉아 있는 사람입니다. 이 가정 바깥에 있는 사람은 화면을 열자마자 막히는데, 만든 쪽은 그 사실을 오래 모릅니다. 화면이 안 열리는 것이 아니라 열리기는 하는데 쓸 수가 없는 상태라서 오류 기록에 아무것도 남지 않기 때문입니다.

그 시절 문의 창구에서 이런 대화가 오갔습니다. 사용자가 "탭 키로는 저장 버튼까지 갈 수가 없습니다" 라고 쓰면, 답장은 "마우스로 클릭해 보시겠어요" 였습니다. 마우스를 쓸 수 없어서 보낸 문의에 마우스를 쓰라는 답이 돌아온 겁니다. 묻는 쪽도 답하는 쪽도 악의는 없었고, 다만 그런 사용자가 있다는 것을 계산에 넣어 본 적이 없었습니다. 이런 문의는 대개 한 번 오고 끊깁니다. 두 번째 답장까지 같은 말이 돌아오면 사람은 문의를 그만두고 서비스를 바꾸기 때문에, 지표에는 문의 건수가 아니라 이름 없는 이탈로만 남습니다.

문제가 개인의 사정으로 읽히는 한 고칠 사람이 정해지지 않습니다. 접근성이라는 말이 바꾼 것이 이 지점입니다. 눈이 보이지 않아서 못 쓴다고 적으면 고칠 데가 없지만, 이미지에 설명이 붙어 있지 않아서 못 쓴다고 적으면 고칠 파일과 고칠 사람이 생깁니다. 원인을 사람의 몸에서 화면의 결함으로 옮겨 놓은 것이 이 개념이 한 일의 전부라고 해도 됩니다. 쓸 수 없는 상태가 결함으로 적히면 다른 결함과 같은 줄에 놓여 순서를 다툴 수 있게 됩니다.

여기에 접근성 법제가 겹치면서 순서가 한 번 더 바뀌었습니다. 장애가 있는 사람도 서비스를 쓸 수 있게 하라고 요구하는 규정으로, 한국의 장애인차별금지법과 미국의 관련 법이 여기 해당합니다. 공공기관과 일정 규모 이상의 사업자는 지키지 않으면 시정 요구나 소송을 받습니다. 배려로 부르던 일이 지키지 않으면 손해가 나는 일이 되면서, 접근성은 여유가 있을 때 하는 작업에서 출시 조건 목록에 적히는 항목으로 자리를 옮겼습니다.

접근성 아래 용어는 세 갈래로 묶입니다. 무엇을 어디까지 맞춰야 하는지 정해 둔 기준, 화면에서 실제로 손보는 구현, 사용자 쪽에서 화면을 대신 읽어 주는 보조 기술입니다.

기준은 한 자리입니다. WCAG는 웹 표준을 만드는 국제 단체가 낸 지침으로, 지켜야 할 항목을 A·AA·AAA 세 등급으로 나눠 둡니다. 실무에서 목표로 삼는 값은 대개 가운데인 AA 입니다. 항목이 숫자로 적혀 있어서 판정이 됩니다. 본문 글자와 배경의 밝기 차이를 4.5 대 1 이상으로 두라는 조항이 대표적인데, 흰 배경 위의 연회색 글자는 2.8 대 1 정도라 떨어지고 같은 회색이라도 한 단계 진하면 통과합니다. 항목은 네 가지 원칙 아래 묶여 있습니다. 화면의 정보가 눈이든 귀든 어느 한 감각에만 매여 있지 않을 것, 모든 기능을 마우스가 아닌 방법으로도 조작할 수 있을 것, 문구와 동작이 예측 가능할 것, 여러 브라우저와 보조 기술에서 같게 작동할 것입니다. 국내 공공기관 사업의 접근성 요구도 대부분 이 지침을 바탕으로 적혀 있어서, 검토서에 적힌 문장을 따라가면 거의 이 항목 번호로 이어집니다.

보조 기술도 한 자리입니다. 스크린 리더는 화면에 있는 것을 소리로 읽어 주는 프로그램입니다. 위에서부터 차례로 읽기만 하는 게 아니라 제목만 건너뛰며 듣거나 버튼 목록만 뽑아 듣는 식으로 문서를 훑습니다. 그래서 이 프로그램에 무엇이 어떤 이름으로 전달되는지가 구현 갈래 대부분의 관심사가 됩니다. 이름이 붙어 있지 않은 아이콘 버튼만 늘어선 화면은 "버튼, 버튼, 버튼" 으로 읽히고, 이름이 붙어 있으면 "공유 버튼, 댓글 버튼, 삭제 버튼" 으로 읽힙니다. 같은 화면인데 하나는 아무 정보가 없고 하나는 목차 구실을 합니다.

구현은 일곱 자리이고, 화면에서 손대는 자리가 서로 다릅니다.

1. 시맨틱 마크업 — 요소의 뜻에 맞는 태그를 써서 구조를 드러냅니다. 모양만 버튼처럼 꾸민 상자는 스크린 리더에 그냥 상자로 읽히고 키보드로 선택되지도 않습니다. 버튼용 태그로 만들면 두 가지가 저절로 따라옵니다.
2. ARIA — 태그만으로 알릴 수 없는 역할과 상태를 속성으로 덧붙입니다. 직접 만든 드롭다운이 지금 열려 있는지 닫혀 있는지를 알리는 자리입니다. 태그로 되는 일을 대신하는 용도가 아니라, 태그가 없는 경우에만 씁니다.
3. 대체 텍스트 — 이미지를 글로 설명합니다. "이미지" 라고만 적힌 것과 "3분기 매출 그래프, 7월 대비 12퍼센트 증가" 라고 적힌 것은 듣는 사람에게 전혀 다른 정보입니다.
4. 키보드 내비게이션 — 마우스 없이 탭과 엔터와 화살표만으로 모든 기능에 닿게 만듭니다. 손을 쓰기 어려운 사용자뿐 아니라 마우스가 고장 난 사람에게도 같은 길이 됩니다.
5. 포커스 링 — 지금 선택된 자리를 테두리로 보여 줍니다. 시안에서 지저분해 보인다고 지우는 일이 잦은데, 지우면 키보드만 쓰는 사람은 자기가 어디에 있는지 모르는 채로 엔터를 누르게 됩니다.
6. 터치 타깃 — 손가락이 닿는 영역을 최소 크기 이상으로 확보합니다. 아이콘 그림이 16이라도 누를 수 있는 영역은 44 안팎으로 잡습니다.
7. 색각 이상 고려 — 색만으로 정보를 구분하지 않게 합니다. 성공은 초록 점, 실패는 빨강 점으로만 표시한 목록은 남성 스무 명 중 한 명꼴로 구분이 되지 않으니 모양이나 글자를 함께 답니다.

세 갈래 밖에 걸친 것도 있습니다. 모션 감소는 화면이 크게 움직일 때 어지러움을 느끼는 사용자를 위해 운영체제 설정을 읽어 애니메이션을 줄이는 처리입니다. 접근성 항목이면서 동시에 인터랙션 설계의 결정이라 두 자리에 걸쳐 있습니다.

기준이 어디까지 맞출지를 정하고, 구현이 화면에서 그것을 만들고, 보조 기술이 그 결과를 사용자에게 전달합니다. 셋 중 하나만 어긋나도 나머지가 무의미해집니다. 대체 텍스트를 다 채워 놓고 버튼을 상자로 만들어 두면 읽히기는 하지만 눌리지 않습니다. 반대로 키보드로 모든 자리에 갈 수 있게 해 두고도 지금 어디에 있는지 보여 주지 않으면, 사용자는 길은 열려 있는데 자기 위치를 모르는 상태로 화면을 헤매게 됩니다.

"이 회색 글자가 배경이랑 3 대 1이라 AA 기준에 안 맞아요. 한 단계 진하게 갈게요."

색을 취향으로 고르는 것이 아니라 판정 기준에 걸려 바꾼다는 말입니다.

"모달 열고 탭을 누르면 포커스가 뒤 화면으로 새요. 저장까지 못 갑니다."

마우스를 쓰지 않는 사람은 이 화면에서 작업을 끝낼 수 없다는 뜻입니다.

"이번 기업 고객 보안 검토서에 접근성 항목이 들어왔어요. 어디까지 맞출 수 있을까요?"

계약 조건이 됐으니 현재 수준을 확인해 달라는 요청입니다.

페이지덱에서 이 말이 제일 자주 오간 때는 공공기관 고객과의 계약을 앞둔 분기였습니다. 수아가 받아 온 검토서에 접근성 항목이 열두 줄 들어 있었고, 태오가 그중 아홉 줄은 이미 맞는다고 확인했습니다. 남은 셋은 문서 편집 화면이었습니다. 편집기 안의 도구 막대를 직접 만들어 둔 탓에 탭으로 넘어가지지 않았고, 표를 읽어 주는 이름이 붙어 있지 않았습니다.

민서와 태오가 나눈 판단은 어디를 고치느냐였습니다. 도구 막대 하나만 급히 손보면 2주면 되지만 다음 화면에서 같은 일이 반복되고, 공용 부품 쪽을 고치면 6주가 걸리는 대신 이후 화면은 자동으로 따라옵니다. 지현은 계약 일정과 견줘 도구 막대를 먼저 고치고 공용 부품은 다음 분기 작업으로 올리기로 정했습니다. 대신 그 사이에 만드는 새 화면은 공용 부품 쪽 규칙을 미리 따르게 해서, 고칠 목록이 더 늘지 않도록 막았습니다. 급한 것과 옳은 것이 다를 때 둘 다 적어 두고 순서만 정한 셈입니다.

접근성을 시각장애인을 위한 작업으로 좁혀 읽는 경우가 가장 많습니다. 소개 자료에 늘 스크린 리더가 먼저 나오니 그렇게 굳기 쉽습니다. 실제 범위는 훨씬 넓어서 손 떨림 때문에 작은 버튼을 못 누르는 사람, 소리를 못 듣는 사람, 긴 문장을 읽기 어려운 사람이 다 걸리고, 한 손에 짐을 들고 지하철에서 화면을 보는 사람이나 햇빛 아래에서 흐린 글자를 읽어야 하는 사람처럼 잠깐 그런 상태가 되는 경우까지 포함합니다. 좁게 읽으면 "우리 사용자 중에 몇 명이나 된다고" 라는 말로 우선순위에서 밀리는데, 밀린 뒤에 빠져나가는 쪽은 그 몇 명이 아니라 밝은 데서 흐린 글자를 못 읽고 조용히 창을 닫는 다수입니다.

출시 직전에 점검하는 항목으로 보는 오해도 흔합니다. 확인할 목록의 모양으로 전달되니 마지막에 훑으면 되는 일처럼 보입니다. 하지만 걸리는 것 대부분은 색이 아니라 구조입니다. 어떤 태그로 만들었는지, 읽히는 순서가 어떻게 되는지, 상태를 무엇으로 알리는지는 화면을 짜는 시점에 결정되고 나중에 바꾸려면 다시 만들어야 합니다. 그대로 두면 출시 2주 전에 대비가 모자란 색만 몇 개 고치고 키보드로 못 가는 화면은 그대로 나가게 됩니다. 점검 시점을 시안 단계로 당기면 같은 작업이 몇 시간짜리로 줄어듭니다. 글자 색을 고르면서 대비 값을 함께 확인하고, 화면을 짜면서 탭 순서를 한 번 눌러 보는 정도로 끝나는 일이 출시 직전에는 화면 전체를 다시 짜는 일이 됩니다.