카테고리 보관물: Web Accessibility

Web Accessibility

Web Accessibility

장차법 시행의 부작용

댓글 11개

2004년에 웹 표준 이라는 것을 알게되고, 얼마 지나지 않아 웹 접근성이라는것도 알게되었다. 그 이후로 어떤 방법이 되었던 우리나라의 웹이 접근성이 나아지는데에 도움이 되려고, 조금이라도 노력을 해왔다고 생각을 했다.

저번주 금요일에 친한 동생인 김준극과 점심을 먹는데 옆 테이블에서 들려오는 대화에서 퍼블리셔, 접근성 표준 이런 얘기가 들리길래 조금 관심있게 들었는데… 요즘 그들이 제일 이슈가 되고있다 뭐 이런말이 들리더라…

밥을 먹는데 뭔가 감회가 새롭다고 해야하나…(난 별로 한것도 없지만…) 2004년 당시에는 웹 표준이나 접근성에 대해 말하는사람도 별로 없었고, 정말 그들만의세상이었는데… 이제 그나마 얘기가 나오는구나 생각이 들더라… 물론 웹 표준은 애플의 힘이 컷다고 하는게 부정 할 수 없는 사실이고(적어도 우리나라에선…) 접근성은 “장애인 차별금지 및 권리구제 등에 관한 법률”이 큰 역할을 해왔지만, 초기부터 많은 노력을 해왔던 분들의 땀과 노력의 결과라고도 생각을 한다.

표준에 비해 접근성은 아직 논란의 소지가 많다고 했던가… 이것 또한 시간이 해결해 주리라 생각하고 있었는데 그렇지는 않은것 같다.

나도 남들보다는 아주~~~ 조금 접근성을 접했다는 이유로 정보화 진흥원에서 웹 접근성 전문가로 활동중인데 내가 한 자문 활동이 다른 사이트에서 자신들의 묻고답하기로 변경되어 있는것을 보게 되었다.
웹 접근성 연구소에서의 내가 진행한 자문
모 인증센터의 사이트 내가 웹접근성 연구소에서 자문한내용과 질문과 답이 동일하다.
이미지의 내용은

[질문]
1.display:none이 적용된 개체(?)에도 접근성 작업을 꼭 해야 하나요?
2. table 작업 시, 제가 알기로는 caption, summary 둘 중에 하나만 넣어주면 된다고 들었거든요. 맞나요?
3. table 작업 시 ‘scope’ 속성의 사용은 필수인가요?
답변 부탁드립니다^^

[답변]
품질마크의 기준을 물어보시는것같습니다.
품질마크의 심사가이드 항목에 따라 설명해 드리면
1. 당연히 display:none의 콘텐츠도 평가대상에 포함됩니다. 언젠가는 노출이 되어야할 콘텐츠 일테니까요.
2. 현재의 기준은 caption과 summary중 하나만 넣어도 인정해주는것으로 알고 있습니다.
3. scope나 headers의 경우 복잡한 표의 명확한 안내를 위해 설계되었다고 보시면 됩니다.
품질마크의 심사기준은 제공하라고 되어있습니다.
다만 품질마크의 경우 그 기준이 바뀔 수 있기 때문에 제공할수 있는 항목은 (2번 같은) 모두 제공해주시는것이 바람직합니다.

로 두개의 사이트의 내용이 동일하다.

그 사이트의 인증현황을 봤더니 한국정보화진흥원이 정보문화진흥원이었던 당시의 웹접근성품질마크 1회차의 결과물이 동일하게 제공되고 있지 않은가…
웹 접근성을 잘지키려는 노력도 좋지만 그전에 다른 사이트의 내용을 가져다 쓰는것은 문제가 있지 않을까?

또한 웹 접근성을 컨설팅하는 업체들에 대한 많은 이야기들을 듣는데 그들이 컨설팅을 해주는 내용이라는게 접근성을 알고 컨설팅을 해주는것이 맞을까 할 정도로 근거없고 틀린 내용들을 많이 알려주는것을 듣게 되었다.

