오늘도 a11y 이야기

Category
a11y, 개발 노트
Posted
2014-12-11 11:27
세월호 참사 1주기 결코 잊지 않겠습니다. ※ 본 포스트는 네이버 하드코딩하는사람들 카페에서 2014/12/06에 진행한 세미나에서 발표한 내용임을 밝힙니다.. 스압주의! ( 블로그에 포스팅 작업으로 인해 반말체로 바뀌었…)

웹 접근성 = 인터넷 경사로

웹 접근성은 웹 페이지에 경사로를 만드는 것이다.
아마 이 이야기는 이제는 많이 들어본 이야기일 것이다..
작년 4월 11일부로 장애인금지 및 권리구제 등에 관한 법률의 적용이 모든 법인으로 확대가 되어짐에 따라, 많은 이들이 접근성에 대응하기 위해 이곳 저곳의 접근성 세미나라든지 강의 등을 들으며 꽤 많이 들었을 법 한 이야기다.

웹접근성이 무엇이고, 어떻게 해야 하는지 등등 이제는 하도 많이 들어서 다 아는 얘기인 것 같다. 이제는 어느 접근성 세미나를 가도 그다지 새로울 것이 없는 것만 같다.
그런데 과연 우리는 정말 접근성에 대해서 잘 알고 있고 잘 적용을 하고 있는 걸까?

아파트 앞 경사로 사진

아파트 현관 앞 계단을 장애인이 이용할 수 없으니 옆에 경사로를 만들었다. 장애인들이 이용할 수 있도록 접근성을 제공한 것이다. 그런데 이 경사로는 접근성이 잘 제공된 것일까?

사실 이 사진은 접근성이 올바르게 제공되지 않은 케이스다.
이 경사로는 경사가 높아서 웬만큼 힘이 있고 운동신경이 있는 사람이 아니라면 올라갈 수 없거나 올라가다 뒤로 밀려서 다칠 수 있는 위험성이 있는 경사로다.
즉, 접근성을 제공한다고 제공하였으나 실제로는 장애인들이 이용할 수 없는 접근성이 제공된 셈이다.

혹 우리가 만드는 웹 접근성도 이러한 상황은 아닌지 돌아봐봐야 할 필요가 있지 않을가 싶다.

준수한다고 했는데 뭔가 준수가 되지 않은 듯 하면서 준수 된 거 같기는 한 그런 접근성 ;;;
무엇이 문제일까?

접근성을 어떻게 접근할 것인가?

접근성이라는 문제에 어떻게 접근할 것인가? 이 문제가 선결되어야 할 것 같다.

기술적 접근 vs. 인문적 접근, 만드는 자 vs. 사용하는 자

접근성 작업을 하게 되면 대다수의 작업자들이 작업 시 가장 먼저 떠올리는 것은 아마도 접근성 지침이 아닌가 싶다.
대체 텍스트를 제공해야 하므로 img 요소에 alt 속성을 작성하고, 키보드 운용이 가능하게 해야 하므로 그에 맞게 마크업이 되어야 하고…
그런데 문제는 이 작업에 있어 많은 부분 기술적인 접근만을 하는 경우가 많다라는 것.

접근성에 있어서 만드는 이의 관점 그리고 사용하는 이의 관점 누구의 관점이 중요할까?
아마도 사용하는 이의 관점이 중요하다라고 하는데에는 이의를 제기할 사람을 없을 것이라 생각한다. 당연히 사용하는 자가 중요하다.
그러나 우리는 과연 접근성 작업에 있어 고려하고 있는건 사용자의 입장일까 아니면 만드는 사람의 관점일까?
한 번 생각을 해 봐야 할 문제일것 같다.

접근성이 잘못 적용된 예의 캡쳐화면

이미지 요소를 마크업 할 때 접근성 준수를 위해 alt 값을 넣어야 한다라고 알고 있기 때문에 alt를 넣는다. 그런데, 사용자에게 어떤 정보가 어떻게 넘어가야 접근성이 제공되느냐를 먼저 고민하지 않다보니 다음과 같은 문제가 나타나게 된다.

