웹 콘텐츠(의) 접근성(을 높이기 위한 제작) 지침 1.0

Translated document may contain errors from translation.
이 번역본은 원본 문서에 없으나 번역 과정에서 생긴 오류를 포함할 수도 있습니다. 번역 과정에서 생긴 오류를 발견하신 분은 gregshin at hanafos.com으로 내용을 보내주시면 감사하겠습니다.

요약

이 지침은 장애인들이 어떻게 웹 콘텐츠 에 접근할 수 있게 할 것인지 설명하고 있다. 이 지침은 모든 웹 콘텐츠 개발자 (페이지를 제작하는 사람과 사이트 디자이너)와 저작 도구 개발자를 위한 것이다. 이 지침의 첫째 목표는 웹 페이지의 접근성을 높이는 것이다. 그러나 이 지침을 따름으로써 웹 표시 장치(user agent)(예를 들어, 탁상용 브라우저, 음성 브라우저, 이동 전화, 자동차용 컴퓨터 등)의 종류나 사용 환경(소음이 심한 곳, 조명이 지나치게 어둡거나 지나치게 밝은 곳, 손을 사용할 수 없는 환경 등 매우 다양한 환경에서 웹이 쓰인다.)과 무관하게 모든 이가 보다 쉽게 웹 콘텐츠에 접근할 수 있을 것이다. 또, 이 지침을 따름으로써 웹 정보 검색을 더 빠르게 할 수 있다. 이 지침은 개발자에게 그림(이미지)이나 동영상 등을 쓰지 말라고 권하지는 않는다. 그러나 멀티미디어에 담긴 내용을 더 많은 사람들이 향유하게 하는 방법을 설명하고 있다.

이 문서는 접근성 원칙(accessibility principles)과 디자인 아이디어에 대한 참고서라고 할 수 있다. 이 문서에서 논의된 방법들은 웹의 국제화와 무선 접속에 대한 고려 사항을 포함하고 있다. 그러나 이 문서는 접근성에 관해 집중적으로 다루고 있으며, W3C의 다른 관련 활동에 대해서 상세하게 다루지는 않는다. 이들에 대한 자세한 정보는 W3C의 무선 및 이동 접속에 대한 활동 홈페이지 와 W3C의 국제화 활동에 대한 홈페이지를 참조하라.

이 문서는 다양한 웹 기술에 대한 브라우저의 지원 여부나 지원 정도에 대한 정보를 제공하지 않으며 (그런 정보는 안정적인 문서에 포함하기에는 너무 빨리 변화한다.) 그런 것과 상관없는 안정적인 (역자 추가: 그리고 보편적인) 내용을 제공하려고 한다. 대신에 웹 접근성 이니셔티브 (WAI) 웹사이트에서 그런 정보를 제공하고 있다([WAI-UA-SUPPORT]를 참조하라.).

이 문서의 부록은 주제와 중요도에 따라 분류한 모든 체크포인트를 담고 있다. 부록에 있는 체크포인트는 이 문서에 있는 해당 정의와 연결되어있다. 부록에서는 이미지, 멀티미디어, 표(tables), 프레임, 폼(forms), 스크립트 등이 다뤄지고 있다. 부록은 표 형식 또는 단순 나열식으로 볼 수 있다.

다른 문서인 "웹 콘텐츠의 접근성을 높이기 위한 기술적 방법 1.0"([TECHNIQUES])에서는 이 문서에서 정의한 체크포인트를 어떻게 구현할 것인지 설명하고 있다. 그 문서에서는 각 체크포인트를 더 자세하게 다루고 있고, Hypertext Markup Language (HTML), Cascading Style Sheets(CSS), Synchronized Multimedia Integration Language (SMIL), Mathematical Markup Language (MathML)를 사용한 예제를 제시하고 있다. 또 그 문서에서는 문법 검사(validation)와 시험 기법에 대한 내용이 들어있으며, HTML 요소(elements) 및 속성(attributes)에 대한 색인과 어떤 기술이 그것을 사용하는지에 대해서도 나와 있다. 기술적 방법을 다루는 문서는 기술의 변화를 따라가는 것이 중요하므로 이 문서보다는 더 자주 개정될 것이다. Note. 모든 브라우저와 멀티미디어 프로그램이 지침에서 제시한 모든 기능을 지원하지는 않는다. 특히 HTML 4.0이나 CSS 1, CSS 2에서 새로이 규정한 것은 지원되지 않을 가능성이 더 높다.

"웹 콘텐츠 접근성을 높이기 위한 제작 지침 1.0"은 웹 접근성 이니셔티브가 발행하는 접근성 지침 시리즈의 일부이다. 시리즈에는 접근성을 높이기 위한 웹 표시 장치 제작 지침 (User Agent Accessibility Guidelines, [WAI-USERAGENT])과 접근성을 높이기 위한 저작 도구 개발 지침(Authoring Tool Accessibility Guidelines, [WAI-AUTOOLS])도 들어있다.

이 문서의 현재 상태

이 문서는 W3C 회원과 다른 관계자의 검토를 거쳐 W3C 총재가 W3C 권고안으로 승인하였다. 이 문서는 안정적인 문서이므로 참고 자료로 쓰이거나 규범적인 참고 문헌으로 다른 문서에서 인용할 수 있다. W3C가 권고안을 만드는 것은 (표준) 사양에 대해 주의를 환기시키고, 보다 넓은 범위에서 그 사용을 촉진하기 위해서이다. 이렇게 함으로써 웹의 기능성과 보편성을 향상시킬 수 있다.

이 사양에 대한 영어판만이 규범력을 지닌다. 그러나 다른 언어 번역판을 보고 싶으면, http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS 를 참조하면 된다.

이 문서에 대해 지금까지 알려진 오류 목록은 http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA 에서 볼 수 있다. 이 문서에 오류가 있으면 wai-wcag-editor@w3.org 로 메일을 보내주기 바란다.

W3C의 권고안 문서 목록이나 다른 기술적인 문서는 http://www.w3.org/TR에서 찾아볼 수 있다.

이 문서는 W3C의 웹 접근성 이니셔티브의 일환으로 만들어진 것이다. 웹 콘텐츠 지침에 관한 워킹 그룹 (Web Content Guidelines Working Group)의 목적은 이 그룹의 헌장에 나와있다.

부록에 나와있는 체크포인트 목록은 표 형식이나 단순한 나열식 두 가지로 볼 수 있다.

1. 소개

웹 디자이어인 당신에게 웹 접근성이 생소한 개념이라면 많은 다른 사용자들은 당신과 다른 환경에서 웹을 보고 있다는 것을 생각해 보라.

• 어떤 사람들은 보고, 듣고, 움직이는데 장애가 있을 수 있고, 또는 정보의 일부를 처리하지 못 하는 수도 있다.
• 어떤 사람들은 글을 읽고, 이해하는 것에 어려움을 가지고 있다.
• 키보드나 마우스가 없거나, 또는 키보드나 마우스를 사용하지 못 하는 환경일 수도 있다.
• 어떤 사람들은 텍스트만 나오는 화면이나, 아주 작은 화면을 써야 할 수도 있고, 또 느린 인터넷 접속만이 가능할 수도 있다.
• 자기 언어가 아닌 경우 특정 언어를 유창하게 말하고 이해하지 못 한다.
• 사용자의 눈, 귀, 손이 다른 일(예: 운전, 시끄러운 환경에서 작업 등)을 하고 있거나 다른 일로 방해를 받을 수도 있다.
• 사용자에 따라 초기 버전의 브라우저를 쓸 수도 있고, 전혀 다른 브라우저를 쓸 수도 있으며, 음성 브라우저나 다른 운영 체계를 쓸 수도 있다.

콘텐츠 개발자들은 페이지를 디자인할 때에 이런 다양한 상황을 고려 해야 한다. 다른 고려 요소도 있지만, 접근성이 높은 디자인을 채택할 경우 일반적으로 장애를 가진 사용자들에게 우선 이익이 되고, 전체 웹 사용자들에게도 이익이 된다. 예를 들어서, FONT라는 요소를 사용하지 않고 대신에 스타일 시트를 사용하여 글꼴 스타일을 조정하게 되면, HTML 제작자 들은 페이지에 대한 더 쉬운 제어가 가능하고, 시력이 나쁜 사람들에게도 페이지를 잘 볼 수 있게 할 수도 있으며, 스타일 시트를 공유함으로써, 종종 페이지 다운로드 시간을 줄이는 효과를 줄 것이다.

이 지침에서는 접근성에 대해 다루고, 접근성이 높은 디자인을 위한 기법을 제공한다. 또, 위의 글꼴 예에서 다루었듯이, 장애가 있는 사람들에게 문제가 될 만한 전형적인 시나리오를 다룬다. 예를 들어, 첫 번째 지침에서는 어떻게 이미지의 접근성을 높일 수 있는지 설명한다. 어떤 사용자는 이미지를 볼 수 없을 것이고, 어떤 사람은 텍스트 기반의 브라우저를 쓸 수도 있으며, 또 다른 이들은 (이를테면 인터넷 속도가 느려서) 이미지를 일부러 보이지 않게 설정했을 수도 있다. 이 지침에서 접근성을 높이기 위해 이미지를 쓰지 말라고 권고하지는 않는다. 대신에 이미지를 대체할 수 있는 텍스트 설명을 제공해 줌으로써 접근성을 높일 수 있을 것이다.

텍스트 설명을 붙이는 것이 어떻게 이미지에 대한 접근성을 높이는가? "대체 텍스트"라는 말의 두 단어가 모두 중요하다.

• 텍스트 콘텐츠는 사용자에게 합성된 음성으로, 점자로, 또는 말 그대로 시각적인 텍스트로 제시될 수 있다. 이들 각각의 경우 다른 감각 기관을 통해 전달된다. 즉, 합성된 음성은 귀를 통해서, 점자는 촉각을 통해, 그리고 텍스트는 시각을 통해 전달된다. 이렇게 함으로써 여러가지 감각 기관에 장애를 지닌 이들의 정보 접근성을 제고할 수 있다.
• 텍스트가 유용하려면 텍스트도 이미지가 의도했던 것과 같은 기능이나 목적을 전달해야 한다. 예를 들어서 우주에서 바라본 지구 사진에 대한 대체 텍스트가 있다고 생각해보자. 만약 이미지를 보여주는 목적이 주로 장식적인 것이라면, "우주에서 바라본 지구 사진" 정도가 필요한 목적에 부합하는 텍스트가 될 것이다. 만약에 사진을 보여주는 목적이 세계 지리에 대한 특정한 정보를 예로 들기 위한 것이라면 텍스트 설명도 그런 정보를 담고 있어야 한다. 만약 이미지를 선택하여 (예를 들면 사진을 클릭하도록 해서), 지구에 관한 정보를 제공하도록 되어 있다면, 그것에 대한 대체 텍스트도 "지구에 관한 상세 정보" 정도가 되는 것이 좋을 것이다. 그러므로, 이미지가 사용자들에게 제공하는 기능이나 목적과 똑같은 것을 텍스트가 제공해 준다면, 그것은 훌륭한 대체 텍스트가 될 수 있다.

대체 텍스트를 사용하는 것은 장애인들에게만 이득을 주는 것이 아니다. 검색 로봇은 페이지 색인을 만들 때에 그 대체 텍스트를 사용할 수 있기 때문에 모든 사용자들이 페이지를 더 빨리 찾을 수 있도록 도움을 줄 수 있다. (역자 주: 또 다른 보기는 단어나 문장을 포함하고 있는 이미지이다. 이 이미지에 대체 텍스트를 붙여 주면, 웹 페이지 자동 번역 프로그램으로 이미지에 들어 있는 단어나 문장에 쓰인 언어를 모르는 이도 내용을 파악할 수 있다.)

웹 콘텐츠 개발자들은 이미지나 다른 멀티미디어 콘텐츠에 대해서 대체 텍스트를 제공해야 하는 한편, 사용자들에게 최종적으로 정보를 표시해주는 표시 장치 (예를 들면 브라우저나, 이를 지원하는 화면 음성 변환기, 점자 표시 장치 등)는 사용자들에게 대체 텍스트에 담긴 정보를 최종 전달해 주어야 한다.

텍스트가 아닌 다른 대체 방법 (예 : 아이콘, 녹음된 음성, 또는 수화를 보여주는 비디오)도 인지적인 장애, 학습 장애, 청각 장애를 포함하여 문자로 쓰여진 텍스트에 접근하는 데에 어려움을 겪는 많은 사람들에게 문서에 대한 접근성을 높여줄 수 있다. 이는 또 읽는 것을 싫어하거나 못 읽은 사람들에게도 도움이 될 수 있다. 시각 정보에 대한 음성 설명같은 것이 텍스트 형식이 아닌 대체 표현 방법이 될 것이다. 멀티미디어 프리젠테이션에서 시각 부분에 대한 음성 설명을 통해 시각 정보를 볼 수 없는 사람에게 도움을 준다.

