접근성의 대상과 구현에 대한 의견

얼마전 특정 형태의 컨텐츠에 대한 접근성구현 방안에 대한 의견을 요구 받은적이 있었다.
그에 대한 의견을 제시하면서 이전부터 가지고 있었던 접근성 구현에 관한 의견을 적어봐야 겠다는 생각이 들었다.

의견제시를 요청 받았던 것은 많은 사이트들이 사용하고 있는 아래와 같은 달력형태의 컨텐츠에 대한 접근성을 고려한 구현 방법이었다.

달력형태의 대관일정표시

그리고 커뮤니티등에서 얻은 의견은 다음과 같은 이야기들이 있었다고 한다.

달력이 이미지로 되어잇으면 대체텍스트(alt)가 필요하구요
달력 날짜에 링크가 걸려있으면 대체텍스트(title)이 필요합니다
링크에 따른 tabindex도 필요하구요..
표로 만드시는거면
말씀하신 summary와 caption
그리고 thead와 tbody를 나누셔야 됩니다
thead부분에는 th가 존재해야되구요.

위의 의견이 틀렸다고 생각하지는 않치만 관점을 바꿔 볼 필요도 있지 않나 한다.
위의 답변의 기준은 컨텐츠의 형태 즉 달력형태를 기준으로 판단했을 때이며 이는 시각적 디자인 중심의 해석에서 비롯된다고 본다. 바라보는 관점을 좀더 목적지향적으로 다시 말해 컨텐츠 지향적으로 생각해 본다면 다른 의견이 있을수 있다고 본다.
예시로 든 위의 달력형태의 컨텐츠의 목적은 무엇일까 사용자에게 무얼 전달하고자 하는것일까를 생각해보자. 그리고 과연 그것이 반드시 위의 그림과 같이 <table/> 코드형식을 갖추어야 했을가를 생각해 보자.
컨텐츠의 제목열로 보이는 [행사 및 대관일정]으로 미루어 보아 행사가 있는 날짜, 행사명, 회의실이름, 주최자 또는 예약자정보 정도가 될것이다.
아마도 행사가 있는 날짜에 포커스가 걸리면 툴팁등으로 위의 내용이 나타날것이다.
하지만 이러한형태가 컨텐츠를 전달하기 위한 필수 불가결한 요소일 것 인가 이다.

개인적인 의견은 달력의 형태는 앞서 언급한 컨텐츠의 내용을 효과적으로(효과적인지는 모르겠으나) 또는 예쁘게 보이게끔 (있어보이게 끔) 하기위한 부가적인 형태라고 보여진다. 다시말해 달력형태는 필수정보(Core)가 아닌 부가정보(Add)또는 확장 정보(Extension)라고 할수 있다.

필수정보인 일정내용과 그를 돋보일려는 부가적인 달력형태가 얽혀있기 때문에 이에대한 접근성의 방안의 판단도 그리 쉽지 않을 것 이라 생각한다. 이러한 형태가 환경이 갖춰진 사용자에게는 문제가 없을수도 있으나 접속환경에 장애가 있는 사용자에게는 문제가 될수도 있을 것이다.
정보중요도에 따른 분리된구조의 장점

다시 문의내용의 돌아와서 위의 의견요청에 대해 Na!의 답신은 다음과 같았다.

기본사항
  • 위와 같은 달력형태는 <table />로 구성하는 것은 바른 선택이라 생각됨
  • <table /> 코딩표준을 지키면 기본적인 접근성은 지켜진다고 생각함
  • [summary]속성으로 “몇 개의 일정이 있습니다.”와 같은 테이블에대한 설명을 작성
  • 행사 및 대관일정과 년도와 월 → <caption />으로 작성 : 디자인상 어려울 수도 있다고 봄
  • 요일 이름 → <thead />로 작성
기능에 관한 사항
  • 일정이 있는 날은 해당일의 일정정보로 링크가 연결되어야 할 것으로 보임
  • 일정이 없는 날은 <span />으로 일정이 있는 날은 <a />로 작성하는 것이 좋다고 생각함
    – Javascript링크는 권장되지 않음
    – 일정일과 일정 없는 날이 각기 다른 tag로 구성되므로 각각의 디자인을 입힐 수 있음
  • 일정 일의 <a />에는 [title] 속성으로 링크가 되는 타켓 페이지에 대한 힌트를 작성해주면 더좋을 것 같음 (마우스 오버시 툴팁으로 해당 일정제목등 표시됨)

이 내용은 앞서의 커뮤니티등을 통해서 얻은 답변과 다르지 않을것이다.
하지만 Na!의 의견은 다음부분에 더 무게 를 두고 있다.