상기 이미지 중 추천 제휴사 페이지네이션 부분의 코드
<h4 class="cocmSubTitTy1">추천 제휴사</h4>
<ul class="cocmBSShopBannerPaging recommendNo clearfix">
	<li>
		<a href="#recommendList1">
			<img src="/pc/images/ollehktclub/main/btn_num1_on.gif" alt="추천 제휴사 배너1">
		</a>
	</li>
	<li>
		<a href="#recommendList2">
			<img src="/pc/images/ollehktclub/main/btn_num2.gif" alt="추천 제휴사 배너2">
		</a>
	</li>	
	<li>
		<a href="#recommendList3">
			<img src="/pc/images/ollehktclub/main/btn_num3.gif" alt="추천 제휴사 배너3">
		</a>
	</li>	
	<li>
		<a href="#recommendList4">
			<img src="/pc/images/ollehktclub/main/btn_num4.gif" alt="추천 제휴사 배너4">
		</a>
	</li>
	<li>
		<a href="#recommendList5">
			<img src="/pc/images/ollehktclub/main/btn_num5.gif" alt="추천 제휴사 배너5">
		</a>
	</li>
</ul>

위 코드를 스크린리더기로 읽게 되면 다음과 같다.

UI 상으로 볼 때, 해당 부분은 페이지네이션의 기능인데 사용자가 받아들이는 정보는 "추천 제휴사 배너 번호 링크"가 된다. 사실 추천 제휴사 배너 번호라는 정보도 참으로 무언지 알 수 없는 정보 그 자체이기도하다. 듣는 사람 입장에서는 이 링크 자체가 배너인 듯도 한데 무슨 배너인지는 알 수가 없는 셈이다.

어떤 것인지 알겠는가?
alt 를 넣으라고 하니 넣기는 넣었는데 기술적으로만 접근을 하다보니 "이게 배너 1번 영역을 보여주는 링크이니 배너 1, 이건 배너 2번 영역을 보여주는 링크이니 배너 2" 라고 넣은 것이지 정작 사용자가 정보를 어떻게 받아들이게 되는지에 대한 접근을 하지 않은 것이라 볼 수 있다.

심지어 어떤 패스트푸드점의 웹 사이트에 들어가봤을 때에는 각 햄버거 메뉴의 대체 텍스트가 "메뉴 1", "메뉴 2", "메뉴 3" … 과 같이 되어 있어서 이건 도무지 무슨 맛의 어떤 제품인지 알 수 있는 방법이 없는 경우도 있었다.

이것이 바로 접근성 작업에 대해 기술적으로만 접근한 것이요, 사용자의 입장이 아닌 만드는 이의 입장에서 고민된 결과다.
그렇다면 어떻게 사용자의 입장에서 접근성을 제공 할 수 있을까?

접근성에 어떻게 접근을 할 것인가?

그 첫 걸음이 아마도 장애에 대한 이해가 먼저이지 않을까 싶다.

각 장애별 웹 이용 방법에 대한 이해

모든 장애에 대해 훑어보기에는 분량이 방대(?)할 수 있으므로 간략하게만 훑어보자.

먼저는 전맹장애의 경우, 익히 알고 있는 대로 Screen Reader를 사용하여 웹을 이용한다.
국내에서 가장 많이 사용하는 것이 아마도 엑스비전테크놀로지의 센스리더일 것이고, 외산 리더기인 JAWS, 혹은 오픈소스인 NVDA를 이용해서 사용하게 된다.

화면을 확대하고 모니터에 바짝 눈을 두어 화면을 보고 있는 저시력자 사진
사진 출처 : “누구를 위하여 종을 울리나” – 김혜일(emotion)님 접근성 세미나 자료 中

위 사진은 저시력 장애를 가진 이가 컴퓨터를 사용하고 있는 사진이다.
화면을 확대하고도 모니터에 눈을 바짝 대고 화면을 보고 있다. 저시력자의 경우 화면 확대를 위해 돋보기 툴이라던가 화면 확대 보조기기를 사용하기도 한다.

데브온 한국웹접근성그룹 부스에서 조우스를 체험해 보고 있는 방문객 사진
조우스 – 이미지 출처 : KWAG Facebook

상지 장애(위 사진의 케이스는 목 아래로는 움직일 수 없는 케이스에 해당한다.)의 경우 마우스 대신 조우스를 이용해 입으로 포인터를 컨트롤 하는 경우이다.
한 번 상상해보라. 저렇게 입으로 마우스를 컨트롤 해서 체크박스를 선택해야 할 때 레이블이 제대로 연결되어 있지 않다면 정말 환장할 노릇이 아닐지 모르겠다.