2. 접근 가능한 디자인에서 다루는 주제

이 지침에서는 두 가지 보편적 주제를 다룬다. 콘텐츠가 여러 환경에서 내용을 보전하면서 쉽게 변환되어 표시될 수 있는가 하는 것이 하나이고, 이해하고 탐색하기 쉬운 콘텐츠를 만드는 것이 하나이다.

2.1 콘텐츠가 정보를 보전하면서 여러 방법으로 표시 가능하도록 하기

이 지침을 따름으로써, 콘텐츠 개발자들은 여러 환경에서 정보를 보전하면서 변환될 수 있는 페이지를 만들 수 있다. 여러 환경에서 쉽게 변환될 수 있는 페이지란, 소개 부분에서 나왔던 신체, 감각, 인지 장애나 작업 환경의 제약 조건, 기술적인 장벽과 상관없이 접근성이 높은 페이지이다. 여러 환경에서 쉽게 변환되는 페이지를 디자인하기 위해서는 다음과 같은 원칙들이 있을 수 있다.

• (정보의) 표현 방법(presentation)과 (정보에 내재하는) 구조(structure)는 분리한다. (콘텐츠, 구조, 표현 방법(presentation) 사이의 차이에 대해서 읽어보라.)
• (대체 텍스트를 포함해서) 텍스트를 제공한다. 텍스트는 거의 모든 종류의 브라우저에서 가능한 형태로 전달될 수 있고, 거의 모든 사용자들에게 접근가능하다.
• 볼 수 없거나 들을 수 없는 사용자에게도 전달할 수 있는 문서를 만든다. 오디오나 비디오의 경우, 다른 감각 채널로 그 목적이나 기능이 동일한 정보에 접근할 수 있게 해야 한다. 이것은 맹인을 위해 전체 사이트를 미리 오디오 녹음하여 제공하라는 뜻이 아니다. 맹인 사용자의 경우 화면 음성 변환기(screen reader) 기술을 이용해서 페이지 내의 모든 텍스트 정보를 접할 수 있다.
• 한 가지 하드웨어에 의존하는 문서를 만들지 않는다. 사람들은 마우스가 없을 수도 있고, 화면이 작을 수도 있고, 화면 해상도가 낮을 수도 있고, (역자 주 : 고해상도 모니터를 쓰는 경우라도 화면 확대 장치를 쓰는 약시인 사람은 한번에 화면의 극히 작은 일부만을 볼 수 있다.) 흑백 화면일 수도 있고, 화면이 없고 단지 음성만 나오거나, 텍스트만 나올 수도 있다.

여러 환경에서 정보를 보전하면서 쉽게 변환되는 문서에 대한 주제는 지침 1에서 11 사이에 주로 다루어진다.

2.2 이해하고 탐색하기 쉬운 콘텐츠 만들기

콘텐츠 개발자들은 콘텐츠를 이해와 탐색이 쉽게 만들어야 한다. 이것은 단지 말을 간결하고 명확하게 써야 한다는 것뿐만 아니라, 페이지 내에서 혹은 페이지 사이에 이해하기 쉬운 탐색 방법을 제공해야 한다는 것을 뜻한다. 페이지마다 항해(navigation) 도구과 방향(orientation) 정보를 제공함으로써 접근성과 편리함을 극대화할 수 있다. 탁상용 브라우저의 사용자들만 볼 수 있는 시각적인 단서(예를 들면, 이미지 맵, 가변적인 스크롤바, 줄줄이 늘어선 프레임, 그래픽 등)를 모든 사용자들이 이용할 수 있는 것은 아니다. 사용자들은 음성 합성 장치나 점자 표시 장치 등을 통해 페이지를 볼 경우와 같이 한 번에 한 단어씩만 접근 가능하다든지, 또는 좁은 화면이나 낮은 해상도 때문에 한 번에 일부분만 볼 수 있는 경우가 있기 때문에, 맥락 정보를 잃어버릴 수 있다. 방향 정보가 없다면 사용자들은 아주 큰 표나 목록, 메뉴 등을 이해하지 못 할 수도 있다.

콘텐츠를 이해하고 탐색하기 쉽게 만드는 것에 대해서는 지침 12에서 14 사이에서 주로 다루고 있다.

3. 이 지침의 구성

이 문서는 14개의 지침 또는 접근성을 높이기 위한 디자인의 일반적인 원칙을 담고 있다. 각각의 지침은 다음과 같은 요소를 포함하고 있다.

• 지침의 번호
• 문장으로 기술된 지침 자체
• 세 개의 항해 링크. 오른쪽 화살표 아이콘은 다음 지침으로 넘어가는 링크이고, 왼쪽 화살표는 이전 지침으로, 위 화살표는 목차로 돌아가는 링크로서 목차 내에서 현재 보고 있는 지침의 위치를 알 수 있게 해 준다.
• 이런 지침이 나온 이론적 근거와 지침이 도움을 주고자 한 사용자층
• 체크포인트 정의

각 지침에 있는 체크포인트 정의는 전형적인 콘텐츠 개발 상황에서 이런 지침이 어떻게 적용가능한지 설명해 준다. 각각의 체크포인트 정의는 다음과 같이 구성되어 있다.

• 체크포인트 번호
• 체크포인트 문장 자체
• 체크포인트의 중요도(우선 순위). 중요도 1인 체크포인트는 스타일 시트를 사용하여 눈에 띄도록 강조하였다.
• 부가적인 주의 사항이나 정보, 예제, 관련 지침이나 체크포인트에 대한 상호 참조 정보
• 제시된 체크포인트를 구현하고 예제를 제시해 주는 기술적인 문서([TECHNIQUES])에 대한 안내

각 체크포인트는 실제 페이지나 사이트를 점검할 때 체크포인트를 만족시키는지 검증할 수 있도록 가능한 한 구체적으로 작성하였다.

3.1 이 문서의 규칙

이 문서는 다음과 같은 편집상의 규칙을 따르고 있다.

• 요소(element) 이름은 대문자로 표시한다.
• 속성(attribute) 이름은 소문자로 따옴표 안에 표시한다.
• 용어의 정의로 연결되는 링크는 스타일 시트를 사용하여 강조 표시하였다.

4. 중요도(우선 순위)

각각의 체크포인트는 워킹 그룹에서 접근성에 미치는 영향력에 따라 부여한 우선 순위(중요도)가 매겨져 있다.

[중요도 1]

웹 콘텐츠 개발자들이 반드시 따라야 할 체크포인트이다. 그렇지 않을 경우, 일부 사용자들이 정보에 접근하는 것이 불가능해진다. 이 체크포인트는 웹 접근성을 보장하기 위해서 지켜야 하는 기본적인(필수적인) 요구 사항이라고 할 수 있다.

[중요도 2]

웹 콘텐츠 개발자가 되도록 지켜야 할 체크포인트이다. 그렇지 않을 경우, 일부 사용자들이 정보에 접근하는 것에 어려움을 겪게 될 것이다. 이 체크포인트를 만족시킴으로써 웹 문서에 접근하는데 중요한 장벽을 제거할 수 있다.

[중요도 3]

웹 콘텐츠 개발자는 이 체크포인트를 지키는 것이 좋다. 그렇지 않을 경우, 일부 사용자들이 정보에 접근하는 것에 다소 어려움을 겪을 것이다. 이 체크포인트를 만족시킴으로써 웹 문서의 접근성을 향상시키게 될 것이다.

일부 체크포인트의 경우에는 조건에 따라 중요도(우선 순위)가 변하는 것을 명시하고 있다.

5. 적합성(호환성) 수준

여기에서는 지침에 대한 세 가지 적합성 수준을 정의한다.

• "A"수준의 적합성: 1순위 중요도를 갖는 모든 체크포인트들을 만족하는 경우
• "AA" 수준의 적합성: 1순위와 2순위 중요도를 갖는 모든 체크포인트들을 만족하는 경우
• "AAA" 수준의 적합성: 1, 2, 3순위 중요도를 갖는 모든 체크포인트들을 만족하는 경우

Note. 적합성 수준은 텍스트로 표시되어 화면 음성 변환기로 변환될 수 있도록 되어있다.

적합성 표시를 할 때에는 다음과 같은 두 가지 형식 중에 하나를 반드시 따라야 한다.

제 1 형식에서 명시해야 하는 항목

• 지침의 제목: "Web Content Accessibility Guidelines 1.0"
• 지침의 URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
• 만족하는 적합성 수준: "A", "AA", 또는 "AAA".
• 적합성을 만족하는 범위 (예를 들면, 페이지, 사이트, 또는 사이트의 특정한 일부분 등)

제 1 형식의 예

This page conforms to W3C's "Web Content Accessibility Guidelines 1.0", available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level Double-A. (이 페이지는 W3C의 http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505 에서 제시한 "웹 콘텐츠의 접근성을 높이기 위한 제작 지침 1.0"의 AA 수준을 만족합니다.)

제 2 형식: 매 페이지에 W3C에서 제공하는 세 개의 적합성 표시 아이콘 중에 하나를 삽입하고, W3C의 적합성을 설명해주는 곳으로 링크를 걸어 준다. 아이콘에 대한 자세한 정보와 페이지 내에 삽입하는 방법은 [WCAG-ICONS]에 나와 있다.

6. 웹 콘텐츠(의) 접근성(을 높이기 위한 제작) 지침

지침 1. 시각/청각적인 콘텐츠에 대해서는 그것을 대신할 수 있는 대체 텍스트를 제공한다.

시각적/청각적 콘텐츠를 제시할 때에는 근본적으로 그 기능과 목적이 동일한 대체 콘텐츠를 제공한다.

어떤 사용자들은 이미지, 동영상, 소리, 애플릿 등을 직접 사용할 수 없지만, 그런 시청각적인 콘텐츠에 대한 대체 정보를 포함하고 있는 페이지는 사용 가능할 것이다. 대체 정보는 반드시 원래 콘텐츠와 동일한 목적을 달성할 수 있어야 한다. 따라서, 목차로 돌아가는 윗화살표 그림에 대한 대체 텍스트는 "목차로 돌아가기" 정도가 될 수 있을 것이다. 어떤 경우에는 대체 정보가 시각적인 콘텐츠(예 : 복잡한 차트, 빌보드, 다이어그램의 경우)에 대한 시각적인 모양을 설명할 수도 있고, 음성 콘텐츠(예: 교육용 음성 강의 녹음물의 경우)에 대한 내용을 담을 수도 있다.

이 지침에서는 텍스트가 아닌 콘텐츠(이미지, 오디오, 비디오)에 대한 대체 텍스트 제공의 중요성을 강조하고 있다. 대체 텍스트는 다양한 기술적인 방법을 통해 여러 종류의 장애를 가진 사용자들에게 접근 가능한 방법으로 변환될 수 있다는 점에서 효력이 있다. 텍스트는 음성 합성기가 읽어줄 수도 있고, 점자 표시 장치를 통해 출력될 수도 있고, 컴퓨터 화면과 종이를 통해 (여러가지 크기로) 시각적으로 출력될 수도 있다. 음성 합성기의 출력은 맹인이나, 인지적인 장애, 학습 장애, 청각 장애 등으로 인해 읽는 것에 어려움이 있는 사람들에게 아주 중요한 역할을 한다. 점자는 시각 장애인 뿐 아니라, 청각과 시각에 모두 장애를 가진 사람에게는 필수적이다. 시각적으로 보여지는 텍스트는 대부분의 웹사용자는 물론이고 청각 장애인에게 혜택을 준다.

텍스트에 대한 텍스트가 아닌 대체물(예를 들어, 이미지, 비디오, 오디오)을 제공하는 것도 일부 사용자들, 특히 문맹자들이나 난독증이 있는 이들에게 도움을 줄 수 있다. 영화나 다른 시각적인 표현물에서 몸짓이나 다른 시각적인 단서가 충분한 오디오 정보 없이 제공되는 수가 있다. 이런 시각적인 정보를 말로 설명하지 않고 제공한다면, 시각적 내용을 볼 수 없는 사람들은 지각할 수 없을 것이다.

체크포인트:

1.1 모든 비-텍스트 콘텐츠에 대해서는 대체 텍스트를 제공한다. (예를 들어 "alt", "longdesc" 등을 쓰거나 또는 요소 내의 콘텐츠에 직접 쓴다.) 이것은 다음을 포함한다.: 이미지, (기호를 포함하여) 그래픽으로 나타낸 텍스트, 이미지 맵의 영역, 애니메이션(예: 애니메이션 GIF), 애플릿, 프로그램 객체, 아스키 아트 (역자 주: 영문자와 기호를 여러 개 이용하여 시각적으로 그림을 표현한 것), 프레임, 스크립트, 리스트 불릿으로 쓰인 이미지(역자 주: 목록을 나열할 때 각 항목 앞에 쓰인 점, 동그라미 등과 같은 이미지), 공간을 확보하기 위해 쓰인 빈 그림(spacers), 그래픽 버튼, (사용자와의 상호 작용에 의해 또는 자동으로 연주되는) 사운드, 독립적인 오디오 파일, 비디오의 오디오 트랙, 비디오. [중요도 1]

