백남중

하이퍼 텍스트(Hyper Text)로 시작한 인터넷이 그림, 동영상, 오디오와 같은 멀티미디어가 포함되면서 인터넷 활용의 많은 형태를 바꾸어 놓았다.

그러나 유용한 멀티미디어 콘텐츠는 두 가지 장애 영역에서 접근에 어려움을 주고 있다.

첫 번째는 청각장애인의 문제이다.
청각장애인은 멀티미디어 콘텐츠의 오디오를 접할 수 없기 때문에 이를 해결할 수 있는 대체 매체를 제공해 주어야 한다.
즉 청각장애인이 접근할 수 있도록 영상 매체와 동기화된 캡션을 제공해 주거나 수화 자막 또는 대본을 제공해 주어야 한다.

두 번째는 시각장애인의 문제이다.
시각장애인은 청각장애인과는 반대로 영상매체의 오디오 부분은 접할 수 있으나 그 조작을 할 수 없는 경우 접근에 어려움을 갖는다.
시각장애인의 대부분은 스크린 리더를 활용하여 인터넷을 하기 때문에 주어지는 영상 매체를 어떻게 제어하느냐가 커다란 쟁점이 된다.

따라서 WCAG2.0의 1.4.2 오디오 제어에서는 '3초 이상 자동으로 재생되는 웹 페이지의 오디오는 중지 또는 일시 정지 기능을 제공하거나, 전체 시스템의 볼륨 제어와는 다른 독립적인 볼륨 제어 시스템을 제공해야 한다'고 정의하고 있다.

시각장애인의 입장에서 보면
- 스크린 리더를 사용하는 시각장애인의 입장에서 보면 스크린 리더의 음성이 기본 소리가 되고(foreground sound) 나머지 소리는 배경음(background sound)가 될 수 밖에 없다. 따라서 배경음으로 인하여 스크린 리더의 음성 출력을 인지할 수 없다면 접근에 문제가 된다.
- 자동으로 영상 매체의 오디오가 재생되는 경우 제어 방법이 없다면 해당 사이트의 내용을 파악하는데 문제를 가져오며
- 특히 스크린 리더의 음성이 오늘날과 같이 TTS와 같은 소프트 웨어에 기반을 두고, 오디오 사운드와 같은 볼륨 콘트롤을 사용하는 경우에는 더욱 그렇다. 따라서 별도의 볼륨 콘트롤을 제공하는 것이 매우 중요하다.

이러한 문제를 해결하기 위하여
- 자동 재생 오디오가 3초 이내에 자동으로 꺼지거나
- 웹 페이지의 처음에 콘트롤을 제공하여 자동으로 재생하는 오디오를 끌 수 있게 하거나
- 사용자의 요청에 의해서만 오디오가 재생될 수 있도록 하여야 한다고 권고하고 있다.
WCAG 2.0 1.4.2 Audio Control

이어지는 내용

센스리더 프로페쇼날이 1.2로 업데이트 되면서 기능키의 일부가 변경되거나 새로 추가되었다.
이에 센스리더 관련 핫키를 다시 정리하였다.

(변경 및 추가 사항)
툴팁 읽기: Ctrl-Alt-Shift-T (레이블 및 타이틀 속성 확인)
다음 링크로: Ctrl-'(어퍼스트로피)
이전 링크로: Ctrl-Shift-'(어퍼스트로피)
이전 방문한 링크로: Ctrl-Shift-;(세미콜론)
다음 방문한 링크로: Ctrl-;(세미콜론)
이미지 읽기 토글: Ctrl-,(쉼표)
자동 포커스 선택: Ctrl-.(마침표)
숨김 항목 읽기 토글: Ctrl-/(슬래시)
마크목록 ctrl+J 추가