웹 접근성이 장차법으로 저변이 넓어진것도 사실이지만, 그에 따른 부작용도 많이 생기는것같다. 법으로 제한 되는 것 이다보니…
그것을 이용해서 사업을 하려는 사람도 많이 보이고 뭔가 한 몫을 잡으려고 하는 분들도 보이는것 같다.

물론 이 세상은 돈이 상당히 중요하고 확실히 때가 있는 사업이기 때문에 그를 이용해서 돈을 버는것은 뭐라할 생각이 없다.(나도 회사원치고는 돈을 많이 벌었으니 ㅋㅋ)
하지만 할거면 제대로 공부를 하고 열심히 누가봐도 떳떳하게 사업을 했으면 하는 바람이 있다.
내가 머리가 나빠서인지는 몰라도 웹 접근성을 나름 7년 넘게 공부하고 있는데 정말 끝이 없다. 1~2년 공부해서 사업할 수준이 되는 영역이 절대 아니다.

결론은
1. 사업을 할거면 제대로 해라. 괜히 협박이나하고 공포분위기 조장해서 될것이아니다.
수년간 보상 바라지 않고 노력해서 쌓아 올린 접근성에게 피해주지말자.
2. 접근성은 지키는것이 아니다. 사람이 다같이 함께 행복하게 살기 위한 노력이다.

Web Accessibility

Skip Navigation에 대한 쓸데없는 생각

댓글 2개

보통 웹 사이트를 만들때 매 페이지마다 반복되는 영역이 존재하기 마련이고, 페이지의 선형화를 통해 웹 사이트를 탐색하는 사람은 매번 반복되는 영역을 거쳐야지만 웹 사이트의 핵심 콘텐츠에 접근 할 수 있다. 그런 연유로 WCAG2.0이나 KWCAG2.0은 Skip Navigation 링크를 제공하는것을 권장하고 있다.

Direct Link와 Skip Navigation

Direct Link와 Skip Navigation을 혼동하는 경우가 가끔 보이는데 이것은 성민장군님의 블로그에서 너무나도 훌륭하게 잘 설명해 주셨으니 참고 하는것이 좋을 것 같다.

다만 요즘들어 드는 잡생각이 Direct Link를 제공하는것이 과연 잘못된 일일까? 반복된 영역을 추가로 만든다는 함정이 생길 수 있다는 문제점이 있고, 각 섹션의 헤딩을 통해서 빠르게 탐색이 가능하므로, Direct Link는 필요없다는 결론인데… 사이트내의 페이지 구조가 복잡해지고, 양이 많아지면 많아질수록 Direct Link가 필요할수도 있지않을까?라는 생각을 하게 되었다.
그래서 각 탐색을 쉽게 하는 콘텐츠를 제공하는것을 내 나름대로 재정의 해보았다.

Skip Navigation
각 페이지마다 반복되는 영역을 건너뛰기 위한 링크 제공
Section Heading
각 섹션을 빠르게 탐색하기 위한 용도
Direct Link
페이지에서 중요하다고 생각되는 영역이나 접근을 유도하고 싶은 부분으로의 이동을 위한 링크

예를 들어보자. 일반적인 스킵 네비게이션의 사용은 다음과 같을것이다.



<p><a href="#contentsArea">반복영역 건너뛰기</a></p>

<h1>로고</h1>

<ul>

  <li><a href="#">메인 네비게이션1</a></li>

  <li><a href="#">메인 네비게이션1</a></li>

  <li><a href="#">메인 네비게이션1</a></li>

</ul>

<div id="contentsArea">

콘텐츠 영역

</div>

로고와 메인 네비게이션이 페이지마다 반복적으로 노출되는 부분이므로 스킵 네비게이션을 제공하는것은 좋은방법이다. 라고 말할 수 있다.
그러나 Direct Link와 Skip Navigation를 구분하지 못하는 경우는 다음과 같을 수 있다