마우스 스틱을 이용하여 키보드를 이용하고 있는 사진
마우스 스틱 – 이미지 출처 : 시사저널

마찬가지로 상지장애의 경우 키보드를 이용하는 방법이다.

루게릭 병을 앓고 있는 박승일 전코치가 안구마우스를 통해 컴퓨터를 이용하고 있는 사진
안구 마우스 – 이미지 출처 : 미디어스

아이스버킷챌린지 열풍 덕(?)분에 많은 이들이 알게 된 그 루게릭병을 앓고 있는 박승일 전 코치의 사진이다.
이분의 경우는 아예 온 몸의 근육을 사용할 수 없기 때문에 안구마우스를 이용하여 안구의 움직이라든가 눈의 깜박임을 통해 컴퓨터를 이용하고 있다.

내가 그 상황이라면?

접근성이 온전히 제공되기 위해서는 내가 그 상황이라면 내가 웹을 사용하는데 어떤 불편함이 있을까? 내가 정확한 정보를 얻으려면 웹이 어떻게 만들어져있어야 할까? 라는 질문에서부터 접근성이 시작되어야 하지 않을까싶다.

공감 (共感)

함께 공 자에 느낄 감 자. "상대의 느끼는 바를 함께 느낀다." 라는 뜻의 단어

접근성은 바로 이 공감으로부터 시작되어야 하지 않을까 싶다.
장애의 입장에서 무엇이 불편하고 또한 무엇이 필요하며 어떻게 해야 내가 원하는 정보를 정확하고 바르게 얻을 수 있을지를 먼저 생각하자는 것이다.
이것이 바로 앞에서 말한 인문적 접근이다.
접근성에 있어 우선 되어야 할 것은 기술이 아니라 그것을 이용하는 사람이다.

그렇다면 어떻게 해야 장애인의 입장에서 공감을 해 볼 수 있을까?

장애자인 나를 상상하기

내가 만약 볼 수 없거나, 들을 수 없거나, 몸을 움직일 수 없거나 한다면 그런 상황 속에서 나는 어떻게 웹을 이용하고 있을까? 내가 만드는 웹이 어떻게 만들어져 있어야 내가 불편함 없이 쉽게 잘 이용할 수 있을까를 상상해보면 가능하지 않을까싶다.
만일 내가 눈이 안보이는 상황을 머리 속에서 그려보고 이 웹을 탐색하고 있는 자신을 상상해보자는 것이다.
컴퓨터가 현재 이 웹 페이지를 어떻게 읽어주고 있고 그 때 나는 무엇이 불편할까를 상상해 본다면 충분히 그 불편함을 공감해 볼 수 있지 않을까?

도저히 상상으로는 모르겠다 한다면, 직접 체험을 해보는 방법도 있겠다.

네이버 웹접근성 체험 부스

네이버 널리에서는 웹접근성을 체험해 볼 수 있는 웹 페이지를 제공해주고 있다.
이곳에서는 각 장애별로 장애에 대한 설명과 어떤 보조 도구를 이용하는지, 어떤 불편함이 있는지 등을 체험해 볼 수 있도록 제공되어져있다.

네이버 그린팩토리 접근성 체험 부스 소개 사진
웹이 아닌 현실세계(?)에서 보조 도구들을 체험해 볼 수 있는 공간 중 한 곳으로 분당 네이버 그린팩토리에 있는 접근성 체험 부스를 이용해 볼 수도 있겠다.

한국정보화진흥원 체험관 전경 사진
분당이 너무 멀다 싶다면(서울 사는 이들 중에…) 한국정보화진흥원 등촌청사에 있는 정보통신 보조기기 체험관에서 체험을 해 볼 수도 있다.

뭐 나는 이도저도 다 어렵다 한다면 가장 손쉽게 체험할 수 있는 방법으로
PC에 스크린리더를 설치한 뒤(센스리더의 경우는 30분 동안 무료로 사용이 가능하고, NVDA는 오픈소스이기 때문에 제한이 없는 것으로 안다.) 모니터를 꺼 둔 상태로 내가 만든 웹을 한 번 이용해보거나, 볼펜을 입에 물고 볼펜으로 키보드를 쳐서 특정 페이지에 로그인을 해 보거나 하는 등의 방법이 있겠다.