예를 들면 HTML에서 :

• IMG, INPUT, APPLET 요소에는 "alt"를 사용하거나, OBJECT, APPLET 요소 내에 대체 텍스트를 제공한다.
• 복잡한 콘텐츠(예를 들면 차트)의 경우 "alt"를 통해 제공한 텍스트가 대체 텍스트 역할을 충분히 하지 못 하므로, 부가적인 설명을 해 주어야 하는데, IMG나 FRAME의 경우 "longdesc"에 자세한 설명을 달아 주고, OBJECT는 그 내부에 추가적인 설명을 제공하거나 또는 설명 링크를 제공한다.
• 이미지 맵의 경우, AREA에 "alt" 속성을 넣어주거나, MAP에 A 요소를 사용해서 콘텐츠를 넣어 주도록 한다.

관련 체크포인트 : 체크포인트 9.1, 체크포인트 13.10.

지침 1.1과 관련된 기술/기법

1.2 서버측 이미지 맵에는 각 활성 영역마다 중복적인 텍스트 링크를 넣어 준다. [중요도 1]

지침 1.5와 지침 9.1도 참조하라.

체크포인트 1.2와 관련된 기술/기법

1.3 시각적인 트랙에 대응하는 텍스트를 자동으로 읽어 주는 웹 표시 장치가 널리 보급되기 전에는, 멀티미디어 프리젠테이션을 할 때에 시각적인 트랙의 중요한 정보에 대해서는 음성 설명을 제공해 주어야 한다. [중요도 1]

체크포인트 1.4에서처럼 음성 설명(auditory description)을 오디오 트랙과 동기 시켜야 한다. 시각적인 정보에 대응하는 텍스트에 관해서는 체크포인트 1.1을 참조하라.

체크포인트 1.3과 관련된 기술/기법

1.4 시간을 기반으로 한 멀티미디어(예를 들면 동영상이나 애니메이션)과 그에 상응하는 대체물(예를 들면 시각적인 트랙에 대한 캡션(텍스트 자막)이나 음성 설명)은 동기시켜야 한다.[중요도 1]

체크포인트 1.4와 관련된 기술/기법

1.5 클라이언트측 이미지 맵에 있는 링크에 대한 대체 텍스트를 찾아 표시해 주는 웹 표시 장치가 널리 보급되기 전에는 각 활성 영역에 대해 중복적인 텍스트 링크를 제공해야 한다. [중요도 3]

체크포인트 1.2와 체크포인트 9.1도 참조하라.

지침 1.5와 관련된 기술/기법

지침 2. 색깔만으로 정보를 구분하면 안 된다.

컬러가 아닌 흑백으로 보았을 때에도 텍스트와 그래픽을 이해할 수 있도록 해야 한다.

오직 색깔만 사용해서 어떤 정보를 전달한다면, 일부 색깔을 구별할 수 없는 사람들이나, 흑백 디스플레이를 사용하는 사람들, 또는 비시각적인 장치를 사용하는 사람들은 그 정보를 받아보지 못 할 것이다. 전경색과 배경색이 같은 계통의 색조로 너무 비슷하다면 흑백 디스플레이를 사용자나 색약 혹은 색맹이 있는 사람에게는 충분한 대비 효과를 주지 못 할 것이다.

체크포인트:

2.1 색깔과 함께 전달되는 모든 정보는 색깔이 없더라도 맥락이나 다른 마크업에 의해 구별 가능해야 한다. [중요도 1]

지침 2.1과 관련된 기술/기법

2.2 전경색과 배경색의 조합이 색맹이나 색약이 있는 사람에게, 또는 흑백 디스플레이를 통해 보는 사람들이 보았을 때에 충분한 대비를 갖도록 해야 한다. [이미지 색깔의 경우 중요도 2, 텍스트 색깔의 경우 중요도 3].

지침 2.2와 관련된 기술/기법

지침 3. 마크업과 스타일 시트를 사용하되 적법하게 사용한다.

문서를 만들 때에 적절한 구조적인 요소를 사용한다. 문서의 외형적 표현(presentation)에 관계되는 것은 표현 요소나 속성을 사용하기보다는 스타일 시트를 사용한다.

표준 사양을 따르지 않는 마크업의 오용은 접근성에 대한 저해 요인이다. 시각적인 표현 효과를 얻기 위해 (예를 들면 내용물의 자리 배치를 위해 표를 쓴다든지, 글꼴의 크기를 바꾸기 위해 H1, H2 등 헤더용 마크업을 쓰는 것처럼) 마크업을 잘못 사용하면, 특정한 소프트웨어를 사용하는 사용자들이 페이지의 구조를 파악하거나 항해하는 것이 어려워진다. 더구나 (예를 들어 HTML의 PRE 요소를 써서 표 안에 있는 데이타처럼 보이게 구성하는 것처럼) 구조적인 정보를 전달할 때 구조를 나타내는 마크업을 쓰지 않고 표현을 위한 마크업을 쓰면 다른 표시 장치에서 페이지를 제대로 나타내지 못 할 수 있다. 내용(content), 구조(structure), 표현(presentation)의 차이에 대한 설명을 참조하라.

콘텐츠 개발자들은 옛날 브라우저에서 원하는 형식으로 콘텐츠를 보여주는 방법을 그냥 사용하고 싶은 유혹에 빠진다. 개발자들은 이런 방법이 접근성 문제를 일으킨다는 것을 알아야 한다. 그리고 문서의 내용을 특정한 양식으로 표현하는 것이 일부 사용자가 그 문서에 접근조차 못 하게 하는 것을 정당화할 만큼 중요한 것인지 생각해 보아야 한다.

극단적인 다른 한편으로는, 콘텐츠 개발자들이 어떤 브라우저나 관련 기술이 그것을 제대로 처리하지 못 한다고 해서 적절한 마크업의 사용을 포기해서는 안 된다. 예를 들면, 몇몇 오래된 화면 음성 변환기(screen readers) 에서는 양옆으로 나열된 일련의 텍스트를 읽어내지 못 하지만, HTML에서 표에 적당한 정보(tabular information)를 표시하기 위해 TABLE 요소를 사용하는 것은 적절한 것이다. 체크포인트 10.3을 참조하라. TABLE 요소를 바르게 사용하고, 또 다른 표현 방법으로 쉽게 변환되도록 표를 설계하면 (지침 5를 참조하라.) 소프트웨어가 표를 이차원 격자가 아닌 다른 방법으로 나타낼 수 있다.

체크포인트:

3.1 적절한 마크업 언어가 있을 때에는 정보 전달을 위해 이미지를 쓰지 말고 마크업을 쓴다.[중요도 2]

예를 들면, 수학 공식을 나타내기 위해서는 MathML과 스타일 시트 를 써서 텍스트의 형식이나 자리 배치를 조절할 수 있다. 또, 텍스트를 나타내기 위해 이미지를 쓰지 말고, 대신에 텍스트와 스타일 시트를 사용한다. 지침 6과 지침 11을 참조하라.

체크포인트 3.1과 관련된 기술/기법

3.2 공식 문법에 맞도록 문서를 작성하라.[중요도 2]

예를 들면, 문서의 시작 부분에는 기존에 정의된 DTD(예를 들면, strict HTML 4.0 DTD)를 참조하도록 문서 형식(document type) 을 선언해 주어야 한다.

체크포인트 3.2와 관련된 기술/기법

3.3내용물의 자리 배치와 표현 방식을 조절하기 위해서는 스타일 시트를 사용하라.[중요도 2]

예를 들면, 글꼴 스타일을 조절하기 위해서는 HTML의 FONT 요소를 쓰는 대신에 CSS의 'font' 속성을 쓰도록 한다.

체크포인트 3.3과 관련된 기술/기법

3.4 마크업 언어의 속성값이나 스타일 시트의 속성값에는 절대 단위를 쓰지 말고 상대 단위를 사용한다. [중요도 2]

예를 들면, CSS에서 크기를 나타내기 위해 절대 단위인 'pt', 'cm' 등을 쓰지 말고 'em'이나 퍼센트와 같은 상대 단위를 쓴다. 만약 절대 단위를 쓸 때에는 콘텐츠가 사용 가능한 것인지 유효성 검사를 받도록 한다. 유효성 검사 부분을 참조하라.

체크포인트 3.4와 관련된 기술/기법

3.5 문서의 구조를 나타내기 위해 제목 요소(header elements)를 쓰되, 사양에 맞게 사용한다.[중요도 2]

예를 들면, HTML에서 H1의 하위 섹션임을 나타내기 위해 H2를 사용한다. 단순히 글꼴 효과를 위해 헤더를 사용하지는 말라.

체크포인트 3.5와 관련된 기술/기법

3.6 목록(list)과 목록 아이템을 적절히 사용한다. [Priority 2]

예를 들면, HTML에서 OL, UL, DL 리스트를 적절히 사용한다.

체크포인트 3.6과 관련된 기술/기법

3.7 인용 마크업을 사용한다. 들여쓰기와 같은 시각적 형식을 조절하기 위해 인용 마크업을 사용하지 말라.[중요도 2]

예를 들면, HTML에서 짧은 인용에는 Q를, 긴 인용에는 BLOCKQUOTE 요소(element)를 사용한다.

체크포인트 3.7과 관련된 기술/기법

지침 4. 내용에 쓰인 언어(자연어)가 무엇인지 명시한다.

외국어나 약자는 마크업으로 (다른 부분과) 구분 지어서 적절한 발음이나 해석이 가능하도록 한다.

콘텐츠 개발자들이 마크업을 사용하여 언어를 바꾸면, 음성 합성 장치와 점자 표시 장치도 자동으로 새로운 언어 모드로 전환해서 다국어 사용자에게 접근성을 높이도록 되어있다. 콘텐츠 개발자들은 적절한 마크업이나 HTTP 헤더를 통해 주된 언어(자연어)를 명시해 주어야 한다. 콘텐츠 개발자들은 또한 약자에 대한 풀어 쓴 본디말을 제공해야 한다.

언어(자연어)를 마크업으로 명시해 주면 ( 역자 주: 예를 들어 음성 합성 장치나 점자 표시 장치 ) 단지 보조적인 기술에 도움을 줄 뿐만 아니라 검색 엔진이 단어 검색에서 특정 언어로 쓰인 문서를 가려낼 수 있게 한다. 또한 언어(자연어)로 마크업을 하는 것은 학습 장애, 인지 장애, 청각 장애가 있는 사람을 포함해 모든 사람에게 웹의 가독성을 높여준다. (언어를 명시해 주면 같은 표기 체계를 쓰거나 일부 표기 체계를 공유하지만 글꼴이나 합자(ligature)에 대한 선호가 다른 복수의 언어- 예를 들어, 일본어와 중국어, 러시아어와 알바니아어, 영어와 터키어 -로 쓰인 문서를 표시할 때 언어에 따라 다른 글꼴, 합자 규칙, 줄바꿈 규칙 등을 적용하는 것이 가능하다.)

약자에 대한 풀이를 생략하거나 언어(자연어) 전환을 명시하지 않으면, 읽는 기계나 점자 생성 기계에 의존하는 이가 이해하지 못 할 수도 있다.

체크포인트:

4.1 문서의 텍스트나 대체 텍스트(text wequivalent)(예를 들면, 오디오나 비디오 내용물에 붙인 캡션)의 언어(자연어)가 바뀌면 명확한 방법으로 표시해 주어야 한다.[중요도 1]

예를 들면, HTML에서는 "lang" 속성을 사용한다. XML에서는, "xml:lang"을 사용하면 된다.

체크포인트 4.1과 관련된 기술/기법

4.2 약어(abbreviation)나 두문자어(acronym)가 문서에서 처음 나올 때에는 본디말을 명시해 주어야 한다.[중요도 3]

예를 들면, HTML에서는 ABBR과 ACRONYM 요소에 대해서 "title" 속성을 쓴다. 문서의 본문(main body)에서 약어나 두문자어를 풀어 써 주는 것도 문서의 사용자 편의성(usability)을 높여 주는 방법이다.

체크포인트 4.2와 관련된 기술/기법

4.3 문서의 주 사용 언어를 지정해 준다. [중요도 3]

예를 들면, HTML에서는 HTML 요소에 대해 "lang"이라는 속성을 정의해 준다. XML에서는 "xml:lang"을 사용한다. 서버 운영자는 서버의 설정을 변경하여 HTTP의 콘텐츠 교섭 기능(contents negotiation mechanism) ([RFC2068], section 14.13)을 작동하도록 하여야만 클라이언트가 자동으로 원하는 언어로 쓰인 문서를 읽어들일 수 있다.

체크포인트 4.3과 관련된 기술/기법