<ul id="skipnav">

  <li><a href="#mainNavigation">메인 메뉴바로가기</a></li>

  <li><a href="#leftArea">왼쪽영역 바로가기</a></li>

  <li><a href="#searchArea">검색영역 바로가기</a></li>

  <li><a href="#contentsArea">콘텐츠로 바로가기</a></li>

</ul>

<h1>로고</h1>

<ul id="mainNavigation">

  <li><a href="#">메인 네비게이션1</a></li>

  <li><a href="#">메인 네비게이션1</a></li>

  <li><a href="#">메인 네비게이션1</a></li>

</ul>

<div id="leftArea">

왼쪽 영역

</div>

<div id="searchArea">

검색 영역

</div>

<div id="contentsArea">

콘텐츠 영역

</div>

이런 경우를 Skip Navigation 과 Direct Link를 잘못 이해하고 사용한다고 볼 수 있는데, id가 skipnav 부분이 페이지마다 오히려 반복되어버려서 Skip Navigation의 용도가 적절하지않다고 볼 수 있다.

Skip Navigation 과 Direct Link를 둘다 제공하는건 어떨까라는 생각을 해보았는데… 내가 구조를 만들어본다면 다음과 같이 구성 될 수 있을것이다.



<ul id="skipnav">

  <li><a href="#contentsArea">반복영역 건너뛰기</a></li>

</ul>

<ul id="directnav">

  <li><a href="#searchArea">검색영역 바로가기</a></li>

  <li><a href="#adArea">홍보영역 바로가기</a></li>

</ul>

<h1>로고</h1>

<ul id="mainNavigation">

  <li><a href="#">메인 네비게이션1</a></li>

  <li><a href="#">메인 네비게이션2</a></li>

  <li><a href="#">메인 네비게이션3</a></li>

</ul>

<div id="leftArea">

왼쪽 영역

</div>

<div id="searchArea">

검색 영역

</div>

<div id="contentsArea">

콘텐츠 영역

</div>

<div id="adArea">

광고 영역

</div>

이러면 Skip Navigation 다음에 Direct Link가 위치하고 로고와 메인 네비게이션이 위치하므로 Skip Navigation 이후 부터는 반복된 영역이라고 볼 수 있지 않을까?
물론 현재 권장하는 스킵 네비게이션은 하나만 제공하는것이 좋습니다 라는 공식에는 맞지 않을지도 모르지만, Direct Link를 제공하는것이 어쩌면 선형화를 통해 페이지를 접근하는 사람에게는 더욱 도움이 되지 않을까? 라는 생각을 해보게 되었다. 물론 현재 우리나라의 상황을 보아할때 페이지마다 변경 될 수 있는 Direct Link를 제공할것이라 생각되지는 않지만…

이것에 대한 근거로 KWCAG2.0의 2.4.1 (반복 영역 건너뛰기) 콘텐츠의 반복되는 영역은 건너뛸 수 있어야 한다.에는 다음과 같은 설명이 있다.

여러 개의 건너뛰기 링크 제공: 건너뛰기 기능은 웹 페이지의 가장 앞에 위치해야 한다. 여러 개의 건너뛰기 링크를 제공하는 경우에는 핵심 콘텐츠로 이동하기 위한 건너뛰기 링크를 가장 앞에 위치시킨다. 만일 배경음 바로가기 링크 참조가 있는 경우에는 그 다음에 위치시킨다.

웹 사이트를 만드는 웹 저작자라면 한번쯤 고민 해봐야 할 문제가 아닐까 싶다. 각 페이지를 구성할때 조금이라도 좀 더 노출시키고 싶은 콘텐츠들이 존재할테니까, 단순히 ‘Skip Navigaion만 지원했으니 끝!!’ 이럴수는 없는 노릇아닌가?

참고로 당연히 반복되는 영역이 없으면 Skip Navigaion이 없어도 무방하다고 생각한다. 내가 만드는 웹 페이지가 반복되는 영역이 있는지 없는지 잘 살펴봐야 할 것이다. SKip Navigation을 위한 SKip Navigation을 만드는 경우는 없어야 할것이다.