근원적인 관점에서는..
스크린리더를 주로 고려하는 것이라면 아무리 앞에서와 같이 테이블을 표준 방식으로 잘 작성하였다 하여도 테이블형태의 일정달력 자체가 그리 접근성이 높을 수 없다고 생각함 (일정이 있던 없던 숫자만 나열되는 셀을 최소 30개넘게 기다려야 함 – 요일이름 까지)
그러므로 달력이 무엇을 전달하고자 하는가를 생각해 보면 처리 더 좋은 방안이 나올 수 있다고 봄
개인적인 의견을 제시하자면..
  1. 해당월에 일정있는 날의 간략한 리스트를 제공함
  2. 달력테이블 앞에 달력 테이블을 건너 뛸 수 있는 skip link를 제공함
  3. 다자인적 요구에 따라 1과 2를 숨길수도 있음

코드 예시

<ul title=“OOOO년 OO월 일정”>
      <li><a href=“[일정상세 페이지 주소]”>OO일 : 일정제목 1</a></li>
      <li><a href=“[일정상세 페이지 주소]”>OO일 : 일정제목 2</a></li>
</ul>
<a href=“#nextContents”>달력테이블 건너 뛰기</a>
<table>………일정 달력 형태………………</table>
<div id=“nextContents” />
  • 전달하고자 하는 근본적 내용은 일정이 있는 날짜와 일정이 무엇인가 일것 임 (달력의 형태는 그것을 효과적으로 또는 멋지게 보이고자 하는 부가적이 요소임)
  • 달력의 형태만을 가지 접근성을 확보하고자 하는 생각은 디자인이나 코딩적이 생각임 컨텐츠 위주로 생각해 본다면 위와 같은 더 좋은 방법을 찾을 수 있음 (이러하기 때문에 기획자가 접근성에 대한 마인드를 가져야함 위와 같은 생각은 디자이너나 퍼블리셔가 생각해내는 것은 쉽지 않다고 봄)
  • 위의 방법을 구현하는 작업소요는 그다 지 크지않은 이미 일정에 대한 요소는 달력의 내용을 구성하기 위해 서버프로그램에 모두 추출하였으므로 위와 같이 간단한 출력만으로 더 좋은 접근성을 구현할수 있다고 생각함

문의 자체가 스크린리더에 중점이 있어 위와 같은 내용으로 의견을 제시하였지만 위와 같은 형태의 응용은 다양한 환경에서 사용될 수 있다고 본다.
일례로 분리되지 않은 형태의 기능을 모바일기기에서 접근했다면 달력에는 일정이 있는 날짜의 표시가 색상이나 폰트의 굵기등으로 표시가 되겠지만 상세내용을 보기위해서는 하나의 링크를 거쳐야 한다. 모바일환경에서 클릭한번의 비용과 PC환경에서 클릭한번의 비용은 엄연히 다르다. 예전에 Windows Mobile이 Palm과 비교하여 욕먹는 (요즘은 아이폰과 비교되어 욕먹고 있지만..) 이유가 프로그램을 실행시키는데 Palm보다 두배정도의 조작을 요한다는 것이 있었다.

마우스 오버로 정보를 표시한다고 하지만. 터치환경에서 마우스 오버가 어떻게 지원될지를 생각해본다면 그 역시 바람직하지 않다는것을 곧 알게될 것이다.
위처럼 핵심 정보와 부가적 요소를 분리하여 구성하면 사용자 환경에 따라 어떤 형태로 출력해줄것인가도 선택적으로 결정해줄수 있다.
(개인적인 방안을 제시해 본다면 위코드중 ul부분은 HTML출력하고 나머지 달력 table은 환경에 따라 javascript등으로 선택적으로 출력하는 방안을 사용하겠다.)

접근성을 동일 다른 환경에서의 동일한 UI나 UX의 구현이라고 이야기 하는사람도 있는것 같으나 Na!의 의견은 그것은 불가능 하다고 생각하며 그럴 필요성도 느끼지 못한다.
접근성의 대상은 코드가 아니라 컨텐츠-Core Information 이다라고 생각한다.
접근성은 어떻게 코드를 만드냐도 물론 중요하다. 하지만 더 중요한 것은 무엇이 중요하게 전달되어야 하는가에 대한 선택이며 판단이다. (코드는 그수단을 제공하는 것 이다라고 생각한다.)

그렇기 때문에 기획자 또는 웹사이트 제작을 총괄하는 PM은 접근성에 대한 개념을 가져야 한다.

접근성은 코드를 어떻게 만들어야 한다는 Negative적인 규제적인 요소가 아니라 사이트가 전달하고자 하는 바를 다양한 환경의 사용자에게 원활히 전달하게끔 하여 사이트의 목적을 더 잘 달성해 줄수 있도록 하는 Positive한 요소이며 이를 구현하는 방법은 완성된 디자인에 어떤어떤 코드를 더하여 만드는 것 보다 사이트의 설계시에 컨텐츠와 사용자에 대한 고려로 부터 출발하는 것이 더 쉽고 더낳은 접근성을 구현할수 있다고 믿는다.

Tags: , ,

Leave a Reply