구현

각 장애별로 어떤 불편함이 있고, 무엇을 필요로 하는지 알았다. 그렇다면 이제 필요한 것은 그 안 것을 실제 작업으로 옮기는 일이다.
여기서부터가 이제 기술적인 접근이 시작되는 부분이다.

내가 장애인의 입장이라면 내가 웹을 사용할 수 있기 위해 필요한 것이 무엇인가?

아마도 실제 구현에 있어 가장 먼저 떠올리게 되는 것이 바로 KWCAG 문서가 아닐까 싶다.
KWCAG 2.0 문서를 기준으로 13개의 지침과 22개 검사항목이 존재한다. 아마도 이 지침과 항목들에 대해서 어렵다 느끼는 이들이 많지 않을까 싶다.
사실 이 지침과 검사 항목들 그리고 개선 방법들을 다 지식으로 외우려 한다면 분명히 어렵다.
솔직히 필자도 13개 지침과 22개 검사항목에 무엇 무엇이 있는지 정확하게 기억하지 못한다.

하지만, 장애와 각 장애를 가진 이들이 어떻게 웹을 이용하고 무엇이 불편하며 어떻게 제공을 해야 이들이 정보를 올바르게 받아들일 수 있을지를 공감하고 이해하게 된다면 KWCAG 문서의 내용을 굳이 외우지 않더라도 그 내용들에 대해 충분히 알수 있게 될거라 생각한다.

따지고 보면 KWCAG 문서는 장애인들이 웹을 어떻게 이용하고 있고, 어떤 불편함이 있는지 그리고 그것을 해소하기 위해 무엇이 필요한지를 정리해둔 문서라고 볼 수 있다.
최소한 이렇게 제공을 하면 장애인들이 그나마 불편하지 않게 쓸 수 있습니다 라고 최소한의 가이드를 정리한 문서인 셈이다. (바로 이러한 이유로 접근성 세미나에서 KWCAG 문서는 최소한이다 라고 이야기 하는게 아닐까?)

앞서 말한 바와 같이 내가 각 장애의 입장이라면 내가 각 상황에서 웹을 이용해야 한다면,
내가 웹 페이지로부터 얻고 싶은 정보를 정확하고 쉽게 얻으려면 정보가, UI가 어떻게 제공되어야 할지를 생각하고 고민해보았을 때 KWCAG 지침들 그 이상의 것들이 도출되어질 것이라 생각한다.

바로 이것이 앞서 이야기했던 기술적 접근 이전의 인문적 접근을 말하는 것이고, 만드는 입장에서 접근성을 준수하기 위해 뭘 해야지 뭘 해야지 외우는 것이 아니라 사용자 입장에서 무엇이 왜 필요하고 어떻게 제공받도록 할 것인가를 고민하고 만들어야 한다라는 것이다.

그리고 끊임없이 어떻게 해야 사용자의 사용성을 높일 수 있을지를 고민해야 불편함을 가진 이들에게 정말 필요한 접근성이 제공되어질 것이라 생각한다.

접근성을 업무 프로세스 안으로…

그리고 구현에 필요한 한 가지가 바로 접근성을 업무 프로세스 안으로 넣어두는 것이다.

기획, 디자인, 개발 단계마다 각자가 접근성을 고려해서 작업하고 알아서 검수하면 더할 나위 없이 좋겠으나…
실제적으로 기획자, 디자이너, 서버사이드 개발자가 접근성을 잘 알아서 하는 경우가 극히 드물다…
접근성 이슈가 상대적으로 프론트엔드에 가장 많은 것은 맞는데 그렇다 하더라도 프론트엔드 직군 외 타 직군에서 접근성에 대해서 알고 있는 경우는 너무 적다. 어쩔 수 없는 사실이다.