문득 드는 생각이 메인 페이지에 네비게이션이 있다해도 Skip Navigation이 꼭 있어야 할까? 판단하기 나름이긴한데… 이건 다른 분들의 의견을 좀 들어볼 필요가 있을것 같다.

덧붙임

  • 백수생활이 오래되니 확실이 잡생각이 많이 난다.
    이런걸 생각을 다하다니;;;
  • 저번글의 포스트넘버가 1000번이었는게 포스팅된 글의 갯수는 200개 였다.
    즉 200번째 글이라는…
    뭐 그렇다고… 참 글안쓴다…
Web Accessibility

HTML5에서의 Table Element의 summary

댓글 2개

HTML5에서는 HTML4까지 표의 요약을 설명하는 용도로 사용되던 summary속성을 폐기했다.
폐기라기 보기보다는 사용하면 좋지않은 지침(Not a good indicator)정도로 표현했다고 본다.
암튼 summary가 “사용하면 좋지않은 지침(이후 deprecated 정도로 맘대로 표현하겠다.)”이 되어버린 이유가 몰까 궁금했다.
summary는 표의 설명이기 때문에 복잡한 구조의 표를 선형화시켜서 이해하는 사람에게 큰 도움이 되지 않던가! 왜 없에버린거야!! 라며 이유를 찾기 시작했다.

그에 대한설명은 현재 버전의 html5 Specification에는 존재하지 않고, 2011년 4월 5일날(나무를 심자! 음…) 나온 “HTML5 Edition for Web Authors“에서 찾을 수 있었다.

The summary attribute on table elements was suggested in earlier versions of the language as a technique for providing explanatory text for complex tables for users of screen readers. One of the techniques described above should be used instead.

note : In particular, authors are encouraged to consider whether their explanatory text for tables is likely to be useful to the visually impaired: if their text would not be useful, then it is best to not include a summary attribute. Similarly, if their explanatory text could help someone who is not visually impaired, e.g. someone who is seeing the table for the first time, then the text would be more useful before the table or in the caption. For example, describing the conclusions of the data in a table is useful to everyone; explaining how to read the table, if not obvious from the headers alone, is useful to everyone; describing the structure of the table, if it is easy to grasp visually, might not be useful to everyone, but it might also not be useful to users who can quickly navigate the table with an accessibility tool.

암호 해독을 해보면…

테이블 요소에 대한 summary 속성은 스크린 리더 사용자를 위한 복잡한 표에 대한 설명 텍스트를 제공하기 위한 기술로 html 언어의 이전 버전에서 제안 되었고, 위에 설명 된 기술 중 하나가 대신 사용된다.

특히 웹 저작자는 테이블 대한 설명 문구는 시각 장애인에게 도움이 될 가능성이 있는지 여부를 고려하는 것이 좋다. 만약 자신의 설명 문구가 유용하지 않을 경우에는, summary 속성을 포함하지 않는 것이 좋다. 유사하게 웹 저작자가 명시한 설명문구가 시각장애인 아닌 사람에게도 도움이 될 수 있다면(이 표를 처음보는 사람이라던가), 이 설명 텍스트는 summary속성을 사용하는것 보다는 테이블의 앞에 설명하거나 caption을 사용하는것이 더 유용할것이다. 예를 들어 테이블에 포함된 데이터의 결론을 설명하는 것은 모든 이에게 유용하며, 헤더를 읽는것 만으로 충분히 이해할 수 없는 테이블을 어떻게 읽을 것인지 설명하는 것 또한 모든 이에게 유용하다. 그러나 그 시각적으로 이해하기 쉽게 되어있는 테이블의 구조를 설명하는건 누구에게나 별 도움이 되지 않으며, 접근성 도구의 도움을 받아 빠르게 탐색할 수 있는 이들에게도 도움이 되지 않는다.