지침 5. 표는 표를 지원하지 않는 환경에서도 유연하게 변경될 수 있도록 만든다.

표를 작성할 때에는 접근 가능한 브라우저나 다른 웹 표시 장치에 의해 변환될 수 있는 필요한 마크업을 반드시 넣도록 한다.

표는 진짜 표 형식으로 나타내는 것이 적절한 정보("데이터 테이블")를 위해서 쓰여야 한다. 콘텐츠 개발자들은 표를 내용물의 자리 배치를 위해 쓰는 것("레이아웃 테이블")을 피해야 한다. 또한 아무렇게나 표를 쓰는 것은 화면 음성 변환기를 이용해 웹을 보는 사용자들에게 특수한 문제를 일으킨다. (체크포인트 10.3을 참조하라.)

어떤 웹 표시 장치에서는 표 내에서 칸 사이를 탐색할 수 있고, 헤더와 다른 칸에 대한 정보에 접근할 수 있게 한다. 마크업을 제대로 사용하지 않으면, 이런 표들은 웹 표시 장치에 적절한 정보를 제공해 주지 못 할 것이다. (지침 3도 참조하라.)

다음과 같은 체크포인트를 지킴으로써 음성을 통해 표에 접근하는 사용자(예를 들면, 음성 합성 장치나 차량용 컴퓨터)나 한 번에 페이지의 일부만 볼 수 있는 사용자(예를 들면, 음성 출력 장치나 점자 표시 장치에 의존하는 시각 장애인이나 약시인 사람 또는 작은 화면을 사용하는 사용자 등)에게 직접적으로 이득을 줄 것이다.

체크포인트:

5.1 데이터가 들어있는 표에는 제목행과 제목열(통칭하여 header)을 명시한다. [중요도 1]

예를 들어 HTML에서는, 데이터가 담긴 칸을 나타내기 위해 TD를, 제목행이나 제목열에는 TH를 사용한다.

체크포인트 5.1과 관련된 기술/기법

5.2 두 개 이상의 논리적인 제목행이나 제목열을 갖는 데이터가 들어있는 표에서는 데이터 칸끼리 또는 제목 칸끼리 관련 짓는 마크업을 사용한다. [중요도 1]

예를 들면, HTML에서 행을 모둠 지으려면 THEAD, TFOOT, TBODY와 같은 마크업을 사용하고, 열을 모둠 지으려면 COL, COLGROUP을 사용하며, 데이터 사이에 더 복잡한 관계를 기술하려면 "axis", "scope", "headers"와 같은 속성을 사용한다.

체크포인트 5.2와 관련된 기술/기법

5.3 표 내용을 펼쳐서 순서대로 나열했을 때에 의미가 없는 경우에 단지 내용물의 자리 배치만을 위해 표를 사용하지는 말아라. 내용물을 배치하려는 목적으로 표를 쓴다면, 대안적인 대체 정보(표를 풀어서 순서대로 나열한 것(linearized version) 등)를 제공한다. [중요도 2]

Note. 만약 웹 표시 장치가 스타일 시트를 쓴 위치 지정이 가능하다면, 내용물의 자리 배치를 위해 표를 사용해서는 안 된다. 체크포인트 3.3도 참조하라..

체크포인트 5.3과 관련된 기술/기법

5.4 만약 자리 배치를 위해 표를 사용한다면, 시각적인 형식을 맞추기 위해 구조 표시용 마크업을 사용하지 말아라. [중요도 2]

예를 들면, HTML에서 (테이블의 헤더가 아닌) 내용을 가운데 정렬로 맞추고 굵게 표시하기 위해 TH 요소를 사용하지 말아라.

체크포인트 5.4와 관련된 기술/기법

5.5 표의 요약 정보를 제공하라. [중요도 3]

예를 들면, HTML에서는 TABLE 요소에 "summary" 속성을 사용한다.

체크포인트 5.5와 관련된 기술/기법

5.6 표의 제목줄(헤더 부분)에 들어가는 내용에는 약자를 제공하라. (역자 주: 제목줄에 약자를 씀으로써 화면 음성 변환기가 매번 제목을 읽을 때마다 긴 제목을 반복해서 읽는 것을 피할 수 있다.) [중요도 3]

예를 들어 HTML에서는, TH 요소에 "abbr" 속성을 사용한다.

체크포인트 5.6과 관련된 기술/기법

체크포인트 10.3도 참조하라..

지침 6. 새로운 기술을 사용한 페이지는 그 기술을 지원하지 않는 환경에서도 내용을 보전하면서 표시될 수 있도록 한다.

새로운 기술을 지원하지 않는 표시 장치를 쓰거나 또는 그런 기능을 꺼 놓았다고 하더라도 페이지에 접근 가능하도록 해야 한다.

콘텐츠 개발자가 현존 기술의 문제점을 해결하기 위해 새로운 기술을 사용하는 것은 장려할 일이지만, 구버전의 브라우저나 새로운 기능을 꺼놓은 사용자들에게도 여전히 그 페이지가 보이도록 하는 방법을 알아야 한다.

체크포인트:

6.1 스타일 시트가 없더라도 읽을 수 있게 문서를 구조화한다. 예를 들면, HTML 문서가 스타일 시트가 없이 표시되더라도 반드시 그 문서를 읽을 수 있어야 한다. [중요도 1]

내용을 논리적으로 구조화한다면, 스타일 시트가 작동하지 않거나 지원되지 않을 경우에도 문서의 내용이 의미있는 순서대로 표시가 될 것이다.

체크포인트 6.1과 관련된 기술/기법

6.2 동적인 콘텐츠가 변할 경우 대응하는 대체 텍스트(equivalents)도 좇아서 변하도록 한다. [중요도 1]

체크포인트 6.2와 관련된 기술/기법

6.3 스크립트나 애플릿, 또는 다른 프로그램 객체를 사용하지 않거나 지원하지 않는 경우에도 페이지의 내용을 이해할 수 있어야 한다. 그것이 불가능하다면, 대안적으로 접근 가능한 페이지에 그들을 대체할만한 정보를 제공하라. [중요도 1]

예를 들면, 스크립트 기능이 꺼져 있거나 지원되지 않을 경우에도 스크립트를 활성화하는 링크가 작동하도록 해야 한다. (예를 들어, 링크의 목적지 로 "javascript:"를 쓰지 말라. 역자 주 : "href" 속성의 값으로 "javascript:"를 쓰는 것은 접근성 지침 위반일 뿐 아니라 HTML 표준 위반이기도 하다. ) 만약 스크립트 없이 페이지를 사용하는 것이 불가능하다면, NOSCRIPT라는 요소를 사용하여 대체 텍스트를 제공하거나, 클라이언트측 스크립트 대신에 서버측 스크립트를 사용하라. 또는 체크포인트 11.4에서와 같이 대안적으로 접근 가능한 페이지를 제공하라. 지침 1도 참조하라.

체크포인트 6.3과 관련된 기술/기법

6.4 스크립트나 애플릿을 쓸 때에는 이벤트 처리 루틴(event handler)이 입력 장치에 독립적이어야 한다. [중요도 2]

장치 독립성의 정의를 참조하라.

체크포인트 6.4와 관련된 기술/기법

6.5 동적인 콘텐츠가 접근 가능한지 확인하고, 그렇지 않으면, 대안적인 제시를 하거나 대안적인 페이지를 제공한다. [중요도 2]

예를 들면, HTML에서는 모든 프레임셋(frameset) 끝에 NOFRAMES를 사용한다. 일부 응용 프로그램에게는 서버측 스크립트가 클라이언트측 스크립트보다 더 접근성이 높은 경우도 있다.

체크포인트 6.5와 관련된 기술/기법

체크포인트 11.4도 참조하라..

지침 7. 시간에 따라 변하는 콘텐츠는 사용자가 제어할 수 있게 한다.

객체나 페이지가 움직이거나, 깜박이거나, 스크롤되거나, 자동으로 갱신되는 경우에는 사용자가 중간에 이를 잠시 멈추게 하거나 완전히 중단할 수 있도록 해야 한다.

인지적인 장애나 시각적인 장애가 있는 사람들 중 일부는 빠르게 움직이는 텍스트를 일부 또는 전혀 읽지 못 한다. 인지적인 장애가 있는 사람들은 움직임 때문에 페이지 내에서 다른 내용을 보지 못 할 수도 있다. 화면 음성 변환기는 움직이는 텍스트를 읽을 수 없다. 신체적 장애가 있는 사람들은 움직이는 객체에 반응하기 위해 충분히 빠르고 정확하게 움직이지 못 한다.

Note. 다음의 모든 체크포인트들은 웹 표시 장치가 적절한 제어 기능을 지원할 때까지 콘텐츠 개발자들이 책임져야 할 사항에 대한 것이다.

체크포인트:

7.1 웹 표시 장치가 사용자들에게 깜박임을 조절할 수 있게 하기 전까지는 화면에 깜박임을 넣지 않는다. [중요도 1]

Note. 광과민성 간질이 있는 사람들은 (방전) 섬광 조명 장치 등에 의한 명암의 급격한 변화는 물론이고, 초당 4회 ~ 59회 사이의 깜박임(초당 20회 부근의 깜박임에 가장 민감)에 의해 발작을 일으킬 수 있다.

체크포인트 7.1과 관련된 기술/기법

7.2 웹 표시 장치가 사용자들에게 깜박임을 조절할 수 있게 하기 전까지는 콘텐츠가 깜박이지(예를 들어, 주기적으로 내용을 나타냈다 사라졌다 하는 식으로 표현하는 것) 않도록 한다. [중요도 2]

체크포인트 7.2와 관련된 기술/기법

7.3 웹 표시 장치가 사용자들에게 움직임을 조절할 수 있게 하기 전까지는 페이지에 움직임을 넣지 않는다. [중요도 2]

페이지 내에 움직이는 콘텐츠를 넣을 경우, 스크립트나 애플릿 내에 사용자가 움직임이나 변화를 중지시킬 수 있는 방법을 제공한다. 움직임을 만들 때에 스크립트와 함께 스타일 시트를 사용하면 움직임 효과를 사용자가 쉽게 조절할 수 있다. 지침 8도 참조하라.

체크포인트 7.3과 관련된 기술/기법

7.4 웹 표시 장치가 (자동) 갱신을 멈추거나 무시하는 기능을 제공하기 전에는 정기적으로 자동 갱신되는 페이지를 만들지 않는다. [중요도 2]

예를 들면, 웹 표시 장치가 그 기능을 무시할 수 있도록 허용할 때까지는 HTML에서 "HTTP-EQUIV=refresh"로 페이지를 자동 갱신하지 말라.

체크포인트 7.4와 관련된 기술/기법

7.5 웹 표시 장치가 자동 페이지 전환(auto-redirect)을 멈추거나 무시하는 기능을 제공하기 전에는, 자동 전환용 마크업을 사용하지 않는다. 대신에 자동 전환할 수 있도록 서버를 설정한다. [중요도 2]

체크포인트 7.5와 관련된 기술/기법

Note. BLINK와 MARQUEE 요소는 W3C HTML 사양에 정의된 것들이 아니므로 사용해서는 안 된다. 지침 11도 참조하라.

지침 8. 별도로 포함된 사용자 인터페이스에 대해서도 직접적인 접근성을 보장한다.

사용자 인터페이스가 접근 가능한 디자인 원칙 (특정 기능에 대한 장치 독립적인 접근, 키보드 사용 가능성, 음성 변환 가능성 등)을 따르도록 한다.

포함된(임베드된) 객체가 "자체의 인터페이스"를 가지고 있을 때에는 -- 마치 브라우저 자체가 인터페이스를 가진 것처럼 -- 그 인터페이스가 접근 가능해야 한다. 만약 임베드된 객체의 인터페이스를 접근 가능하게 만들 수 없다면, 접근성 있는 대체물을 제공해야 한다.

Note. 접근 가능한 인터페이스에 대한 정보는 웹 표시 장치 접근성 지침([WAI-USERAGENT])과 저작 도구 접근성 지침([WAI-AUTOOL])을 참조한다.

체크포인트:

8.1 스크립트나 애플릿과 같이 프로그램을 사용하는 요소는 (장애인을 위한) 보조 기술을 이용해서 직접적으로 접근 가능하거나 또는 보조 기술과 호환성을 유지해야 한다. [기능이 중요하고 다른 곳에서 따로 나타나지 않을 경우에는 중요도 1, 그렇지 않으면 중요도 2.]

지침 6도 참조하라..

체크포인트 8.1과 관련된 기술/기법

지침 9. 장치 독립적인 설계를 한다.

다양한 입력 장치를 통해 페이지 내 요소를 활성화할 수 있는 기능을 사용한다.