그렇다고 니들이 말아먹은 접근성 나는 책임 안지고 난 내 분야쪽 접근성만 할래~ 할 수는 없지않은가!!!
그렇다면 어찌하랴… 기획, 디자인, 개발이 끝날 때 마다 그나마 아는 놈이 점검을 해 주기라도 해야지 ㅠ_ㅠ
디자인까지 다 끝나서 넘어왔는데 접근성이 배제된 기획으로 인해 디자인을 다시 해야 하는 상황이라면 기획부터 다시!! 해서 일정을 주구장창 늘려놓을 수 없으니, 접근성을 아는 이가 없는 상황에서는 각 단계가 끝날 때 마다 점검을 해 주어서라도 접근성 이슈가 계속해서 발생되어 수시로 커뮤니케이션을 다시 하고 일정이 자꾸만 늘어나는 상황을 최소한으로 줄여볼 수 있지 않을까 싶다.

접근성 테스트

접근성 작업이 완료 되었다면 테스트를 해 봐야 실제로 접근성이 잘 제공되었는지를 알 수 있고, 접근성을 잘 준수했노라고 보고할 근거를 남길 수 있다.
그렇다면 어떻게 테스트를 해야 할까?

자동화 툴 이용

일단은 자동화 툴을 이용하는 거다.

K-WAH로 본 블로그를 테스트 한 결과 사진
가장 대표적인 자동화 툴이 아마도 K-WAH가 아닐까 싶다. K-WAH는 웹접근성 연구소에서 제공을 하고 있으며 URL을 지정하고 약간의 설정을 해두면 페이지 내 존재하는 링크들을 타고 이동하면서 알아서 페이지를 수집하여 검사를 진행하고 결과를 알려준다.
K-WAH의 좋은 점이라면 사진에서와 같이 보기 좋은 레포트로 출력을 해 준다라는 것!!!
다만, K-WAH는 로그인이 필요한 사이트의 경우에는 이용이 불가하다. (4.0 버전까지는 확인을 했는데 이후 버전에는 개선이 되었는지 어떤지 모르겠다 ; )
또한 링크가 자바스크립트로 되어 있는 경우 역시 페이지 수집이 불가하다. 현 버전에서는 개선이 되었다는 것으로 들었는데 테스트를 진행해본 것은 아니라 정확히 얼마만큼 잘 수집하는지는 모르겠다 ;;;;

Open Wax로 본 블로그를 테스트 한 결과 캡쳐 화면
크롬이나 파이어폭스를 사용한다면 확장 프로그램으로 Open-WAX 혹은 N-WAX를 설치하여 사용해 볼 수도 있다.
N-WAX는 NHN의 접근성 지침(NWCAG)에 따라 점검을 진행해 주는 툴이고 Open-WAX는 N-WAX를 오픈소스화하여 KWCAG 2.0을 기준으로 점검을 해 준다.
이 툴의 장점이라면 화면을 보는 동시에 한 쪽에서는 진단 결과를 확인 할 수 있고 각 점검 영역을 토글하여 펼쳐보면 어떤 내용들에 대해 점검이 되었는지를 일목요연하게 확인해 볼 수 있다.
다만, 이 툴의 경우는 페이지를 자동으로 수집해주지 못하기 때문에 페이지를 들어가서 일일이 실행을 해 주어야 한다.

pajet으로 본 블로그를 테스트 한 결과 캡쳐 화면
파젯이라는 툴도 있는데 이것은 신현석님과 홍윤표님이 만든 검사도구로 알려져있다. 북마클릿형태이며 즐겨찾기에 추가해 두었다가 점검하고자 하는 페이지에서 즐겨찾기에 추가해둔 북마크를 실행하면 된다. 현재 듣기로는 KWAG에서 파젯의 차기 버전을 준비중이란다. (기대하고 있으요 ㅋ)

자동화 툴이 만능은 아니다.

그런데 한 가지 문제가 있다.
바로 자동화 툴에서 점수가 높거나 문제가 발견되어지지 않는다 해서 정말로 문제가 없다는 것은 아니라는 것이다.

<h4 class="cocmSubTitTy1">추천 제휴사</h4>
<ul class="cocmBSShopBannerPaging recommendNo clearfix">
	<li>
		<a href="#recommendList1">
			<img src="/pc/images/ollehktclub/main/btn_num1_on.gif" alt="추천 제휴사 배너1">
		</a>
	</li>
	<li>
		<a href="#recommendList2">
			<img src="/pc/images/ollehktclub/main/btn_num2.gif" alt="추천 제휴사 배너2">
		</a>
	</li>	
	<li>
		<a href="#recommendList3">
			<img src="/pc/images/ollehktclub/main/btn_num3.gif" alt="추천 제휴사 배너3">
		</a>
	</li>	
	<li>
		<a href="#recommendList4">
			<img src="/pc/images/ollehktclub/main/btn_num4.gif" alt="추천 제휴사 배너4">
		</a>
	</li>
	<li>
		<a href="#recommendList5">
			<img src="/pc/images/ollehktclub/main/btn_num5.gif" alt="추천 제휴사 배너5">
		</a>
	</li>