라고 되어있다.
난 저 다른나라 암호를 해독하면서 note 부분이 참으로 공감이 갔다. 현재 KWCAG2.0 과 웹 접근성 품질 마크의 순기능으로 인해(부작용은 좀 나중에… 할 수 있을까?) 우리나라의 웹 저작자는 대부분 caption을 명시하고 summary속성을 명시하고 있다. 다만 caption은 제목 summary는 요약정보라는 공식 아닌 공식에 갇혀서 caption을 단지 테이블의 제목 복사, summary는 표의 구조(th나열)을 사용하는것이 현실이다. 현재의 공식을 각요소의 참역할로 보면 caption은 역할도 문제가 없고 다루기도 쉽다. 그러나 summary는 문제가 있다. summary는 구조의 요약정보만 알려주는것에 제한되어서는안되고 표의 내용을 요약할수 있어야 한다고 생각한다. 그러나 테이블의 내용에 대해 요약을 제공하는게 쉬운일은 아니라는것이다. 특히 data가 서버에서 db를 불러와 제공되는 표의 경우는 더욱 힘들것이다. 이게 summary를 제대로 쓰기에 힘든 가장 중요한 이유가 아닐까 생각한다.

facebook에서 김혜일님이 사용자입장에서 summary를 th의 항목만 나열해 넣는 경우에 “어차피 summary 듣고 나서 th를 바로 들어야하기 때문에 사실 큰 도움이 되지는 않습니다.“라는 코멘트를 하셨던것도 HTML5의 Spec. 과 의미가 통한다고 본다.

그럼 해결책을 찾아보자 다시 spec. 으로 돌아가 Tabluar data의 Techniques for describing tables 부분을 보면 답이 있다.

For tables that consist of more than just a grid of cells with headers in the first row and headers in the first column, and for any table in general where the reader might have difficulty understanding the content, authors should include explanatory information introducing the table. This information is useful for all users, but is especially useful for users who cannot see the table, e.g. users of screen readers.

Such explanatory information should introduce the purpose of the table, outline its basic cell structure, highlight any trends or patterns, and generally teach the user how to use the table.

역시 암호 해독을 해보면…

셀의 그리드로 구성되고 그 첫 행과 첫 열에 헤더 정보가 있는 단순한 구조가 아니거나, 독자가 표의 내용을 이해하는데 어려움을 느낄 수 있는 테이블일 경우에는, 테이블을 소개하는 설명 정보를 포함시켜야 한다. 이 정보는 모든 사용자에게 유용하다, 특히 테이블을 볼 수 없는 사용자(스크린리터 사용자 같은)에게 유용하다.

설명 정보는 테이블의 목적을 소개해야 하고, 기본적인 셀 구조를 나타내야 하며, 표의 경향과 패턴을 강조하고, 사용자가 테이블을 어떻게 사용할지 가르칠 수 있는 것이어야 한다.

라고 되어있고 그 위치는 구조상 테이블의 위나 caption앨리먼트에서 구조화를 통해 표현 할 수 있다고 한다. 이것에 대한 예는 4.9.1.1 Techniques for describing tables – 4.9.1 The table element 에서 확인 가능하다.
caption의 경우 html4에서는 inline element였으므로 내부의 구조화가 어려웠던 반면, html5에서는 content model이 Flow Content로 된것도 뭐 좋은 현상이라고 볼 수 있지 않을까?

내맘대로 결론을 한줄 요약을 해보면

  • 품질마크 딸라고 어거지로 summary 끼워 넣지마 정말 도움이 되는게 뭔지 고려해봐
  • 아 파젯은 어케 고치지?
  • 암호해독은 어려워

정도가 되겠다.
생각해보니 웹 접근성 품질마크에서 예전에는 caption 대신 table위에 제목을 제공해도 허용이었던거같은데 ._.

오늘도 즐거운 웹 접근성 라이프…음…

Web Accessibility

Pajet KWAG2.0 Ver.

댓글 2개

웹 접근성을 향상을위한 페이지 검증 도움도구인 pajet이 KWCAG2.0 기반으로 변경이 되었습니다.

예전 버전과 크게 변경된것은 아니지만, 몇몇 기능이 추가되었고 결과에 대한 리포팅을 지침별로 정렬시켜 두었습니다.