장치 독립적인 접근이란 사용자가 웹 표시 장치 또는 문서와 원하는 입력(또는 출력) 장치 -- 마우스, 키보드, 음성, 머리 움직임 입력 장치(head wand), 기타 등등 -- 를 사용해서 상호작용이 가능한 것을 말한다. 예를 들어, 양식(form)에서 항목을 선택하거나 제출하거나 하는 등의 작업을 마우스나 다른 지시(포인팅) 장치로만 할 수 있다면, 시력이 없는 사람이나 음성 입력 장치를 사용하는 사람, 키보드만 쓰는 사람, 또는 지시 장치가 아닌 다른 입력 장치를 쓰는 사람들은 양식을 사용할 수 없을 것이다.

Note. 이미지 맵이나 그림을 링크로 쓸 때에는 대체 텍스트 링크를 제공해서 지시 장치가 없는 경우에도 상호 작용이 가능하도록 해야 한다. 지침 1도 참조하라.

일반적으로 키보드 조작이 가능한 페이지는 음성 입력 장치나 명령행 인터페이스를 통해 접근 가능하다.

체크포인트:

9.1 기하학적인 도형으로 정의가 안 되는 영역이 있는 경우를 제외하고는 서버측 이미지 맵(server-side image maps) 대신에 반드시 클라이언트측 이미지 맵(cliend-side image maps)을 사용한다. [중요도 1]

체크포인트 1.1, 체크포인트 1.2, 체크포인트 1.5도 참조하라.

체크포인트 9.1과 관련된 기술/기법

9.2 자체 인터페이스를 가진 요소의 경우, 장치 독립적인 방법으로 작동할 수 있도록 한다. [중요도 2]

장치 독립성에 대한 정의를 참조하라.

지침 8도 참조하라.

체크포인트 9.2와 관련된 기술/기법

9.3 스크립트를 사용할 때에는 특정 장치에 종속적인 이벤트 처리 루틴(event handler)보다는 논리적인 이벤트 처리 루틴를 사용한다. [중요도 2]

체크포인트 9.3과 관련된 기술/기법

9.4 링크, 폼 컨트롤, 객체들을 따라 논리적인 탭 순서를 만들어 놓는다. [중요도 3]

예를 들면, HTML에서는 "tabindex"라는 속성을 사용하거나, 페이지를 논리적으로 디자인하여 탭 순서를 정의한다.

체크포인트 9.4와 관련된 기술/기법

9.5 중요한 링크 (클라이언트측 이미지 맵에 들어있는 링크 포함), 폼 컨트롤, 폼 컨트롤 묶음에는 키보드로 접근 가능한 단축키를 제공한다. [중요도 3]

예를 들면, HTML에서는 "accesskey" 속성을 통해 키보드 단축키를 정의한다.

체크포인트 9.5와 관련된 기술/기법

지침 10. 잠정적인 접근성 보장 기법을 사용한다.

잠정적인 접근성 보장 기법을 써서 (장애인을 위한) 보조 장치나 오래된 브라우저에서 제대로 작동하게 한다.

예를 들면, 옛날 브라우저에서는 빈 편집 상자를 채워 넣을 수 없다. 오래된 화면 음성 변환기에서는 연속적으로 붙어 있는 링크들을 하나로 읽어 버린다. 그래서 이런 요소들은 접근이 어렵거나 불가능하다. 또한, 현재 창이 아닌 다른 창을 활성화하거나 새로운 팝업창을 띄우는 것은 이를 알 수 없는 시각 장애자를 헛갈리게 한다.

Note. 웹 표시 장치가 사용자들에게, 또는 장애인을 위한 보조 기술이 이런 것을 지원하기 전까지는 다음 체크포인트들을 고려해야 한다. 이들은 "잠정적"이다. 즉, Web Content Guidelines Working Group에서는 이 문서를 출판하는 시점에서는 이들이 유효하고 필요하다고 간주한다. 그러나, 미래에 웹 기술이 이들을 수용한 후에는 더 이상 필요하지 않을 것이다.

체크포인트:

10.1 웹 표시 장치가 사용자에게 웹 표시 장치가 새로운 자식 창(팝업 창)이 열리는 것을 막을 수 있는 기능을 제공하기 전까지는 팝업 창이나 새로운 창이 생기게 하지 말고, 사용자에게 알리지 않은 채로 현재 창이 아닌 창을 활성화 해서도 안 된다. [중요도 2]

예를 들면, HTML에서는 새로운 창을 여는(역자 주: 새로운 창을 target으로 하는) 프레임을 사용하지 않는다.

체크포인트 10.1과 관련된 기술/기법

10.2 웹 표시 장치가 레이블(label)과 폼(form) 컨트롤 사이의 명시적으로 지정된 연관을 명료한 방법으로 인식 가능하게 해 줄 때까지는 (왜냐하면 모든 폼 컨트롤은 레이블과 정확히 짝지어진 것이 아니므로), 레이블을 적절한 (폼 컨트롤과의 연관에 혼동의 여지가 없는) 위치에 놓아야 한다. [중요도 2]

(하나 이상의 컨트롤/레이블을 한 줄에 놓을 때에는) 레이블이 폼이 나오기 바로 직전에 같은 줄에 놓여야 하며, (한 줄에 하나의 레이블이나 폼만을 배열할 때에는) 레이블이 폼 바로 윗 줄에 나와야 한다. 체크포인트 12.4도 참조하라..

체크포인트 10.2와 관련된 기술/기법

10.3 웹 표시 장치(장애인을 위한 보조 기술을 포함하여)가 나란히 놓인 두 단 이상의 텍스트를 웹 페이지 저자가 의도한 순서대로 표시/해석(render) 하기 전까지는 텍스트의 다단 배치를 위해 쓴 모든 표에 대해서 (현재 페이지나 별도의 페이지에) 순차적인 대체 텍스트를 제공한다. [중요도 3]

Note. 선형화된 표(linearized table)에 대한 정의를 참조하기 바란다. 이 체크포인트는 (일부 화면 음성 변환기처럼) 다단 텍스트를 처리하지 못 하는 웹 표시 장치를 사용하는 사람들에게 도움을 준다. 그렇다고 이 체크포인트가 개발자들에게 표 형식으로 나타내는 것이 적절한 정보에 대해 표를 사용하지 말라고 하는 것은 아니다.

체크포인트 10.3과 관련된 기술/기법

10.4 웹 표시 장치가 사용자에게 빈 컨트롤을 정확하게 처리할 수 있게 하기 전까지는 편집 상자(edit boxes)와 텍스트 영역(text area)에 기본값이 되는 문자를 넣어준다. [중요도 3]

예를 들면, HTML에서는 TEXTAREA와 INPUT에 대해서 이렇게 한다.

체크포인트 10.4와 관련된 기술/기법

10.5 웹 표시 장치가 사용자에게 (장애인을 위한 보조 기술들을 포함해) 인접한 링크를 명확히 구분할 수 있게 해 주기 전까지는, 바로 인접한 링크들 사이에는 링크가 걸리지 않고 인쇄 가능한 (양쪽 공백으로 둘러싸인) 문자를 삽입해 주어야 한다. [중요도 3]

체크포인트 10.5와 관련된 기술/기법

지침 11. W3C의 기술과 지침을 준수한다.

W3C의 (명세에 따른) 기술과 접근성 향상 지침을 사용한다. W3C의 기술을 사용할 수 없을 때, 또는 그렇게 했을 때에 구 기술과 호환성이 문제가 되는 상황에서는 접근 가능한 다른 버전의 콘텐츠를 (따로) 제공한다.

이 지침에서는 다음과 같은 이유 때문에 W3C의 기술(예를 들면, HTML, CSS 등)을 사용하도록 권장한다.

• W3C 기술들은 "자체 내장된(built-in) " 접근성 관련 특징들을 갖추고 있다.
• W3C의 문서들(specifications)은 개발 단계에서부터 접근성을 확보하기 위해 초기 검토를 거친다.
• W3C의 문서들은 공개적으로 업계의 합의 과정을 거쳐서 개발된다.

많은 비 W3C 형식의 문서(예를 들면 PDF, Shockwave 등)를 보기 위해서는 별도의 플러그인이나 독립적인 응용 프로그램을 필요로 한다. 종종 이런 형식 문서들은 (장애인을 위한 보조 기술을 포함한) 표준 웹 표시 장치에서 보거나 탐색할 수 없다. 비 W3C, 비표준 기술(특정 업체에서 만든 요소, 속성, 값, 확장 기술 등)을 사용하지 않음으로써 더욱 다양한 하드웨어와 소프트웨어를 쓰는 더 많은 사람들에게 웹 페이지를 접근 가능하게 할 수 있다. 접근성이 낮은 기술(특정 업체의 기술이건 아니건) 을 반드시 써야 한다면, 동일한 역할을 하는 접근 가능한 페이지를 반드시 제공해야 한다.

W3C의 기술을 쓸 때에도, 접근성 지침에 맞도록 사용해야 한다. 새로운 기술을 사용할 때에는 그것이 새 기술을 지원하지 않는 환경에서도 정보를 보전하면서 잘 표시될 수 있도록 해야 한다. (지침 6도 참조하라.)