(인터넷 관련 변경 및 추가사항)
미디어 재생: 콘트롤 ](대괄호 닫고)
미디어 중지: 콘트롤 [(대괄호 열고)
미디어 앞으로: 알트 ](대괄호 닫고)
미디어 이전으로 알트 [(대괄호 열고)
미디어 볼륨크게: 알트+쉬프트 ](대괄호 닫고)
미디어 볼륨작게: 알트+콘트롤 [(대괄호 열고)
미디어 빠르게 : 콘트롤+쉬프트 ](대괄호 닫고)
미디어 속도 느리게: 콘트롤+쉬프트 [(대괄호 열고)
미디어 정상 속도로: 콘트롤+쉬프트 =
미디어 정보: 콘트롤+알트+쉬프트 ](대괄호 닫고)
활성 미디어 변경: 콘트롤+알트+쉬프트 [(대괄호 열고)
이미지 읽기 방법(레이블만, 모두, 읽지않기): Ctrl+, (comma)
자동포커스on/off: Ctrl+. (period)
숨김항목 on/off: Ctrl+/ (slash)

기능키는 모드에 따라 다르게 작동하기 때문에 커서모드 앞에는 검정 마우스를, 뷰모드 앞에는 흰마우스를, 가상커서에는 체크 표시를 하여 구분하였다.

이 자료를 만들기 위해 도와주신 방미희님, 한혜진님께 감사를 드립니다.

센스리더프로1.2 핫키 다운받기

CSS의 미디어 타입에는 aural (음성 출력), braille (점자 출력), handheld (포켓, 모바일), print (인쇄), projection (투사 장치), screen (스크린, 모니터), tty (전신 타자기, Tele Type Writer), tv (텔레비전, Television)이 있고 이 모든 장치를 정의할 경우에는 all(모든 출력 장치)을 사용한다. 기본적으로 미디어 타입이 지정되어 있지 않은 경우에는 모든 장치 media="all"을 지정한 것과 같다.
정찬명: CSS와 웹 접근성. 그리고 장치의 표준화

위와 같은 미디어 타입으로 출력하지 않기 위해서는 display:none을 사용한다.
CSS2 규격에서는 display:none의 속성에 대해 다음과 같이 설명하고 있다.

이 값은 양식화 구조 안의 박스에 엘레멘트를 생성하지 않는다(그 엘레멘트는 배열 효과가 없다). 하위(descendant) 엘레멘트들도 어떤 박스 생성하지 않는다; 이 작용은, 하위에 'display' 속성을 설정함으로서, 덮어씌워(override) 질 수 없다.
'none'의 디스플레이(display)는 보이지 않는 박스를 생성하지 않는다는 점에 유의하라; 이는 아무 박스도 생성하지 않는다. CSS 기능들을 엘레멘트가 양식화 구조 안에서, 그 자체는 보이지 않으나 양식화에 영향을 주는 박스를 생성할 수 있다. 세부사항 보임성(visibility)를 참조하라.
보이는 양식화 모델

즉 display:none은 홈 페이지 내에서 특정 엘레멘트나 콘텐츠를 감출 때 많이 사용하며, 해당 내용을 보이게 하기 위해서는 display:block을 사용한다.
대표적인 사용 방법 예로 주메뉴에서 부메뉴를 감추는 것을 들 수 있다.

그런데 현재 사용하고 있는 방법이 스크린 리더와의 음성 출력에 있어서 문제가 있다.
1. 주메뉴와 부메뉴의 display:none, display:block
2. 센스 리더와 display:none 처리 역사
3. display:block과 스크린 리더
4. 바램


이어지는 내용

많은 웹 접근 관련 글에서 h1은 한 번만 사용하라고 되어 있습니다.
즉 모든 페이지는 적어도 하나의 h1이 있어야 하며, 페이지의 메인 헤딩에 h1을 적용하라고 권고하고 있습니다.

Better Connected, Better Results: Headings
- Every page must have at least one (the H1)
- Only one H1 per page
- The H1 must be applied to the main heading of the page

wcag2.0의 Understanding Succession Criterion 2.4.10에서는 콘텐츠를 구조화하기 위하여 섹션 헤딩(section heading)을 사용하라고 레벨 AAA로 정의하고 있습니다.
2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)
또한 헤딩의 중간 단계를 건너 뛰지 말고 적절하게 제공하라고 권고하고 있습니다.
예를 들어 h1에서 h2를 건너 뛰고 h3으로 이동한다든지의 경우처럼 말입니다.