http://mydeute.com/was/pajet.html 페이지에서 확인이 가능합니다.

PAJET은 js, CSS를 기반으로 실행되는 툴이기 때문에 웹 사이트에 대해 영향을 많이 받습니다. 때문에 결과가 제대로 보이지 않을 수 있습니다.  ㅠ_ㅠ

저도 노력해서 디버깅을 하고 있지만, 사용하시는 분들의 도움이 절실히 필요합니다. 많은 성원 부탁드립니다 🙂

Web Accessibility

동영상에 자막제공하기

댓글 남기기

예전부터 만들어논 문서인데.. 그냥 오픈합니다.

동영상 서비스의 접근성 지침 및 가이드(WCAG2.0)

지침 1.2 시간에 기반한 미디어(Time-based Media): 시간에 기반한 미디어를 위한 대체물을 제공하라.

  1. 텍스트 콘텐츠를 이해하기 쉽게 도와주는 미디어의 역할
  2. 자막을 제공
  3. 음성 서비스(대체 콘텐츠)를 제공
  4. 설명에 대한 자막제공
  5. 수화

자막이란?

멀티미디어 콘텐츠에 대한 정보나 대화 내용, 번역 등을 콘텐츠에 동시에 보여주는 방식

자막(sami) 제공하기

SAMI

SAMI(사미, Synchronized Accessible Media Interchange; 접근성 미디어 동기화 교환)는 마이크로소프트 사에서 1998년에 발표한 미디어 접근 제안이다. 마크업 언어로 구조화되어 있으며 개인용 컴퓨터에서의 미디어 재생용 자막을 간단히 만들 수 있도록 하는 데 중점을 두고 설계되어 방송용으로는 적합하지 않다.
SAMI 문서를 전문적으로 만들 수 있는 유틸리티도 있지만, SAMI 문서는 문자열로 되어 있기 때문에 어떤 문서 편집기로도 다룰 수 있다. 파일 확장자로 .smi 혹은 .sami를 사용하는데 .smi는 SMIL 파일도 사용하는 확장자이기 때문에 서로 충돌하게 된다.  SAMI 문서에 여러 종류의 언어를 담을 수 있다.
대한민국에서는 자막 포맷으로 SAMI가 가장 많이 쓰인다.

youtube는 플래시 기반의 멀티미디어 재생기임에도 불구하고 자막 업로드를 제공하고 있다.
youtube의 자막이 보여지는 방식

youtube에 자막을 업로드...

기타 멀티미디어 업로드 사이트에서는 특별한 자막 지원여부를 확인해보지 않았다.

MEDIAPLAYER를이용해 자막을 지원하기

http://mydeute.com/tip/mov/gee.html

<object id="Player" classid="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" width="480" height="272">
<param name="URL" value="gee.wmv">
<param name="autoStart" value="false">
<param name="captioningID" value="captions">
<param name="SAMIFileName" value="gee.smi"> 
<!--[if !IE]> <-->
<object type="application/x-ms-wmp" data="gee.wmv" width="480" height="272">
<param name="pluginspage" value="http://www.microsoft.com/Windows/MediaPlayer/">
<param name="url" value="gee.wmv">
<param name="autoStart" value="false">
<param name="captioningID" value="captions">
<param name="SAMIFileName" value="gee.smi"> 
</object>
<!--> <![endif]-->
</object>
<div id="captions" style=""> </div>
  • <param name=”captioningID” value=”captions”> : 자막이 보여질 element의 ID 지정
  • <param name=”SAMIFileName” value=”gee.smi”> : 자막 파일의 경로

대부분의 브라우저에서 자막 확인이 가능함

올바른 자막의 제공

단순한 대화나 말에 대한 자막뿐만 아니라, 상황을 이해 할 수 있는 설명도 포함 하는것이 좋다.

사용자가 쉽게 자막을 제공 할 수 있게 하는 방법

자막을 제작할 수 있는 환경을 구성한다. (동영상 업로드시)