Note. (PDF나 포스트스크립트 문서, RTF 문서를 HTML, XML과 같은) W3C의 마크업 언어로 변환한다고 해서 그것이 언제나 접근성이 높은 문서가 되는 것은 아니다. 따라서 변환 과정이 끝난 후에는 각 페이지의 접근성과 사용자 편의성(usability)에 대한 검사를 해보도록 한다. (유효성 검사 절을 참조하라. 만약 페이지가 쉽게 변환하기에 적당하지 않다면, 원본 문서의 표현 방식이 적절하게 변환될 수 있을 때까지 페이지를 계속 수정해 나가거나, HTML이나 일반 텍스트(plain text) 버전을 따로 제공한다.

체크포인트:

11.1 하고자 하는 일에 적합한 W3C 기술이 있다면 되도록이면 최신판을 찾아 채택한다. [중요도 2]

W3C의 최신 문서들을 어디에서 찾을 수 있는지에 관한 정보를 얻으려면 참고 자료 목록을 참조하고, 웹 표시 장치가 W3C의 기술을 어떤 식으로 지원하는지에 대한 정보는 [WAI-UA-SUPPORT]를 참조하라.

체크포인트 11.1과 관련된 기술/기법

11.2 낡은 W3C 기술(deprecated features of W3C technologies)을 사용하지 말라. [중요도 2]

예를 들면, HTML에서 낡은(deprecated) FONT 요소를 쓰지 말라. 대신 스타일 시트를 사용한다. (예를 들면, CSS에서 'font' 속성을 지정하면 된다.)

체크포인트 11.2와 관련된 기술/기법

11.3 사용자들이 자신의 선호에 따라 문서를 받아볼 수 있도록 예를 들면, 언어, 콘텐츠 유형 등과 같은 정보를 제공한다. [중요도 3]

Note. HTTP가 제공하는 콘텐츠 교섭 기능을 사용하라.

체크포인트 11.3과 관련된 기술/기법

11.4 만약 모든 노력을 해보았어도, 접근성이 높은 페이지를 만들 수 없다면, W3C의 기술을 사용하고, 접근 가능하며, 원래의 페이지와 동일한(equivalent) 정보(또는 기능)를 담고 있으며, 원래 페이지만큼 자주 개정되는 별도의 페이지를 제공하라. [중요도 1]

체크포인트 11.4와 관련된 기술/기법

Note. 콘텐츠 개발자는 다른 방법이 실패했을 때에만 별도의 페이지를 만드는 것이 좋다. 왜냐하면 별도로 존재하는 대안 페이지는 일반적으로 "본" 페이지보다 덜 자주 개정되기 때문이다. 원래의 페이지에 있는 정보를 볼 수 없다는 점에서 "본" 페이지에 비해 낡은 내용을 담은 페이지는 접근성이 낮은 페이지만큼이나 사용자에게 좌절을 주게 마련이다. 자동으로 생성된 대안 페이지는 아마도 좀 더 자주 개정할 수 있을 것이다. 그러나 콘텐츠 개발자는 여전히 자동 생성된 페이지가 의미가 통하는지, 그리고 본 페이지와 대안 페이지의 링크를 통해 사이트를 제대로 탐색할 수 있는지 주의해서 확인해 보아야 한다. 별도의 대안 페이지를 만들기 전에 원래 페이지의 디자인에 대해 다시 생각해보라. 원래 페이지를 접근 가능하도록 하면 아마 모든 사용자에게 득이 될 것이다.

지침 12. 맥락과 방향 정보를 제공한다.

맥락과 방향 정보를 제공함으로써 사용자들이 복잡한 페이지나 요소들을 이해할 수 있게 된다.

요소들을 모둠 짓고 요소 사이의 관계에 대한 맥락 정보를 제공하는 것은 모든 사용자들에게 유용하다. 페이지 내의 각 부분이 복잡하게 얽혀 있으면 인지적인 장애가 있거나 시각적인 장애가 있는 사람들은 페이지 해석에 어려움을 겪는다.

체크포인트:

12.1 프레임을 구분하고 프레임 사이의 탐색을 쉽게 하기 위해서 모든 프레임에는 제목(이름)을 붙여야 한다. [중요도 1]

예를 들면, HTML에서 FRAME 요소에는 " title" 속성을 사용하라.

체크포인트 12.1과 관련된 기술/기법

12.2 프레임 이름만으로 명백하지 않을 때에는 프레임의 목적을 설명하고, 프레임들이 서로 어떤 관계가 있는지 설명을 붙인다. [중요도 2]

예를 들면, HTML에서는 "longdesc"을 사용하거나, 별도의 설명 링크(description link)를 추가한다.

체크포인트 12.2와 관련된 기술/기법

12.3 큰 덩어리로 이루어진 정보는 자연스럽게 그리고 적절하게, 더 쉽게 다룰 수 있는 몇 개의 모둠으로 나눈다. [중요도 2]

예를 들어, HTML에서는 SELECT 안에 있는 OPTION 요소들을 모둠 짓기 위해 OPTGROUP을 사용한다. 폼 컨트롤들을 모둠 짓기 위해서는 FIELDSET과 LEGEND를 사용한다. 적절하다면 다단계 목록(nested lists)을 사용한다. (역자 주 : 목록을 나열할 때 그냥 텍스트를 직접 표현하지 말고 UL, OL, DL 등을 적절히 사용하라는 뜻.) 문서를 구조화하기 위해 머리말(headings)을 사용한다. (역자 주 : 글자를 크게 하기 위해서가 아니고 제목을 표현하기 위해서 H1, H2, H3 등의 요소를 사용하라는 뜻). 지침 3도 참조하라.

체크포인트 12.3과 관련된 기술/기법

12.4 컨트롤과 그 컨트롤의 레이블을 명시적으로 짝지어야 한다. [중요도 2] (컨트롤과 그 레이블을 바로 옆에 둔다든지 하는 식으로는 둘 사이에 암묵적 연관만을 부여한다.)

예를 들면, HTML에서는 LABEL 요소와 "for" 속성을 사용한다.

체크포인트 12.4와 관련된 기술/기법

지침 13. 명확한 탐색 구조를 가져야 한다.

사용자가 사이트 내에서 찾고자 하는 것을 실제 찾을 확률을 높이기 위해 명확하고 일관성있는 탐색 방법 -- 방향 정보, 탐색 막대, 사이트 지도 등 -- 을 제공해야 한다.

명확하고 일관성있는 탐색 방법(navigation mechanisms)은 인지적인 장애인, 맹인 뿐 아니라 모든 사용자에게 편리함을 준다.

체크포인트:

13.1 각 링크의 목표 위치(target)를 명확히 한다. [중요도 2]

링크 텍스트(link text)는 -- 단독으로 또는 여러 링크들 가운데 일부로 -- 맥락을 떼어놓고 읽더라도 충분히 의미 있어야 한다. 링크 텍스트는 또한 간결해야 한다.

예를 들면, HTML에서 "여기를 누르시오."라고 쓰지 말고 "버전 4.3에 대한 정보"라고 쓰도록 한다. 링크 텍스트를 명확하게 함과 아울러 링크에 이름을 붙여서 링크의 목표 위치(에 담긴 내용)를 더 명확하게 해 줄 수 있다. (예를 들면, HTML에서는 "title"이라는 속성을 사용한다.)

체크포인트 13.1과 관련된 기술/기법

13.2 각 페이지와 사이트에는 메타데이터(metadata)를 제공함으로써 의미있는/의미론적(semantic) 정보를 부여한다. [중요도 2]

예를 들면, 문서의 저자, 콘텐츠의 유형 등을 나타내기 위해 RDF ([RDF])를 사용하라.

Note. 일부 HTML 웹 표시 장치(user agents)에서는 문서의 관계 구조를 나타내는 HTML LINK 요소의 "rel"이나 "rev" 속성을 파악하여 탐색 도구를 생생해 주기도 한다. (예를 들면, rel="next", rel="previous", rel="index" 등.) (역자 주 : 예를 들면, 모질라, 넷스케이프 커뮤니케이터, 오페라 등의 브라우저에서 탐색 도구 모음(아이콘, 버튼)이 자동으로 생성된다.) 체크포인트 13.5도 참조하라.

체크포인트 13.2와 관련된 기술/기법

13.3 사이트의 전체적인 구성에 관한 정보(예를 들면, 사이트 지도나 목차 같은 것)를 제공하라. [중요도 2]

사이트의 전체적 구성을 설명할 때에는 접근성 관련된 기능이 어떤 것이 있는지 요약해서 설명해 준다.

체크포인트 13.3과 관련된 기술/기법

13.4 일관적인 탐색 방법을 사용한다. [중요도 2]

체크포인트 13.4와 관련된 기술/기법

13.5 사이트 탐색 기능의 존재를 잘 드러내고 이에 보다 쉽게 접근할 수 있도록 탐색 막대(navigation bars)를 제공하라. [중요도 3]

체크포인트 13.5와 관련된 기술/기법

13.6 관련된 링크들은 한데 묶어 두고, 웹 표시 장치가 그 모둠을 식별할 수 있도록 표시한다. 그리고, 웹 표시 장치가 사용자들에게 그런 기능을 제공하기 전까지는 모둠을 건너 뛸 수 있는 방법도 제시해 주어야 한다. [중요도 3]

체크포인트 13.6과 관련된 기술/기법

13.7 검색 기능을 제공할 때에는 사용자의 수준과 선호하는 방식에 따라 다른 형태의 검색을 할 수 있도록 한다. [중요도 3]

체크포인트 13.7과 관련된 기술/기법

13.8 장, 절 등의 제목(headings), 문단, 목록 등의 선두에는 이들을 식별할 수 있는 고유한 정보를 넣는다. [중요도 3]

Note. 이것은 일반적으로 "앞에서 제시(front-loading)" 라고 하는데, 음성 합성기처럼 순차적으로 정보에 접근하는 기기를 사용하는 사람들에게 특히 도움이 된다.

체크포인트 13.8과 관련된 기술/기법

13.9 문서 묶음(예를 들어, 여러 페이지로 이뤄진 문서)에 대한 정보를 제공한다. [중요도 3]

예를 들면, HTML에서는 LINK 요소에 "rel", "rev" 속성을 붙여서 관련된 문서 묶음을 지정할 수 있다. 여러 페이지로 구성된 문서 묶음을 만드는 다른 방법은 zip, tar와 gzip, stuffit 등으로 관련 문서를 모아 압축하는 것이다.

Note. 오프라인 (인터넷에 연결하지 않은 상태) 처리에 의한 성능 향상은 브라우징을 천천히 할 수 밖에 없는 장애인의 인터넷 접속 비용을 낮추어 준다. (역자 주: zip, tar/gzip, stuffit 등으로 만든 문서 묶음을 제공해 준다면 이 문서 묶음을 내려 받은 후에 인터넷 접속을 끊은 채로 읽을 수 있어서 인터넷 접속 비용이 높은 곳에 있는 장애인이나 비장애인 모두에게 비용 절감 효과가 있다. "rel"이나 "rev"로 연관 지어진 문서를 한꺼번에 내려 받는 기능을 제공하는 웹 표시 장치도 마찬가지 이유로 유용하다.)

체크포인트 13.9와 관련된 기술/기법

13.10 여러 줄로 이루어진 문자 그림(ASCII art)을 건너뛸 수 있는 방법을 제공해 주어야 한다. [중요도 3]

체크포인트 1.1과 용어 사전에 있는 문자 그림(ascii art)의 예를 참조하라.

체크포인트 13.1과 관련된 기술/기법

지침 14. 문서는 명확하고 간결해야 한다.

문서를 이해하기 쉽도록 명확하고 단순하게 만들어라.

일관성 있는 내용물의 자리 배치, 알아보기 쉬운 그래픽, 이해하기 쉬운 언어는 모든 사람에게 혜택을 준다. 특히, 인지적인 장애가 있어나 독해에 어려움을 겪는 이들에게 도움이 된다. 그러나, 맹인, 약시(弱視)인 사용자, 그림을 볼 수 없거나 또는 보지 않기로 선택한 사람들을 위해 그림에는 대체 텍스트를 반드시 넣어야 한다. 지침 1도 참조하라.)

간단 명료한 언어를 씀으로써 보다 효과적인 의사 소통 및 전달이 가능하다. 인지적 장애나 학습 장애가 있는 사람들이 글로 쓰여진 정보에 접근하는 것은 어려운 일일 수 있다. 간단 명료한 언어는 모국어가 다른 언어인 사람, 또는 수화로 주로 의사 소통하는 사람에게도 혜택을 줄 수 있다.

체크포인트:

14.1 사이트의 콘텐츠에 적합한 가장 명확하고 간결한 언어를 사용하라. [중요도 1]

체크포인트 14.1과 관련된 기술/기법

14.2 문자로 된 내용에는 페이지의 이해를 도울 수 있다면 그래픽 혹은 청각적 보조 내용물을 추가해준다. [중요도 3]

지침 1도 참조하라.

체크포인트 14.2와 관련된 기술/기법

14.3 여러 페이지에 걸쳐 일관성 있게 쓸 표현 방법 스타일(스타일 시트를 쓰는 것이 좋은 방법이지만, 여기서 스타일은 꼭 스타일 시트에만 국한된 것은 아니다.)을 개발하라. [중요도 3]

체크포인트 14.3과 관련된 기술/기법

부록 A. -- 유효성 검사(Validation)

자동 검사 도구와 수동 검사를 통해 접근성이 확보되었는지 검사를 한다. 자동 검사 도구를 쓰는 방법은 일반적으로 빠르고 편하지만 접근성에 관한 모든 문제점을 식별하지는 못 한다. 수동으로 직접 검사를 할 경우 언어의 명료성과 탐색의 용이성 등을 담보할 수 있다.

(페이지) 개발의 맨 첫 단계에서부터 검사를 시작하라. 초기에 식별한 접근성 관련 문제점은 더 수정하기 쉽고, 피해 갈 수 있다.

아래는 몇 개의 중요한 유효성 검사 방법인데 기술/기법에 관한 문서의 유효성 검사 절을 참조하라.

1. 자동화된 접근성 검사 도구와 브라우저 유효성 검사 도구를 사용하라. 소프트웨어 도구가 모든 접근성 관련 문제점을 다룰 수는 없다는 점을 유의해야 한다. 예를 들면 링크 텍스트의 의미가 적절한지 여부나, 대체 텍스트(text equivalent)의 적용 가능성(applicability) 등은 다룰 수 없다.
2. 문법 검사를 하라(예를 들면, HTML, XML 등).
3. 스타일 시트의 문법 검사를 하라(예를 들면, CSS).
4. 텍스트만 나오는 브라우저 또는 에뮬레이터로 시험해 보라.
5. 여러 개의 그래픽 브라우저를 써서 다음과 같은 조건 하에서 시험해 본다.
   • 소리와 그래픽을 모두 받는 설정
   • 그래픽을 받지 는 설정
   • 소리를 받지 않는 설정
   • 마우스를 쓰지 않는 설정
   • 프레임, 스크립트, 스타일 시트, 애플릿을 사용하지 않는 설정
6. 최근에 나온 것 뿐 아니라 오래된 브라우저를 포함하여 여러 개의 브라우저로 시험해 보라.
7. 음성 브라우저(self-voicing browser), 화면 음성 변환기, 화면 확대 장치, 낮은 해상도의 화면 등을 써보라.
8. 철자법과 문법 검사기를 사용하라. 음성 합성기를 통해 페이지를 읽는 사람들은 철자법이 틀린 단어에 대해서 합성기가 읽어주는 것으로는 무슨 단어인지 추측할 수가 없을 것이다. 문법적인 오류도 없어야 이해하기가 쉽다.
9. 문서가 간단 명료하게 작성되었는지 다시 점검하라. 일부 워드 프로세서가 생성해 주는 가독성 통계치같은 것들이 명확성이나 간결성에 대한 좋은 지표로 쓰일 수 있다. 그보다 더 나은 방법은 경험있는 편집자에게 명료성을 검토해 주도록 부탁하는 것이다. 또한 경험있는 편집자는 특정 언어(단어나 표현)나 아이콘 사용이 야기할 수도 있는 잠재적으로 민감한 문화적인 문제점을 가려내어 문서의 사용자 편의성(usability)을 높일 수도 있다.
10. 장애인이 직접 문서를 검토하게 하라. 웹 사용에 능숙한 정도가 크게 다른 ("초보자와 전문가") 장애인을 통해 접근성이나 사용자 편의성 측면의 문제점과 그 심각성에 대해 귀중한 피드백을 얻을 수 있을 것이다.

부록 B. -- 용어집

접근 가능한(Accessible)

장애가 있는 사람이 사용할 수 있는 콘텐츠는 접근 가능한 콘텐츠이다.

애플릿(Applet)