사실 h1 문제는 몇 개를 사용했는냐는 문제보다는 어느 곳을 지정할 것인가 하는 문제입니다.
즉 h1을 문서 처음의 회사 로고에 설정할지, 아니면 본문 중에서 가장 중요한 곳을 설정할지의 문제입니다.
우리나라에서는 대부분의 사이트들이 처음 회사 로고에 h1을 사용하지만 외국도 반드시 그런 것은 아닌 것 같습니다.
W3C의 경우에는 헤딩 사용이 아주 모범적입니다.
미국 정부 홈페이지의 경우 왼쪽 위에 있는 성조기 부분을 h1로 처리하지 않고 본문 시작 부분 Government Information by Topic를 h1로 처리하였습니다.
* 미국 정부는 wcag의 지침을 따르는 것이 아니라 508조에 의하기 때문에 h1, h4, h2, h4로 이동했습니다.

두 사이트 모두 구조도 위에 있는 내비게이션은 헤딩이나 목록 처리를 하지 않고 본문 부분만 처리한 것이 이채롭습니다.

h1을 어디에 설정하느냐 하는 문제는 지난 주 Twitter에서도 문제가 되서 이에 대한 찬성, 반대 사이트 h1debate가 개설 되었습니다.
오늘(2009.6.17 오후 5시) 현재의 찬반은 로고 30.97% : 메인 타이틀 69.03%입니다.

우리하고는 약간 다른 헤딩의 사용에 대한 방식이 무엇을 의미하는지 다시 한번 되새겨 볼 필요가 있을 것 같다.

많은 웹 문서에서 목록을 남용하고 있다.
물론 혹자는 코딩에 정도가 없다고 항변할 수 있으나, 기본적인 문법을 따르지 않는 것은 접근성을 논의하기 이전의 문제이다.
여기서는 웹 문서에서 목록의 코딩 오용에 대해 알아보고자 한다.

웹 문서에서 연속된 내용을 나타내는 방법에는 <ul>과 <ol>이 있다.
또한 사전의 표제어처럼 항목에 대한 설명을 달기 위해서는 정의목록 <dl>을 사용한다.

HTML 4.01의 목록에 관한 내용:

• 앞 목록 예제는 번호없는 목록으로 <UL> 엘레멘트로 만들어진다.
  
• <OL> 엘레멘트로 만들어지는 번호있는 목록(ordered)은 번호가 강조되는 정보에 사용된다.
• 정의 목록(definition list)은 <dl> 엘레멘트로 만들어 지는데, 다른 것도 포함 할 수 있으나, 일반적으로 텀(term:작은제목)/정의(definition)의 짝들로 이루어진다.

-목차-

1. HTML, WCAG와 목록 관련 조항
2. 잘못 사용 사례
    2.1 각각의 목록을 <ul>로 처리한 경우
    2.2 한 개의 목록을 두 개 이상으로 나누는 경우
    2.3 정의 목록(<dl> definition list)의 잘못 사용 문제
    2.4 <li> 대신 <dd>를 사용하는 경우
    2.5 정의 목록과 <li>를 혼용한 경우
3. 스크린 리더 활용자를 위한 목록 코딩을 위한 제언
    3.1 <ol>의 활용
    3.2 정의 목록의 음성 출력 문제

(본 글에서는 내용의 이해를 돕기 위하여 WAT(Web Accessibility Tool)을 사용하여 분석한 화면을 캡춰하여 'WAT의 List item 보기 화면'라는 명칭 하에 원래의 화면과 비교하였다)


이어지는 내용