</ul>

앞서도 봤던 접근성이 잘못 적용된 예의 코드다.
사실 이 코드만 가지고 자동화 툴로 검사를 해보면 100% 접근성이 제공 된 것으로 나오게 된다. 하지만 분명 이 코드는 접근성이 올바르게 제공되지 않은 코드다.

자동화 툴은 아직까지 인텔리전스하지 못하다. 아니 인텔리전스하다 하더라도 이 정보가 과연 적절한가라는 검증은 할 수 없지 않나? 인공두뇌가 아닌 이상에야… = _=a
거기다 자동화 툴이 키보드 운용성이라던지 시간 제한이 있는 컨텐츠인지 아닌지를 판단하지는 못한다.
결국, 접근성 검사는 일일이 직접 수동으로 검증을 해 봐야 한다라는 얘기다. 쿨럭…

접근성 준수 쉽지 많은 않다 하지만 해야 한다.

접근성을 준수해서 아니, 접근성을 잘 제공하는 웹을 만드는 것은 분명 쉬운 일은 아니다.
하지만, 어렵다고 안 할텐가? 어렵다고 대강 대강 할텐가?
피할 수 없다면 즐기고 기왕 해야 한다면 잘 해봤으면 좋겠다.

어려우니까 힘드니까 대강할래 혹은 안할래 한다면, 접근성은 계속해서 현상 유지만을 할 수 밖에 없다.
그리고 나서 나이가 들고 노안이 오고 점점 이해력이 둔해지고 WWW를 이용하는게 어려워졌을 때 웹을 이용하기가 어렵다면 그 때는 또 그 때 작업자들을 탓할 것인가?

당장 내일이라도 내가 장애인이 될 수도 있다.
당장 장애인이 되지 않는다 하더라도 분명 사람은 늙는다. (벤자민 같은 경우는 영화에나 나오는 거고…) 늙으면 그 만큼 또한 장애가 생겨나게 마련이다.
내가 지금 노력하는 접근성 향상은 향후 내가 다시 돌려받게 되는 혜택이 되지 않을까?
내가 안 해도 남이 하겠지라는 생각이라면, 이 한마디를 던져드리고 싶다. "남들도 당신과 똑같은 생각을 하고 있을겁니다." 라고.

이게 왜 이렇게 돼 있는지를 알아줬으면 좋겠다

여기 5분짜리 영상이 하나 있다. 일단 이걸 먼저 보도록 하자.
( 나는 성질이 급하다 하는 이는 00:00 ~ 01:04, 02:00 ~ 03:00, 05:50 ~ 끝 구간만 봐도 좋다.)

웹 접근성을 장차법 때문에 혹은 마크를 따기 위해 혹은 시키니까라는 이유로 나에게 의미없이 작업을 하게 되면 앞서 본 영상과 동일한 상황을 만들어 낼 수 있다.
영상 속에서 인터뷰하신 분이
법적으로 설치하라고 하니까 설치한 거죠이게 왜 필요한가는, 자기들한테는 의미가 없는 거예요 근데 제가 말하고 싶은 것은 이게 왜 이렇게 설치가 돼 있는지를 알아줬으면 좋겠다.
라고 한다.
웹 접근성이 법적으로 하라고 하니까, 시키니까 하는 것이지 자기들한테는 의미가 없다라는 것.
혹 그것이 지금 내가 작업하고 있는 웹 접근성 작업에 해당하는 말이 아닌지 돌아봐야 하겠다.

접근성을 하는 목적은 결국 누구나 쉽게 접근하고 쉽게 사용할 수 있게 하며 편리하게 웹을 이용할 수 있게 하기 위해서다.
그러기 위해 모두가 함께 접근성이 왜 필요하고 또 어떻게 제공할지를 고민하고 노력하는 웹 문화를 만들어 갔으면 좋겠다.

Authored By 멀더끙