웹 페이지에 삽입된 프로그램

(장애인을 위한)보조 기술(Assistive technology)

장애인들이 일상적인 활동을 수행하는데 도움을 주기 위해 특별히 디자인된 소프트웨어나 하드웨어. 보조 기술에는 휠체어, 음성 독서 장치(reading machine), 집게류(devices for grasping) 등이 있다. 웹 접근성 부분에서 일반적인 소프트웨어 기반의 보조 기술에는 (다른 웹 표시 장치들 중에서) 탁상용 그래픽 브라우저와 연동하여 작동하는 화면 음성 변환기(screen reader), 화면 확대 장치, 음성 합성 장치, 음성 입력 소프트웨어 등이 있다. 하드웨어적인 보조 기술에는 특수 키보드(alternative keyboards)나 특수 지시 장치(alternative pointing devices) 등이 있다.

문자 그림(ASCII art)

문자 그림이란 그림을 나타내기 위해 조합된 문자와 기호들을 가리키는 말이다. 예를 들면 ";-)"는 사람의 웃는 얼굴을 흉내낸 이모티콘이다. 아래는 빛의 깜박임(점멸) 주파수에 따른 광과민성 발작증 (광과민성 간질) 환자의 반응 빈도 (눈을 감은 경우와 뜬 경우에)를 보여주는 문자 그림이다. [문자 그림 그냥 지나가기 또는 차트에 대한 설명 보기 ]:

 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      빛의 깜박임 주파수 (Hertz)

역자 주: 2003년 7월 현재 최신 인터넷 익스플로러 6.0에서는 한국어 문서에 있는 pre 요소의 내용을 고정폭 글꼴(fixed-pitch font)로 표시하지 않기 때문에 위 문자 그림은 가지런하게 보이지 않는다. 다른 대부분의 시각적인 브라우저 (예: 넷스케이프, 오페라, 모질라, 캉커러 등)에서는 정상적으로 나타난다.

저작 도구(Authoring tool)

HTML 편집기, 문서 변환 도구, 데이터베이스로부터 웹 콘텐츠를 생성하는 모든 도구를 저작 도구라 한다. 접근 가능한 저작 도구를 만들기 위해서는 "저작 도구의 접근성을 높이기 위한 지침"([WAI-AUTOOLS])을 참조하라.

하위 호환성을 갖춘(Backward compatible)

구 버전의 언어, 프로그램 등과도 계속 잘 작동하는 디자인

점자(Braille)

점자는 문자나 숫자를 표현하기 위해 6개의 볼록한 점을 여러 가지 모양으로 배치해 맹인들이 손가락으로 읽을 수 있도록 해놓은 것이다. "Accessible"이라는 단어는 점자로 아래와 같이 표현한다:

흔히 "동적 점자 표시 장치"라고 하는 점자 표시 장치는 컴퓨터와 같은 전자 제품에서 내린 명령에 따라 점들을 볼록하게 하거나 오목하게 할 수 있다. 그 결과 순간순간 변하는 점자들의 행이 만들어진다. 최근의 동적 점자 표시 장치의 경우 한 개의 셀(6 또는 8개의 점)에서 80개의 셀까지 한 줄에 나타내며, 대부분은 한 줄에 12개 ~ 20개 정도의 셀을 나타낸다.

콘텐츠 개발자(Content developer)

웹 페이지를 만들거나 웹 사이트를 디자인하는 사람

쓰이지 않는(Deprecated)

낡은 요소(element) 또는 속성(attribute)이란 같은 기능을 하거나 효과를 지닌 새로운 constructs의 등장으로 말미암아 더 이상 쓰지 않는 것이 바람직한 요소나 속성이다. 이들은 앞으로 나올 HTML 개정판에서는 없어져서 효력을 잃을 수 있다. 접근성 지침 구현을 위한 기술 문서에 있는 HTML 요소와 속성 색인에 보면 어떤 요소와 속성이 HTML 4.0에서 낡은 것인지 알 수 있다.

웹 제작자들은 낡은 요소와 속성을 쓰지 않아야 한다. 웹 표시 장치에서는 하위 호환성을 위해 계속 지원해야 한다.

장치 독립적(Device independent)

사용자들은 자신이 필요해서 선택한 입출력 장치를 이용해 웹 표시 장치(, 그리고 웹 문서)와 상호 작용할 수 있어야 한다. 입력 장치에는 지시 장치, 키보드, 점자 입력 장치, 머리 움직임 입력 장치, 마이크 등이 있다. 출력 장치에는 모니터, 음성 합성 장치, 점자 표시 장치 등이 있다.

"장치 독립적인 지원"이 웹 표시 장치가 모든 입출력 장치를 지원해야 한다는 뜻은 아님에 유의해야 한다. 웹 표시 장치는 지원하는 장치들에 대한 중복적인 입출력 방법을 지원해야 한다. 예를 들어 웹 표시 장치가 키보드와 마우스 입력을 지원한다면, 사용자들은 키보드나 마우스 어떤 것을 쓰든 모든 기능을 다 사용할 수 있어야 한다.

문서 콘텐츠, 구조, 표현 방법(Document Content, Structure, and Presentation)

어떤 문서의 콘텐츠란 그것이 언어, 그림, 소리, 동영상, 애니메이션 등을 통해 사용자에게 전달하고자 하는 것을 뜻한다. 문서의 구조란 그것이 논리적으로 구성되는 방식(예를 들면 장과 절, 소개, 목차 등을 통해)을 말한다. 문서의 구조를 표시하는 요소 (예를 들면 HTML에서 P, STRONG, BLOCKQUOTE 같은 것들)를 구조적 요소라고 한다. 문서의 표현 방법이란 문서가 나타내어지는 방법(예를 들면, 종이로 출력되거나, 모니터상에 2차원 그래픽으로 출력되거나, 음성 합성기로 출력되거나, 또는 점자로 출력되는 것 등)을 뜻한다. 문서의 표현 방법을 표시하는 요소(예를 들면, B, FONT, CENTER 같은 것들)를 표현을 위한 요소라고 한다.

예를 들어 문서의 헤더(header) 부분을 생각해보자. 헤더 부분의 콘텐츠는 헤더가 나타내는 것(예를 들면 "범선(Sailboats)")이다. HTML에서, 헤더는 H2와 같은 요소로 표시되는 구조적 요소이다. 마지막으로, 헤더를 표현하는 방법 몇 가지를 들자면 다음과 같다 : 굵은 글꼴로 페이지 여백에 표시하기, 줄 중앙에 좌우 여백을 동일하게 해서 두기, 특정한 음성 스타일로 읽어주기 (음성 글꼴을 쓰는 경우).

동적 HTML(Dynamic HTML (DHTML))

DHTML은 HTML, 스타일 시트, 문서 객체 모형(Document Object Model) [DOM1], 스크립팅 등이 같이 쓰인 경우를 지칭하는 '판촉용' 비공식 용어이다. 따라서 정식으로 DHTML에 대해 W3C에서 정의한 것은 없다. 대부분의 지침이 DHTML을 쓰는 경우에 적용되지만 다음의 지침은 스크립트와 스타일 시트를 사용하는 것과 관련된 문제점을 집중적으로 다루고 있다: 지침 1, 지침 3, 지침 6, 지침 7, 지침 9.

요소(Element)

이 문서에서는 "요소"라는 용어가 엄격한 SGML의 맥락에서 쓰이기도 하고, 더 일반적으로는 (비디오나 소리와 같은) 콘텐츠의 유형을 뜻하거나 (헤더나 목록(list)과 같은) 논리적인 construct를 뜻하기도 한다. 두 번째 의미를 통해서는 HTML에서 나온 지침이 다른 마크업 언어에 쉽게 적용될 수 있다는 것을 강조하고 있다.

(SGML) 요소의 일부는 표시되는 콘텐츠를 가지고 있으며(예를 들면, HTML에서 P, LI, 또는 TABLE), 일부는 외부의 콘텐츠에 의해 대체되기도 하고(예를 들면 IMG), 일부는 문서의 처리 방법(processing)에 영향을 준다(예를 들면 STYLE은 스타일 시트에 의해 처리되고, SCRIPT는 스크립트 엔진에 의해 처리되므로). 텍스트 문자들이 문서의 일부가 되도록 만드는 요소를 텍스트 요소라고 한다.

상응하는 요소(대체물, Equivalent)

한 콘텐츠가 사용자에게 제시됨에 있어서 다른 콘텐츠와 근본적으로 똑같은 기능이나 목적을 수행할 때에 그 콘텐츠는 다른 콘텐츠에 "상응한다(equivalent)"고 표현한다. 이 문서에서 말하는 상응하는 콘텐츠에서는 본래의 콘텐츠가 비장애인에게 제공하는 것과 동일한 기능(장애의 종류나 현재의 기술 수준에서 적어도 가능한 수준에서)을 장애인에게도 제공해야 한다. 예를 들면, "보름달"이라는 텍스트는 보름달 그림과 똑같은 정보를 사용자에게 전달해줄 것이다. 상응하는 정보란 동일한 기능을 수행하는 것에 초점을 두고 있음에 유의하라. 만약 그림이 어떤 링크의 일부분이고, 그 링크의 목표 위치에 대해 짐작하기 위해서 그림을 반드시 이해해야 한다면, (예를 들어 이미지 맵에서 사이트 내부로 가는 링크인지 여부, 내용의 난이도-- 웹에 올려진 강의 교재 등에서 -- 등을 색깔이나 아이콘 등 시각적 방법으로 구별해 놓았다면, 이미지 맵에 넣은 대체 텍스트를 통해서도 이 구별이 가능해야 한다.) 그림을 대체하는 요소에서도 링크의 목표 위치에 대한 아이디어(내용, 성격, 위치 등)를 사용자에게 제공해야 한다. 접근성이 낮은 콘텐츠에 대해 대체(상응하는) 정보를 제공하는 것은 장애인들의 문서에 대한 접근성을 높이는 주요한 방법 중 하나이다.

똑같은 목적을 수행하기 위해서는 상응하는 대체 요소가 원래 콘텐츠에 대한 기술이나 설명을 포함할 수도 있다. (즉, 원래 콘텐츠가 어떻게 보인다든지, 어떻게 소리가 난다든지 하는 식으로.) 예를 들면, 복잡한 차트에 담긴 정보를 (장애인들에게) 이해시키기 위해서는 차트 안에 있는 시각적인 내용을 (텍스트나 음성으로) 기술해야 한다.

텍스트로 된 콘텐츠는 사용자에게 합성된 음성이나, 점자, 시각적인 텍스트 등으로 제시될 수 있으므로, 이 지침에서는 그래픽이나 음성 정보에 대해서 대체 텍스트(text equivalents)를 넣을 것을 요구하고 있다. 대체 텍스트는 모든 주요한 콘텐츠에 담긴 정보를 전달할 수 있도록 쓰여야 한다. 텍스트가 아닌 대체 요소(Non-text equivalents) (예를 들면, 시각적으로 표현한 내용에 대한 음성 설명, 글로 쓰여진 내용에 대해 수화로 사람이 설명하는 것을 담은 비디오 등)를 통해서도 시각 정보나 글로 쓰여진 텍스트에 대해 접근할 수 없는 많은 사람들 -- 맹인들, 인지적 장애인들, 학습 장애인들, 청각 장애인들 -- 에게 접근성을 높여줄 수 있다.

대체 정보를 제공하는 방법은 여러 가지가 있다. 속성을 지정함으로써 (예: HTML과 SMIL에서 "alt" 속성값을 지정함으로써), 요소를 통해 (예: HTML에서 OBJECT를 통해), 문서 내의 설명을 통해, 또는 별도의 문서를 링크하여(예: HTML에서 "longdesc" 속성에 링크를 걸어서, 또는 설명 링크를 통해서) 가능하다. 대체 정보의 복잡성에 따라 몇 가지 기술을 동시에 사용할 필요도 있을 것이다. 예를 들어 처음 보는 사람을 위한 자세한 정보는 "longdesc" 링크를 통해 제공함과 아울러, 내용에 친숙한 사람들에게는 간략한 대체 정보를 "alt" 속성을 써서 제공할 수 있다. 언제 어떻게 대체 정보를 제공해줄 것인가에 대한 자세한 내용은 기술 문서([TECHNIQUES])에 나와있다.

텍스트 원고(text transcript)란 일반 음성 언어와 음향 효과와 같은 비음성 소리를 포함한 오디오 정보에 대한 텍스트 대체물이다. 캡션(자막, caption)은 동영상 비디오의 오디오 트랙 부분에 대한 텍스트 원고 가운데 비디오 및 오디오 트랙과 동기된 것을 가리킨다. 캡션은 일반적으로 비디오 화면 위에 겹쳐져서 시각적으로 나오는데, 이것은 청각 장애인(완전 귀머거리나 청력이 약한 사람)이나 오디오를 들을 수 없는 상황의 사람(예를 들면 시끄러운 방에 있는 사람)들에게 도움을 준다. (부가적으로 외국어 학습자에게도 도움을 준다. 이것은 접근성을 높이는 것이 비장애인을 돕는 또다른 보기이다.) 결합 텍스트 원고(collated text transcript)는 비디오 정보에 대한 텍스트 설명(비디오 트랙에 나오는 동작, 몸짓, 그래픽, 장면 전환 등에 대한 설명)과 캡션을 결합한 것이다. 이러한 텍스트 대체물은 시각과 청각에 모두 장애가 있는 사람이나 영화나 애니메이션을 플레이조차 할 수 없는 사람들에게도 프리젠테이션에 대해 접근할 수 있게 해준다. 이것은 또 검색 엔진이 정보를 찾을 수 있게도 해준다.

비-텍스트 형식의 대체물의 한 예로 프리젠테이션의 주요 시각적인 요소에 대한 음성 설명을 들 수 있다. 이런 설명은 사람의 목소리로 미리 녹음한 것일 수도 있고, (미리 녹음하거나 즉석에서 만들어지는) 합성 음성일 수도 있다. 음성 설명은 보통 비디오 내에서 오디오가 잠시 멈추는 곳에서 오디오 트랙에 동기되어 제시된다. 음성 설명은 동작/움직임, 몸짓, 그래픽, 장면 전환 등에 대한 정보를 담고 있다.

이미지(Image)

그래픽으로 나타낸 표현 방법

이미지 맵(Image map)

이미지가 영역으로 나뉘고 그 영역이 특정한 동작(actions)과 연결된 것. 활성 영역을 클릭하면 그것에 해당하는 동작이 실행된다.

사용자가 클라이언트측 이미지 맵의 한 영역을 클릭하면 웹 표시 장치가 어디에서 클릭이 일어났는지 계산을 하고 그 영역의 링크를 따라간다. 서버측 이미지 맵의 한 영역을 클릭하면 클릭이 일어난 곳의 좌표를 서버로 보내고, 서버에서 그 다음 동작이 일어난다.

콘텐츠 개발자는 클라이언트측 이미지 맵의 영역마다 장치 독립적인 링크를 추가로 제공하여 접근성을 제고할 수 있다. 클라이언트측 이미지 맵을 사용하면 웹 표시 장치는 사용자의 지시 장치가 활성 영역에 있는지 없는지 즉시 피드백을 제공해 준다.

중요한(Important)

문서를 이해하기 위해서는 어떤 정보에 대한 이해가 필수적이라고 한다면 그 정보는 중요하다고 말한다.

선형화된 표(Linearized table)

특정 방향(예를 들면 페이지 아래 방향으로 -- 역자 주: 맨 아래에 이르면 다음 열의 맨 위로 이동해서 다시 아래 방향으로)으로 이동하면서 각 칸의 내용을 문단으로 바꿔서 얻어진 문단들의 열이 구성하는 텍스트. 문서 원본에서 정의한 칸들의 순서에 따라 문단이 생겨날 것이다. 칸들은 순서대로 읽었을 때에 의미가 통해야 하고 (문단이나 헤더나 목록을 생성하는) 구조적 요소를 포함하고 있어서 표를 선형화한 후에 페이지의 의미도 통해야 한다.

링크 텍스트(Link text)

링크 걸린 텍스트를 표시한 것

자연어(Natural Language)

프랑스어, 일본어, 수화, 점자처럼 말로, 글로 또는 부호(수화나 점자와 같이)로 나타낼 수 있는 인간이 사용하는 언어를 통칭함. HTML([HTML40], 섹션 8.1) 에서 "lang" 속성에 의해 콘텐츠의 자연어를 지정하며, XML ([XML], 섹션 2.12)에서는 "xml:lang" 속성에 의해 자연어를 지정한다.

탐색 방법(Navigation Mechanism)

탐색 방법이란 사용자가 페이지나 사이트를 탐색할 수 있게 해 주는 방법을 말한다. 전형적인 방법에는 다음과 같은 것들이 있다.

탐색 막대

탐색 막대는 문서나 사이트의 가장 중요한 부분에 갈 수 있는 링크를 모아놓은 것을 말한다.

사이트 지도

사이트 지도는 페이지나 사이트의 구성에 대한 전반적인 조감을 할 수 있게 한다.

목차

목차는 일반적으로 문서의 가장 중요한 장과 절에 대한 목록(또는 링크)들이다.

개인용 정보 단말기(Personal Digital Assistant, PDA)

PDA는 소형의 휴대 가능한 컴퓨터 기기이다. 대부분의 PDA들은 일정, 연락처, 이메일과 같은 개인 정보를 관리하는 데에 쓰인다. PDA는 일반적으로 손에 휴대할 수 있는 기기이며, 여러 가지 입력 방법을 제공하는 작은 화면을 가지고 있다.

화면 확대 장치(Screen magnifier)

화면의 일부분을 확대해서 더 쉽게 볼 수 있도록 해주는 소프트웨어 프로그램. 화면 확대 장치는 주로 약시인 사람(시력이 매우 낮은 사람)이 쓴다.

화면 음성 변환기(Screen reader)

화면의 내용을 소리내어 사용자에게 읽어주는 소프트웨어 프로그램. 화면 음성 변환 장치는 주로 맹인들이 쓴다. 화면 음성 변환 장치는 화면에 표시된 텍스트 문자만을 읽어주며, 그림으로 그린 글자는 읽을 수 없다.

스타일 시트(Style sheets)

스타일 시트는 문서의 표현 방법을 정의하는 문장을 모아놓은 것이다. 스타일 시트는 세 가지 방법으로 정의할 수 있다. 콘텐츠 개발자가 정의할 수도 있고, 사용자가 정의할 수도 있고, 웹 표시 장치(브라우저) 개발자가 표시 장치에 고유한 기본으로 쓸 스타일 시트를 정의할 수도 있다. CSS ([CSS2])에서는 콘텐츠 개발자, 사용자, 웹 표시 장치 간의 상호 작용을 캐스케이드(cascade)라고 한다.

표현 마크업(Presentation markup)은 HTML에서 B나 I 요소처럼 (구조보다는) 모양을 바꾸는 효과를 가진 마크업이다. STRONG과 EM 요소는 특정한 글꼴 모양과 독립적인 정보를 전달하는 것으로 표현 마크업이 아님에 주의하라.

표(에 적합한) 정보(Tabular information)

자료들(텍스트, 숫자, 그림 등) 간의 논리적인 관계를 나타내기 위해 표를 사용하였을 때에 그 정보를 "표 형식 정보"라고 하고, 그 표를 "자료(용) 표(data tables)"라고 한다. 표에 의해 나타내고자 하는 (자료들간의) 관계는 시각(보통 이차원의 격자로 나타낸다), 음성(보통 각 칸의 내용을 읽기에 앞서 해당 헤더-- 열 혹은 행의 제목 --를 읽는다.), 또는 다른 형식으로 표현할 수 있다.

웹 표시 장치가 사용자에게 ...할 때까지는(Until user agents ...)

대부분의 체크포인트에서는 콘텐츠 개발자가 만든 페이지와 사이트가 접근성을 가질 것을 요구한다. 그러나 장애인을 위한 보조 기술을 비롯한 웹 표시 장치가 다루고 처리하기에 보다 적합한 접근성 관련 문제도 있다. 이 문서를 발간하는 시점에서 필요한 접근성 관련 제어 방법을 모든 웹 표시 장치나 보조 기술이 지원하지는 않고 있다. 예를 들면, 어떤 웹 표시 장치에서는 사용자가 깜박거리는 콘텐츠를 끌 수 없고, 일부 화면 음성 변환기(screen readers)에서는 표(table)를 잘 다루지 못 한다. "웹 표시 장치가 사용자에게 ...할 때까지는"이라는 문구가 담긴 체크포인트는 대부분의 웹 표시 장치가 필요한 접근성 관련 기능을 제공할 때까지는 웹 콘텐츠 개발자가 이런 현실을 감안하여 추가로 고려해야 할 접근성 관련 문제를 다루고 있다.

Note. W3C의 WAI Web site ([WAI-UA-SUPPORT]를 참조) 에서 접근성 관련 기능을 웹 표시 장치에서 얼마나 잘 지원하는지에 대한 정보를 제공한다. 콘텐츠 개발자는 이 페이지에 자주 들러서 갱신되는 정보를 참고하는 것이 좋다.

웹 표시 장치(User agent)

탁상용 그래픽 브라우저, 텍스트 브라우저, 음성 브라우저, 휴대 전화, 멀티미디어 플레이어, 플러그인, 그리고 화면 음성 변환기(screen readers), 화면 확대 장치(screen magnifiers), 음성 인식 소프트웨어와 같이 브라우저에 연동하여 쓰이는 소프트웨어적인 보조 기술을 포함한 웹 콘텐츠에 접속하는 소프트웨어.

감사의 글

웹 콘텐츠 지침 워킹 그룹의 공동 의장:

Chuck Letourneau, Starling Access Services

Gregg Vanderheiden, Trace Research and Development

W3C 팀 연락처:

Judy Brewer와 Daniel Dardailler

이 지침을 만들기 위해 시간을 내주시고 귀중한 의견을 주신 다음 분들에게 감사 드립니다:

Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White

한국어 번역에 도움을 주신 분

Jungshik Shin

이 문서의 본래 초판은 위스콘신 대학의 Trace R & D Center에서 나온 "통합된 웹 사이트 접근성 지침(The Unified Web Site Accessibility Guidelines)" ([UWSAG])에 기본을 두고 만들어졌습니다. 위 문서에는 수고하신 다른 분들의 이름도 나와 있습니다.

참고 문헌(참고 자료)

W3C의 최신 문서를 보려면 W3C 기술 보고서(W3C Technical Reports)를 참고하기 바란다.

[CSS1]

"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. CSS1 권고안: http://www.w3.org/TR/1999/REC-CSS1-19990111.
CSS1 최신 버전: http://www.w3.org/TR/REC-CSS1.

[CSS2]

"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. CSS2 권고안: http://www.w3.org/TR/1998/REC-CSS2-19980512.
CSS2 최신 버전: http://www.w3.org/TR/REC-CSS2.

[DOM1]

"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. DOM Level 1 권고안: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
DOM Level 1의 최신 버전: http://www.w3.org/TR/REC-DOM-Level-1

[HTML40]

"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. HTML 4.0 권고안: http://www.w3.org/TR/1998/REC-html40-19980424.
HTML 4.0 최신 버전: http://www.w3.org/TR/REC-html40.

[HTML32]

"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. HTML 3.2 최신 버전: http://www.w3.org/TR/REC-html32.

[MATHML]

"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. The MathML 1.0 권고안: http://www.w3.org/TR/1998/REC-MathML-19980407.
MathML 1.0 최신 버전: http://www.w3.org/TRREC-MathML.

[PNG]

"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. PNG 1.0 최신 버전: http://www.w3.org/TR/REC-png.

[RDF]

"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. RDF 권고안: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
RDF 1.0 최신 버전: http://www.w3.org/TR/REC-rdf-syntax

[RFC2068]

"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.

[SMIL]

"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. SMIL 1.0 권고안: http://www.w3.org/TR/1998/REC-smil-19980615
SMIL 1.0 최신 버전: http://www.w3.org/TR/REC-smil

[TECHNIQUES]

"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. 이 문서에서는 "웹 콘텐츠 접근성 지침 1.0"에서 정의한 체크포인트를 어떻게 구현하는지에 대해 설명하고 있다. 이 기술 문서의 최신 버전: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/

[WAI-AUTOOLS]

"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. 저작 도구 접근성 지침에 대한 가장 최신 작업 초안(Working Draft): http://www.w3.org/TR/WAI-AUTOOLS/

[WAI-UA-SUPPORT]

이 문서에서는 (보조 기술을 포함하여) 웹 표시 장치들이 여기에서 언급된 접근성 관련 기능을 얼마나 지원하는지에 대해 언급하고 있다. 문서 있는 곳: http://www.w3.org/WAI/Resources/WAI-UA-Support

[WAI-USERAGENT]

"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. 접근성이 높은 웹 표시 장치를 설계하기 위한 이 지침에 대한 최신 작업 초안: http://www.w3.org/TR/WAI-USERAGENT/

[WCAG-ICONS]

적합성 아이콘들에 대한 정보와 그것의 사용법: http://www.w3.org/WAI/WCAG1-Conformance.html

[UWSAG]

"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. 통합된 웹 사이트 지침은 위스콘신 대학교의 Trace R & D Center에서 미 연방 교육부 산하 국립 장애 재활 연구소(National Institute on Disability and Rehabilitation Research, NIDRR)의 지원을 받아 만들었다. 문서 있는 곳: http://www.tracecenter.org/docs/html_guidelines/version8.htm

[XML]

"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. XML 1.0 권고안: http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of XML 1.0 is available at: http://www.w3.org/TR/REC-xml