이 웹 페이지는 WCAG 2.0 을 위한 테크닉: 웹 컨텐츠 접근성 가이드라인 2.0에 대한 테크닉과 에러처리들로부터 일반적인 테크닉들을 나열한다. 테크닉에 대한 정보를 보려면 WCAG 2.0 테크닉 소개를 보기 바란다. 다른 기술들에 대한 테크닉을 보려면 차례를 참조하기 바란다.
링크를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 페이지의 주된 컨텐츠로 바로 감으로서 여러개의 웹 페이지들에 연관되어 있는 내용들의 블럭을 건너뛰는 메커니즘을 제공하는 것이다. 웹 페이지에서 처음에 나타나는 인터랙티브한 아이템은 메인 컨텐츠의 시작을 가리키는 링크이다. 링크를 활성화하면 다른 컨텐츠를 뒤로 돌리고 주된 컨텐츠에 초점을 맞추게 된다. 이러한 테크닉이 가장 유용한 곳은 웹 페이지가 하나의 주 컨텐츠 영역을 가지는 경우이며, 동일한 중요성을 갖는 컨텐츠 영역 여러개로 구성된 페이지에서는 큰 효과를 갖지 못한다.
노트: 시각적인 링크는 키보드를 이용하여 내비게이팅 하는 사용자 - 마우스를 같이 사용하는 사용자를 포함한다 - 와, 키보드 입력을 천천히 생성하는 테크닉을 이용하는 사용자들, 화면 확대 소프트웨어의 사용자들, 시각이 불편하지 않은 동료와 함께 일하는 스크린 리더 사용자들, 키보드만 사용하는 사용자들, 그리고 음성 인식 소프트웨어를 이용해 내비게이팅 하는 사용자들에게 필요하다.
온라인 신문은 여러개의 정보 섹션을 포함하고 있다: 검색 기능, 회사 광고, 사이드바, 사소한 기사들, 신문사에 연락하는 방법 등. 머리기사는 페이지의 중앙에 위치해 있다. 사용자가 탭을 눌렀을때 처음 만나는 링크는 "머리기사로 바로 가기" 라는 타이틀을 갖고 있다. 링크를 활성화하게 되면, 시각적 초점을 그 기사로 옮기게 된다. 탭을 다시 누르면 사용자를 주요 기사의 첫번째 링크로 옮기게 된다.
웹 페이지는 자신을 구성하는 각각의 페이지들에서 다양한 내비게이션 테크닉을 포함하고 있다 : 흔적 남기기, 검색도구, 사이트맵, 관련된 자원의 목록 등이다. 페이지의 첫번째 링크에는 "주된 내용으로 바로 가기" 라는 타이틀이 달려 있다. 사용자는 내비게이션 영역의 다른것들을 건너뛰기 위해 링크를 활성화한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
페이지에서 포커스를 받을 수 있는 컨트롤 중 첫번째가 링크인지 확인한다.
링크가, 자신이 주된 컨텐츠 영역으로의 링크임을 설명하고 있는지 확인한다.
링크가 항상 보이는지, 아니면 키보드 포커스를 받았을 때 보이는지 확인한다.
링크를 활성화했을때 페이지의 주된 컨텐츠로 포커스가 이동하는지 확인한다.
링크를 활성화 한 후, 키보드 포커스가 주된 컨텐츠로 이동하였는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
컨텐츠를 이동하거나 스크롤하는 것을 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 내용의 컨텐츠의 이동, 또는 스크롤을 일시정지시키는 방법을 제공하는 것이다. 사용자가 자신이 느끼는 혼란스러움을 경감하고자, 또는 읽을 시간을 얻기 위해 그러한 이동을 일시정지할 필요가 있다면, 그렇게 할 수 있고, 또 필요할때 다시 시작할 수 있다. 이러한 메커니즘은 WCAG를 만족하는 인터랙티브 컨트롤을 통해서 제공되거나, 혹은 키보드 단축키를 이용해 제공되어질 수 있다. 키보드 단축키가 사용되었다면, 그것들은 문서화되어 있다.
페이지의 상단에, 스크롤되는 뉴스 배너가 있다. 그것을 읽고자 하는 사용자는 esc 키를 눌러서 스크롤을 잠시 멈출 수 있다. 키를 다시 누르면 스크롤이 다시 시작된다.
페이지에 "신발끈을 묶는 방법"이란 제목을 가진 링크가 있고, 그 링크는 플래시 애니메이션을 가리킨다. 링크의 바로 앞에 있는 텍스트에는, 스페이스바를 눌러서 애니메이션을 일시정지시킬 수 있고, 다시 누르면 다시 시작할 수 있다는 내용이 있다.
움직이거나 스크롤되는 컨텐츠를 포함한 페이지에서,
페이지, 혹은 사용자 에이전트에서 제공하는, 컨텐츠의 이동이나 스크롤링을 일시정지하는 메커니즘을 실행한다.
이동이나 스크롤링이 멈추었고, 스스로 다시 시작하지 않는지 확인한다.
컨텐츠의 이동을 재시작하는 메커니즘을 실행한다.
이동이나 스크롤링이 멈췄던 곳에서 다시 시작하는지 확인한다.
#2 와 #4 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
이 테크닉은 그 기능의 성공적인 수행을 위해 타이밍에 밀접한 상호작용을 필요로 하지 않는 기술이나 방법들에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은, 사용자들이 자신이 하려는 일을 완수하는데에 필요한 시간 전체를 제공하는 것이다. 이 테크닉은 타이밍에 밀접한 상호작용을 요구하지 않는 작업을 제공하는 것과 결부되어 있다. 사용자들은 그러한 작업과 상호작용하기 위해 필요로 하는 시간을 최대한 허용받는다.
문제 전체를 웹 페이지에 게제하는 시험. 사용자들은 문제를 풀기 위해 원하는대로 시간을 쓸 수 있다.
플레이어가 제한시간 내에 자신의 일을 해야 하는 방식이 아니라, 자신의 턴에서 원하는대로 시간을 쓸 수 있는 게임.
입찰자들이 타이밍에 맞춰서 여러번의 경쟁 입찰을 하는 방식이 아니라 단 한번의 입찰만을 할 수 있는 온라인 경매. 응찰은 하루에 한번 가능하므로, 누구든지 입찰 폼을 완성하는데 충분한 시간을 가질 수 있다. 경매가 종료되면 최고가가 낙찰된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
시간 제한이 있는 상호작용이 있는지 살펴본다.
#1 에 해당하는 것이 없다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
오디오와 비디오를 지원하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 확장된 청각 설명이 첨부된, 비디오 컨텐츠의 두번째 버전을 제공하는 것이다. 전통적인 청각 설명을 제작하는 데 있어서 한가지 어려운 점은, 이따금씩 나레이터가 대단히 제한된 시간 동안 방대한 양의 정보를 전달해야만 하는 경우가 있다는 것이다. 확장된 청각 설명을 사용하면, 오디오와 비디오의 재생을 잠시 멈춤으로서, 대화 사이사이의 짧은 휴지기간이 적당한 설명을 전달하기에는 충분치 못한 경우에도 중요한 정보를 전달할 수 있다.
확장된 청각 설명이 첨부된, 영화 컨텐츠의 두번째 버전을 제공하게 되면 시각 장애인들 역시 이러한 컨텐츠에 접근할 수 있다. 그러한 사용자들은 대사만 듣는 것이 아니라, 등장인물들의 대사 만으로는 표현되지 않는 비디오의 여러가지 상황과 문맥들 역시 들어야만 하는데, 일반적인 대화 사이의 짧은 시간으로는 이것이 충분치 않기 때문이다.
추가적인 설명을 필요로 하지 않는 사람들에게는 이러한 확장된 설명이 방해가 되기 때문에, 보통은 이 기능을 켜고 끌 수 있도록 테크닉들이 제공된다. 대체적으로, 추가적인 설명이 있는 버전과 없는 버전 모두를 제공할수도 있다.
불타고 있는 건물에서 탈출하는 가족에 관한 온라인 비디오를 가정해 보자. 남편과 아내는 그들의 어린이들이 어디에 있는지 끊임없이 대화하고 있다. 그동안, 배경에서는, 벽이 무너지고 있는데, 이것은 줄거리에서 아주 큰 역할을 차지한다 - 무너진 벽이 그들의 탈출을 막을 것이기 때문이다. 비디오 트랙은 나레이터가 벽이 무너지고 있는 것을 자세히 설명하는 동안 잠시 멈추었다가 다시 재생된다.
거의 끊임없이 이어지는 나레이션을 갖고 있는 비디오 교재를 상상해 보자. 비디오의 일부분을 보는것에 어려움을 느끼는 사람들을 위한 대체 버전이 준비되어 있다. 대체 버전은 비디오를 잠시 멈추고, 중요한 정보들에 대한 설명을 읽어줄 것이다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
확장된 청각 설명이 포함된 버전의 영화를 연다.
원래의 대화 사이에 필요한 나레이션을 넣을 수 있는 공간이 충분치 않았던 곳에서 확장된 청각 설명을 위해 비디오가 멈추는지 확인한다.
청각 설명에 필요한 정보가 있는지 확인한다.
대체 버전(들)이 분리된 페이지에 있다면, 가능한 링크(들)이 그러한 대체 버전으로 연결되어 있는지 확인한다.
#2, #3, #4 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
시청각적 정보를 표현하는 모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 청각 장애가 있는 사람들이 실시간으로 동기화된 방송에 접근할 수 있도록 하는 것이다. 정확한 실시간 자막을 생성하는 것은 매우 어려운데, 실수를 정정하거나, 다시 듣거나, 단어들이 정확하게 표현되었는지 누군가에게 자문을 구할 시간이 없기 때문이다. 또한, 진행이 매우 빠르다면 그것을 간단하게 표현하거나 다른 말로 바꾸는 것 역시 어렵다.
현존하는 속기술과 빠른 타자 기술을 응용하는, 실시간 텍스트 삽입 기술이 존재한다. 텍스트로 변환된 음성을 다시 음성으로 바꾸는 기술(음성을 듣고 그것을 컴퓨터에 조심스럽게 말하는 기술자가 있다. 컴퓨터는 그 기술자의 음성에 최적화되어 있다)이 현재 전화 교환 서비스에서 사용되고 있으며, 이후에는 자막에서 사용될 수 있을 것이다. 언젠가는 대화를 텍스트로 정확하게 바꾸는것도 가능해질 것이다.
(역주 : 이 테크닉에서 "자막" 은 closed caption, 켜고 끌 수 있는 기능이 제공되는 인코딩된 텍스트를 의미한다.)
예제 1: 텔레비젼 스튜디오에서 온라인 저녁 뉴스에 사용할 자막을 만들기 위해 실시간 자막 서비스를 사용한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
G157: 웹 페이지에 실시간 음성 캡션 서비스를 포함시키기순서와 정책들이 자막이 실시간으로 전달될 것을 보증하는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
접근성 API와 상호작용하도록 프로그램된 표준 컴포넌트를 제작하는 프로그래밍 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 보조 공학 기술들이 웹 컨텐츠를 이해하고, 대체적인 사용자 인터페이스를 이용하는 사용자들에게도 동일한 정보를 제공할 수 있도록 하는 것이다.
컨텐츠를 마크업 언어를 이용해 제작하지 않고 프로그래밍 언어나 도구를 이용하여 제작하는 경우가 있다. 많은 경우, 이러한 기술들은 접근성 API와 상호작용하도록 이미 프로그램되어진 인터페이스 컴포넌트를 갖는다. 이러한 경우, 페이지의 저자가 그러한 컴포넌트를 이용하고 속성들(예를 들어, 이름 등)을 기입해 넣는다면, 결과물인 인터페이스 컴포넌트는 보조 공학 기술에서 이용되어질 수 있다
그러나, 페이지의 저자가 새로운 인터페이스 컴포넌트를 제작하기를 원하며 표준 컴포넌트를 이용할 수 없다면, 스스로 접근성 관련 준비를 추가할 수 있도록 확실히 해야 할 것이다. 또한 그것이 접근성 API와 호환되도록 구현해야 할 것이다.
완성된 후, 그러한 컴포넌트는 반드시 접근성 지원을 테스트해야 한다.
웹 페이지에서 애플릿을 생성하기 위해 자바를 사용한다. 저자 그룹은 완전히 새로운 형태의 인터페이스 컴포넌트를 제작하기를 원하며, 따라서 이미 존재하는 자바 객체를 사용할 수 없다. 이들은 자바 스윙(swing) 클래스를 이용해서 그들의 컴포넌트를 제작하는데, 자바 스윙 클래스가 기존의 몇가지 접근성 API들에 연결될 준비가 되어 있기 때문이다. 자바 스윙 클래스를 이용해서 생성한 그들의 인터페이스 컴포넌트는 자신의 이름과 기능을 사용자에게 노출하고 있으며, 따라서 보조 공학 기술에서 이들을 설정할 수 있고, 업데이트가 있다면 보조 공학 기술에 그것을 알릴 수 있다.(역주 : 원문에서 AT 라는 약어가 사용되어 있는데, 문맥상 Assistive Technology의 약자인 것으로 판단하여 그렇게 해석하였다)
웹 페이지에서 C++ 언어로 작성된 액티브X 컨트롤을 이용하고 있다. 이 컨트롤은 마이크로소프트 액티브 억세서빌리티(MSAA) API를 명시적으로 지원하여, 받아들이는 명령들에 대해 정보를 노출하고 있다. 따라서 컨트롤은 MSAA를 지원하는 시스템에서 구동되는 사용자 에이전트를 실행한 보조 공학 기술들과 직접적으로 상호작용한다.
접근성있는 사용자 에이전트에서 컨텐츠를 표현한다.
그 사용자 에이전트의 접근성 API에 맞게 디자인된 접근성 도구를 사용해서 각각의 UI 컴포넌트를 평가한다.
그 도구가 각각의 UI 컴포넌트의 이름과 기능들을 찾아내는지 확인한다.
컴포넌트의 값을 변경한다.
접근성 도구에서 그 변경을 인식하는지 확인한다.
컴포넌트가 보조 공학 기술과 함께 동작하는지 확인한다.
각각의 UI 컴포넌트들이 #3, #5, #6 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
컨텐츠의 깜박거림을 지원하는 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 컨텐츠의 깜박임으로부터 비롯하는 집중력 저하를 최소화하고, 사용자들이 페이지의 다른 컨텐츠에 다시 집중할 수 있도록 하는 것이다.
다양한 기술을 사용해서 깜박이는 컨텐츠를 만들 수 있는데, 그들 중 상당수는 깜박이는 컨텐츠를 계속해서 연속적으로 보여주는 옵션을 포함하거나, 깜박이는 컨텐츠가 보여질 횟수를 다른 방법으로 명시하도록 되어 있다. 컨텐츠의 깜박임을 5초 미만으로 제한하면, 이러한 깜박임 때문에 초래될 집중력 저하를 최소화할 수 있다. 이렇게 하면 특정 타입의 학습기능 장애를 겪는 사람이나, 시력이 낮은 사람들에게 도움을 줄 수 있다.
할인중인 상품들을 강조하기 위해 애니메이션 이미지를 사용하고 있다. 판매중인 아이템의 목록 중간에, "세일중" 이라는 문구 뒤에 위치한, 붉은색 태그가 달린 이미지가 있어서, 해당 상품이 할인된 가격에 제공됨을 알리고 있다. 붉은 태그가 달린 이미지는 페이지가 로딩된 뒤 5초간 깜박거린 후, 깜박임을 멈춘다.
깜박이는 모든 아이템을 찾아낸다.
각각의 깜박이는 아이템들에 대해, 깜박임의 시작부터 끝까지의 시간이 5초 이내인지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 폼 컨트롤의 값을 바꿀 경우 문맥에 어떠한 변화가 있을 것인지 정보를 주기 위한 것이다. 일반적으로 폼 컨트롤의 값을 바꾸는 것이 문맥의 변화를 초래하지는 않기 때문에, 저자들이 이러한 행동의 결과를 미리 알려주는 것이 중요하다. 가능하다면, 폼 컨트롤 자체에 그러한 변화에 대한 설명을 프로그램적으로 연관시켜 두는 것은 좋은 아이디어라 할 수 있다.
다음은 서로 다른 상황에서 이러한 설명을 제공하는 것에 대한 예제이다.
세팅을 바꿈으로서 문맥의 변화를 초래하게 되는 UI 요소보다, 웹 페이지 상에서 읽는 순서상으로 앞서게끔, 설명을 제공한다.
여러 단계로 구성된 처리에서, 사용자가 여러 단계를 끝마쳐야만 도달할 수 있는 UI 요소에 그러한 사용자의 변경으로 인해 문맥의 요소가 변경되는 점이 있다면, 그에 대한 설명을, 처리의 일부분으로서, 단계들 앞에 제공한다.
(역주 : 번역이 매우 혼란되는 점이 있음을 사과드리며, 예제 2번을 보면서 이해하시기 바란다)
설정이 변경됨으로서 문맥에 변화가 있게 되는 웹 어플리케이션의 사용 이전에 사용자의 훈련을 거치게 되는 인트라넷의 경우, 설명이 훈련의 일부로 포함된다.
페이지의 상단에 독일어, 프랑스어, 스페인어 옵션을 포함하는 몇개의 라디오 버튼들이 있다. 이러한 버튼들의 앞에는, 옵션을 선택함으로서 언어가 변경된다는 설명이 있다.
50개의 항목으로 구성되는 온라인 설문에서 한번에 하나의 질문을 표시한다. 각각의 설문의 첫머리에는, 이 질문에 대한 답변에 따라 다음 질문이 달라짐을 설명하는 설명이 보인다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
폼 컨트롤 설정의 변경이 문맥의 변화를 초래하게 될 컨텐츠를 찾는다.
컨트롤이 변경되었을 때 어떤 일이 일어날 것인지에 대한 설명이 컨트롤의 활성화 이전에 사용자에게 나타나는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
색상과 텍스트를 지원하는 모든 기술.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 색상의 차이가 정보를 전달할 목적일 경우 - 예를 들어 폼 필드에서 요구되는 것과 같은 - 그러한 색상 차이를 통해 전달되는 정보는 텍스트를 통해서도 명시적으로 전달되어야 함을 확실하게 하기 위한 것이다.
기술 회합의 스케줄 세션이 3개 트랙으로 구분되었다. 첫번째 트랙은 푸른색 배경으로 표시되어 있다. 두번째 트랙은 노란색 배경으로 표시되어 있다. 세번째 트랙은 녹색 배경으로 표시되어 있다. 각각의 세션 이름 뒤에는 트랙을 구분하는 코드가 텍스트로 표시되어 있다 : 트랙 1에 T1, 트랙 2에 T2, 트랙 3에 T3.
기술 회합의 스케줄 세션이 3개 트랙으로 구분되었다. 각 세션의 제목 뒤에는 그것이 어떤 트랙에 속하는지 보여주는 색깔이 있는 아이콘이 있다: 푸른색 아이콘은 트랙 1을, 노란색 아이콘은 트랙 2를, 녹색 아이콘은 트랙 3을 나타낸다. 각각의 아이콘은 "트랙 1", "트랙 2", "트랙 3" 으로 읽을 수 있는 대체 텍스트와 연결되어 있다.
몇개의 필수적인 필드를 포함하는 폼이 있다. 필수적인 필드의 레이블은 붉은색으로 보인다. 이에 더해, 각각의 레이블 마지막에는 * 문자가 있다. 폼의 완성에 관한 설명에는 "모든 필수적인 필드들은 붉은색으로 표시되었으며, * 마크가 있다." 라는 구절이 있고, 예제가 그 뒤에 있다.
노트: * 기호가 모든 스크린 리더기(의 모든 모드)에서 읽히지 않을 수도 있으며, 기호가 보통 텍스트보다 작게 표시되기 때문에 시력이 나쁜 사용자에게는 잘 보이지 않을 수도 있다. 저자들은 * 기호가 사용되었음을 알리는 텍스트를 포함시키고, * 기호의 크기를 늘리는 것을 고려하는 것이 중요하다.
온라인 대출 프로그램에서는 녹색 버튼이 진행, 붉은색 버튼이 취소임을 미리 설명하고 있다. 폼은 Go 라는 텍스트를 포함한 녹색 버튼을 포함하고 있다. 설명에는 "Go 라고 표기된 버튼을 눌러서 당신의 결과를 제출하고 다음 단계로 진행하시오" 라고 표기되어 있다.
이 테크닉에는 사용할 수 있는 자원이 없다.
정보를 전달하기 위해 색상의 차이를 이용하는 모든 아이템에서 :
전달될 정보가 텍스트로도 사용 가능하며, 그 텍스트가 조건적인 컨텐츠가 아닌지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
일반적인, 그리고 적색 번쩍임 한계에 대한 위반을 테스트하는 목적은, 광과민성 발작 증상을 가진 사람들이 그러한 증상을 초래할수도 있는 내용에 노출되는 일 없이 웹 사이트를 볼 수 있도록 하기 위함이다. 경고를 제공할 수 있지만 그 경고를 못보고 지나칠수도 있고, 어린이들은 그러한 경고를 읽지 못하거나, 이해하지 못할 수도 있다. 이러한 테크닉으로 모든 내용을 검사하여, 그것이 번쩍임, 혹은 적색 번쩍임 한계를 위반하였을 경우 그러한 내용을 사이트에 넣지 말거나, 한계를 위반하지 않도록 수정하여야 한다.
노트 1: 간단한 형태의 번쩍임을 검사하는 몇가지 간단한 테스트들이 있다. 예를 들어 :
내용이 초당 3회, 혹은 그 미만으로 번쩍일 경우 G19: 컨텐츠의 어떤 부분도 1초의 시간 내에 3회 이상 번쩍이지 않도록 확실히 하기 를 사용할 수 있다.
번쩍이는 내용이 화면의 한 부분에만 존재하고, 그 부분이 충분히 작다면, G176: 번쩍이는 영역을 충분히 작게 유지하기 를 사용할 수 있다.
노트 2: 그렇지 않은 모든 경우, 모든 항목들을 추적하고 그것을 연속적인 비디오로 기록하는 도구가 필요하다.
폭풍의 애니메이션이 6개의 벼락을 보여준다. 번쩍임은 대단히 빠르고 또 커서, 번쩍임 분석 도구로 테스트 해 본 결과 일반적인 번쩍임 한계를 위반하고 있었다. 애니메이션은 각각의 번쩍임 뒤에 짧은 일시정지 시간을 추가하도록 수정되었다. 그렇게 바꾼 후, 애니메이션은 일반적인 번쩍임 한계를 위반하지 않는다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
컨텐츠가 일반적인 번쩍임 그리고/또는 적색 번쩍임 한계를 위반하지 않는지 확인한다.
일반적인 번쩍임과 적색 번쩍임 한계를 모두 넘지 않는지 판단하기 위해 도구를 사용한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
시각적 출력을 생성하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자들이 배경 위에 표현된 글씨를 확실히 읽을 수 있도록 하는 것이다. 이 테크닉은 낮은 시력을 가진 사람들이 읽기 편하도록 고대비를 제공하는 4.5:1 대비 테크닉을 넘어서는 것이다.
배경이 단색(혹은 순흑색, 혹은 순백색)이라면, 각각의 글자들이 배경과 7:1의 대비를 가짐을 확실히 함으로서 텍스트의 대비를 유지할 수 있다
배경이나 글자가 다양한 상대적 광도를 갖거나, 또는 패턴이 있다면, 글자들 주변의 배경을 선택하거나 혹은 음영을 주어서 글자가 배경 전체와는 7:1의 대비를 갖지 못하더라도 그 뒤의 배경과는 7:1의 대비를 갖도록 유지할 수 있다.
때때로, 배경의 상대적 광도가 페이지 사이에서 바뀌는 것에 따라 글자의 상대적 광도를 변경함으로서 그러한 대비를 유지할 수 있다.
다른 방법으로, 배경의 이미지나 색상이 충분한 상대적 광도 차이를 가지지 못할 경우, 텍스트 주변에 빛무리를 줌으로서 필요한 대비를 제공할 수도 있다.
회사의 로고에 맞게끔 밝은색의 글자를 사용하기 위해 검은색 배경을 선택했다.
대학 캠퍼스의 사진 위에 텍스트가 배치되어 있다. 배경의 사진에 다양한 색상과 어두운 부분이 존재하기 떄문에, 텍스트 아래의 영역은 흰 안개처럼 표시함으로서 원래의 사진 영역을 대단히 흐리게 하였고, 가장 어두웠던 부분도 검은색 텍스트와 7:1의 대비를 유지할 수 있을 정도의 밝기를 갖게끔 하였다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
다음의 식을 사용하여 각 글자의 상대적 광도를 측정한다(모두가 같은 경우는 제외하고):
R, G, B가 다음과 같이 정의되었을 때 광도 L = 0.2126 * R + 0.7152 * G + 0.0722 * B
RsRGB <= 0.03928 이라면 R = RsRGB/12.92, 그렇지 않다면 R = ((RsRGB+0.055)/1.055) ^ 2.4
GsRGB <= 0.03928 이라면 G = GsRGB/12.92 그렇지 않다면 G = ((GsRGB+0.055)/1.055) ^ 2.4
BsRGB <= 0.03928 이라면 B = BsRGB/12.92 그렇지 않다면 B = ((BsRGB+0.055)/1.055) ^ 2.4
또한 RsRGB, GsRGB, and BsRGB 은 다음과 같이 정의된다:
RsRGB = R8bit/255
GsRGB = G8bit/255
BsRGB = B8bit/255
"^" 기호는 이산 제곱 연산자이다.
노트: 글자가 별칭으로 사용되었을 경우, 글자의 경계선에서부터 2개의 픽셀 사이의 상대적 광도 값을 사용한다.
같은 식을 사용하여, 글자의 바로 다음에 있는 배경 픽셀의 상대적 광도를 측정한다.
다음의 식을 사용해서 광도 대비를 계산한다.
대비가 7:1 이상인지 확인한다.
#4 를 만족한다
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
시각적 출력을 생성하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 배경 위에 표현된 글씨를 확실히 읽을 수 있도록 하는 것이다. 성공기준 1.4.3에 대해, 이 테크닉은 볼드체가 아닌 18포인트 미만의 텍스트, 또는 볼드체인 14포인트 미만의 텍스트에 대한 최소한의 대비 비율을 설명한다. 성공기준 1.4.5에 대해, 이 테크닉은 볼드체가 아닌 18포인트 미만의 텍스트, 또는 볼드체인 14포인트 미만의 텍스트에 대한 7:1의 대비 비율 요구를 경감시킨다.
배경이 단색(혹은 순흑색, 혹은 순백색)이라면, 각각의 글자들이 배경과 4.5:1의 대비를 가짐을 확실히 함으로서 텍스트의 대비를 유지할 수 있다
배경이나 글자가 다양한 상대적 광도를 갖거나, 또는 패턴이 있다면, 글자들 주변의 배경을 선택하거나 혹은 음영을 주어서 글자가 배경 전체와는 4.5:1의 대비를 갖지 못하더라도 그 뒤의 배경과는 4.5:1의 대비를 갖도록 유지할 수 있다.
때때로, 배경의 상대적 광도가 페이지 사이에서 바뀌는 것에 따라 글자의 상대적 광도를 변경함으로서 그러한 대비를 유지할 수 있다
다른 방법으로, 배경의 이미지나 색상이 충분한 상대적 광도 차이를 가지지 못할 경우, 텍스트 주변에 빛무리를 줌으로서 필요한 대비를 제공할 수도 있다.
회사의 로고에 맞게끔 밝은색의 글자를 사용하기 위해 검은색 배경을 선택했다.
대학 캠퍼스의 사진 위에 텍스트가 배치되어 있다. 배경의 사진에 다양한 색상과 어두운 부분이 존재하기 떄문에, 텍스트 아래의 영역은 흰 안개처럼 표시함으로서 원래의 사진 영역을 대단히 흐리게 하였고, 가장 어두웠던 부분도 검은색 텍스트와 4.5:1의 대비를 유지할 수 있을 정도의 밝기를 갖게끔 하였다.
연결된 자원들의 대비 샘플들 역시 보기 바란다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
(현재 목록화된 것이 없다)
다음의 식을 사용하여 각 글자의 상대적 광도를 측정한다(모두가 같은 경우는 제외하고):
R, G, B가 다음과 같이 정의되었을 때 광도 L = 0.2126 * R + 0.7152 * G + 0.0722 * B
RsRGB <= 0.03928 이라면 R = RsRGB/12.92, 그렇지 않다면 R = ((RsRGB+0.055)/1.055) ^ 2.4
GsRGB <= 0.03928 이라면 G = GsRGB/12.92 그렇지 않다면 G = ((GsRGB+0.055)/1.055) ^ 2.4
BsRGB <= 0.03928 이라면 B = BsRGB/12.92 그렇지 않다면 B = ((BsRGB+0.055)/1.055) ^ 2.4
또한 RsRGB, GsRGB, and BsRGB 은 다음과 같이 정의된다:
RsRGB = R8bit/255
GsRGB = G8bit/255
BsRGB = B8bit/255
"^" 기호는 이산 제곱 연산자이다.
노트: 글자가 별칭으로 사용되었을 경우, 글자의 경계선에서부터 2개의 픽셀 사이의 상대적 광도 값을 사용한다.
같은 식을 사용하여, 글자의 바로 다음에 있는 배경 픽셀의 상대적 광도를 측정한다.
다음의 식을 사용해서 광도 대비를 계산한다.
대비가 4.5:1 이상인지 확인한다.
#4 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은, 번쩍임이 지나치게 크고 밝을 경우 특정 질환을 초래할 수 있는 것으로 알려진 속도에서의 번쩍임을 막는 것이다. 일부 사용자는 화면 확대기를 사용할수도 있으므로, 이 테크닉은 컨텐츠의 크기에 관계 없이, 1초에 3회 이상의 번쩍임이 생기지 않도록 제한한다.
노트 1: 이 테크닉은 레벨 1 성공기준보다 엄격하지만 더 테스트하기 쉽고, 또한 레벨 1 성공기준을 만족하는지 테스트하는 용도로도 사용할 수 있는데, 왜냐하면 레벨 1 성공기준에서는 모든 한계값들이 초당 3.5회로 설정되어 있기 때문이다. 대부분의 컨텐츠에는 번쩍임이 없고, 심지어는 깜박거리는 컨텐츠들조차 이정도의 속도를 갖는 경우는 드물다. 따라서, 성공 기준에 명시된 더 복잡한 테스트를 수행해야만 하는 상황을 피하기 위해, 컨텐츠가 1초의 단위시간 동안 한번, 두번, 혹은 최대한 세번 번쩍이는 것을 확실히 함으로서 이 테크닉을 따라올 수 있다.
노트 2: 3.5회의 번쩍임에 관해 : 밝음에서 어두움으로, 혹은 어두움에서 밝음으로 7번의 전환이 있다면, 그것은 3.5회의 번쩍임이고, 허용되는 3회의 번쩍임(6번의 전환)보다 많은 것이다.
3.5회의 번쩍임, 또는 7번의 전환의 예:
(시작하는) 어두움-밝음-어두움-밝음-어두움-밝음-어두움-밝음 또는
(시작하는) 밝음-어두움-밝음-어두움-밝음-어두움-밝음-어두움.
컨텐츠가 벼락의 번쩍임을 포함하고 있다. 컨텐츠는 벼락이 2회, 혹은 3회만 번쩍이도록 디자인되었다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
1초의 단위시간 동안 3회를 초과하는 번쩍임이 없는 것을 확인한다.
3회의 번쩍임이 있다면, 마지막의 밝음/어두움 상태가 시작의 그것과 같은지 확인한다.
1단계와 2단계를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
상호작용의 동작을 지원하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은, 사용자들이 컨텐츠의 부분집합에 갇혀서, 마우스나 기타 포인팅 디바이스를 사용해야만 빠져나올 수 있는 상황에 처하지 않도록 만드는 것이다. 이것의 흔한 예는, 플러그인에 의해 렌더링된 컨텐츠이다. 플러그인이란, 사용자 에이전트의 호스트 윈도우 안에서 컨텐츠를 렌더링하고, 플러그인이 포커스를 갖고 있는 동안 모든 사용자 행동에 반응하는 사용자 에이전트이다. 만약 플러그인이 포커스를 부모 윈도우에게 반환하는 메커니즘을 갖고 있지 않다면, 키보드를 사용해야만 하는 사용자들은 그러한 플러그인의 컨텐츠 안에 갇힐 가능성이 있다.
이런 문제는, 다음에서 제시하는 메커니즘 - 사용자가 컨텐츠의 부분집합에서 빠져나올 방법을 제공하는 - 중 하나를 사용함으로서 피할 수 있다:
컨텐츠 내부에서 포커스를 전진시키는 키보드 기능(일반적으로 탭 키)가, 컨텐츠의 부분집합의 마지막 내비게이션 위치에 도달했을 때 그 부분집합을 빠져나오도록 확실히 한다.
포커스를 컨텐츠의 부분집합 밖으로 옮길 수 있는 키보드 기능을 제공한다. 부분집합 내부에, 그러한 기능을 접근성 있는 방법으로 문서화하여 제공한다.
부분집합 내부에서 사용된 기술이 "부모로 이동하는" 키보드 명령어를 네이티브하게 제공하고 있다면, 그러한 명령어를 사용자가 플러그인에 진입하기 전에 알려서 플러그인 밖으로 다시 나가는 방법을 인식하도록 한다.
사용자가 키보드를 이용해서 서브 컨텐츠로 진입할수는 있지만, 그 서브컨텐츠에서 기본값만으로 키보드를 이용해서 빠져나올수는 없는 기술(예를 든다면, 그것은 웹 컨텐츠 기술이거나 그 사용자 에이전트의 기능이 아닐 수 있다)을 저자가 사용하고 있다면, 이 테크닉을 구현하기 위해서 저자는 그러한 기능을 직접 만들어 넣거나, 아니면 그 기술을 사용하지 않아야 한다.
사용자가 탭 키를 사용해서 애플릿 내부로 진입하면, 그 이후에 눌러지는 탭 키들은 애플릿에 의해 다루어지며, 사용자가 탭을 사용해 애플릿 외부로 이동하는 것을 방지하게 된다. 하지만, 애플릿은 사용자가 자신 내부의 탭 순서상 마지막까지 도달하였을 때 키보드 포커스를 부모 윈도우로 반환하도록 디자인되었다.
웹 페이지에 접근성을 지원하지 않는 컨텐츠가 포함되어 있지만, 그 컨텐츠는 키보드를 사용해서 접근성을 지원하는 영역으로 포커스를 되돌리는 방법을 설명하고 있다. 이 설명은 접근성을 지원하지 않는 컨텐츠보다 앞서서 배치되어 있다.
접근성을 지원하지 않는 컨텐츠에서 도움말 정보를 제공하고 있는데, 이 도움말에는 키보드를 사용해서 접근성을 지원하는 컨텐츠로 포커스를 되돌리는 방법을 설명하고 있으며, 도움말 정보 자체는 키보드를 사용해서 접근할 수 있다.
웹 페이지에서 제공되는 도움말 정보에, 키보드를 사용해서 접근성을 지원하지 않는 컨텐츠로부터 지원하는 컨텐츠로 포커스를 이동하는 방법을 문서화하고 있다. 또한 이 도움말 정보를 키보드를 사용해 접근할 수 있다.
이 테크닉에 연관된 자원이 없다.
(현재 목록화된 것이 없다)
컨텐츠의 처음부터 끝까지 탭으로 이동해본다.
키보드 포커스가 함정에 빠져서, 사용자가 거기에서 빠져나와 컨텐츠의 다른 부분들로 이동을 계속할 수 없도록 되는 곳이 있는지 확인한다.
#2 에 해당하는 경우가 없다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
JAWS 5.0과 그 이후는 다음의 키 입력을 포함한다:
alt+왼쪽 화살표: 앞 문장을 읽는다.
alt+오른쪽 화살표: 다음 문장을 읽는다.
alt+숫자패드 5: 현재 문장을 읽는다.
Ctrl+숫자패드 5: 현재 문단을 읽는다.
Window-Eyes 5.5 는 현재 문장과 현재 문단을 읽는 핫키를 지원한다.
WindowEyes 를 사용해서 인터넷 서핑을 하려면 브라우즈 모드로 해야 한다. 현재 문장과 현재 문단에 해당하는 핫키는 버전 6.1에서는 브라우즈 모드에서 동작하지 않고 있다.
공장 초기값에서 주변의 링크 문맥을 읽어주는 설정은 다음과 같다:
데스크탑에서:
글자 = CTRL-숫자패드-왼쪽 화살표
단어 = CTRL-숫자패드-오른쪽 화살표
줄 = CTRL-숫자패드-중앙
문장 = 브라우즈 모드에서 사용 불가
(다음 문장을 읽는 명령어는 데스크탑 기본값에서 설정되어 있지 않지만, 다음 줄은 아래쪽 화살표이다.)
다음 문단 = P
앞 문단 = Shift P
현재 문단 = 브라우즈 모드에서 사용 불가
랩탑
글자 = ALT-SHIFT-<
단어 앞 = ALT-SHIFT-J
단어 = ALT-SHIFT-K
단어 다음 = ALT-SHIFT-L
문장 앞 = ALT-SHIFT-7
문장 = 브라우즈 모드에서 사용 불가
문장 다음 = 브라우즈 모드에서 사용 불가
문단 = 랩탑 기본값에서 정의되지 않음
줄 앞 = ALT-SHIFT-U
줄 = ALT-SHIFT-I
줄 다음 = ALT-SHIFT-O
이 테크닉의 목적은, 링크와, 그 문장의 문맥을 가지고 링크의 목적을 식별하도록 하는 것이다. 링크를 감싸고 있는 문장은, 그러한 문장이 없었다면 불명확했을 링크에 문맥을 제공한다. 설명은 사용자로 하여금 이 링크를 페이지의 다른 링크들 - 다른 목적지로 향하게 하는 - 가운데에서 구별하도록 하고, 또한 사용자가 그 링크를 따라갈지 결정하는데 도움을 준다. 단순히 목적지의 URI를 제공하는 것은 일반적으로 충분한 설명이 되지 못함을 유의하라.
노트: 이러한 설명이 가장 유용하려면 링크를 이해하는데 필요한 추가적인 정보가 링크보다 앞서서 나타나야 한다. 추가적인 정보가 링크보다 뒤에 있다면, 스크린 리더 사용자들은 페이지를 순서대로(위에서 아래로) 읽고 있기 때문에 혼란스러움과 어려움을 느낄 수 있다.
웹 페이지에 "이 페이지에 광고하려면 여기를 클릭하시오." 라는 문장이 포함되어 있다.
링크 구문인 '여기를 클릭하시오' 라는 것 만으로는 링크를 이해하기에 충분하지 못하지만, 정보는 링크와 같은 문장에서, 링크보다 앞서서 제공되고 있다.
웹 페이지에 "미국으로의 첫번째 이주민들은 메이플라워 호를 타고 왔다." 라는 문장이 있다.
뉴스 요약에 이러한 문장이 포함되어 있다 : "The Smallville Times의 보도 내용은 교육 위원회에서 8월 27일부터 시작하는 2007년도 학교 달력을 채택했다고 한다.", "보도 내용" 이라는 단어는 교육위원회 회합에 대한 Smallville Times의 기사에 대한 링크이다.
노트: 비록 이 예제가 성공 기준을 만족하기는 하지만, 링크를 이해하는데 필요한 정보를 링크 이후에 배치하는 것은 스크린 리더를 가지고 문서를 읽는 사람들에게 불편을 끼친다.
이 테크닉에 연관된 자원이 없다.
컨텐츠 안의 각각의 링크들이 이 테크닉을 사용하는지 확인한다.
링크가 문장의 일부인지 확인한다.
링크의 텍스트가, 그것을 감싸고 있는 문장의 텍스트와 결합하여 그 링크의 목적을 설명하고 있는지 확인한다.
위의 확인결과가 모두 참이다..
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
동기화된 미디어 정보를 표현하는 모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 들을 수 없거나, 텍스트를 빠르게 읽을 수 없는 사람들이 동기화된 미디어에 접근할 수 있도록 하는 것이다.
일차적인 의사소통을 수화를 통해서 하는 사람들에게, 자막이 진행하는 속도에서 그것을 읽고 이해하는 것은 이따금씩은 꺼려지고, 또한 이따금씩은 불가능한 일이다. 이러한 사람들에게는 오디오 정보를 수화로 표현하여 제공하는 것이 중요하다.
이것을 가장 호환성있게 하는 방법은, 수화 통역자의 비디오를 비디오 스트림에 포함시키는 것이다. 이렇게 하였을 경우의 단점은, 이미지 전체를 확대하지 않고서는 쉽사리 확대하기 어려운 저해상도 이미지를 제공하게 된다는 것이다.
노트 1: 비디오 스트림이 너무 작다면, 수화 통역을 알아볼 수 없게 될 것이다. 수화 통역의 비디오를 포함하는 비디오 스트림을 만들때는, 접근성을 지원하는 컨텐츠 기술을 가지고 비디오 스트림을 풀스크린으로 보여줄 수 있는 메커니즘이 확실히 존재하도록 해야 한다. 그렇지 않다면, 비디오 스트림이 풀 스크린 크기였을때 수화 비디오가 차지했을만한 크기로 그것(수화 비디오)의 크기를 조정할 수 있도록 해야 한다.
노트 2: 일반적으로 수화는 프린트된 언어를 수화로 표현한 것과는 다르기 때문에, 저자는 어떠한 내용을 수화로 포함시킬것인지 결정해야 한다. 보통, 일차적인 청중의 수화 언어가 사용될 것이다. 다국어 버전으로 의도되었다면, 다양한 수화를 사용할수도 있다. 다양한 수화 언어를 사용하는 것에 관해 조언적 기술들을 참조하라.
예제 1: 텔레비전 방송국에서 온라인 뉴스 비디오에 수화 번역을 한쪽 코너에 제공한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
수화 도서 출판 가이드라인
"수화 표현"수화 언어 번역을 필름으로 제작할 때 고려해야 할 이슈들에 대한 광범위한 개요를 제공한다. 인쇄된 것을 원본으로 하는 경우와, 말해진 것을 원본으로 하는 경우 모두를 다루고 있다.
필름으로 제작하는 기술에 대한 것들이12장, “수화 촬영"에서 다루어지고 있다.
동기화된 원본 미디어 컨텐츠와 연계하여 수화 통역을 어떻게 디스플레이할것인지에 대한 유용한 정보들이 13 장, "편집"에서 다루어지고 있다.
노트: 이러한 테크닉들이 웹에 기반하는 프리젠테이션에 접목될수도 있을 것이다.
청각에 문제가 없고, 수화에 익숙한 사람이 프로그램을 지켜보도록 한다.
화면에 수화 통역이 나타나는지 확인한다.
대화와, 중요한 소리들이 통역자를 거쳐서 화면에 전달되는지 확인한다.
#2 와 #3 을 만족한다
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 단어, 구절, 혹은 약어들에 대해 같은 웹 페이지, 혹은 다른 웹 페이지에서 정의를 제공하고, 둘 사이에 링크를 연결하는 것이다.
링크들은 단어, 구절, 약어의 정의에 접근하는 강력한 수단이다. 사용자는 링크를 통해 정의를 빠르고 쉽게 찾을 수 있으며, 사용자 에이전트의 뒤로 가기 버튼을 이용해 컨텐츠로 다시 돌아올 수 있다.
스포츠 부상에 대한 글에 등장하는 기술적인 단어들과 약어들에, 의학 사전 상의 정의에 대한 링크가 걸려 있다.
텍스트북에서, 각 장마다 새롭게 등장하는 단어들에 대한 용어집을 포함하고 있다. 그러한 단어들이 처음 등장할 때 마다, 용어집에 실려 있는 단어의 정의에 대한 링크가 제공된다.
약어들에 대한 일반적인 용어집이 제공된다. 약어가 사용될 때 마다, 용어집에 있는 적합한 정의로 바로 연결되는 링크가 걸려 있다.
jargon 이라는 단어에 대해, WCAG2 용어집에 실려 있는 정의로 가는 링크가 걸려 있다.
"modulo" 라는 단어는 수학에 관한 웹 컨텐츠에서 사용되는 전문 용어이다. 그것의 정의가 웹 페이지 내에 포함되어 있다. modulo 라는 단어들은 모두 그 정의에 대한 링크를 갖고 있다.
일본어 숙어가 그 정의로 링크되어 있다. 이 예제는 관용적 표현의 정의를 가리키는 페이지 상의 링크를 이용한다.
예제 코드:
<p>....<a href="#definition">さじを投げる</a>....</p>
<h3>脚注：</h3>
<dl>
<dt id="definition" name="definition">さじを投げる</dt>
<dd>どうすることもできなくなり、あきらめること。</dd>
</dl>
이 테크닉에 연관된 자원이 없다.
정의되어야 할 각각의 단어, 구절, 약어들에 대해:
그러한 것들 중 적어도 첫번째 나타나는 것이 링크인지 확인한다.
각각의 링크가 그것의 정의를 가리키는지 확인한다.
#1 과 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 청각에 문제가 있는 사람들이 대사를 이해하는데 큰 어려움이 없도록 배경 소리를 포함시키는 것이다. 전경의 대사가 배경 소리보다 20데시벨 이상 크도록 하면, 대사는 배경 소리보다 4배 크게 된다. 데시벨(dB)에 대한 정보를 보려면, 데시벨에 관해 를 참조하라.
나레이터가 폭동 장면을 설명하고 있다. 폭동 장면의 볼륨은 아나운서의 볼륨과 믹스되기 전에 그보다 20데시벨 만큼 낮도록 조절되었다.
이 예제는 배경음악과 함께 나오는 음성을 묘사한다. 음성은 배경음악보다 20데시벨이 적절하게 높다. 음성(전경)은 -17.52데시벨(평균적 RMS)에서 녹음되었고, 음악(배경)은 -37.52에서 녹음되었으므로 전경이 배경보다 20데시벨 높다.
오디오 예제: 전경이 배경보다 20데시벨 높다 (mp3)
오디오 예제의 전사물 (좋은 대비):
"일반적으로 전경이란 현재 말하여지고 있는 목소리를 말하며 반드시 이해되어야 한다. 내가 지금 말하는 목소리는 배경의 음악보다 20데시벨이 높다. 이것은 어떻게 해야 하는지에 대한 예제이다.."
위의 오디오 예제는 오디오 편집기 파일의 스냅샷을 통해 시각적으로 표현되었다. 전경과 배경을 포함하고 있는 섹션 하나가 강조되어 있다. 배경만을 포함하고 있는 섹션에 비해 훨씬 큰 파형이 그려져 있다.
이 예제는 음성이 배경보다 20데시빌 이상 높지 않은 경우를 보여준다. 음성(전경)은 -18데시벨로 녹음되었고, 음악(배경)은 약 -16 데시벨로 녹음되어서, 전경이 배경보다 2데시벨밖에 높지 않다.
오디오 예제 : 전경이 배경보다 20데시벨 이상 높지 않다(mp3)
오디오 예제의 전사물 (나쁜 대비):
"이것은 배경에 비해 충분히 크지 않은 음성의 예제이다. 전경인 음성은 배경보다 겨우 2데시벨 가량 높다. 따라서 난청이 있는 사람에게는 이해하기가 어려울 것이다. 하나의 단어를 다른 단어와 구별하기도 쉽지 않다. 이것은 하면 안되는 것의 예제이다."
강조된 섹션은 전경과 배경을 포함한다. 파형은 배경만을 포함하고 있는 섹션과 거의 같은데, 이것은 전경의 음성에 비해 본다면 배경이 너무 크게 녹음되었음을 의미한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
데시벨에 관하여 Gregg Vanderheiden
전경의 음성 사이에서 배경이 큰 부분을 찾아낸다.
볼륨을 dB(A) SPL 단위로 측정한다.
전경 음성의 볼륨을 dB(A) SPL 단위로 측정한다.
값을 뺀다.
결과가 20, 혹은 그보다 큰지 확인한다.
#5 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 컨텐츠가 보조 기술에 표현될 때, 사용자가 그 순서를 보고 컨텐츠에 대해 파악할 수 있도록 하는 것이다. 어떤 기술은, 기반된 컨텐츠의 순서가 혼란스러운 경우에도 컨텐츠가 시각적으로는 의미있는 순서로 렌더링되도록 허용한다.
예를 들어, HTML에서 서로 다른 방향성을 갖는 언어들을 혼용하는 경우, 양방향 알고리즘은 구두점들을 잘못된 위치에 놓을 수도 있다. 정확한 순서를 가진 컨텐츠는 렌더링 기본값이 그러한 구두점들을 컨텐츠 흐름 내에서 제대로 표현하도록 옮기는 것이 아니라, 그러한 구두점들을 컨텐츠의 흐름 내에서 올바른 순서로 관리하고, 양뱡향 알고리즘을 덮어쓰는 마크업을 사용한다.
시각적으로 렌더링되었을 때, 스페이스나 탭과 같은 공백문자들은 컨텐츠의 일부로 보이지 않을 수 있다. 하지만 시각적 포맷을 조절하기 위해 컨텐츠에 삽입되었을 경우, 그러한 공백문자들은 컨텐츠의 의미에 관여할 수 있다.
성기게 말해서, HTML 문서에서 테이블 레이아웃을 이용하여 컨텐츠 블럭들의 위치를 조절하는 것은, 눈으로 볼 때는 관계된 정보들이 근접하게 위치한 것 처럼 보일지는 몰라도, 컨텐츠의 흐름에서는 분리되는 결과를 낳는다. 레이아웃 테이블이 행 단위로 읽히므로, 일러스트레이션의 캡션이 일러스트레이션 다음 행에 위치해 있다면, 그 캡션을 이미지와 연결하는 것이 불가능해질수도 있다.
박물관 전람회의 웹 페이지에 많은 링크들이 포함된 내비게이션 바가 있다. 이 페이지는 또한 전람회에 출품된 그림 한 점과 그 제목, 그리고 그림에 대한 자세한 설명을 포함하고 있다. 내비게이션 바에 들어 있는 링크들은 의미 있는 순서를 구성하고 있다. 제목, 그림, 설명 텍스트들 또한 의미있는 순서를 형성하고 있다. 이러한 요소들을 페이지에 배치하는 방법으로 CSS를 사용하고 있다.
예제 코드:
Markup:
<h1>내 박물관 페이지</h1>
<ul id="nav">
<li><a href="#">Link 1</a></li>
...
<li><a href="#">Link 10</a></li>
</ul>
<div id="description">
<h2>모나리자</h2>
<p>
<img src="img.png" alt="Mona Lisa">
</p>
<p>...그림에 대한 자세한 설명...</p>
</div>
CSS:
ul#nav
{
float: left;
width: 9em;
list-style-type: none;
margin: 0;
padding: 0.5em;
color: #fff;
background-color: #063;
}
ul#nav a
{
display: block;
width: 100%;
text-decoration: none;
color: #fff;
background-color: #063;
}
div#description
{
margin-left: 11em;
}
이 테크닉에 연관된 자원이 없다.
그 기술에 맞는 표준 접근법을 이용해 컨텐츠를 선형화한다 (예를 들어 레이아웃 스타일들을 없애거나 선형화 도구를 사용해서)
컨텐츠의 순서가 원래의 것과 같은 의미를 전달하는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
이 테크닉은 특정 기술에 묶이는 것이 아니며 링크를 지원하는 모든 기술에서 사용될 수 있다.
이 테크닉은 다음과 연관된다:
이 테크닉을 통해, 캡션이나 오디오 설명을 묶어놓은 문서에 대한 링크를 제공할 수 있다. 그러한 묶음 문서는 같은 웹 페이지의 다른 위치, 혹은 다른 URI에 있을 수 있다. 그러한 문서에 대한 링크는 텍스트가 아닌 컨텐츠에 바로 인접하게 배치된다. 링크는 동기화된 미디어 컨텐츠의 바로 앞, 혹은 바로 뒤에 있을 수 있다. 만약 그러한 문서가 같은 웹 페이지에 다른 컨텐츠로서 존재한다면, "문서의 마지막" 이라는 문구를 마지막에 놓음으로서 사용자가 읽기를 마치고 전의 위치로 돌아가야 함을 알게 하라. 만약 "돌아가기" 버튼이 사용자를 링크를 누르기 전의 위치로 돌려 놓지 못한다면, 텍스트가 아닌 컨텐츠로 돌아가게 하는 링크가 제공된다.
"Olympic_Sports.htm" 이라는 페이지 위의 마크업
예제 코드:
<a name="Olympic_Wrestling"></a>
<p><a href="http://www.example.com/movies/olympic_wrestling.mov">올림픽 레슬링 동영상</a>,
<a href="http://www.example.com/transcripts/olympic_wrestling_transcript.htm>올림픽 동영상 자막 모음</a></p>
olympic_wrestling_transcript.htm 페이지의 마크업
예제 코드:
<p>스포츠 아나운서 1: 오늘밤, 잉글랜드의 "Will Johnson" 과 아르헨티나의 "Theodore Derringo" 선수 사이에 대단한 경기가 있을 것입니다.</p>
<p>배경: 500명의 관중들이 서있는 경기장 한가운데에 매트가 설치되어 있다...</p>
<p> ...대화들 ...<p>
<p> ...배경들 ...</p>
<p> ...기타...</p>
<p>스포츠 아나운서 2: 오늘밤은 이것으로 끝입니다. Will Johnson이 금메달을 땄군요. 함께해주셔서 감사합니다.
<a href="../movies/Olympic_Sports.htm#Olympic_Wrestling>동영상 페이지로 돌아가기</a> </p>
이 테크닉에 연관된 자원이 없다.
텍스트가 아닌 컨텐츠의 바로 앞이나 혹은 뒤에 링크가 있는지 확인한다.
(캡션이나 대체 자원의)묶음 문서에서 이 동기화된 미디어에 해당하는 부분을 가리키는 유효한 링크인지 확인한다.
동기화된 미디어 컨텐츠의 원래 위치로 사용자를 돌려 놓을 뒤로가기 버튼, 또는 링크가 잘 작동하는지 확인한다.
#1부터 3을 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
인터랙티브한 요소들과, 그러한 요소들에 대해 기본적인 탭 순서를 정의하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 인터랙티브한 요소들이 컨텐츠 내에서의 순서와 관계에 맞는 순서로 포커스를 받을 것임을 확실히 하는 것이다. 컨텐츠를 디자인할 떄에는, 링크나 폼 컨트롤 같은 인터랙티브한 요소들이 기본적인 탭 순서를 따라갔을때 컨텐츠 내에서의 순서와 관계에 걸맞게 위치하도록 배치된다. 개개의 기술들이 각자 자신의 기본적 탭 순서를 정의하므로, 컨텐츠에 컨트롤들을 배치하는 메커니즘은 어떤 기술을 사용할지에 따라 달라지게 될 것이다.
예를 들어, HTML의 경우, 기본적인 포커스 순서는 요소들이 컨텐츠 소스에서 나타나는 순서를 따른다. HTML 소스의 순서가 웹 페이지 상에서의 시각적인 순서와 일치한다면, 탭을 눌러서 컨텐츠를 순회하는 것은 컨텐츠의 시각적 레이아웃을 따라가게 된다. 소스 순서가 시각적 순서와 일치하지 않는다면, 컨텐츠를 따라가는 탭 순서는 시각적으로 표시된 컨텐츠 사이의 논리적 관계를 반영해야 한다.
두개의 텍스트 입력 필드를 포함하는 폼이 있다. 필드들은 순서대로 채워져야 한다. 첫번째 텍스트 필드는 컨텐츠에서 처음에 배치되어 있고, 두번째 필드는 두번째에 배치되어 있다.
두개의, 나란히 배치된 정보 섹션을 포함하는 폼이 있다. 하나의 섹션은 지원자에 관한 정보를 담고 있고, 다른 섹션은 지원자의 배우자에 관한 정보를 담고 있다. 지원자 섹션의 모든 인터랙티브 요소들은, 배우자 섹션의 요소가 포커스를 받기 전에 포커스를 받게 된다. 각각의 섹션의 요소들은, 그 섹션을 읽는 순서에 따라 배치되어 있다.
이 테크닉에 연관된 자원이 없다.
컨텐츠 내에 있는 인터랙티브한 요소들의 순서를 파악한다.
인터랙티브한 요소들의 논리적인 순서를 파악한다.
인터랙티브한 요소들의 순서가 논리적인 순서와 같은지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
음성 상호작용에 대한 것을 제외한 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은, 스크린 리더 사용자들이 페이지에서 재생되는 사운드 때문에 방해받지 않도록 웹 페이지에서 사운드를 재생하도록 하는 것이다. 또한, 저자들이 웹 페이지에 사운드를 조절하는 컨트롤을 넣지 않아도 되도록 하며, 스크린 리더 사용자들이 컨트롤을 찾을 수 없게 되는 문제(스크린 리더로부터 들을 수 없는 경우)를 방지해준다.
테크닉은 간단한다. 사운든 3초, 혹은 그 미만으로 재생된 후 자동으로 멈춘다.
예제 1: 웹 페이지가 트럼펫 팡파레와 함께 열리고 조용해진다.
예제 2: 홈페이지가 열릴 때 사장의 음성으로 "Binfor, 품질이 우리의 비지니스입니다." 라는 소리가 난 후 조용해진다.
예제 3: 웹 페이지가 진행하는 방법을 음성으로 안내하면서 열린다. "시작하려면, 엔터 키를 누르십시오."
예제 4: 웹 페이지가 경고와 함께 열린 후, 조용해진다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
(없음)
페이지를 로드한다.
자동으로 재생되는 모든 소리가 3초 미만의 시간 내에 멈추는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 연속된 컨텐츠를 좀 더 예측하기 쉽도록 배치함으로서, 컨텐츠가 좀 더 쉬워지게 만드는 것이다. 페이지들 사이에서 반복적으로 나타나는 유닛들이 같은 상대적 순서를 갖도록 하면, 그러한 것들에서 일관성있는 레이아웃이나 표현을 할 수 있다. 다른 컴포넌트들이 그것들 사이에 삽입될 수 있지만, 그것들 사이의 상대적인 순서는 변하지 않는다.
이 테크닉은 또한 반복되는 내비게이션 컴포넌츠에도 적용된다. 웹 페이지는 보통 내비게이션 메뉴, 또는 사용자가 다른 웹 페이지로 이동할 수 있게 하는 다른 내비게이션 수단을 포함한다. 이 테크닉은 그러한 내비게이션 컴포넌트가 반복될 때 마다 그 안의 링크, 혹은 프로그램된 참조들이 동일한 상대적 순서로 나타나도록 함으로서 내비게이션 컴포넌트들의 배치가 좀 더 예측하기 쉽도록 한다. 다른 링크들은 이미 존재하는 것들 사이에 삽입되거나 배치될 수 있다. 예를 들어 웹 페이지들의 집합의 서브섹션에 내비게이션을 허용해도 상대적인 순서가 변하지는 않는다.
웹 사이트에서 로고, 타이틀, 검색 폼, 그리고 내비게이션 바가 각각의 페이지 상단에 배치되어 있다. 이것들은 각각의 페이지에서 반복될 때 마다 동일한 상대적인 순서를 갖는다. 어떤 페이지에서는 검색 폼이 없는 경우도 있는데, 그렇다 해도 다른것들은 여전히 같은 순서이다.
사이트의 왼편에 내비게이션 메뉴가 있고, 그 메뉴에는 사이트의 주요 섹션을 가리키는 링크들이 있다. 사용자가 링크를 통해 사이트의 다른 섹션을 방문할 경우, 방문한 페이지에도 마찬가지의 상대적인 순서를 가진, 사이트의 주요 섹션들을 가리키는 링크들이 나타난다. 이따금씩 어떤 링크가 없기도 하고 추가되기도 하지만, 다른 링크들은 항상 같은 상대적 순서를 갖고 있다. 예를 들어, 상품을 판매하고 훈련을 제공하는 회사의 사이트에서, 사용자가 훈련 섹션에서 상품 섹션으로 이동할 경우, 각각의 상품들에 대한 링크가 내비게이션 목록에서 사라지고, 대신 훈련과정들에 대한 링크들이 추가된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
웹 페이지의 집합에서, 각각의 웹 페이지들에서 반복되는 컴포넌트들을 나열한다(예를 들어, 웹 사이트의 각각의 페이지에서).
각각의 컴포넌트에 대해, 그것이 나타나는 각각의 웹 페이지에서, 반복되는 다른 컴포넌트들과 동일한 상대적 순서를 갖는지 확인한다.
각각의 내비게이션 컴포넌트에서, 링크들, 혹은 프로그램된 참조들이 항상 같은 상대적 순서를 갖는지 확인한다.
#2 를 만족한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 단어, 구절, 혹은 약어의 정의를 용어집에서 제공함으로서 정의하는 것이다. 용어집은 단어, 구절, 약어들과 그 정의를 알파벳 순으로 나욜한 목록이다. 용어집은 특정한 훈련과정, 혹은 기술 영역에 관련된 컨텐츠에서 사용되는 단어, 구절, 약어들에서 가장 적절하다. 용어집은 또한 단어나 구절의 발음 역시 제공할 수 있다.
용어집은 웹 페이지의 마지막에 포함되거나, 웹 페이지의 집합 안에 있는 컨텐츠를 가리키는 메커니즘들 중 하나를 통해서 가리킬 수 있다. (성공기준 2.4.5 에 대한 이해를 보라.)
용어집이 동일한 단어, 숙어, 약어에 대해 여러개의 정의를 포함하고 있다면, 단순히 그러한 용어집을 제공하는 것 만으로는 이 성공 기준을 만족하기에 충분하지 않다. 그러한 경우 정확한 정의를 찾아내는 다른 테크닉이 사용되어야 한다. 단어, 구절, 약어의 사용이 그 페이지에서 유일하지 않은 경우 - 즉, 그러한 것이 여기에서는 이런 뜻, 저기에서는 저런 뜻으로 사용되는 경우 - 에 이것은 특히 중요하다.
온라인 대화 포럼의 사용자들이 타이핑을 신속하게 하기 위해 몇가지의 약어, 두문자어를 만들어내었다. 예를 들어, LOL은 "크게 웃는다" 이고, FWIM은 "가치있는 것을 위해" 라는 뜻이다. 사이트에서는 종종 사용되는 약어와 두문자어들에 대해 그것을 풀어 쓴 약어집 페이지를 제공하고 있다.
수학 이론을 다루는 웹 페이지에서 자주 사용되는 수학적 단어, 약어, 두문자어들에 대한 용어집을 제공하고 있다.
교과서에서는 각 챕터마다 처음으로 등장하는 단어에 대한 용어집을 포함하고 있다.
'Hij ging met de kippen op stok' (그는 나가서 닭들 옆에서 잤다) 라는 구절이 포함된 네덜란드어가 있다. 용어집에서는 이 구절이 'Hij ging vroeg naar bed' (그는 일찍 잠자리에 들었다) 라는 뜻임을 설명하고 있다.
미국 소설 "허클베리 핀의 모험"에는 1840년대 미국 남서부에서 사용되었던 숙어적인 표현들이 많이 사용되고 있다. 학생들을 위해 제작된 온라인 판에서는, 각각의 숙어적인 표현들이 용어집에 링크되어 있다.
이 테크닉에 연관된 자원이 없다.
다음 중 하나에 해당하는지 확인한다 :
용어집이 페이지에 포함되어 있거나, 또는
용어집에 접근할 수 있는 다른 메커니즘이 제공된다.
각각의 단어, 구절, 약어들이 그 정의대로 용어집에서 정의되어 있는지 확인한다.
용어집이 각각의 것들에 대해 하나의 정의만을 포함하고 있는지 확인한다.
세가지를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
노트 : WCAG에서 "약어" 의 정의는 다음과 같다 : "단어, 구절, 혹은 이름의 축약된 형태이며, 그 원래의 표현이 참조하는 기관에 의해 제거되지 않은 상태이며, 약어가 아직 언어의 일부가 되지 않은 상태인 경우"
모든 기술
이 테크닉은 다음과 연관된다:
이것은 성공기준 2.4.5를 충분히 만족하는 컨텐츠의 위치를 찾아내는 여러 테크닉 중 하나이다. 사이트맵이란 사이트의 다양한 섹션으로의 링크를 제공하는 웹 페이지이다. 사이트 내부에서 사이트맵을 사용 가능하게 하기 위한 최소한의 조건은, 사이트맵에 포함된 모든 페이지들이 사이트맵에 링크를 갖고 있는 것이다.
사이트맵은 다양한 목적들을 수행한다.
사이트 전체에 대한 개요를 제공한다.
사이트가 어떠한 것을 포함하고 있고, 그러한 컨텐츠들이 어떻게 조직화되어있는지 사용자가 이해하는 것을 돕는다.
사이트의 다양한 부분에서 서로 다르게 나타날 수 있는 내비게이션 바 들의 복잡함을 경감하는 대체수단을 제공한다.
사이트맵의 다른 형태들도 있다. 가장 간단하면서 가장 많이 쓰이는 사이트맵의 형태는, 각각의 섹션 또는 서브사이트를 가리키는 링크들을 보여주는 사이트의 아웃라인이다. 그러한 아웃라인은 사이트 내부에서의 더 복잡한 관계들 - 사이트의 서로 다른 섹션들에서 페이지 사이의 링크들 같은 - 을 보여주지는 않는다. 일부 대형 사이트들은 사이트맵에 확장 가능한 헤딩을 사용하고, 그러한 헤딩에서 각각의 섹션들에 대한 추가적인 자세한 정보들을 보여주고 있다.
사이트맵은 사이트의 컨텐츠와 구조를 설명한다. 사이트가 업데이트될때마다 사이트맵 역시 업데이트되어야 하며 이것은 중요하다. 사이트의 모든 섹션들에 대한 링크를 제공하지 않는 사이트맵, 사이트의 구조와 다른 구조를 보여주는 사이트맵, 더이상 유효하지 않은 링크를 포함하는 사이트맵 들은 유효한 사이트맵이라 할 수 없다.
Web Accessibility Initiative 는 WAI 사이트맵를 제공하며, 이것은 웹 사이트의 서로 다른 섹션들을 목록화하고 있다. 사이트맵은 웹 사이트의 서로 다른 섹션들을 보여주고, 그러한 섹션들 내부의 하위구조 일부를 보여준다.
온라인 잡지 사이트의 사이트맵이 잡지의 모든 섹션들과, 각각의 섹션들의 서브섹션들을 보여주고 있다. 이것은 또한 도움말, 연락방법, 개인정보 정책, 고용정보, 구독방법, 잡지의 홈페이지에 대한 링크들을 포함한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
국립 접근성 커리큘럼 센터의 그래픽 오거나이저 페이지는 여러 종류의 그래픽 오거나이저들과 그 사용법에 대한 유용한 살펴보기를 제공하며, 이에 더해 학습 장애를 갖고 있는 학생들이 그러한 그래픽 오거나이저를 사용하는 것의 효율성에 대해 관련있는 연구들의 요점을 제공하고 있다.
사이트가 사이트맵을 포함하는지 확인한다.
사이트맵에 포함된 모든 링크들이, 사이트의 대응하는 섹션들을 가리키는지 확인한다.
사이트맵의 링크들 각각에 대해, 그것이 가리키는 페이지가 사이트맵에 대한 링크를 포함하고 있는지 확인한다.
사이트의 페이지들 각각에 대해, 사이트맵에서 출발한 몇개의 링크를 따라감으로서 그것에 도달할 수 있는지 확인한다.
위 확인을 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이것은 성공기준 2.4.5를 충분히 만족하는 컨텐츠의 위치를 찾아내는 여러 테크닉 중 하나이다. 차례는 동일한 문서의 섹션들과 서브섹션들에 대한 링크를 제공한다. 문서의 정보들은 보통 계층적으로 정리되어 있으며, 순서에 따라 읽힐 의도를 가지고 있다. 도서관에 많은 책들이 있고, 그 책들이 각각 자신의 차례를 갖는 것과 마찬가지로, 웹 사이트는 많은 문서들을 포함할 수 있으며, 그것들 각각은 자신의 차례를 가질 수 있다.
차례는 두가지 목적을 가지고 있다:
사용자에게 문서의 컨텐츠와 구조에 대한 훝어보기를 제공한다.
독자들이 온라인 문서의 특정 섹션으로 바로 갈 수 있도록 한다.
차례는 보통 문서의 주요 섹션들만을 포함하지만, 확장 가능한 차례를 통해 복잡한 문서의 좀 더 자세한 정보를 제공하는 것이 바람직한 경우도 있다.
문서의 섹션들은 하나의 웹 페이지에 위치할수도 있고, 여러개의 웹 페이지로 분할될수도 있다. 문서가 여러개의 웹 페이지로 분할되었을 경우 차례는 더욱 유용한다.
내비게이션 바, 혹은 사이트맵과 같은 다른 탐색 요소들과 차례 사이에는 차이점이 있다. 차례는 동일한 문서의 섹션들에 대한 링크를 제공한다. 그러한 섹션들은 같은 페이지에 있을수도 있고, 여러개의 웹 페이지에 분할되어 있을 수도 있다. 하지만, 이것들은 하나로 묶여서 완성된 아이디어를 형성한다. 이것을 더 잘 이해하려면, 섹션들을 갖고 있는 하드카피 서적을 상상해 보라. 각각의 섹션들은 책에 귀속된다. 도서관에는 많은 책들이 있을 수 있다. 이 예에서, 도서관이 전체 웹 사이트이다.
WCAG 2.0 은 차례 를 포함하는데, 이 차례는 문서의 섹션들과 서브섹션들에 대한 링크들의 계층적 목록이다. 차례의 계층구조는 섹션들의 구성을 반영하고, 차례의 각 아이템들은 사용자를 해당 섹션으로 바로 이동시키는 링크들이다.
어도비 리더 7.0으로 접근성있는 PDF 문서 제작하기 : 장애를 가진 사람들을 위한 가이드 의 첫 페이지는 가이드의 섹션들을 목록화하고 있는 차례를 제공한다. The 장애를 가진 사람들을 위한, PDF 버전의 가이드 는 3 페이지에, 문서 전체에 대한 좀 더 자세한 차례를 포함하고 있다.
이 테크닉에 연관된 자원이 없다.
문서에 차례, 또는 차례를 가리키는 링크가 있는지 확인한다.
차례에 나타나는 아이템들의 값과 순서가 문서의 섹션들의 이름 및 순서에 대응하는지 확인한다.
차례의 각 항목들이 문서의 정확한 섹션과 링크되어있는지 확인한다
위의 모든 확인을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
(역주 : 원문에서는 breadcrumb trail이란 단어를 사용한다. 어린이가 끌려가면서 빵부스러기를 흘려서 추적자를 도왔다는 동화에서 유래한 비유이며, 우리말에 적절한 표현이 없어서 "발자취" 라는 단어를 사용하였다.)
모든 기술
이 테크닉은 다음과 연관된다:
발자취는 사용자가 웹 페이지의 구조, 이전의 페이지로 돌아가는 방법, 경우에 따라서는 현재 위치가 웹 페이지의 시리즈 속에서 어떠한 위치에 있는지를 시각적으로 이해하는데 도움을 준다. 발자취는 사용자가 현재의 웹 페이지에 도달하기 위해 거쳤던 경로 상의 위치들을 보여주거나, 또는 현재의 페이지가 사이트 구조 속에서 갖는 위치를 보여준다.
발자취는 현재의 웹 페이지에 도달하기 위해 거쳤던 웹 페이지들로의 링크들을 이용해 구현된다. 그러한 것들은 각각의 웹 페이지가 있었던 것과 같은 위치에 있게 된다.
사용자가 발자취에 있는 아이템들을 구분할 수 있는 적절한 시각적 분리기호를 제공한다면 많은 도움이 될 수 있다. 그러한 분리 기호는 ">", "|", "/", and "::" 같은 것들이 될 수 있다.
한 개발자가 하이퍼링크를 생성하는 방법을 찾기 위해, 저작 도구 제조사의 웹 사이트를 검색하고 있다. 검색결과가 그를 그 저작 도구를 이용해서 하이피링크를 만드는 특정 지침으로 인도하고 있다. 그것은 발자취를 생성하기 위해 다음의 링크를 포함하고 있다:
예제 코드:
홈 :: 개발자 센터 :: 방법 센터
이 예제에서 발자취는 현재 웹 페이지의 타이틀인 "하이퍼링크를 만드는 방법"은 포함하지 않고 있다. 그러한 정보는 웹 페이지의 타이틀에서 찾을 수 있다.
한 사진작가의 포트폴리오 웹 사이트는 여러개의 갤러리들로 이루어져 있으며, 각각의 갤러리들은 다시 범주들로 세분되어 있다. Gentoo 펭귄의 사진을 포함하는 웹 페이지에 도달하기 위해 그 사이트를 탐색한 사용자는 페이지의 상단에서 다음과 같은 발자취를 발견할 수 있을 것이다:
예제 코드:
홈 / 갤러리 / 극지방 / 펭귄 / Gentoo 펭귄
"Gentoo Penguin" 을 제외한 모든 아이템들이 링크로 구현되어 있다. 현재의 위치인 Gentoo Penguin 은 발자취에 포함되어있긴 하지만 링크로 구현되어 있지는 않다.
이 테크닉에 연관된 자원이 없다.
웹 페이지의 집합에서 발자취가 구현되었을 경우:
하나의 페이지로 탐색해 간다.
발자취가 표시되었는지 확인한다
발자취가 현재 위치에 도달하기까지의 탐색 순서를 정확하게 보여주는지, 혹은 사이트 구조 내에서 현재의 위치가 차지하는 계층적 경로를 정확하게 보여주는지 확인한다.
현재의 위치를 포함하지 않는 발자취에 대해:
발자취에 있는 모든 요소들이 링크로 구현되어 있는지 확인한다.
현재 위치를 포함하는 발자취에 대해:
현재의 위치를 제외한 모든 요소들이 링크로 구현되어 있는지 확인한다.
현재 위치는 링크로 구현되어 있지 않음을 확인한다.
모든 링크들이 발자취에서 명시된 정확한 웹 페이지를 가리키는지 확인한다.
발자취를 포함하는 집합 내부의 모든 웹 페이지들에 대해
#2, #3, #6 을 만족한다.
아니라면, #4 또는 #5 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉은 소리만 있는 라이브 컨텐츠, 영상만 있는 라이브 컨텐츠에 대해 설명적인 라벨 제공한다. 이러한 라벨은 시간에 기초한 오디오 미디어, 또는 그러한 미디어에 대한 대체, 혹은 영상의 오디오 설명과 함께 사용될 수 있다. 하지만 그러한 대체는 이 테크닉의 일부는 아니다. 이 테크닉의 목적은 사용자가 텍스트가 아닌 컨텐츠를 판별 - 설령 그것에 접근할 수 없더라도 - 할 수 있도록 하는 것이다. 노트: 완전한 대체를 사용할 수 있다고 하더라도, 사용자들이 텍스트가 아닌 컨텐츠에 마주쳤을때 혼란스럽지 않도록, 또한 그것을 그러한 대체에 연결할 수 있도록 그것을 식별할 수 있게 해주는 것이 중요하다.
동부 해안 고속도로에 관한 라이브 비디오 피드에 다음과 같은 라벨이 붙어 있다 : "I-81 인터체인지 바로 남쪽의 동부 해안 고속도로에 관한 라이브 비디오이며 현재의 교통 상황을 보여준다."
미시시피 하원에 대한 라이브 오디오 피드에 다음과 같은 라벨이 붙어 있다 : "미시시시피 하원에 있는 마이크에서, 라이브 오디오"
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트가 아닌 컨텐츠를 제거하거나, 숨기거나, 가린다.
텍스트 대체(들)을 보여준다.
텍스트가 아닌 컨텐츠의 목적이 분명한지 확인한다 - 설령 컨텐츠가 없어졌더라도
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
일반적인 테크닉. 모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 동기화된 미디어에 포함된 정보들을 제공하는 대체적이고 접근성있는 방법을 제공하는 것이다.
동기화된 미디어 표현에서, 정보는 다음과 같이 다양한 방법으로 전달된다 :
대화,
소리 (자연적인것, 그리고 인공적인것),
세팅과 배경,
사람, 동물, 그밖의 행동과 표현,
텍스트 또는 그래픽,
그외 다른것들.
동일한 정보를 접근성있는 형태로 제공하기 위해, 이 테크닉은 동기화된 미디어와 동일한 정보를 제공하고 동일한 내용을 갖는 문서를 생성하는 방법을 포함한다. 그러한 문서는 이따금씩 대본이라고 불린다. 그것은 모든 중요한 대화와 행동들을 포함하며, 이에 더불어 이야기의 일부분인 배경과 기타의 것들에 대한 설명도 포함한다.
동기화된 미디어를 제작하기 위해 처음부터 실제 대본을 사용하였다면, 이것은 좋은 출발점이 될 수 있다. 그러나 실제 생산과 편집에 있어서는, 동기화된 미디어는 그러한 대본과는 다르게 변경되는 경우가 있다. 이 테크닉에 대해, 원래의 대본은 동기화된 미디어의 최종 편집본에서 실제로 일어나는 대화와 상황들에 맞게끔 고쳐질 것이다.
추가적으로, 동기화된 미디어의 몇몇 특별한 경우에는 재생중에 몇몇 곳에서 상호작용을 포함하는 경우가 있다. 이따금씩, 결과적으로 어떤 행동(예를 들어, 무언가를 구입하거나, 보냈거나, 이루어졌다)이 그 자리에 들어간다. 다른 경우, 그것이 동기화된 미디어의 흐름을 바꿀수도 있다(예를 들어, 미디어는 사용자의 입력에 의해 선택되는 몇가지의 흐름을 가지고 있다). 이러한 경우들에서, 사용자가 동기화된 미디어에서 가졌을 옵션이나 가능성들을, 논의중인 대체 수단에서도 마찬가지로 사용할 수 있게끔 링크나 기타 메커니즘이 사용될 것이다.
사원들에게 새로운 장비를 어떻게 사용하는지 보여주는 훈련 필름이 있다. 필름에는 사용법의 데모를 보여주는 동안 계속해서 이야기하는 사람이 있다. 훈련 필름을 만들기 위해 사용한 대본이 시작점이 될 수 있다. 이것을 편집하고 수정해서, 최종적인 대화나 기타 것들과 대응하도록 했다. 필름과, 그에 맞는 대체 미디어를 회사의 웹 사이트에서 사용할 수 있다. 사원들은 장비를 사용하는 법을 배우기 위해 둘중 하나, 혹은 둘 모두를 사용할 수 있다.
사용자들이 가상의 매장을 둘러볼 수 있도록 되어 있는 인터랙티브 쇼핑 환경이 생성되었다. 대체 수단에서는 사용자들이 가상의 장바구니에 물건을 드래그하는 대신, 텍스트 기반의 링크들을 사용해서 동일한 쇼핑을 할 수 있도록 되어 있다.
이 테크닉에 연관된 자원이 없다.
대체 수단을 참조하면서 동기화된 미디어를 지켜본다
대체 수단의 대화들이 동기화된 미디어의 그것과 일치하는지 확인한다.
대체 수단에 소리에 대한 설명이 들어있는지 확인한다.
대체 수단에 세팅과 그 변화에 대한 설명이 들어있는지 확인한다.
대체 수단에 행동들과, 모든 '배우'(사람들, 동물들, 기타)의 표현들에 대한 설명이 들어있는지 확인한다.
대체 버전(들)이 분리된 페이지에 들어 있다면, 사용자가 다른 버전들에 접근할 수 있도록 하는 링크(들)이 사용 가능한지 확인한다.
#2, 3, 4, 5 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
All technologies
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 페이지에 온라인 사전에 접근하는 메커니즘을 추가해서 단어, 구절, 전문용어, 약어의 확장들에 대한 정의를 제공하는 것이다. 이 테크닉은 저자가 용어집이나 기타 메커니즘을 사이트에 만들어내도록 요구하지 않고, 웹에 이미 존재하는 자원들을 사용하도록 하고 있다. 페이지에서 그러한 접근방법을 제공함으로써, 사용자는 원하는 정의를 쉽게 찾아낼 수 있다. 이 테크닉은 정확한 정의를 돌려주는 온라인 사전에만 사용될 수 있다.
컴퓨터가 어떻게 동작하는지 설명하는 사이트가 있다. 이 사이트의 각 페이지에는 검색 폼이 포함되어있을 수 있다. 그러한 검색은 컴퓨터 단어들, 약어들, 두문자어들을 포함하는 온라인 사전에 대해 행해질 것이다. 사전이 컴퓨터 단어들에 특화되어 있으므로, 이 사전에서 찾아낸 약어의 의미는 일반적인 사전보다 정확할 것이다.
영문법의 온라인 과정에서, 새로운 단어들이 포함된 텍스트 문단을 제공하고 있다. 각각의 단어들은 그 단어의 정의를 찾기 위한 온라인 사전에 링크되어 있다. 링크를 활성화하면 새 창이 열리고, 그 특정 단어가 정의된 온라인 사전이 거기 나타날 것이다..
이 테크닉에 연관된 자원이 없다.
정의되어야 할 각각의 단어, 구절, 약어들에 대해:
온라인 사전을 통해 단어, 구절, 약어를 검색할 수 있는 메커니즘이 웹 페이지 안에 있는지 확인한다.
단어, 구절, 약어를 사전으로 검색한 결과가 정확한 정의를 나타내는지 확인한다.
#1 과 #2 를 만족한다.
노트 : WCAG에서 "약어" 의 정의는 다음과 같다 : "단어, 구절, 혹은 이름의 축약된 형태이며, 그 원래의 표현이 참조하는 기관에 의해 제거되지 않은 상태이며, 약어가 아직 언어의 일부가 되지 않은 상태인 경우"
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 모든 웹 페이지에서 사용자들이 형식을 갖춘 데이터 영역에 접근할 때 최소한 하나 이상의 도움말 정보에 대한 링크를 제공함으로서 문맥에 밀접한 도움말을 제공하는 것이다. 링크는 그 웹 페이지에 특화된 정보를 가진 도움말 페이지를 가리킨다. 다른 접근법은 모든 인터랙티브한 컨트롤에 대해 도움말 링크를 제공하는 것이다. 이러한 링크를 컨트롤의 바로 앞이나 바로 뒤에 배치하면 사용자들이 컨트롤에 대해 어려움을 겪을때 탭을 사용해서 쉽게 그러한 정보에 접근할 수 있다. 도움말 정보를 새 창으로 제공하면 이미 폼에 입력한 데이터가 전혀 손실되지 않음을 보장할 수 있다. 노트 : 링크가 도움말을 제공하는 유일한 수단인 것은 아니다.
아래의 예제는 도움말 링크를 포함하는 라벨 요소를 보여준다. 라벨 요소에 도움말 링크를 포함하면 스크린 리더 사용자들이 폼 필드와 상호작용할때 도움말 링크를 사용할 수 있게 된다.
예제 코드:
<form action="test.html">
<label for="test">테스트 컨트롤
<a href="help.html" target="_blank">도움말</a></label>
<input type="text" name="test" id="test" />
</form>
폼을 포함하는 웹 페이지를 찾는다.
폼을 완성하는 것에 특화된 도움말을 포함하는 이 웹 페이지, 또는 다른 자원을 가리키는 링크가 최소한 하나 이상 있는지 판단한다.
각각의 인터랙티브한 컨트롤의 앞이나 뒤에 그 컨트롤에 특화된 도움말 정보를 제공하는 링크가 있는지 판단한다.
#2 또는 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 긴 설명(예를 들어, longdesc)을 제공하는 기능을 네이티브하게 갖고 있지 않거나, 그러한 기능이 지원되지 않을 것으로 알려진 기술들에서, 다른 위치에 있는 긴 설명에 대한 링크를 제공하는 것이다.
이 테크닉을 통해, 텍스트가 아닌 컨텐츠와 다른 위치에서 긴 설명이 제공된다. 이것은 같은 URI의 다른 위치일수도 있고, 다른 URI일 수도 있다. 그러한 긴 설명을 가리키는 링크는 텍스트가 아닌 컨텐츠에 바로 인접하게 위치할 수 있다. 만약 설명이 다른 텍스트들과 함께 존재한다면, "설명의 끝" 이라는 표식을 끝부분에 놓아서, 사용자들이 언제 설명을 읽는 것을 중지하고 메인 컨텐츠로 돌아와야 하는지 알도록 한다. 만약 "뒤로가기" 버튼이 사용자를 링크를 누르기 전의 위치로 돌려놓지 않는다면, 텍스트가 아닌 컨텐츠가 있는 위치를 가리키는 링크가 제공된다.
이 테크닉은 HTML 명세에 'longdesc' 가 추가되기 전 까지는 널리 사용되었다. HTML에서는 이것을 D-링크라고 불렀는데, 이미지 다음에 D 문자를 놓고, 이 D를 긴 설명으로 가는 링크가 되게끔 구현하는 일이 잦았기 때문이다. 이 테크닉은 기술에 종속되지 않으며, 링크를 지원하는 모든 기술에서 사용될 수 있다.
최고 순위의 판매원 3명의 판매량을 막대 차트로 표시하고 있는 웹 페이지가 있다.
짧은 대체 텍스트는 "최고 순위 판매원 3명의 10월 판매량" 이라고 씌어 있다.
텍스트가 아닌 컨텐츠의 바로 다음에, 긴 설명을 암시하는 작은 이미지가 있다. 이미지의 대체텍스트는 "차트의 긴 설명"이다. 이미지는 페이지의 하단으로 링크되는데, 거기에는 "이 페이지의 차트들에 대한 설명" 이라는 제목의 섹션이 있다. 링크가 가리키는 특정적인 설명은 : "10월 판매량. Mary가 400개를 판매하여 선두에 있다. Mike는 389개를 판매하여 바짝 추격하고 있다. Chris는 350개를 판매하여 최고 순위 3명의 마지막에 있다. [설명의 끝]"
최고 순위의 판매원 3명의 판매량을 막대 차트로 표시하고 있는 웹 페이지가 있다.
짧은 대체 텍스트는 "최고 순위 판매원 3명의 10월 판매량" 이라고 씌어 있다.
텍스트가 아닌 컨텐츠의 바로 다음에, 긴 설명을 암시하는 작은 이미지가 있다. 이미지의 대체텍스트는 "차트의 긴 설명"이다. 이미지는 다른 페이지로 링크되는데, 페이지의 제목은 "10월 판매량 보고서의 차트에 대한 설명"이다. 링크가 가리키는 특정적인 설명은 : "10월 판매량. Mary가 400개를 판매하여 선두에 있다. Mike는 389개를 판매하여 바짝 추격하고 있다. Chris는 350개를 판매하여 최고 순위 3명의 마지막에 있다. 설명의 끝. <link> 판매량 차트로 돌아가기</link>"
차트가 하나 있다. 차트 바로 아래에 있는 캡션은 긴 설명으로의 링크 역할을 수행한다. 링크의 타이틀 속성을 이용해서, 그것이 긴 설명을 가리키는 링크라는 점을 명확히 한다.
마틴 루터 킹의 연설을 녹음한 파일이 있다. 그 파일에 대한 링크와, 글로 적은 것에 대한 링크가 나란히 나타난다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트가 아닌 컨텐츠의 바로 앞이나 뒤에 링크가 있는지 확인한다.
그 링크가, 살펴보고 있는 텍스트가 아닌 컨텐츠에 대한 긴 설명을 가리키는 유효한 링크인지 확인한다.
그 설명이 텍스트가 아닌 컨텐츠와 동일한 정보를 전달하는지 확인한다.
컨텐츠의 원래 위치로 돌아올 수 있는 링크, 혹은 뒤로가기 버튼이 있는지 확인한다.
위의 네가지를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 설명을 보기 위해 다른 위치로 이동할 것을 요구하지 않으면서 긴 설명을 제공하는 것이다. 또한, 텍스트가 아닌 컨텐츠의 몇가지 기능을 놓칠수도 있는 모든 사람들에게 유용할 수 있는 설명을 모든 사용자가 볼 수 있도록 한다.
이 테크닉을 통해, 긴 설명은 보통의 프리젠테이션(즉, 모든 사람이 그것을 받는다)의 형태로 제공되어진다. 설명은 텍스트가 아닌 컨텐츠 근처에 위치하지만, 바로 옆일 필요는 없다. 예를 들어, 차트에 대한 긴 설명을 담은 캡션이 다음 문단에 존재할 수 있다.
이러한 긴 설명의 위치를 짧은 대체텍스트로 제공하여, 텍스트가 아닌 컨텐츠를 볼 수 없는 사용자가 어디에서 그것을 찾아야 하는지 알려준다.
최고 순위의 판매원 3명의 판매량을 막대 차트로 표시하고 있는 웹 페이지가 있다.
짧은 대체텍스트에는 이렇게 씌어 있다 : "최고 순위 판매원 3명의 10월 판매 차트. 자세한 내용은 차트 다음에 있는 텍스트에 들어 있다:"
차트의 다음 문단에는 이렇게 씌어 있다 : "10월 판매량. Mary가 400개를 판매하여 선두에 있다. Mike는 389개를 판매하여 바짝 추격하고 있다. Chris는 350개를 판매하여 최고 순위 3명의 마지막에 있다."
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
긴 설명의 위치를 포함하는 짧은 대체텍스트가 있는지 확인한다.
긴 설명이 시각적으로도, 그리고 선형으로 읽는 순서로도, 텍스트가 아닌 컨텐츠 근처에 있는지 확인한다.
긴 설명이 그러한 컨텐츠와 동일한 정보를 전달하는지 확인한다.
위 세가지를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
자신을 자동으로 업데이트하는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자들이 컨텐츠의 자동 업데이트, 혹은 기타 긴급하지 않은 끼어듬을 연기할 수 있도록 하는 것이다. 이러한 것은 선호되는 옵션(프리퍼런스)을 통해 구현할수도 있고, 혹은 사용자에게 임박한 업데이트가 있음을 알리고 그들이 그것을 승인하도록 하는 방식으로 구현할수도 있다. 프리퍼런스를 제공했다면, 자동 업데이트를 기본값으로는 차단하고, 사용자가 그것을 허용했다면 컨텐츠 자동 업데이트의 빈도를 스스로 정할 수 있다.
재고 견적을 보여주는 웹 페이지가 있고, 그 내용을 주기적으로 업데이트한다. 페이지에는 짧은 폼이 있는데, 그 폼에는 "데이터 갱신 주기(분):" 이라는 필드가 있어서 사용자들이 업데이트 주기를 정할 수 있도록 하고 있다.
자동적으로 업데이트되는 컨텐츠가 있는 페이지를 찾는다.
각각의 자동 업데이트에 대해, 업데이트 타이밍을 조절할 수 있는 메커니즘을 찾는다.
자동 업데이트가 기본값으로 비활성화되어 있거나, 자동 업데이트가 일어날 경우 사용자에게 알리고 그것을 승인받도록 되어 있는지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
자동 업데이트를 지원하는 모든 기술, 혹은 기술 조합
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 자동업데이트를 할지, 한다면 언제 하는지 조절할 수 있도록 함으로서, 그러한 자동적인 갱신이 초래하는 문맥의 변화 때문에 발생할 수 있는 혼란, 혹은 그와 흡사한 것을 방지하는 것이다. 스크린 리더 사용자들은 자동 업데이트가 혼란스럽다고 생각할 수 있는데, 어떤 일이 일어날지 항상 명확한 것은 아니기 때문이다. 페이지가 갱신될 때, 페이지에서의 사용자의 현재 위치를 나타내는 스크린 리더의 "가상 커서"는 페이지의 최상단으로 이동한다. 화면 확대 소프트웨어의 사용자, 독서 장애를 갖고 있는 사용자들은 페이지가 자동적으로 갱신될때 방향을 잃을 수 있다.
어떤 컨텐츠는 새로운 데이터, 정보로 자주 업데이트된다. 일부 개발자들은 컨텐츠 내부에 서버로부터 새 사본을 요청하는 코드를 삽입함으로서 자동적인 업데이트를 강제한다. 이러한 업데이트, 그리고 그 주기가 항상 사용자의 제어권 아래에 있지는 않다. 업데이트를 자동적으로 발생시키는 대신, 사용자가 자신의 필요에 따라 업데이트를 요청할 수 있도록 하는 메커니즘을 제공할 수 있다.
HTML에서는, 개발자가 버튼이나 링크를 제공하고 사용자가 그것을 이용해서 내용을 업데이트하도록 할 수 있다. 예를 들어, http://www.example.com/news.jsp 에 위치한 뉴스 아이템 페이지에서는
예제 코드:
<a href="news.jsp">페이지 업데이트</a>
이메일(웹메일) 인터페이스에서는, 자동으로 업데이트하는 대신 개발자가 버튼이나 링크를 제공하고 들어오는 메일들을 그것을 통해 받도록 할 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
국립 시각장애 연구소(RNIB)의 웹 접근성 센터에서는 타임아웃과 페이지 갱신 을 통해 방침과 테크닉들을 제공하고 있다.
컨텐츠를 업데이트하는 메커니즘을 찾는다 (그러한 메커니즘이 존재한다면).
그러한 각각의 메커니즘에 대해, 그것이 사용자가 업데이트를 요청할 수 있도록 허용하는지 확인한다.
그러한 각각의 메커니즘에 대해, 그것이 자동적인 업데이트를 초래할 수 있는지 확인한다.
#2 를 만족한다면, #3 이 아니다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사운드트랙과 시각적 컨텐츠를 가진 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 시각적으로 제공된 정보의 오디오(말해진) 버전을 제공하여 볼 수 없는 사람들이 시청각물을 이해할 수 있도록 하는 것이다.
현재 대부분의 사용자 에이전트들이 여러개의 사운드 트랙을 병합할 수 없으므로, 이 테크닉은 사용자가 원래의 사운드트랙을 추가적인 오디오 설명이 더해진 것으로 교체하는 것을 허용하는 방법으로 동기화된 미디어에 추가적인 오디오 정보를 더한다. 이러한 추가적인 정보는 컨텐츠를 이해하는데 중요한 행동, 캐릭터, 장면 전환과 화면 텍스트(자막이 아닌)들에 집중된다.
이러한 새 정보들이 원래의 사운드트랙에 있는 핵심적인 오디오 정보를 흐리게 하는 것(혹은 큰 소리때문에 흐려지는것)은 도움이 되지 못하므로, 새 정보들은 대화나 사운드 효과 사이의 잠시 멈추는 부분에 추가된다. 따라서 프로그램에 더해질 수 있는 보충적인 정보의 양은 제한된다.
오디오 설명(시각적 정보의)이 들어있는 사운드 트랙은 사용자가 선택할 수 있는 대체 사운드 트랙일수도 있고, 모든 사람이 듣는 일반적인 사운드 트랙일수도 있다.
북동부 여행 로그에는 추가적인 오디오 설명들이 대화 사이에 삽입되어져 있어서, 시각 장애인들이 (미디어에서) 말하는 사람들이 무엇에 관해 말하고 있는것인지 언제라도 알 수 있다.
딱따구리가 나무에 둥지를 파는 것을 찍은 비디오가 있다. 컨텐츠에는 버튼이 하나 있어서, 사용자가 오디오 설명을 켜고 끌 수 있게 하고 있다.
강의 비디오에, 교수가 "그리고 이것이 가장 중요한 것입니다" 라고 말할때마다 추가되는 오디오 설명이 있다. 오디오 설명은 비디오를 볼 수 없는 사용자가 "이것" 이 무엇인지 알 수 있게 해준다.
영화 필름에 두개의 오디오 트랙이 있는데, 그중 하나는 오디오 설명을 포함한다. 사용자는 자신의 미디어 플레이어에서 어떤 트랙을 들을지 선택할 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
오디오 설명을 포함하고 있는 오디오 트랙이 컨텐츠 자체에 포함된 컨트롤을 통해, 또는 미디어 플레이어에서 프리퍼런스를 선택함으로서 켤 수 있는지 확인한다.
동기화된 미디어를 듣는다.
대화 속의 공백들이 시각적 컨텐츠에 관한 중요한 정보를 전달하는데 사용되고 있는지 확인한다.
#1 과 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크, 오디오 포맷을 지원하는 기술들.
이 테크닉은 다음과 연관된다:
쓰여진 텍스트에서 단어들을 판독(해석) 하는데 어려움을 느끼는 일부 사용자들은 텍스트가 크게 읽혀지는 것을 들을 수 있다면 큰 도움이 될 것이다. 최근에는 사람이 읽는 것을 녹음한 것이나, 혹은 합성된 음성을 통해 쉽게 이러한 서비스를 제공할 수 있다. 예를 들어, 텍스트를 합성된 음성으로 변환하고, 그것을 오디오 파일로 제공한 후 음성 버전으로 지원할 수 있게 하는 제품들이 많이 있다. 이렇게 한 후, 음성 버전에 대한 링크를 컨텐츠 내에 제공할 수 있을 것이다. 사용된 음성의 품질과, 텍스트가 자주 바뀔지의 여부가 비용을 결정할 것이다.
짧은 텍스트와, 정적인 텍스트 컨텐츠의 음성 버전
이 방법은 짧은 텍스트와, 자주 변경되지 않는 긴 문서에서 효과적이다.
누군가가 텍스트를 큰 소리로 읽는 것을 녹음하거나, 개별적인 문서, 혹은 특정한 구절을 합성된 음성으로 변환하는 툴을 사용한다. 선택이 가능하다면, 가장 명확하고 매력적인 목소리를 선택한다.
읽혀진 버전을 오디오 파일로 저장한다. 대중적으로 사용 가능하고 미디어 플레이어들에서 지원되는 오디오 포맷을 사용한다.
음성 버전에 대한 링크를 제공한다.
오디오 포맷을 명시한다. (예를 들어, .MP3, .WAV, .AU, 등.).
그 포맷을 지원하는 미디어 플레이어에 대한 링크를 제공한다.
변하는 텍스트의 읽혀진 버전
페이지가 자주 바뀌거나, 사용자가 텍스트 컨텐츠를 결정하는 경우에는 서버 기반의 방법이 최선일 수 있다. 몇몇 서버 기반의 도구들은 사용자가 자신이 흥미를 가진 텍스트를 선택하고 그것을 들을 수 있도록 허용한다. 일반적으로, 사용자가 버튼을 눌러서 텍스트-음성 변환을 시작하고 큰 소리로 읽게끔 한다.
지방자치단체의 주택 권한 사이트에서는 모든 페이지에 이런 라벨이 붙은 버튼이 있다 : "이 페이지를 큰 소리록 읽는다" 사용자가 버튼을 클릭하면 페이지는 합성된 음성으로 읽혀진다.
이 테크닉에 연관된 자원이 없다.
(현재 목록화된 것이 없다)
컨텐츠의 음성 버전이 사용 가능한지 확인한다.
#1 을 만족한다..
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
폼을 포함하는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 문맥의 변화를 명시적으로 요구할 수 있는 메커니즘을 제공하는 것이다. 제출 버튼의 의도된 사용법이 폼에 입력된 데이터를 제출하는 HTTP 요청을 생성하는 것이므로, 이것은 문맥의 변화를 초래하는 컨트롤에 적합하며, 사용자가 혼란을 느끼지 않는 방법이다.
예제 1: 문맥의 변화를 초래하는 제출 버튼이 모든 폼에 사용되고 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
컨텐츠에서 모든 폼을 찾는다.
각각의 폼에 대해, 제출 버튼이 있는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
여러개의 비디오 스트림의 동기화를 허용하는 모든 동기화된 미디어 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 모든 사용자들에 대한 매체 표현에 영향을 미치지 않으면서도, 들을 수 없거나 텍스트를 빨리 읽을 수 없는 사용자들이 동기화된 미디어에 접근할 수 있도록 하는 것이다.
수화를 주된 의사전달 수단으로 사용하는 사람들에게, 텍스트를 캡션이 표현되는 속도로 읽고 이해하는 것은 이따금씩은 탐탁치 않은 경우이고, 때때로 불가능한 경우도 있다. 이러한 사람들에게는, 오디오 정보의 수화 표현을 제공하는 것이 중요하다.
이 테크닉은 수화 통역을 원래의 비디오 스트림과 동기화된 별도의 비디오 스트림으로 제공함으로서 그것을 가능케 한다. 플레이어에 따라, 이 두번째 비디오 스트림은 원래 비디오 위에 오버레이될수도 있고, 별도의 창에 표시될수도 있다. 수화 통역 부분을 원래의 비디오와 별개로 확대하는 것이 가능할수도 있는데, 이렇게 하면 수화 표현자의 손짓, 몸짓, 표정 변화를 쉽게 읽을 수 있을것이다.
노트 : 수화 언어가 항상 프린트된 언어의 수화 버전인 것은 아니므로, 저자는 어떤 수화 언어를 포함시킬 것인지 결정해야 한다. 보통은 주된 사용자들의 언어가 사용될 것이다. 다양한 사용자를 위한 의도를 갖고 있다면, 다양한 언어를 사용할수도 있다. 다양한 수화 언어에 대해서는 조언적 테크닉을 참고하라.
예제 1: 대학의 교육 프로그램과 더불어, 뷰어의 옵션에 따라 보여질 수 있는 동기화된 수화 언어 통역 비디오가 제공된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
수화 책의 출판에 관한 가이드라인
"수화 언어 표현" 은 수화 언어 통역을 필름으로 제작할때 고려해야 할 광범위한 문제들에 대한 훝어보기를 제공한다. 원본이 씌어진 텍스트와 말해진 텍스트 모두인 경우에 대한 토의도 포함한다.
필름 제작에 관한 테크닉들이12장, “수화 통역자(들)을 필름으로 제작하기" 에서 다루어진다.
원래의 동기화된 미디어 컨텐츠와 연결하여 수화 언어 통역을 표시하는 방법에 대한 유용한 정보가 13장, "편집" 에서 제공된다.
노트: 이러한 테크닉들은 웹에 기반한 표현을 위해서는 수정되어야 할 수도 있다.
(없음)
플레이어에서 수화 언어 창의 표시를 활성화한다.
청각에 문제가 없고, 수화에 익숙한 사람이 프로그램을 지켜보도록 한다.
수화 언어 통역이 스크린에, 혹은 별도의 창에 나타나는지 확인한다.
대화와, 중요한 소리들이 통역에 의해 전달되며, 오디오와 동기화되어 있는지 확인한다.
#3 과 #4 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 텍스트가 아닌 컨텐츠의 모든 기능이 제공되지 못하는 경우라 하더라도 대체 텍스트를 통해 유용한 정보를 제공하는 것이다.
때때로, 대체 텍스트는 텍스트가 아닌 원래의 컨텐츠와 같은 목적을 수행하지 못할 수도 있다. (예를 들어 신속한 2차원 타게팅 기술과, 시각과 손의 협업능력을 고양하기 위해 개발된 애플릿 같은) 이러한 경우 이 테크닉이 사용된다. 이 테크닉을 통해 텍스트가 아닌 컨텐츠의 목적에 대한 설명이 제공된다.
눈과 손의 협업능력을 기르는 애플릿에 다음과 같은 대체 텍스트가 붙어 있다 : "마우스와, 움직이는 타겟을 사용하여 눈과 손의 협업능력을 기르는 애플릿"
카메라 애플릿에 둥근 디스크가 붙어 있다. 그 가장자리를 누르면 원격 카메라를 컨트롤할수 있고, 중앙의 슬라이더를 통해 줌 기능을 조절할 수 있다. 이 애플릿에는 다음과 같은 대체 텍스트가 달려 있다 : "원격 비디오 카메라의 조준과 줌에 대한 컨트롤"
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트가 아닌 컨텐츠를 제거하거나, 감추거나, 가린다.
대체텍스트로 그것을 교체한다.
텍스트가 아닌 컨텐츠의 목적이 명확한지 확인한다 - 설령 그 기능이 사라졌다고 하더라도
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자 입력에서 필수적인 필드들을 포함하는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 반드시 채워져야 하는 필드가 채워지지 않았을 때 사용자에게 알려주는 것이다. 사용자가 필수적인 필드에 대한 입력을 제공하지 않았을 때, 누락된 필드들이 어떤 것인지 사용자가 식별할 수 있게끔 정보가 텍스트로 제공된다. 한가지 접근방법은 클라이언트 사이드 유효성검사를 사용하고, 생략된것들 중 필수적인 필드를 알려주는 경고 대화상자를 제공하는 것이다. 다른 접근방법은 서버 사이드 유효성검사를 사용하는 것인데, 누락된 필수적인 필드들의 위치에 텍스트 설명을 제공하거나, 그러한 필드들을 식별하게 해주는 텍스트 설명과 함께 폼을 다시 보여주는(전에 입력하였던 모든 데이터를 포함해서) 것이다.
사용자가 폼을 제출하려고 하지만, 필수적인 필드들 중 하나 이상의 입력을 빠뜨렸거나 선택사항을 선택하지 않았다. 클라이언트 사이드 유효성 검사를 실행한 결과 누락된 필드가 있음이 발견되었고, 사용자에게 필수적인 필드가 누락되었음을 알리는 경고 대화상자가 나타난다. 문제가 있는 필드의 라벨이 변경되어서 문제가 있음을 식별하게 하고, 그러한 필드를 가리키는 링크가 제출 버튼 뒤에 삽입되어서, 사용자가 경고 대화상자를 종료한 뒤 그리로 갈 수 있다.
사용자가 폼을 제출하려고 하지만, 필수적인 필드들 중 하나 이상의 입력을 빠뜨렸거나 선택사항을 선택하지 않았다. 서버사이드 유효성검사를 실행한 결과 누락된 필드가 있어서 사용자에게 폼을 다시 보여주고 있다. 다시 보여지는 폼의 상단에서 누락된 필드가 어떤것인지 알려준다. 필수적이지만 누락된 각각의 필드들 역시 텍스트 라벨을 통해 식별되므로, 사용자가 누락된 필드들을 찾기 위해 목록의 맨 위로 돌아갈 필요가 없다.
사용자가 필수적인 필드들을 포함하고 있는 폼을 작성하고 있다. 필드들의 라벨을 통해 그 필드가 필수적인지 아닌지 식별할 수 있다. 사용자가 탭 키를 눌러 필수적인 필드로 들어갔다가, 데이터를 입력하거나 선택사항을 선택하지 않고 다시 탭 키를 눌러서 필드를 빠져나왔다. 클라이언트 사이드 스크립트가 필드의 라벨을 변경해서 그 필드를 빈 상태로 두는 것은 에러임을 알린다.
노트: 일부 스크린 리더는 라벨의 변화를 알아채고 사용자에게 알리지 않을 수 있으므로, 스크린 리더 사용자가 에러에 대해 모를 수도 있다.
폼을 작성하고, 하나 이상의 필수적인 필드가 비어있는 채로 그것을 제출한다.
필수적이지만 채워지지 않은 필드들을 식별하는 텍스트가 제공되었는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자의 입력을 수집하지만 허용되는 값이 제한된 컨텐츠
이 테크닉은 다음과 연관된다:
사용자가 입력한 값이 유효성 검사를 거친 결과 에러가 발견되었을 경우, 기본적으로 사용자가 접근할 수 있는 방법으로 설명되어야 한다. 한가지 접근법은 사용자가 폼을 전송하려고 할 때 에러가 있는 필드를 설명하는 경고 대화상자를 표시하는 것이다. 다른 방법은, 유효성 검사가 서버에서 이루어진다면, 폼을 사용자에게 다시 보여주고(사용자가 입력한 데이터는 여전히 그 필드에 있다), 페이지의 상단에 유효성 검사 문제가 있었으며, 그러한 문제의 본질을 알려주고, 문제가 있는 필드를 쉽게 찾을 수 있는 방법을 제공하는 설명 텍스트를 제공하는 것이다. 성공 기준에서 "텍스트로" 라는 부분은, 단순히 문제가 있는 필드의 라벨에 * 문자를 넣거나, 라벨을 빨간색으로 바꾸는 것은 불충분한 것임을 의미한다. 문제를 설명하는 텍스트가 제공되어야 한다.
입력이 허용된 값들 중 하나여야 한다면, 설명 텍스트는 그러한 사실을 지목해야 한다. 텍스트는 가능한 값의 목록을 포함하거나, 허용된 값들 중 입력된 것과 가장 흡사한 것을 추천하는 것이어야 한다.
사용자가 폼 필드에 잘못된 데이터를 입력하였다. 사용자가 폼을 제출하기 전에, 경고 대화상자가 나타나서 그 에러에 대해 설명함으로서 사용자가 그것을 수정할 수 있게 한다.
사용자가 폼 필드에 잘못된 데이터를 입력하고 전송하였다. 서버는 폼을 되돌리는데, 되돌려진 폼에는 사용자가 입력한 데이터들이 여전히 존재하며, 페이지의 상단에 입력 에러가 있었음을 명확하게 텍스트로 지적한다. 텍스트는 그러한 에러의 본질을 설명하고, 어떤 필드에 문제가 있는지 명확하게 가리킴으로서 사용자가 쉽게 그 필드로 이동하여 문제를 수정할 수 있게 한다.
폼 필드에 잘못된 데이터를 입력한다.
문제에 대한 정보가 텍스트로 제공되는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자의 데이터 입력을 받아들이지만 그 포맷, 값, 형태에 제한을 두는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 제공한 정보를 받아들일수 없는 경우 이를 정정하는데 필요한 도움을 제공하는 것이다. 사용자가 입력한 데이터가 유효성 검사를 거친 결과 에러가 발견되었다면, 에러의 상세와 그 위치가 텍스트로 제공되어 사용자가 그 문제를 식별할 수 있게 한다. 한가지 접근 방법은 클라이언트 사이드 유효성검사를 실행하여, 사용자가 잘못된 데이터를 필드에 입력하는 즉시 그 에러를 설명하는 경고 대화상자를 제공하는 것이다. 다른 접근방법은 서버사이드 유효성 검사를 사용하여, 폼을 다시(이전에 입력된 모든 데이터를 포함한다) 보여주는 것이다. 그 페이지의 상단에는 에러가 있었으며, 어떠한 문제인지, 그리고 문제가 있는 필드를 쉽게 찾을 수 있는 방법을 제공하는 것이다.
어떠한 방법으로든, 설명 텍스트가 제공되었다면, 그것은 다음 중 한가지를 통해 사용자를 도와야 한다:
필드에 입력할 수 있는 정확한 데이터의 예를 제공하거나,
그 필드에 적합한 데이터를 설명하거나,
정확한 데이터 중 사용자가 입력한 것과 흡사한 값을 보여주고, 사용자가 그러한 정확한 값들 중 하나를 입력하는 방법에 대한 지침을 함께 제공해서 사용자가 그렇게 할 수 있도록 한다.
사용자가 폼 필드에 잘못된 데이터를 입력하였다. 사용자가 필드를 벗어날 때, 경고 대화상자가 나타나서 문제에 대해 설명하고 사용자가 그것을 고칠 수 있도록 한다.
사용자가 폼 필드에 잘못된 값을 입력하고 폼을 제출하였다. 서버는 사용자가 입력한 데이터들을 그대로 가지고 있는 폼을 되돌리면서, 페이지의 상단에 입력 에러가 있었음을 명확하게 지목하는 텍스트를 포함시킨다. 텍스트는 문제가 어떠한 것인지 설명하고, 어떤 필드에 문제가 있는 것인지 명확하게 지목하여, 사용자가 쉽게 그것을 찾아내고 문제를 수정할 수 있게끔 한다.
사용자가 폼 필드에 잘못된 값을 입력하고 그것을 제출하려고 한다. 클라이언트 사이드 스크립트가 그 에러를 찾아내고, 제출을 취소시킨 후, 문서를 수정하여 제출 버튼 다음에 에러를 설명하고, 에러가 있는 필드에 대한 링크를 포함하는 설명 텍스트를 추가한다. 스크립트는 또한 문제가 있는 필드의 라벨을 변경하여 그것을 강조한다.
폼을 채워 넣는데, 요구되는 포맷이나 값을 만족하지 않는 것을 입력한다.
에러가 있는 필드를 지목하고, 왜 잘못된 것인지, 어떻게 고칠 수 있는지에 대한 어느정도의 정보를 제공하는 텍스트가 제공되는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
(역주:원문에는 upper secondary education level 이라고 기재되어 있지만 국내 현실과 다르므로 고등 교육 수준이라 옮겼다)
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 복잡한 컨텐츠의 요약을 제공하는 것이다. 원래의 컨텐츠에 더해 요약이 제공된다.
단어와 문장을 해석하기 어렵게 만드는 장애를 가진 사용자들은 복잡한 단어를 읽고 이해하는데에 문제가 있을 수 있다. 이 테크닉은 컨텐츠에 들어 있는 가장 중요한 아이디어와 정보들에 대한 짧은 문장을 제공한다. 요약은 원본에 비해 짧은 문장이고, 좀더 일반적인 단어들을 사용하므로 읽기 쉽다.
요약을 준비하기 위해 다음의 단계들을 사용할 수 있다:
컨텐츠에서 가장 중요한 아이디어와 정보들을 찾는다.
같은 아이디어와 정보를 표현하는, 더 일반적인 단어들과 짧은 문장으로 하나 이상의 문단들을 작성한다. (문단들의 숫자는 원래 컨텐츠의 길이에 따라 다르다)
요약이 읽기 쉬운지 판단한다.
요약을 편집한다. 긴 문장을 둘로 나누거나, 길거나 익숙치 않은 단어들을 짧고, 좀더 일반적인 단어들로 교체할 것을 고려한다.
3과 4를 필요한 만큼 반복한다.
기술 혁신을 설명하는 기사가 있다. 기사의 제목 바로 다음에 나오는 첫번째 것은 "요약" 이라는 헤딩을 갖는 섹션이다. 요약에 들어 있는 문장들의 평균 길이는 16개의 단어이고(기사의 문장들은 평균 23개 단어로 이루어져 있다), 기사에서 사용되는 기술적인 전문 용어들 대신 짧고 일반적인 단어들을 사용하고 있다. 읽힘성readbility 공식이 적용되었다; 요약은 중등 교육 수준 이하의 독해 능력을 요구한다.
이 테크닉에 연관된 자원이 없다.
보풀적인 컨텐츠로 제공된 각각의 요약들에 대해 :
요약의 읽힘성 정도를 측정한다.
요약이 중등 교육 수준 이하의 독해 능력을 요구하는지 확인한다.
# 2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
자막을 지원하는 사용자 에이전트가 있는 시청각 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 청각 장애가 있거나, 혹은 다른 이유로 인해 동기화된 미디어의 대화를 듣는 것에 어려움을 갖는 사람들이, 청각에 문제가 없는 사람의 도움을 요청하지 않고도 그러한 매체와 대화, 소리들을 볼 수 있게끔 하는 것이다. 이 테크닉을 통해 모든 대화와 중요한 소리들이, 사용자가 요청하지 않으면 보이지 않는 텍스트로 포함된다. 결과적으로, 그것들은 필요할 경우에만 보인다. 이것은 사용자 에이전트에서 캡션에 대한 특별한 지원을 요구한다.
노트 : 캡션을 자막과 혼동해서는 안된다. 자막은 대화에 대한 텍스트만을 제공할 뿐, 중요한 소리는 포함하지 않는다.
예제 1: 청각장애인 사용자들이 그들의 인터랙티브 교육 소재를 이용할 수 있도록 하기 위해, 대학에서는 그들의 모든 인터랙티브 청각 교육 프로그램에서 캡션과 함께 캡션을 켜는 지침을 제공하고 있다.
예제 2: 미디어 판매점의 모든 온라인 영화들이 캡션을 포함하고 있고, 클로즈드 캡션의 포함을 허용하는 포맷으로 제공된다.
예제 3: 동기화 정보를 포함한 특별한 캡션이 영화에 제공된다. 화면에서, 영화 창과 동기화된 별도의 창에서 캡션을 재생할 수 있는 플레이어를 사용할 수 있다.
예제 4: 지역 뉴스 이벤트의 비디오는 플레이어에 따라 비디오에 오버레이된 상태로도, 또는 분리된 창에서도 재생될 수 있는 캡션을 제공하고 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
캡션 가이드
SMIL
다른 캡션
미디어 플레이어의 클로즈드 캡션 기능을 켠다
동기화된 미디어 컨텐츠를 본다
모든(대화들과 중요한 소리들의) 캡션이 보이는지 확인한다.
#3 을 만족한다
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 각각의 웹 페이지에 설명적인 타이틀을 제공하는 것이다. 설명적인 타이틀은 사용자가 타이틀 자체에서 컨텐츠와 방향을 찾고 탐색하는데 도움을 준다. 설명적인 타이틀은 사용자가 자신이 사용하고 있는 웹 페이지가 어떤 것이며, 언제 변경되었는지 쉽게 식별할 수 있게 해준다. 설명적인 타이틀은 사용자가 페이지 컨텐츠를 읽거나 해석하지 않고도 웹 페이지를 식별하도록 하는데 사용될 수 있다. 사용자들은 정확하고 설명적인 타이틀이 사이트맵이나 검색 결과 목록에 제공될 때 자신이 원하는 컨텐츠를 더 빠르게 식별할 수 있다. 설명적인 타이틀이 링크 텍스트에서 사용되었을 때, 그것들은 사용자가 자신이 흥미를 갖는 컨텐츠를 더 정확하게 탐색하는데에 도움을 준다.
각각의 페이지의 타이틀은 :
웹 페이지의 목적을 명확히 해야 하고,
컨텐츠와 분리되어 읽혔을 때 - 예를 들어 스크린 리더에 의해 읽히거나, 사이트맵 혹은 검색결과 목록에 있을 때 - 에 의미가 있어야 하고,
짧아야 한다.
또한 타이틀이 다음과 같다면 도움이 된다 :
웹 페이지가 속하는 사이트, 혹은 다른 자원을 명시한다.
웹 페이지가 속하는 사이트, 혹은 다른 자원에서 유일하다.
큰 조직체 내의 그룹에서 웹 페이지를 출판했다. 페이지의 타이틀은 첫째로 페이지의 토픽을 명시하고, 그룹의 이름 다음에 조직체의 이름을 보여주고 있다.
예제 코드:
<title>채용 정보: 그룹 이름: 조직 이름</title>
2004년 남아시아 쯔나미에 관한 동기화된 미디어가 "2004년 쯔나미" 라는 타이틀을 갖고 있다.
클로즈드 캡션을 생성하는 가이드라인과 제안들을 제공하는 웹 페이지가 있다. 이 웹 페이지는 더 큰 사이트의 "서브 사이트"의 일부분이다. 타이틀은 - 문자를 이용해서 3부분으로 나뉜다. 첫번째는 조직을 나타낸다. 두번째는 이 웹 페이지가 속하는 서브 사이트를 나타낸다. 세번째는 웹 페이지 자신을 나타낸다. (실제 사용되고 있는 예를 보려면, WGBH – Media Access Group – Captioning FAQ 을 보라.)
현재 판본만을 볼 수 있도록 허용하고 있는 사이트에 "국내 뉴스, 첫 페이지" 라는 타이틀이 붙은 웹 페이지가 있다. 다른 날짜의 판본을 볼 수 있도록 허용하는 페이지는 "국내 뉴스, 첫 페이지, 2005년 10월 17일" 이라는 타이틀을 갖고 있다.
이 테크닉에 연관된 자원이 없다.
웹 페이지에 타이틀이 있는지 확인한다.
타이틀이 웹 페이지의 컨텐츠와 관련이 있는지 확인한다.
타이틀을 통해 웹 페이지를 유일하게 식별할 수 있는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자로부터 정보를 수집하며, 사용자가 제공할 수 있는 형식을 제한하는 페이지
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자들이 입력해야 하는 데이터 형식에 대한 제한에 관한 정보를 제공함으로서 입력 에러를 피할 수 있도록 돕는 것이다. 이것은 데이터가 가져야 하는 포맷의 샘플을 제공하거나, 그러한 포맷의 특징을 설명함으로서 이루어질 수 있다.
노트: 날짜와 시간 같은, 일반적인 변형들을 갖는 데이터 포맷의 경우, 사용자가 가장 편리하게 입력할 수 있는 포맷을 사용할 수 있도록 프리퍼런스 옵션을 제공하는것이 유용할 수 있다.
다음의 HTML 날짜 폼 컨트롤은 날짜가 미국의 대다수의 사용자가 가정하는 월-일-년 형태가 아니라, 반드시 일-월-년 형태로 입력되어야 함을 라벨에 표시하고 있다.
예제 코드:
<label for="date">Date (dd-mm-yyyy)</label>
<input type="text" name="date" id="date" />
주어진 포맷으로만 사용자가 입력한 데이터를 받아들이는 폼 컨트롤들을 식별한다.
1 단계에서 식별된 폼 컨트롤들이 예상되는 포맷에 대한 정보를 제공하는지 판별한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
컨텐츠가 기능성을 포함하는 모든 기술들에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 키보드, 혹은 키보드 인터페이스에 의존하는 사람들이 컨텐츠의 기능성에 접근할 수 있도록 하는 것이다. 이렇게 하기 위해서, 키보드가 아닌 UI 이벤트에 의해 활성화되는 모든 이벤트 핸들러들이 키보드 기반 이벤트들에도 연결되도록 하거나, 다른 장치 종속적인 기능들에 의해 제공되는 기능들을 달성하는 충분한 키보드 기반 메커니즘을 제공하라.
예제 1: 드랙-앤-드롭 기능사용자가 드랙-드롭 기능을 사용하여 온라인 앨범에 있는 사진들을 슬라이드 쇼 프리젠테이션 용도로 재정렬 할 수 있는 기능을 가진 사진 프로그램이 있다. 이것은 또한 사용자가 키보드만 가지고 사진을 선택하여 '잘라내고' 목록의 적당한 위치에 '붙여넣기' 할 수 있는 기능 역시 포함하고 있다.
예제 2: 재정렬 기능사용자가 질문 항목을 적절한 위치로 드래그함으로서 설문조사를 만들어 낼 수 있는 웹 프로그램이 있다. 이 프로그램의 질문 목록에는 텍스트 필드가 있어서, 사용자가 거기에 적절한 숫자를 입력함으로서 원하는대로 질문 항목들을 재정렬하는 기능도 있다.
이 테크닉에 연관된 자원이 없다.
모든 기능들이 키보드만을 사용하여 접근 가능한지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 링크의 목적을 링크의 텍스트에서 설명하는 것이다. 설명은 사용자가 이 링크를 웹 페이지에 있는 다른 링크들로부터 구별하도록 하고, 사용자가 그 링크를 따라갈지의 여부를 결정하는데 도움을 준다. 목적지의 URI는 일반적으로 충분한 설명이 되지 못한다.
예제 코드:
<a href="routes.html">
이것은 Boulders Climbing Gym 를 가리킨다.
</a>
이 테크닉에 연관된 자원이 없다.
이 테크닉을 사용하는 컨텐츠의 모든 링크에 대해:
링크의 텍스트가 링크의 목적을 설명하는지 확인한다.
위 확인을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 짧은 대체 텍스트로 충분하지 않은 경우에, 텍스트가 아닌 컨텐츠에 대해 동일한 목적을 수행하고 동일한 정보를 전달하는 긴 대체 텍스트를 제공하는 것이다.
짧은 대체 텍스트와 합쳐져서, 긴 설명은 텍스트가 아닌 컨텐츠를 대체할 수 있는 것이어야 한다. 짧은 대체 텍스트는 텍스트가 아닌 컨텐츠를 식별하고, 긴 대체 텍스트는 정보를 제공한다. 만약 텍스트가 아닌 컨텐츠가 페이지에서 제거되고, 짧고 긴 설명들로 대체되었다 해도, 페이지는 여전히 동일한 기능과 정보를 제공할 것이다.
대체 텍스트로 어떤 것을 사용할 것인지 결정하는데 있어서 다음과 같은 질문들이 도움이 될 것이다.
텍스트 아닌 컨텐츠가 여기에 존재하는 이유는 무엇인가?
그것이 어떤 정보를 제공하고 있었나?
그것이 수행하던 목적은 무엇이었나?
텍스트가 아닌 컨텐츠를 사용할 수 없었다면, 같은 기능과 정보를 전달하기 위해서 나는 어떤 단어들을 사용했을까?
10월의 판매량을 보여주는 차트에 "10월 세일즈 차트" 라는 짧은 대체 텍스트가 사용되었다. 긴 대체 텍스트는 다음과 같을 것이다 : "10월의 판매량을 보여주는 막대 차트. 6명의 판매원을 보여준다. Maria가 349개를 판매하여 1등이다. Frances가 301개를 판매하여 그 다음이다. 다음으로 256개를 판매한 Juan, 250개를 판매한 Sue, 200개를 판매한 Li, 195개를 판매한 Max 이다. 이 차트의 우선적인 목적은 리더들을 보여주는 것이므로, 설명은 판매량 순서이다."
과거 10년의 겨울 평균 기온을 보여주는 그래프에 "1996-2006의 평균 겨울 기온" 이라는 짧은 대체 텍스트가 사용되었다. 긴 설명에는 이 그래프를 작성하기 위해 사용된 데이터 테이블이 포함되어 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트가 아닌 컨텐츠를 제거하거나, 감추거나, 가린다.
긴 설명을 보여준다.
긴 설명이 텍스트가 아닌 컨텐츠에서 전달하는것과 같은 정보를 전달하는지 확인한다.
#3 is true.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 동기화된 미디어 기술, 클로즈드 캡션을 지원하지 않는 것도 포함한다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 농인이거나 다른 이유로 시청각 자료의 대화를 듣는데 어려움이 있는 사람들에게 그러한 자료를 볼 수 있는 방법을 제공하는 것이다. 이 테크닉을 통해 모든 대화와 중요한 소리들이 비디오 트랙에 텍스트로 포함된다. 결과적으로 그것들은 항상 보이고, 사용자 에이전트가 캡션에 대해 특별한 지원을 할 필요는 없다.
노트: 캡션과 자막을 혼동해서는 안된다. 자막은 대화의 텍스트만을 제공하며 중요한 소리들을 포함하지는 않는다.
모든 사람들 - 자신의 미디어 플레이어에서 캡션을 켜는 방법을 모르더라도 - 이 온라인 영화를 볼 수 있도록 하기 위해, 도서관 협회에서는 캡션을 비디오에 직접 삽입하고 있다.
뉴스 조직에서 모든 자료에 오픈 캡션을 제공한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
(목록화된 것이 없다)
클로즈드 캡션이 꺼져 있는 동기화된 미디어를 지켜본다.
캡션(모든 대화와 중요한 소리들의)이 보이는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 원래의 텍스트가 아닌 컨텐츠와 동일한 목적을 수행하고 동일한 정보를 제공하는 대체 텍스트를 생성하는 것이다. 결과적으로, 텍스트가 아닌 컨텐츠를 제거하고 그것을 대체 텍스트로 교체하여도 어떠한 기능성이나 정보도 손실되지 않을 것이다. 이 대체 텍스트는 텍스트가 아닌 컨텐츠를 설명할 필요는 없다. 이것은 동일한 목적을 수행하고, 동일한 정보를 전달하여야 한다. 이따금씩 대체 텍스트가 텍스트가 아닌 컨텐츠를 설명하는 것 처럼 보일수도 있다. 하지만 이것은, 그렇게 하는 것이 동일한 목적을 수행하기 위한 최선의 방법일 경우에 한한다.
가능하다면, 짧은 대체 텍스트가 목적과 정보를 완전하게 전달하여야 한다. 짧은 구문이나 문장을 통해 이렇게 하는 것이 불가능하다면, 짧은 대체 텍스트는 정보의 간단한 미리보기를 제공하여야 한다. 그리고 긴 대체 텍스트를 추가적으로 사용하여 완전한 정보를 전달하게 할 수 있다.
이 대체 텍스트는 텍스트가 아닌 컨텐츠를 대체할 수 있는 것이어야 한다. 텍스트가 아닌 컨텐츠가 페이지에서 제거되고 텍스트로 대체되었다고 하더라도, 페이지는 같은 기능과 정보들을 제공할 수 있어야 한다. 대체 텍스트는 간결한 것이어야 하지만 가능한 만큼의 정보를 전달할 수 있어야 한다.
(역주:원문에서는 would~ 를 사용하고 있지만 이것을 우리말로 옮겼을때 의미가 전달되지 않아, should~ 를 사용한 것 처럼 의역하였다)
대체 텍스트로 어떤 것을 사용할 것인지 결정하는데 있어서 다음과 같은 질문들이 도움이 될 것이다.
텍스트 아닌 컨텐츠가 여기에 존재하는 이유는 무엇인가?
그것이 어떤 정보를 제공하고 있었나?
그것이 수행하던 목적은 무엇이었나?
텍스트가 아닌 컨텐츠를 사용할 수 없었다면, 같은 기능과 정보를 전달하기 위해서 나는 어떤 단어들을 사용했을까?
텍스트가 아닌 컨텐츠가 그것을 이해하는데에 중요한 단어들을 포함하고 있는 경우에는, 대체 텍스트 역시 그러한 단어들을 포함해야 한다. 이미지에 들어 있는 텍스트가 짧은 대체 텍스트에 다 들어갈 수 없다면, 그러한 사실을 짧은 대체 텍스트에 설명하고 완전한 텍스트를 긴 대체 텍스트로 제공해야 한다.
검색 버튼이 돋보기 그림을 사용하고 있다. 대체 텍스트는 "검색" 이어야 하며 "돋보기" 여서는 안된다.
매듭을 짓는 방법을 보여주는 그림에 매듭을 짓기 위해 밧줄이 어떻게 움직여야 하는지를 보여주는 화살표가 포함되어 있다. 대체 텍스트는 그림이 어떻게 생겼는지 설명하는 것이 아니라 매듭을 짓는 방법을 설명하는 것이다.
장난감을 정면에서 본 그림이 있다. 대체 텍스트는 장난감을 정면에서 본 모습을 설명하고 있다.
타이어를 교체하는 방법을 보여주는 애니메이션이 있다. 짧은 대체 텍스트는 애니메이션이 무엇에 관한 것인지 설명한다. 긴 대체 텍스트는 타이어를 어떻게 교체하는지 설명한다.
TechTron 회사의 로고가 그 회사의 제품 목록에 있는 각각의 상품 다음에 나타나며, "TechTron." 이라 읽히는 짧은 대체 텍스트를 갖고 있다.
10월의 판매량을 보여주는 차트에 "10월 판매량 차트" 라는 짧은 대체 텍스트가 붙어 있다. 이것은 또한 차트에 있는 모든 정보들을 제공하는 긴 설명 역시 갖고 있다.
이미지로 처리된 단어, "전쟁의 역사" 를 포함하는 제목이 있다. 그 이미지의 대체 텍스트는 "전쟁의 역사" 이다.
선반에 놓여진 도서 시리즈에 대한 그림이 있다. 그림에는 인터랙티브한 영역이 포함되어 있는데, 그 영역은 각각의 책에 대한 웹 페이지로의 탐색을 제공한다. 대체 텍스트는 "이 섹션에서 구입할 수 있는 책들입니다. 자세한 정보를 보려면 책을 선택하십시오" 라고 되어 있어서, 이미지와 그 인터랙티브한 속성을 설명하고 있다.
이 테크닉에 연관된 자원이 없다.
텍스트가 아닌 컨텐츠를 제거하거나, 감추거나, 가린다.
대체 텍스트로 교체한다.
손실된 것이 없는지 확인한다(텍스트가 아닌 컨텐츠의 목적이 대체 텍스트로 충족된다)
텍스트가 아닌 컨텐츠가 그것을 이해하는데 중요한 단어들을 포함하고 있다면, 그 단어들이 대체 텍스트에 포함되어 있다.
#3 을 만족한다. 텍스트가 아닌 컨텐츠가 그것을 이해하는데 중요한 단어들을 포함하고 있다면, #4 역시 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉은 원래의 텍스트가 아닌 컨텐츠와 동일한 목적을 수행하고 동일한 정보를 전달하기에 필요한 텍스트가 너무 길거나, 텍스트만으로 이러한 목적을 완수할 수 없는 경우에 사용된다. 그러한 경우 이 테크닉은 텍스트가 아닌 컨텐츠를 간단히 설명하는 짧은 대체 텍스트를 제공하기 위해 사용된다. (그리고 다른 테크닉을 통해 긴 대체 텍스트를 제공하며, 두가지의 조합을 통해 원래의 텍스트가 아닌 컨텐츠와 동일한 목적을 수행하고 동일한 정보를 전달하게끔 한다)
대체 텍스트로 어떤 것을 사용할 것인지 결정하는데 있어서 다음과 같은 질문들이 도움이 될 것이다.
텍스트 아닌 컨텐츠가 여기에 존재하는 이유는 무엇인가?
그것이 어떤 정보를 제공하고 있었나?
그것이 수행하던 목적은 무엇이었나?
텍스트가 아닌 컨텐츠를 사용할 수 없었다면, 같은 기능과 정보를 전달하기 위해서 나는 어떤 단어들을 사용했을까?
10월 판매량을 보여주는 차트에 "10월 판매량 차트" 라는 짧은 대체 텍스트가 붙어 있다. 차트는 또한 차트의 모든 정보들을 제공하는 긴 설명도 가지고 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
테그트가 아닌 컨텐츠의 간단한 설명을 제공하는 짧은 대체 텍스트가 있는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
컨텐츠의 렌더링에 대한 설명을 사용자에게 제공하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 페이지의 아이템들이 형태, 크기, 소리, 위치로만 참조되는 것이 아니라, 그러한 감각적 지각에만 의존하지 않는 방법을 통해서도 참조되는 것을 확실히 하는 것이다. 예를 들어, 참조는 아이템의 기능을 함께 설명할수도 있고, 그 라벨을 함께 설명할수도 있다.
폼을 제출하고 다음 단계로 이동하기 위한 둥근 버튼이 폼에 포함되어 있다. 버튼은 "go" 라는 텍스트로 명명되었다. 지침에는 "폼을 전송하기 위해서는 "go" 라는 이름의 둥근 버튼을 누르시오" 라고 되어 있다. 이것은 버튼을 찾아내기 위해 모양 정보와 텍스트 정보를 모두 포함한 것이다.
온라인 훈련을 제공하는 웹 페이지에 다음과 같은 지침이 있다 : "원하는 온라인 과정으로 이동하기 위해 '클래스 목록' 이라는 제목이 붙어 있는 오른쪽의 링크 목록을 사용하시오". 이 설명은 올바른 링크 목록을 찾는 것을 돕기 위해 텍스트 단서와 함께 위치를 제공하고 있다.
다음의 레이아웃은 오른쪽 하단에 버튼을 위치시키고, 위치로서 그것을 인지시키고 있다. 텍스트 라벨을 알려줌으로서, 위치 정보가 무의미한 선형화된 버전을 사용하고 있는 사용자에게도 어떤 버튼을 이용할지 명확히 하고 있다.
예제 코드:
<table>
<tbody>
<tr>
<td colspan="2">오른쪽 하단의 [미리보기] 버튼을 누르시오.</td>
<td>
<span style="background: ButtonFace; color: ButtonText; border:
medium outset ButtonShadow;
width: 5em; display: block; font-weight: bold; text-align: center;">
Print</span>
</td>
</tr>
<tr>
<td>
<span style="background: ButtonFace; color: ButtonText; border:
medium outset ButtonShadow;
width: 5em; display: block; font-weight: bold; text-align: center;">
Cancel</span>
</td>
<td>
<span style="background: ButtonFace; color: ButtonText; border:
medium outset ButtonShadow;
width: 5em; display: block; font-weight: bold; text-align: center;">
OK</span>
</td>
<td>
<span style="background: ButtonFace; color: ButtonText; border:
medium outset ButtonShadow;
width: 5em; display: block; font-weight: bold; text-align: center;">
Preview</span>
</td>
</tr>
</tbody>
</table>
이 테크닉에 연관된 자원이 없다.
(현재 목록화된 것이 없다)
웹 페이지에서 객체의 모양, 크기, 또는 위치를 언급하는 모든 참조를 찾는다. 각각의 아이템에 대해:
그러한 참조가 모양, 크기, 혹은 상대적인 위치에 대해 아무것도 모르더라도 가리키는 아이템을 찾고 식별할 수 있는 추가적인 정보를 제공하는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 약어의 확장된 형태를 그 약어가 웹 페이지에 처음으로 등장할 때 연결시킴으로서 그러한 확장을 사용 가능하도록 만드는 것이다. 모든 약어의 확장은 웹 페이지를 처음으로 사용하기 위해 검색할 때 찾을 수 있다.
단어, 구절, 이름을 약어, 두문자어, 또는 기타 축약된 형태로 사용할 때는, 그러한 약어 형태를 제공하기 전에 완전한 형태를 제공하라. 이렇게 하면 텍스트를 읽기가 쉬워지며, 많은 스타일 가이드들에서 이렇게 하는 것을 추천한다.
일부 약어들은 확장보다는 설명을 필요로 한다는 점에 유의하라. 이 테크닉은 그러한 약어들에는 적합하지 않다.
이 테크닉은 웹 페이지에서 약어가 처음으로 나타날 때 적용된다. 여러가지 자원들을 하나의 웹 페이지로 합칠 경우에는, 약어가 각각의 자원들의 처음에서 확장될 것이다. 그러나, 이러한 경우에는, 확장된 형태를 제공하기 위해 다른 테크닉을 사용하는 것이 좀 더 적합할 수 있다.
"UN난민고등판무관실 (UNHCR) 은 난민들에게 보호와 원조를 제공하기 위해 1950년도에 설립되었다."
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
컨텐츠에 들어있는 각각의 약어에 대해,
저술된 부분에서 약어가 처음으로 사용된 곳을 찾는다.
처음 사용된 곳 바로 앞에 약어의 확장된 형태가 있는지 확인한다.
그 확장된 형태가 그 약어의 사용에 대한 올바른 확장된 형태인지 확인한다.
#2 와 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
테스트 데이터처럼 데이터를 제출하는 그 시점에 특화된, 그리고 한번 제출되면 수정할 수 없는 데이터를 사용자로부터 수집하는 사이트.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 되돌릴 수 없는 작업을 실행하기 전에 사용자들이 자신의 입력이 정확한지 확인할 수 있는 방법을 제공하는 것이다. 테스트, 재무, 법률 어플리케이션들은 "작업 취소" 가 불가능한 작업을 사용한다. 일단 작업이 한번 제출되면 사용자들이 에러를 정정할 기회가 없으므로, 데이터 제출에 에러가 없어야 하는 점이 중요하다.
간단한, 1 페이지의 폼에서는 사용자가 폼을 제출하기 전에 살펴볼 수 있으므로 이것이 쉽다. 그러나, 여러개의 웹 페이지들로 확장되는 폼의 경우, 데이터는 작업이 제출되기 전에 여러 단계를 거쳐서 수집된다. 사용자는 폼을 전송하는 단계 이전에서 입력했던 모든 데이터를 기억하지 못할 수 있다.
한가지 접근법은 각각의 단계에서의 결과들을 임시로 저장하고, 사용자가 입력한 데이터들을 살펴보고 싶을 때 자신의 마음대로 앞뒤로 이동하는 것을 허용하는 것이다. 다른 접근방법은 모든 단계에서 수집된 모든 데이터들의 요약을 최종적인 작업 전송 이전에 사용자가 살펴볼 수 있도록 제공하는 것이다.
작업을 최종적으로 전송하는 마지막 단계 이전에, 사용자가 자신이 입력한 데이터들을 살펴보고 확인하라는 지침이 제공된다. 사용자가 확인하면, 작업이 완료된다.
(역주:이 장의 설명에서 "작업"은 트랜잭션transaction이며, 이것은 하나의 단위로서 움직여야 되는 여러가지 작업들의 묶음을 말한다. 또한 "최종적인 전송" 은 커밋commit이며, 이것은 트랜잭션 전체를 실행하라는 최종 승인이다. 바로 아래 예제의 계좌이체 전체를 통털어 트랜잭션이라 할 수 있다.)
온라인 뱅킹 어플리케이션에서 계좌들 간의 자금 이체를 완료하기 위해 다음과 같은 여러가지 단계를 제공한다:
"전송할" 계좌를 선택한다.
"전송받을" 계좌를 선택한다.
전송할 금액을 입력한다.
전송할 계좌, 전송받을 계좌, 이체할 금액을 보여주는 트랜잭션 요약이 제공된다. 사용자는 버튼을 눌러서 트랜잭션을 실행할수도, 취소할수도 있다.
테스트 어플리케이션에서 여러 페이지에 걸쳐 질문이 있다. 사용자는 언제라도 이전에 완료한 섹션으로 돌아가서 그것을 검토하고 답을 변경할 수 있다. 마지막 페이지에는 테스트 답안들을 전송하거나, 답안들을 살펴볼 수 있는 버튼들이 제공된다.
여러 단계를 거쳐서 사용자로부터 데이터를 수집하는, 테스트 어플리케이션 혹은 재무, 또는 법률 트랜잭션이 발생하는 것에서:
사용자가 이전 단계로 돌아가서 데이터를 살펴보고 그것을 바꿀 수 있게 허용되는지 판단한다.
트랜잭션을 최종 승인하기 전에 사용자가 입력한 모든 데이터의 요약을 제공하는지, 그리고 필요하다면 에러를 수정할 방법이 제공되는지 확인한다.
#1 또는 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자의 액션에 의해 컨텐츠가 삭제될 수 있는 컨텐츠.
이 테크닉은 다음과 연관된다:
웹 어플리케이션에서 정보를 삭제할 수 있는 기능을 제공할 경우, 서버는 사용자의 실수로 삭제된 정보를 복구할 수 있는 수단을 제공할 수 있다. 한가지 접근방법은 단순히 삭제 표시만을 함으로서 삭제를 미루거나, 혹은 임시 영역(휴지통과 같은)으로 옮겨두고 실제로 삭제할 때 까지 얼마간 대기하는 방법이다. 이러한 시간 동안, 사용자는 데이터 복구를 요청하거나, 아니면 임시 영역에서 그것을 받을 수 있다. 다른 접근방법은 모든 삭제 트랜젝션들을 처리하는 과정을 사용자가 요청한다면 데이터를 복구할 수 있는 방법 - 예를 들어 위키나 소스 컨트롤 어플리케이션에서 하듯 수정 내역을 저장하는 방법이다. 가져올 수 있는 정보들은 트랜잭션을 수정할 때 필요할 그것이어야 한다.
사용자가 폴더를 만들고 그 안에 데이터를 저장할 수 있도록 하는 웹 어플리케이션이 있다. 각각의 폴더와 데이터 아이템은 그것을 액션과 연관시키는 체크박스가 있으며, 이동을 위한 버튼과 삭제를 위한 버튼이 있다. 사용자가 삭제 버튼을 실수로 눌렀을 경우, 대량의 데이터가 손실될 수 있다. 어플리케이션은 사용자에게는 데이터가 바로 삭제된것처럼 표시하지만, 실제 삭제는 1주일 뒤로 예약한다. 1주일간, 사용자는 "삭제된 아이템" 폴더로 가서 실제 삭제를 위해 대기중인 폴더나 데이터의 복구를 요청할 수 있다.
컨텐츠의 삭제를 허용하는 기능을 식별한다.
컨텐츠를 삭제한 후, 복구를 시도한다.
삭제된 정보가 복구될 수 있는지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
All technologies
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 설령 텍스트가 아닌 컨텐츠가 특정한 감각적 경험을 제공하도록 의도된 경우라도 사용자가 그것을 식별할 수 있도록 하는 것이다. 예를 들어, 농인은 오디오 연주 파일이 무엇인지 알기를 원할 수 있다 - 비록 그것을 들을수는 없지만. 흡사하게, 맹인은 시각 이미지의 주제가 무엇인지 알기를 원할 수 있다 - 비록 그것을 볼 수는 없지만.
예제 1: 모나리자 그림에 다음과 같은 대체 텍스트가 붙어 있다 "모나 리자, 레오나르도 다 빈치"
예제 2: 사운드 파일에 다음과 같은 대체 텍스트가 붙어 있다 "테라민을 연주하는 5학년생들".
예제 3: 유명한 모던 아트가 다음과 같이 레이블되어 있다 "Red, Blue and Yellow, by Piet Mondrian"
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
대체 텍스트가 설명적인 이름을 제공하는지 확인한다.
대체 텍스트가 저자, 혹은 다른 사람에 의해 텍스트가 아닌 컨텐츠에 붙여진 이름을 제공하는지 확인한다.
#1 또는 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 일반적이지 않은, 혹은 제한된 방법으로 사용된 모든 단어들의 정의를 제공하는 것이다.
다음과 같은 경우 단어는 일반적이지 않은, 혹은 제한된 방법으로 사용된 것이다:
사전들은 단어의 정의를 다양하게 제공하지만, 컨텐츠를 이해하기 위해서는 하나의 특정한 정의만을 이용해야 한다.
컨텐츠를 이해하기 위해 하나의 특정한 정의를 이용해야만 하며, 사전은 그러한 정의를 드문, 낡은, 고립된, 등으로 표시한다.
컨텐츠를 이해하기 위해 반드시 이용해야 할 새로운 정의를 저자가 만들어내었다.
이 테크닉은 전문용어의 정의를 제공하는데도 사용할 수 있다. 전문용어란, 일부 전문적인, 또는 기술적인 분야에서 사용되고 그러한 분야에 있는 사람들은 이해하지만 그 분야 밖에 있는 사람들은 이해하지 못하는 어휘를 말한다.
이 테크닉은 또한 숙어적 표현을 정의하는데도 사용할 수 있다. 예를 들어, 특정 지역에 사는 사람들은 그 지역에 사는 모든 이들이 이해하지만, 같은 언어를 사용하지만 다른 지역에 사는 사람들은 이해하지 못하는 숙어적 표현을 사용할수도 있다.
"기술" 이라는 단어는 초기 인류가 사용하던 돌로 된 도구들로부터, 최근의 핸드폰과 같은 디지털 장비에까지 폭넓게 사용된다. 하지만 WCAG 2.0 에서 기술이란 단어는 좀 더 제한된 방법으로 사용된다: 그것은 사용자 에이전트에 의해 표현되고, 재생되고, 실행되는 지침들을 인코딩하는 메커니즘을 의미하며, 웹 컨텐츠를 만들어내고 전달하는데 사용되는 마크업 언어, 데이터 포맷, 프로그래밍 언어 들을 포함한다.
"에테르" 라는 단어는 우주 공간을 채우고 있는 물질을 정의하는 단어이다: "그는 소리가 에테르를 통해 전파된다고 믿었다."
"드라이버" 라는 단어는 프린터에 사용될 특정한 지침들을 담고 있는 소프트웨어를 정의한다: "당신의 프린터를 위한 드라이버를 업데이트해야 할 수 있습니다."
몇몇 사람들은 "비밀을 드러낸다" 라는 의미로 "콩을 쏟는다" 라는 말을 쓴다, 예를 들어, "경찰서에서, Joe 는 수상 납치 계획에 대해 콩을 쏟았다."
이 예제는 일본어에서 사용되는 숙어적 표현의 정의를 제공하기 위해 삽입구를 사용하고 있다. 일본어에서 "그가 스푼을 집어던진다" 라는 표현은, 그가 할 수 있는 일이 아무것도 없고 마침내 포기했다는 의미이다.
さじを投げる（どうすることもできなくなり、あきらめること）。
사용자들은 다른 언어로부터 받아들여진 익숙치 않은 단어의 의미를 이해하지 못할 수도 있다: "We need to leave town pronto (quickly).
일본어에서, 가타카나는 외래어에 쓰인다. 단어들이 사용자에게 익숙치 않다면, 그들이 이해할 수 있게끔 의미나 번역을 제공하라.
アクセシビリティ（高齢者・障害者を含む全ての人が利用できること）は、Webサイトに不可欠である。
영어 번역: "접근성" (이것은 고령자와 장애인을 포함한 모든 사용자들이 접근할 수 있는 것이다)은 웹사이트의 필수적인 양상이다.
レイアウトテーブルとCSSの併用をハイブリッド（複合型）という。
영어 번역: 레이아웃 테이블과 CSS를 모두 사용하는 것을 "하이브리드"(여러가지 형태의 조합) 라고 부른다.
이 테크닉에 연관된 자원이 없다.
일반적이지 않은, 혹은 제한된 방법으로 사용된 각각의 단어와 구문에 대해:
그 단어나 구문의 정의가 제공되는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 약어를 이해하는데 필요한 정보를 제공하는 것이다.
약어란 단어, 구절, 또는 이름의 축약된 형태이다. 대부분의 약어에 대해, 단어, 구절, 혹은 이름 전체를 제공하는 것으로 충분하다.
일부 약어들은 외국어에서 차용한 단어나 구절을 나타낸다. 예를 들어, 다음의 짧은 목록에서 표시되는 것과 같은, 영어에서 흔히 쓰이는 많은 약어들이 라틴어 구절에서 가져온 것이다. 여기에서 주어진 확장된 형태는 단순히 배경 정보로서 제공된 것이다. 이러한 분류에 속하는 약어들에 대해서는, 원래의 확장된 형태보다는 설명을 제공하는 것이 좀 더 유용하며, 설명이 확장 대신 제공된다.
| 약어 | 라틴 원형 | 설명 |
|---|---|---|
| a.m. | ante meridiem | 점심 전; 아침 |
| p.m. | post meridiem | 점심 후; 오후 |
| e.g. | exempli gratia | 예를 들어 |
| cf | confer/conferatur | 비교 |
약어가 확장을 필요로 하지 않는 경우(예를 들어, 원래의 형태가 그것이 참조하는 조직에 의해 제거되었거나, 약어 자체가 언어의 일부가 된 경우), 적합하다면 설명을 제공하고, 그렇지 않다면 약어를 설명이 필요치 않은 단어로 취급한다.
몇몇 약어들은 한가지 이상의 의미를 가지며, 그 의미는 문맥에 따라 다르다. 예를 들어, ADA는 어떤 문맥에서는 "미국 치과 협회"를 뜻하며, 다른 문맥에서는 "장애를 가진 미국인들"을 뜻한다. 문맥과 연관된 확장만을 제공할 필요가 있다.
다음의 문장에서, "예를 들어" 라는 설명이 "e.g." 에 대해 제공될 수 있을 것이다: 팀 스포츠, e.g., 야구 또는 축구, 에 참가하는 학생들은 팀 연습 시간에 맞춰서 자신의 스케줄을 조절해야 한다
몇몇 언어(영어와 네덜란드어를 포함하여)는 독일어에서 차용한 두문자어 ABS(Antiblockiersystem: anti-lock brakes)를 사용한다. 확장 대신 설명(anti-lock brakes)이 제공된다.
더 이상 확장을 포함하지 않는 약어들의 예제
여름 언어학 학교, 를 의미하는 SIL은 이제 그 자체로서 하나의 이름이다. SIL의 역사를 보기 바란다.
교육 관리 시스템, 을 의미하는 IMS는 이제 그 자체로서 하나의 이름이다.
이 범주의 예제들에 대해서는, 조직이 무엇인지, 혹은 어떤 일을 하는지에 대한 짧은 설명으로 충분하다.
네덜란드어 "밤에" 를 의미하는 "'s nachts"는 원래 "des nachts"의 약어였다. 현재의 네덜란드에서는, "des"라는 단어는 좀처럼 사용되지 않으며 구식으로 받아들여진다. 그러한 확장을 제공하는 것은 혼란스러울 수 있다. 따라서 "'s nachts"에 대해서는 확장을 제공하지 않는다.
영어 구절 "o'clock"는 원래는 "of the clock" 의 약어였다. 이제 "o'clock" 이 영어의 일부가 되었으므로 확장을 제공할 필요가 없다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
컨텐츠에 있는 각각의 약어에 대해,
약어가 확장된 형태를 갖지 않을 경우, 설명이 제공된다.
약어의 확장된 형태가 다른 언어에서 차용된 것일 경우, 설명이 제공된다.
그렇지 않을 경우, 확장된 형태가 제공된다.
모든 체크사항을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 독해 장애를 가진 사용자들이 컨셉이나 과정들을 설명하는 어려운 텍스트를 이해할 수 있도록 하는 것이다. 텍스트에 더해 일러스트레이션들이 제공된다.
단어와 문장들을 해석하는 것을 어렵게 하는 장애를 가진 사용자들은 복잡한 문장을 읽고 이해하는데에 어려움을 느낄 수 있다. 차트, 다이어그램, 애니메이션, 사진, 그래픽 오거나이저, 기타 시각적 재료들이 이러한 사용자들에게 종종 도움이 된다. 예를 들어:
차트와 그래프는 사용자들이 복잡한 데이터를 이해하는 것을 돕는다.
다이어그램, 순서도, 비디오, 애니메이션들은 사용자들이 과정을 이해하는 것을 돕는다.
컨셉 맵과 기타 그래픽 오거나이저들은 사용자들이 개념들의 관계를 이해하는데 도움을 준다.
사진, 그림, 비디오들은 사용자들이 자연적인, 혹은 역사적인 사건들이나 객체들을 이해하는데 도움을 준다
연례 보고서에서 회사의 작년 성장에 영향을 미친 다양한 요인들을 다루고 있다. 보고서는 또한 그 요인들이 어떻게 상호작용하는지를 묘사하는 차트와 그래프를 포함하고 있다. 각각의 차트와 그래프는 성공기준 1.1.1 에서 요구하는 대체 텍스트들 역시 포함하고 있다. 각각은 또한 번호가 붙은 캡션을 갖고 있다. 이러한 번호는 텍스트에서 차트나 그래프를 참조하는데 사용된다.
상품의 온라인 문서에 단계별 설명서가 포함되어 있다. 각각의 단계는 화면이 어떻게 나타나는지 보여주는 스크린샷으로 묘사되어 있다. 각각의 스크린샷들은 성공기준 1.1.1에서 요구하는 대체 텍스트를 포함하고 있다.
2004년의 쓰나미를 다루는 웹 사이트가 있다. 사이트에서는 쓰나미가 인도양 주변의 여러 지역들에 어떤 영향을 미쳤는지 설명하고 있다. 각각의 지역의 재해에 대한 사진들이 첨부되어 있다. 각각의 사진은 성공기준 1.1.1에서 요구하는 대체 텍스트를 포함하고 있다. 사이트는 또한 쓰나미 기간 동안 수중에서 어떠한 일들이 일어났는지 역시 설명하고 있다. 이 설명은 쓰나미가 어떻게 발생하고, 바다 위에서 어떻게 확산되는지 보여주는 애니메이션을 통해 이루어진다. 애니메이션은 성공기준 1.1.1에서 요구되는 대체텍스트를 포함하고 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
Hall, T., and Strangman, N. CAST: 그래픽 오거나이저. NCAC Publications의 2005년 4월 5일자에서 발췌함. 이 기사는 몇몇 종류의 그래픽 오거나이저를 묘사한다. 각각의 타입이 어떻게 유용한지 설명하고, 그래픽 오거나이저가 어떻게 학습을 돕는지, 특히 학습 장애를 가진 학생들에게 어떤 도움이 되는지에 대한 연구를 요약한다.
Tufte, Edward. 정보를 심상에 그리기. Cheshire, Conn.: Graphics Press. 1990.
Tufte, Edward. 양적 정보의 시각 표현. Cheshire, Conn.: Graphics Press. 1983.
Tufte, Edward. Visual explanations : 이미지와 양, 증거와 서술. Cheshire, Conn.: 1997.
(현재 목록화된 것이 없다)
컨텐츠를 이용하기 위해 반드시 이해하여야 할 아이디어나 과정을 서술한 텍스트를 찾는다.
시각적 일러스트레이션이 컨텐츠 내부에서, 혹은 컨텐츠의 링크를 통해 이용 가능한지 확인한다.
시각적 일러스트레이션이 텍스트에서 서술된 컨셉이나 과정들을 보여주는지 확인한다.
#2 와 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자 인증을 요구하고, 데이터 전송에 시간 제한을 두는 웹 페이지
이 테크닉은 다음과 연관된다:
사용자 인증을 요구하는 웹 서버들은 종종 사용자가 일정 시간동안 아무 행동이 없는 경우 세션을 종료한다. 사용자가 데이터를 충분히 빠르게 입력할 수 없었고 전송 전에 세션이 끝나버린 경우, 서버는 진행하기 전에 재인증을 요구할 것이다. 이러한 경우, 서버는 사용자가 로그인하는 동안 데이터를 임시적인 캐쉬에 저장하고, 사용자가 재인증되면 데이터를 캐쉬에서 꺼내어, 폼은 마치 그러한 타임아웃이 발생하지 않았던 것 처럼 진행된다. 서버는 캐쉬를 무한정 보관하는 것은 아니며, 단일 사용자 세션에서 성공적인 재인증을 보장할 정도의 기간 - 예를 들어 하루 - 동안만 보관한다.
사용자가 포럼에 로그인해서 답글을 올린다. 답글을 작성하는 동안 걸린 시간이 서버에서 연결을 끊는 제한시간보다 길었다. 사용자는 답신을 전송했고, 타임아웃되었다는 응답을 받았으며 요청을 전송하기 위해 다시 로그인할 것을 요구받았다. 사용자가 작성한 답글은 서버에서 유지되었고, 로그인이 성공적이었다면 답글은 정상적으로 처리된다. 만약 로그인이 실패하였다면 답글은 제거된다.
사용자가 인증 영역으로 로그인하여 폼을 채워넣고 있다. 세션은 보안상의 이유로 타임아웃되었다. 폼 데이터는 서버에서 유지되고, 사용자는 타임아웃되었으니 다시 로그인할 것을 요청받는다. 사용자가 정확히 로그인한다면, 폼은 이전에 입력했던 모든 데이터가 유지된채로 사용자에게 보여지고, 폼을 전송할 수 있다. 만약 로그인에 실패한다면 폼 데이터는 제거된다.
데이터 전송을 위해 사용자 로그인을 요구하는 사이트에서,
로그인하고, 시간제한이 있는 작업을 시작한다.
세션이 타임아웃되도록 한다.
데이터를 전송한다.
다시 인증한다.
작업을 진행할 수 있고 데이터 손실이 없는지, 원래의 데이터와 재인증후 변경한 것이 전부 보존되는지 확인한다.
#5 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 예측할 수 있는 방법을 통해 여러가지 것들을 활성화하는 것이다. 인식 장애를 가진 사용자들과, 스크린 리더 혹은 화면 확대기를 사용하는 사람들은 자동적인 폼 전송이라든가 문맥의 변화를 일으키는 기능의 활성화 같은, 예측하지 못한 이벤트들에 혼란을 느낄 수 있다.
이 테크닉을 통해, 문맥에 가해지는 모든 변경은 사용자 관점에서의 특정한 행동에 의해 활성화될 것이다. 이에 더해, 그러한 행동은 일반적으로 문맥의 변화를 초래하는 것들, 예를 들어 링크를 클릭하거나 전송 버튼을 누르는 것 들이다. 단순히 어떤 요소로 포커스를 이동하는것은 문맥의 변화를 초래하지 않을 것이다.
새 창을 띄우기 위해 onfocus 이벤트를 사용하지 않고, 사용자가 버튼을 클릭한(또는 스페이스바를 누른) 경우에만 새 창을 띄운다.
사용자가 "완료" 버튼을 탭으로 선택했을때 다음 화면이 나타나게끔 하지 않고, 제출 버튼을 눌렀을 때 다음 데이터 입력 화면으로 이동하게끔 하였다.
이 테크닉에 연관된 자원이 없다.
(현재 목록화된 것이 없다)
키보드를 사용해서, 모든 컨텐츠에 포커스를 주면서 순회한다.
어떤 컴포넌트가 포커스를 받더라도 문맥의 변화가 일어나지 않음을 확인한다.
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
이름과 역할을 노출하고, 사용자가 설정할 수 있는 속성들을 직접 설정할 수 있게 하고, 바뀐 점을 알려주는 것이 가능한 마크업 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 보조 기술들이 웹 컨텐츠를 이해하여, 대체적인 사용자 인터페이스를 통해 동일한 정보를 전달하고, 사용자들이 보조 기술을 통해 컨트롤들을 조종할 수 있도록 하는 것이다.
이 테크닉은 표준적이고, 문서화되고, 지원되는 기능들을 보조 기술에 노출하는 것을 포함한다. 이것은 표준적인 브라우저들에서 사용하는 표준적인 컨트롤들이 요구사항에 부합하는 것에 의존한다.
HTML에서는 이렇게 가정해도 좋다. 다른 기술에서도 적합할 수 있다.
컴포넌트가 접근성을 지원하는 경우에도, 일부 정보는 저자에 의해 제공될 필요가 있다. 예를 들어, 컨트롤은 이름을 제공할 수 있는 기능을 갖고 있지만, 여전히 저자가 그 이름을 제공해야 한다. 반면에 역할 특성은 그것이 고정된 역할을 수행하는 표준 컴포넌트이므로 이미 제공되고 있을 수 있다.
예제 1: HTML, 또는 XHTML로 씌어진 웹 페이지가 표준적인 폼 컨트롤을 사용하며, title 속성을 통해 폼 컨트롤을 식별한다. 사용자 에이전트는 이 컨트롤에 대한 정보 - 이름을 포함하여 - 를 DOM과, 플랫폼에 특화된 접근성 API를 통해 이용할 수 있도록 만든다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
마크업을 시각적으로 살펴보거나 도구를 사용한다.
식별할 수 있는 각각의 사용자 인터페이스에 대해, 이름과 역할 같은 적합한 마크업이 사용되었는지 확인한다.
사용자 인터페이스 컴포넌트들이 모든 조작을 보조 기술로부터 받아들일 수 있도록 적절한 마크업이 이용되었는지 확인한다.
모든 사용자 인터페이스 컴포넌트에 대해 #2 와 #3 을 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자를 혼란스럽게 하지 않으면서 클라이언트 사이드 리다이렉트를 가능하게 하는 것이다. 리다이렉트는 보통 서버사이드에서 이루어지는 것을 선호하는데(SVR1: 자동 리다이렉트를 클라이언트 사이드 대신 서버 사이드에서 이루어지게 하기 (서버) 를 보라), 서버 사이드 리다이렉트는 서버가 새 URI에 위치한 컨텐츠를 전송하기 전에 새로운 컨텐츠가 표시되게 하는 일이 없기 때문이다. 하지만, 저자들이 항상 서버사이드 기술들에 대한 제어권을 갖고 있는것은 아니다. 그러한 경우에는 클라이언트 사이드 리다이렉트를 사용할 수 있다. 클라이언트 사이드 리다이렉트는 사용자 에이전트가 다른 URI에서 컨첸츠를 가져오도록 지시하는 컨텐츠 내부의 코드에 의해 구현된다. 리다이렉트에서 중요한 것은 목적하는 페이지 또는 웹 페이지가 리다이렉트와 연관된 정보들만을 포함하고 있어야 한다는 것이다.
HTML 4.x와 XHTML 1.x 에서는, meta 요소를 사용하여 클라이언트 사이드 리다이렉트를 구현할 수 있다: H76: 클라이언트 사이드 즉시 리다이렉트를 위해 meta 리프레시 사용하기 (HTML) 를 보라.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
다른 페이지나 웹 페이지를 가리키는 각각의 링크, 혹은 프로그램된 참조를 찾는다.
그러한 것들에 대해, 참조된 웹 페이지가 클라이언트 사이드 리다이렉트를 발생시키는 코드(예를 들어, meta 요소나 스크립트)를 포함하는지 확인한다.
클라이언트 사이드 리다이렉트를 발생시키는 각각의 링크, 혹은 프로그램된 참조들에 대해, 리다이렉트가 시간 제한이나 지현 없이 구현되었는지, 그리고 페이지가 리다이렉트에 관계된 정보만을 포함하고 있는지 확인한다.
2가 거짓이거나 3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
이미지를 지원하는 모든 기술.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 텍스트가 아닌 컨텐츠에서 색상의 차이가 정보를 전달하기 위해 사용되었을 경우, 색상과 무관한 방법으로 같은 정보를 전달하는 패턴이 포함될 것을 확실히 하는 것이다.
부동산 사이트에 미국 여러 지역의 일반적인 주택 가격을 나타내는 막대 차트를 제공한다. 각각의 지역에 대한 막대들은 서로 다른 단일색상과 패턴을 보여준다. 색상의 차이와 패턴의 차이 모두에 성공기준 1.4.1을 만족하는 충분한 대비가 있다. 범례에서는 각각의 막대를 식별하기 위해 동일한 색상과 패턴을 사용한다.
운송 시스템의 온라인 지도에서 각각의 경로를 서로 다른 색상으로 표시하고 있다. 각각의 경로에 있는 경유지들은 마름모꼴, 사각형, 원형과 같은 서로 구별되는 아이콘을 사용하여 각각의 경로를 구별하는 것을 돕는다.
순서도에서 한 과정을 완성하기 위한 반복적인 단계들의 세트를 설명한다. 그것은 지정된 조건을 만족했을 때의 다음 단계를 표시하기 위해 녹색 배경과 화살표를 가진 dashed line (역주 : - - - 처럼 보이는)을 사용하고 있다. 지정된 조건을 충족하지 못했을 경우의 다음 단계는 붉은색 배경과 화살표를 가진 점선을 사용하고 있다. 선의 모양과 배경색은 성공기준 1.4.1을 만족하는 충분한 대비를 가지고 있다.
인터랙티브 게임을 포함하는 컨텐츠가 있다. 게임은 4명의 플레이어로 나뉘며, 각 플레이어는 색상과 패턴을 모두 사용하여 서로 구별된다.
이 테크닉에 연관된 자원이 없다.
정보의 전달을 위해 색상의 차이를 이용하는 웹 페이지 상의 각각의 이미지들에 대해:
색상을 이용해 전달되는 모든 정보가, 색상에 의존하지 않는 패턴을 이용해서도 마찬가지로 전달되는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 일반적이지 않거나 제한된 방법으로 사용된 단어의 정의를 문맥 내에서 제공하는 것이다. 정의는 텍스트로 제공되며, 그러한 단어가 사용되기 직전이나 직후에 제공된다. 정의는 정의하려고 하는 단어와 같은 문장에서 포함될수도 있고, 별도의 문장에 포함될수도 있다.
그는 소리가 에테르, 우주 공간을 채우고 있는 물질로 생각되었던 것을 통해 이동한다고 믿었다.
당신의 프린터 드라이버(드라이버란 당신의 프린터에 특화된 지침들을 포함하고 있는 소프트웨어입니다)를 업데이트해야 할 수 있습니다..
정의: 이 명세서에서 사용하고 있는 키워드 must, must not, required, shall, shall not, should, should not, recommended, may, and optional 들은 RFC 2119에 설명되어있는 대로 해석되어져야 한다.
이 예제는 일본어의 숙어 표현에 대한 정의를 제공하기 위한 삽입구를 사용한다. 일본어에서 "그는 스푼을 집어던졌다" 라는 문구의 의미는, 그는 할 수 없는 일이 없으며 마침내 포기했다는 뜻이다.
さじを投げる（どうすることもできなくなり、あきらめること）。
이 테크닉에 연관된 자원이 없다.
일반적이지 않거나 제한된 방법으로 사용된 각각의 단어나 구절에 대해:
그 단어가 처음 등장한 직전이나 직후에 그것을 정의하는 텍스트가 있는지 확인한다.
#1 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
HTML 4.01, XHTML 1.x를 포함하는 마크업 언어
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 적절하고 의미 있는 요소들을 사용하여 웹 컨텐츠를 마크업하는 것이다. 다른 말로, 요소는 그 의미에 의해 사용되며 시각적으로 나타나는 방법에 의해 사용되는 것이 아니라고 할 수 있다.
적절하고 의미 있는 요소를 사용하면 사용자 에이전트가 그러한 구조를 사용할 수 있음을 확신할 수 있다. 이것은 컨텐츠의 의미를 이해하는데 있어 서로 다른 단위들의 역할을 명시적으로 나타내는 것을 포함한다. 컨텐츠의 부분들은 문단, 헤더, 강조된 텍스트, 테이블 등의 속성을 가지며, 이러한 방법으로 나타낼 수 있다. 몇몇 경우, 컨텐츠의 단위들 사이의 관계 - 제목과 부제목, 또는 테이블 속의 셀 사이의 - 역시 나타내어져야 한다. 이렇게 함으로서, 사용자 에이전트는 사용자가 지각할 수 있는 구조를 만들어낸다 - 예를 들어 서로 다른 종류의 구조들에 서로 다른 시각적 표현을 사용하거나, 음성 표현에서 서로 다른 음성이나 속도로를 사용하는 등이다.
예를 들어, HTML에서, em, abbr, cite 같은 구문 레벨 요소들은 자신이 둘러싸고 있는 단어들에 의미론적 정보를 부가하고, 텍스트를 강조하며, 약어와 인용들을 각각 식별해낸다. 수학에서의 구조와 표현들 사이에서 중요한 구분점들을 유지하도록 디자인된 마크업 언어인 MathML은, 수학적 아이디어들을 나타내기 위해 사용되는 복잡한 표기법들을 "표현하는" 특별한 마크업을 포함하며, 이와 함께 수학적인 아이디어들 자체를 위한 "내용의"(의미적인) 마크업 또한 포함한다.
문단에 다른 페이지로의 하이퍼링크가 포함되어 있다. 하이퍼링크는 a 요소를 이용해 마크업되었다.
예제 코드:
<p>우리의 새로운 도구를 직접 테스트해보시겠습니까? 무료 데모 버전을 우리의
<a href="download.html">다운로드 섹션</a>에서 이용하실 수 있습니다.</p>
결혼의 역사에 관한 페이지에서 제인 오스틴의 소설, 오만과 편견에서 인용한 구절을 예로 들고 있다. 이 책에 대한 참조는 cite 요소로 마크업되었으며, 인용구 자체는 blockquote 요소를 이용해 마크업되었다.
예제 코드:
<p>결혼은 미혼남에게 있어 논리적인 단계로 여겨졌다, 소설
<cite>오만과 편견</cite>의 첫 장에 나타나듯이:</p>
<blockquote>
<p>충분한 부를 소유한 독신 남성이 부인을 원한다는 것은
보편적인 사실이다.</p>
<p>However little known the feelings or views of such a man may
be on his first entering a neighbourhood, this truth is so well
fixed in the minds of the surrounding families, that he is considered
the rightful property of some one or other of their daughters.</p>(번역 생략)
</blockquote>
자동차 매뉴얼에 엔진에 시동을 거는 방법이 설명되고 있다. 지침에는 기어가 중립에 있는 것을 반드시 확인하라는 경고가 포함되어 있다. 저자는 이 경고가 아주 중요한 것이므로, strong 요소를 사용해 마크업해서 충분히 강조되어야 한다고 생각한다.
예제 코드:
<h1>엔진에 시동을 거는 방법</h1>
<p>시동을 걸기 전에, <strong>기어가 중립 상태인 것을
반드시 확인하십시오</strong>. 다음으로, 키를 점화 위치로 돌리십시오.
엔진에 시동이 걸릴 것입니다.</p>
이 예제는 em요소와 strong 요소를 사용해서 텍스트를 강조하는 방법을 보여준다.
예제 코드:
<p>그녀가 <em>정말로</em> 말하고자 했던 것은,
"그것으론 충분치 않다, 그것은 <strong>대단하다</strong>!"</p>
예제 코드:
<style type="text/css">
.vocab {
background-color:cyan;
font-style:normal;
}
</style>
.......
<p>새로운 어휘들은 강조되었고, 푸른색 배경으로
하이라이트 되어 있다.</p>
<p>그 연극에 대한 <em class="vocab">준열한 </em> 리뷰는
약간 지나치게 혹독해 보였다. .... </p>
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
Mathematical Markup Language (MathML) Version 2.0, Second Edition
제프리 젤드만의 책 "웹 표준으로 디자인하기"
Web Design Group의 기사 "문서 스타일: 올바른 태그 사용하기"
컨텐츠에서 의미적인 기능을 갖는 부분이 있는지 확인한다.
의미적 기능을 갖는 각 부분에 대해, 기술에서 그에 대응하는 의미있는 마크업이 존재한다면, 컨텐츠가 그러한 의미있는 마크업을 사용해 마크업되었는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트의 시각적 표현에서 변형을 허용하는 기술들.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 텍스트 포맷의 변형들을 통해 전달된 정보가 텍스트를 통해서도 전달되도록 하는 것이다. 텍스트의 시각적 외형이 정보를 전달하기 위해 변형되었다면, 텍스트를 통해 명시적으로 정보를 선언한다. 시각적 외형의 변화는 폰트 형태, 폰트 크기, 밑줄, 가로지르는 줄, 그리고 기타 텍스트 속성들을 통해 이루어질 수 있다. 이러한 형태의 변화가 정보를 전달한다면, 그러한 정보는 컨텐츠 내의 다른 곳에서 텍스트를 통해서 사용할 수 있어야 한다. 문서의 추가적인 섹션이나, 텍스트 표현의 변형이 있는 곳에 인라인 설명을 통해서 그 정보를 전달할 수 있다.
요약에 반드시 사용되어야 할 단어나 구문이 포함된 문장에서는, 그러한 단어나 구문이 문장의 다른 단어들과는 다른 폰트로 보여진다. 별도의 섹션에서는 또한 요약에서 반드시 사용되어야 할 단어들과 구문들 전체를 목록화하고 있다.
온라인 문서에 몇가지 종류의 초판본이 있다. 삽입된 부분은 밑줄이 그어져 있고 삭제된 부분은 가로지르는 줄이 그어져 있다. 초판의 마지막에는 "변경 이력"이 있어서, 각각의 초판본에 가해진 모든 변경을 목록화하고 있다.
이 테크닉에 연관된 자원이 없다.
텍스트 표현의 변형이 정보를 전달하기 위해 사용된 곳을 찾는다.
그러한 아이템들에 대해, 시각적으로 전달되는 정보가 또한 텍스트로 명시적으로 씌어 있는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은, 최소한 단어가 웹 페이지에서 처음으로 등장하는 경우에는 그 단어 뒤에 발음을을 제공함으로서 단어의 발음을 사용 가능하도록 하는 것이다.
웹 페이지에서 동일한 철자를 갖지만 서로 다른 발음을 갖는 단어들을 사용한다면, 모든 경우에 대해 발음을 제공하지 않는 한 이 테크닉은 적절하지 않다.
이 테크닉은 웹 페이지에서 처음으로 나타나는 약어에 적용된다. 다양한 자원들을 하나의 웹 페이지에 합치는 경우에는, 약어는 각 자원의 처음에서 확장될 것이다. 그러나, 이러한 경우에는, 확장된 형태를 제공하기 위해 다른 테크닉을 사용하는 것이 좀 더 적절할 것이다.
다음 예의 일본어 텍스트에서, 한자(Kanji)의 발음에 관한 정보는 텍스트 바로 뒤에 있는 괄호 안에 나타난다.
예제 코드:
<p> 慶應大学 (けいおう� いがく) </p>
이 테크닉에 연관된 자원이 없다.
발음 정보를 필요로 하는 각각의 단어데 대해:
웹 페이지에서 그 단어가 처음으로 사용된 곳을 찾는다.
처음으로 사용된 직후에 발음이 나타나는지 확인한다.
#2 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 발음에 관한 정보를 같은 웹 페이지, 혹은 다른 웹 페이지에 제공하고, 아이템과 그 발음 사이에 링크를 둠으로서 발음에 관한 정보를 이용할 수 있도록 하는 것이다.
단어가 발음 정보를 포함하는 사전 항목으로 링크되어있다.
단어가 그 발음을 읽는 사운드 파일로 링크되어 있다.
단어가 발음 사전의 항목으로 링크되어 있다.
단어가 그 발음에 대한 국제 표음 알파벳 표현으로 연결되어 있다.
단어가 그 발음의 명확한 표음 스펠링으로 연결되어 있다.
이 테크닉에 연관된 자원이 없다.
발음 정보를 필요로 하는 각각의 단어에 대해:
최소한 그 첫 사용이 링크인지 확인한다.
각각의 링크가 그 발음에 관한 정보를 가리키는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
색상과 텍스트를 지원하는 모든 기술.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 색상과, 텍스트 혹은 문자 단서를 조합하여 정보를 전달하는 것이다. 대부분의 사용자들은 문서를 빠르게 훑어보면서 색상의 차이를 이용하여 전달되는 정보를 찾아낼 수 있다. 색상을 볼 수 없는 사용자들은 텍스트 단서를 보거나 들을 수 있다; 점자 디스플레이나 기타 촉각 인터페이스를 사용하는 사람들은 그러한 텍스트 단서를 만져서 감지할 수 있다.
온라인 폼의 지침에 다음과 같이 씌어 있다, "필수적인 필드들은 붉은색이고, (required) 라는 표시가 붙어 있다." "(required)"가 단서이고, 이것은 label 요소 안에 있다.
예제 코드:
<label for="lastname" class="required">Last name(required):</label>
<input id="lastname" type="text" size="25" value=""/>
.required {
color=red;
}
이 테크닉에 연관된 자원이 없다.
정보의 전달을 위해 색상의 차이를 이용하는 모든 컨텐츠에서:
같은 정보가 텍스트, 혹은 문자 단서로도 이용 가능한지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 블럭의 끝으로 건너뜀으로서 내용 블럭을 지나가는 메커니즘을 제공하는 것이다. 블럭의 첫 링크, 또는 블럭의 바로 앞에 있는 링크는 블럭 직후에 있는 컨텐츠로 포커스를 옮긴다. 링크를 활성화하면 블럭 이전의 키보드 포커스들을 앞서게 된다. 생략해야 할 블럭이 여러개라면, 사용자는 이러한 링크들을 통해 블럭에서 블럭으로 건너뛴다.
기관의 웹 페이지에 내비게이션 바, 또는 메인 메뉴가 있고 그 속에는 사이트의 주요 섹션들, 사이트맵, 기관에 관한 정보, 연락방법에 대한 링크들이 있다. 이 영역의 첫 링크에는 "내비게이션 링크 건너뛰기" 라는 타이틀이 붙어 있다. 사용자는 이 링크를 사용해서 링크들을 건너뛴다.
몇개의 페이지들로 분할된 색인이 도서에 포함되어 있다. 색인의 각 페이지의 시작부분의 내용은 각각의 알파벳 글자이며, 그 글자로 시작하는 항목들의 색인을 가리키는 링크이다. 처음 링크에는 "링크들을 건너뛰어 색인으로 감" 이라는 타이틀이 붙어있다. 사용자는 이 링크를 사용해서 링크들을 건너뛴다.
사이트에 포함된 모든 페이지들에 사이트맵, 기관에 관한 정보, 연락처 정보에 대한 링크들을 포함하는 섹션이 있다. 각각의 섹션에 속하는 모든 페이지들에는 또한 그 서브섹션들을 가리키는 링크 집합이 있다. 첫번째 블럭의 첫번째 링크는 "내비게이션 링크들 건너뛰기" 라는 제목이 붙어 있으며, 링크들의 첫번째 집합을 건너뛴다. 두번째 블럭의 첫번째 링크는 "섹션 링크들 건너뛰기" 라는 제목이 붙어 있으며, 서브섹션 링크들을 건너뛴다.
이 예제는 각 섹션의 시작부분에서 heading 요소를 사용하는것(H69), 그리고 각 섹션의 마지막으로 건너뛰는 링크들을 보여준다. 이렇게 하면 사용자들이 반복된 컨텐츠의 블럭들을 자신의 사용자 에이전트의 기능에 따라 키보드 내비게이션이나 헤딩 내비게이션을 통해 건너뛸 수 있다. 몇몇 섹션들의 내용이 인터넷 익스플로러의 한계를 보완하기 위해 div 로 감싸여 있음을 유의하라(컨텐츠 블럭을 건너뛰는 HTML 링크를 생성하는 방법에 대해서는 사용자 에이전트 노트를 보라).
예제 코드:
<p><a href="#content">Content title</a></p>
<h2>Main Navigation</h2>
<ul>
<li><a href="#subnav">Sub Navigation</a></li>
<li><a href="/a/">Link A</a></li>
<li><a href="/b/">Link B</a></li>
<li><a href="/c/">Link C</a></li>
...
<li><a href="/j/">Link J</a></li>
</ul>
<div class="iekbfix">
<h2 id="subnav">Sub Navigation</h2>
<ul>
<li><a href="#ultranav">Ultra Sub Navigation</a></li>
<li><a href="/suba/">Sub A</a></li>
<li><a href="/subb/">Sub B</a></li>
<li><a href="/subc/">Sub C</a></li>
...
<li><a href="/subj/">Sub J</a></li>
</ul>
</div>
<div class="iekbfix">
<h2 id="ultranav">Ultra Sub Navigation</h2>
<ul>
<li><a href="#content">Content title</a></li>
<li><a href="/ultraa/">Ultra A</a></li>
<li><a href="/ultrab/">Ultra B</a></li>
<li><a href="/ultrac/">Ultra C</a></li>
...
<li><a href="/ultraj/">Ultra J</a></li>
</ul>
</div>
<div>
<h2 id="content">Content title</h2>
<p>Now that I have your attention...</p>
</div>
그리고 CSS는:
예제 코드:
div.iekbfix {
width: 100%;
}
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
링크가 반복된 컨텐츠를 가진 블럭, 또는 블럭의 첫번째 링크 앞에 있는, 포커스를 받을 수 있는 마지막 컨트롤인지 확인한다.
링크의 설명에 블럭을 건너뛴다는 내용이 있는지 확인한다.
링크가 항상 보이는지, 혹은 키보드 포커스를 가질 때 보이는지 확인한다.
링크를 사용하면 포커스를 블럭 바로 다음에 있는 컨텐츠로 옮기는지 확인한다.
링크를 사용한 후, 키보드 포커스가 블럭 바로 다음에 있는 컨텐츠로 이동하는지 확인한다.
위의 확인을 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 블럭의 끝으로 건너뜀으로서 내용 블럭을 지나가는 메커니즘을 제공하는 것이다. 이러한 목록 - 컨텐츠의 시작 부분에 있는 작은 차례와 같은 - 의 링크들은, 컨텐츠의 다른 섹션들로 포커스를 옮긴다. 이 테크닉은 많은 수의 독립적인 섹션들을 가진 페이지 - 포탈 같은 - 에서 특히 유용하다. 섹션 내부에서 블럭을 건너뛰는 다른 테크닉들과 함께 사용할수도 있다.
사이트의 모든 페이지들이 페이지의 주된 컨텐츠, 검색 필드, 내비게이션 바를 각각 가리키는 3개의 링크로 시작한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
이러한 목적으로 제공된 링크 집합들에 포함된 각각의 링크에 대해:
페이지에서 이 링크보다 앞에 있는 컨트롤은 같은 집합에 있는 다른 링크들 이외에는 없는 것을 확인한다.
각각의 링크의 설명에 이것이 컨텐츠 내에 있는 어떤 섹션을 가리킨다는 내용이 있는지 확인한다.
링크가 항상 보이는지, 혹은 키보드 포커스를 가질 때 보이는지 확인한다.
링크를 사용하면 포커스를 컨텐츠의 해당 섹션으로 옮기는지 확인한다.
위의 확인을 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 연관된 웹 페이지들을 가리키는 링크들을 제공함으로서 사용자가 추가적인 정보를 얻을 수 있도록 하는 것이다. 이것은 성공기준 2.4.5를 만족하기에 충분한, 컨텐츠를 찾아내는 테크닉들 중 하나이다. 링크는 웹의 기본적인 컴포넌트이다. 링크는 웹이 컨텐츠들이 서로 그물처럼 연결된 것으로 만드는 메커니즘이다. 대부분의 저자들은 웹 페이지를 만들때 이러한 테크닉을 자동적으로 수용한다.
웹 컨텐츠 접근성 가이드라인 2.0은 가이드라인과 성공 기준에서 사용된 단어들의 정의에 대한 링크, 성공 기준을 만족하는 방법을 설명하는 문서들에 대한 링크, 각각의 섹션에서 그 섹션의 서브섹션들을 가리키는 링크, 그리고 WCAG 1.0 과 WCAG 2.0 비교 체크포인트 를 포함한다. 사용자가 문서를 살펴보면서, 연관된 정보를 찾기 위해 링크를 따라갈 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
웹 페이지의 각 링크들에 대해:
링크가 관련된 정보로 연결되는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 페이지가 속한 집합에 포함된 모든 웹 페이지들에 대한 링크들의 목록을 제공하는 것이다. 이것은 성공기준 2.4.5를 만족하기에 충분한, 컨텐츠를 찾아내는 테크닉들 중 하나이다. 이 테크닉은 웹 페이지들의 작은 집합에만 유효하다. 만약 링크들의 목록이 웹 페이지의 나머지 컨텐츠들보다도 길다면, 사용자들이 웹 페이지를 이해하고 사용하기가 어려울 것이다.
노트: 성공기준 2.4.1 은 이러한 링크 목록을 건너뛰는 테크닉을 요구한다.
가족의 웹 사이트에 모든 가족 구성원의 홈 페이지가 포함된다. 각각의 페이지들은 다른 가족 구성원들의 홈 페이지들에 대한 링크들 목록을 포함한다.
전자책의 각 장들이 분리된 웹 페이지들로 나뉘어져 있다. 각각의 웹 페이지는 책의 모든 장들에 대한 링크들을 포함하는 작은 차례로 시작한다.
이 테크닉에 연관된 자원이 없다.
각각의 웹 페이지들이 사이트 내의 다른 웹 페이지들을 가리키는 링크들의 목록을 포함하는지 확인한다.
그 링크가 대응하는 웹 페이지를 가리키는지 확인한다.
목록이 사이트 내에 있는 모든 웹 페이지들에 대한 링크들을 담고 있는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 현재의 웹 페이지와, 같은 묶음에 들어있는(예를 들어, 같은 사이트에 속한) 다른 웹 페이지들과의 관계를 식별하게끔 하는 것이다. 어떤 경우 이것은 프로그램적으로 이루어질 수 있다 - 예를 들어 HTML 에서 link 요소의 rel 속성을 통해. 다른 경우 페이지의 타이틀에 관계 정보를 포함함으로서 이러한 정보를 제공할 수 있다.
대형 사이트에 수많은 기술들에 대한 교습서와 참고 자료들이 포함되어 있다. 각 페이지의 타이틀은 서브 사이트의 이름과 더불어 그 사이트를 운영하는 조직의 이름을 포함한다.
웹 페이지가 자신이 문서들의 컬렉션에 대한 차례임을 식별시키는 메타데이터를 포함하고 있다. 컬렉션에 속하는 각각의 문서들의 메타데이터는 컬렉션에서 문서의 위치를 식별하고, 차례에 대한 참조를 제공한다.
온라인 교과서가 여러개의 장으로 분할되어 있다. 각각의 페이지의 타이틀은 그 교과서의 제목과 함께, 그 장의 번호와 제목을 포함하고 있다.
이 테크닉에 연관된 자원이 없다.
웹 페이지의 타이틀이 자신이 속한 컬렉션으로의 관계를 설명하는지 확인한다.
웹 페이지에 자신이 속한 컬렉션으로의 관계를 설명하는 메타데이터가 포함되어 있는지 확인한다.
#1 또는 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 내비게이션 용도의 사용자 인터페이스 컴포넌트를 통해 현재 위치에 대한 정보를 제공함으로서 사용자가 방향 감각을 갖게끔 돕는 것이다. 이 테크닉은 웹 페이지가 반드시 순서대로 진행되어야 할 작업 중의 한 단계일 경우 특히 유용한다. 이러한 인식표를 제공함으로서 사용자가 그러한 과정 속에서 자신의 위치를 이해하는 것을 도울 수 있다. 위치는 아이콘 혹은 텍스트를 추가하거나, 그 아이템의 상태를 바꿈으로서 인식시킬 수 있다.
웹 페이지에 탭 패널 스타일의 내비게이션이 구현되어 있다. 패널 탭 목록은 페이지를 가로질러서 표시된다. 현재의 컨텐츠는 패널 탭들의 아래에 보여진다. 사용자가 특정한 패널 탭을 선택하면 컨텐츠는 선택된 탭의 주제를 반영하도록 업데이트된다. 이에 더해, 선택된 탭의 배경 색상은 기본 색으로부터 변경되고, 탭 패널 텍스트 다음에 체크 마크 아이콘이 표시되어서 이것이 현재 패널임일 나타낸다. 체크 마크 아이콘은 적절한 대체 텍스트를 포함한다.
웹 페이지의 레이아웃에서 프레임셋과 프레임을 사용하고 있다. 프레임들 중 하나는 내비게이션 프레임으로 디자인되었고 다른 프레임들은 웹 사이트의 컨텐츠를 표시한다. 사용자가 내비게이션 프레임의 링크를 선택하면, 링크와 관계된 정보가 내용 프레임 내부에 표시된다. 내비게이션 프레임에서 선택된 아이템에 관한 텍스트는 * 문자를 포함하도록 바뀌어서 그것이 선택된 주제임을 나타낸다.
사이트의 내비게이션 바 가 링크들의 목록 형태로 구현되었다. 내비게이션 바는 웹 페이지의 컬렉션에 속한 모든 웹 페이지에서 나타난다. 사용자가 내비게이션 바에 속한 특정 링크에 포커스를 주거나 그 위로 마우스를 가져가면, 그 링크의 배경 색상이 변경된다. 이러한 마우스오버 또는 포커스에 의한 스타일 변화는 웹 페이지의 스타일시트를 이용해 명시되었다. 링크로부터 포커스가 제거되면 스타일은 일반적인 링크 스타일로 바뀐다. 페이지의 내용을 바꾸기 위해 링크를 선택하면 내비게이션 바에서 선택된 링크는, 그 링크를 따라온 결과가 현재의 웹 페이지이므로, 비활성화된다. 배경색을 바꾸는 것은 시각에 문제가 없는 사용자들이 선택된 링크에 대해 시각적인 알림을 제공한다. 링크를 비활성화하는 것은 모든 사용자게에 그것이 현재 선택된 주제임을 알린다.
이 테크닉에 연관된 자원이 없다.
내비게이션 컴포넌트가 웹 페이지 집합 내에서 반복되는 경우:
사용자가 그 내비게이션 유닛 내에서 현재 선택된 아이템을 지목하고 있는지 확인한다.
선택된 아이템이 현재 보여지고 있는 것과 일치하는지 확인한다.
#1 과 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 컨텐츠 내의 섹션 제목들이 설명적이게 만드는 것이다. 설명적인 제목과 타이틀들은(G88: 웹 페이지에 설명적인 타이틀 제공하기을 보라) 사용자에게 컨텐츠와 그 조직에 대한 훑어보기를 제공한다. 설명적인 제목은 컨텐츠 내의 섹션들을, 웹 페이지 전체와의 관계, 그리고 같은 페이지 내의 다른 섹션들과의 관계들 속에서 식별시킨다.
설명적인 제목들은 사용자가 웹 페이지에서 특정한 내용을 찾고, 방향감각을 유지하게끔 돕는다.
저자들은 또한 각 제목의 시작부분에 가장 중요한 정보들을 놓는 것을 고려해볼 수 있다. 이렇게 하면 사용자들이 자신이 필요로 하는 특정한 내용을 찾기 위해 제목들을 훑어볼수 있고, 브라우저나 보조 공학이 제목에서 제목으로 탐색하는 것을 지원할 때 특히 더 유용한다.
재난 발생시 해야 할 일을 설명하는 웹 페이지라면 다음과 같은 제목들을 가질 수 있을 것이다:
예제 코드:
<h1>재난 대비</h1>
<h2>침수 대비</h2>
<h2>화재 대비</h2>
레벨 2 제목들은 그 시작 부분에 눈에 띄는 정보들을 첫 부분에 갖고 있음에 유의하라 (즉, "Preparation for floods", "Preparation for fires", 등).
(역주 : 번역함으로서 의미가 모호해졌다. preparation for flood 란 제목에서, 앞에 위치한 preparation은 공통되는 부분이므로 눈에 띄지 않지만, flood preparation 이라고 쓰면 앞에 위치한 것이 눈에 띄게 된다. 우리말 표현에서는 이러한 대조를 적절하게 표현할 수 없었다.)
한 마을의 역사에 관한 짧은 글에서 그 마을의 발생과 확장을 설명한 후, 현재의 상태에 대해 약간 더 다루고 있다. 웹 페이지의 타이틀은 "우리 마을의 역사" 이다. 첫번째 섹션은 "우리 마을의 시초" 이라 불리고, 두번째 섹션은 "우리 마을의 확장" 이라 불린다. 세번째 섹션은 "우리 마을의 현재"라 블리며, 다음의 서브섹션들로 구성되어 있다: "우리 마을 사람들", "우리 마을 기관들", "우리 마을 건물들".
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
웹 페이지에 제목이 있는지 판단한다.
각각의 제목들이 그 섹션의 내용을 식별하는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 컨텐츠 내에 있는 모든 인터랙티브 컴포넌트들이 그 컴포넌트의 목적을 명확히 하는 라벨을 갖도록 하는 것이다. 기술에 특화된 적절한 테크닉을 이용하여 인터랙티브 컨트롤과 라벨을 연결하면 보조 기술이 그 라벨을 인식하고 사용자에게 보여줄 수 있다.
웹 어플리케이션에서 도시 지도를 제공한다. 사용자는 "줌 인"을 사용하여 맵의 일부분을 더 상세히 볼 수 있고, "줌 아웃"을 사용하여 도시의 더 넓은 부분이 표시되도록 할 수 있다. 컨트롤은 마우스와 키보드 모두로 이용할 수 있다. 컨트롤은 "줌 인(Ctrl + Shift + L)", "줌 아웃(Ctrl + Shift + R)" 이라는 라벨이 붙어 있다.
폼에서 사용자의 이름을 묻고 있다. 이것은 두개의 입력 필드로 이루어져서 사용자의 성과 이름을 묻는다. 첫번째 필드는 "성", 두번째 필드는 "이름" 이라는 라벨이 붙어 있다.
구입 양식이 몇개의 필수 필드들을 포함하고 있다. 필드를 식별하는 것에 더해, 각각의 필수적인 필드들에는 "필수적인" 이라는 단어가 괄호에 감싸여서 들어있는 라벨이 붙어 있다.
이 테크닉에 연관된 자원이 없다.
컨텐츠에 포함된 각각의 인터페이스 컴포넌트에 대해:
그 인터페이스 컴포넌트의 목적을 식별한다.
필요한 라벨이 붙어 있는지 확인한다.
각각의 라벨이 컴포넌트의 목적을 명확히 하는지 확인한다.
#2 와 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
여러 부분으로 구성된 폼을 포함하는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 여러 부분으로 구성된 폼에서 추가적인 시간을 요청할 수 있는 체크박스를 제공함으로서 장애를 가진 사용자들이 작업내용을 잃어버릴 위험을 최소화하는 것이다. 체크박스는 사용자가 정해진 만큼의 추가시간(예를 들어, 15분)을 요청하거나, 무제한적인 연장을 요청할 수 있게 한다. (무제한적 연장을 허용하는 것이 사용자 프라이버시, 혹은 네트워크 보안을 무질서하게 만드는 경우는 그러한 허용이 적절치 못함을 유의하라)
다섯개의 부분으로 구성된 폼의 첫번째 부분을 포함하는 웹 페이지가 있다. 폼을 작성하는 일반적인 지침들 바로 뒤에, "폼의 각 부분을 완성하는데 15분의 추가 시간을 요청합니다" 라는 라벨이 붙어 있는 체크박스가 있다.
웹 페이지에 3개의 부분으로 구성된 폼의 첫 페이지가 포함되어 있다. 폼의 각 부분은 10개 이상의 항목을 포함한다. 몇가지 아이템은 사용자가 추가적인 정보를 얻기 위해 링크를 따라갈 필요가 있다. 폼을 작성하는 일반적인 지침들 바로 뒤에, "이 폼을 완성하기 위해 내가 필요로 하는 만큼의 시간을 요청합니다. 폼의 마지막 부분까지 완성하기 전에 그만두기로 했다면 반드시 웹 브라우저를 닫아야 한다는 것을 이해합니다." 라는 라벨이 붙어 있는 체크박스가 있다.
웹 페이지가 여러개의 부분들로 구성된 폼의 첫 페이지를 포함하고 있다면:
웹 페이지가 폼을 완성하기 위해 추가적인 시간을 요청하는 체크박스를 포함하고 있는지 확인한다.
체크박스를 체크했을 경우 폼을 완성하기 위한 추가적인 시간이 제공되는지 확인한다.
모든 확인을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 마크업 언어, 그리고 다른 많은 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 명세의 형식에 맞게 유효성검사를 거치지 않은 코드들로 인해 웹 페이지가 종종 모호해지는 현상을 방지하는 것이다. 각각의 기술에서 그 기술과 그 버전, 그리고 웹 페이지가 그러한 기술 명세의 형식에 맞게 유효성 검사를 거쳤다는 사실을 명시하는 메커니즘이 사용된다. 기술에 맞는 유효성 검사기를 사용할 수 있다면, 개발자가 그것을 이용할 수 있다.
유효성 검사는 일반적으로 모호성(그리고 그 이상)을 제거하는데, 왜냐하면 유효성 검사에서 필수적인 과정이 그 기술의 마크업(마크업 언어에서) 또는 코드(다른 기술에서)이 제대로 사용되었는지 확인하는 것이기 때문이다. 유효성 검사는 명세의 요구사항들을 완전히 충족하는지 확인할 필요는 없으며, 그 명세에 맞게 자동적으로 내용을 체크하는 것이 최선의 방법이다.
HTML 페이지는 문서 형태 선언 (이따금씩 !DOCTYPE 이라 불리는)을 포함하며, 그러한 선언에서 명시된 HTML 버전에 맞게끔 유효하다. 개발자는 오프라인, 혹은 온라인 유효성 검사기(아래 자원을 보라)를 이용하여 HTML 페이지의 유효성을 검사할 수 있다.
XHTML, SVG, SMIL, 기타 XML 기반 문서들은 문서 형태 정의(DTD), 또는 다른 형태의 XML 스키마를 참조한다. 개발자는 오프라인, 혹은 온라인 유효성 검사기(편집기에 내장되어 있는 것을 포함하여)를 이용하여 XML 페이지의 유효성을 검사할 수 있다.
XML 파일들의 일괄 유효성 검사를 위해 아파치 Ant 의 xmlvalidate 작업을 이용할 수 있다. 다음의 아파치 Ant는 dev\\Web 디렉토리에 들어 있는 .xml 확장자를 가진 파일들의 유효성 검사를 수행하는 간단한 예제이다.
예제 코드:
<target name="validate-xml">
<xmlvalidate lenient="no">
<fileset dir="dev/web" includes="*.xml" />
</xmlvalidate>
</target>
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
W3C 품질 보증 계획Initiative의 doctype을 추가하는 것을 잊지 마시오는 어떤 문서 타입들이 있으며 왜 그것을 사용해야 하는지 설명한다.
W3C 품질 보증 계획의 당신의 웹 문서에서 사용할 수 있는 추천되는 DTD들 은 일반적으로 사용되는 선언들의 목록이다.
내 코드의 유효성을 어떻게 검사하고, 있을 수 있는 에러들은 어떻게 방지하는가? 는 무료 HTML-kit 에 들어있는 HTML, CSS, XML 을 체크하는 도구에 대해 설명한다.
HTML 과 XHTML 유효성검사
월드 와이드 웹 컨소시엄에서 제공하는 W3C 마크업 유효성검사 서비스 는 당신이 URI, 파일 업로드, 그리고 완전한 HTML, XHTML 문서를 직접 입력하여 HTML, XHTML 파일의 유효성을 검사할 수 있게 한다. 파일을 업로드하는 확장된 인터페이스, URI를 통해 유효성 검사를 하는 인터페이스(인코딩과 문서 타입 같은 더 많은 옵션들)들이 분리된 페이지에 존재한다.
W3C 마크업 유효성검사 서비스를 위한 문서화된 설치과정은 이 서비스를 설치하는 방법을 설명한다(예를 들어, 인트라넷에서 사용하기 위해).
HTML 유효성 검사기는 W3C 마크업 유효성검사 서비스의 독일어 버전이다.
Web Design Group 에서 제공하는 WDG HTML 유효성 검사기는 하나의 페이지, 혹은 사이트 전체의 URI를 입력할 수 있게 한다. 또한 일괄처리 모드(검사할 HTML 문서들의 URI를 하나 이상 명시함으로서)로 웹 페이지들의 유효성 검사를 할 수 있는 버전, 파일 업로드에 의한 버전, HTML 코드의 직접 입력을 통한 버전도 있다.
오프라인 HTMLHelp.com 유효성검사기 는 유닉스 사용자들을 위한 도구이다. 이것은 WDG HTML 유효성 검사기의 오프라인 버전이다.
Igor Podlubny 교수의 오프라인 HTML 유효성 검사기 – NoteTab을 위한 클립북은 프로그래밍 에디터인 NoteTab에서 사용할 수 있는 확장 기능이다. 이것은 James Clark의 오픈소스 SGML 파서를 사용하는데, 이 파서는 W3C의 마크업 유효성검사 서비스에서도 사용된 것이다.
Jan Kacur의 윈도우즈용 오프라인 HTML 유효성 검사기는 James Clark의 오픈소스 SGML 파서에 기초한 또 다른 버전의 유효성 검사기이다. 소스코드(델파이)도 이용 가능하다.
Matti Tukiainen의 Do-it-yourself 오프라인 HTML 유효성 검사기는 James Clark의 오픈소스 SGML 파서를 이용하여 윈도우즈에서 간단한 유효성 검사기를 만드는 방법을 설명한다.
Peter Kranz의 전체 사이트 유효성검사는 맥 OS에서 W3C 마크업 유효성 검사 서비스의 수정된 버전을 설치하고 유효성 검사 결과를 XML로 출력하는 방법을 설명한다. Perl과 Python 언어로 된 소스 코드도 사용할 수 있다.
HTML 유효성검사 위젯은 인터넷 익스플로러의 컨텍스트 메뉴에 옵션을 추가하고, 현재 HTML 문서를 Web Design Group의 HTML 유효성 검사기를 통해 검사할 수 있게 한다.
HTML 유효성 검사를 위해 W3C의 마크업 유효성 검사 서비스를 사용할 수 있을까요?는 무료 에디터인 HTML-Kit에서 HTML 유효성 검사를 하는 방법을 설명한다.
HTML/XML 유효성 검사기 는 Tidy 와 PHP 5에 기초해서 온라인으로 HTML 과 XHTML을 수정하는 도구이다. 여러 언어 버전이 있지만 진짜 유효성 검사기는 아니다.
제프리 젤드만의 당신의 사이트를 정합한 DOCTYPE으로 고치시오!는 HTML 과 XHTML의 문서타입이 어떤 일을 하는지, 그리고 몇몇 브라우저의 렌더링 모드에 어떤 영향을 미치는지 설명한다.
Carrie Bickner의 올바른 XHTML을 생성하도록 드림위버 수정하기
Christoph Schneegans의 XHTML-Schemata für FrontPage 2003 und Visual Studio .NET 는 프론트페이지 2004과 비주얼 스튜디오 .넷 에서 올바른 코드를 생성하기 위해 W3C의 XML 스키마를 사용하는 방법을 설명한 독일어 기사이다.
Nvu는 W3C의 마크업 유효성 검사 서비스를 호출하는 오픈소스, 무료 웹 저작도구이며 윈도우즈, 매킨토시, 리눅스에서 사용할 수 있다.
W3C의 Amaya 는 문서를 저장할 때 유효성검사 에러들을 고치도록 경고하는, HTML, XHTML, CSS, SVG, MathML 를 지원하는 오픈소스, 무료 웹 저작도구이다.
웹 개발자 도구 는 모질라 파이어폭스와 Flock의 확장이며, Chris Pedrick 이 개발하였다. HTML과 CSS에 대해 W3C 유효성검사 서비스를 이용할 수 있게 해준다.
XML 유효성검사
HTML/XHTML/WML/XML 유효성 검사기 URI, 또는 파일 업로드를 통해 유효성 검사를 할 수 있다. 확장된 인터페이스도 사용할 수 있다.
HTML/XHTML/WML/XML 유효성 검사기같은 유효성 검사기의 독일어 버전이다.
XML 유효성 검사기 - 문서 유효성 검사 서비스 JavaView 가 개발했으며, XML 파일의 문법 준수 여부와 유효성을 검사한다. 파일업로드, 코드 직접입력을 지원한다.
Apache Ant의 XMLValidate Task 를 사용해서 XML 기반 문서의 유효성 검사를 할 수 있다. 이 도구를 사용하면 디렉토리 전체(와 서브디렉토리)의 XML 파일들을 검사할 수 있다.
XML Schema 유효성 검사기 는 Christoph Schneegans 가 개발한 온라인 툴이며 파일 업로드, URI, 완전한 XML 문서, XML 코드의 직접 입력 등을 통해 XML(XHTML)의 유효성 검사를 지원한다. 북마클릿 역시 지원하여, 현재 보고 있는 페이지의 유효성 검사를 할 수도 있다. 이 유효성 검사기는 W3C의 것보다 더 정확하다고 주장하고 있다.
XML Schema 유효성 검사기 DecisionSoft 에서 제공하는 온라인 툴이며, W3C XML 스키마를 이용해 XML 파일의 유효성을 검사할 수 있게 해준다. 둘 모두를 업로드 할 수 있다.
STG XML 유효성검사 폼 브라운 대학의 Scholarly Technology Group 에서 지원하며, XML 파일을 URI, 파일 업로드, 전체 XML 문서의 직접 입력을 통해 유효성 검사를 할 수 있다.
NetBeans: Working with XML, Part 1, NetBeans: Working with XML, Part 2 Tim Boudreau 외. 오픈소스 NetBeans 프레임워크에서 XML 지원을 활성화 하는 방법, 유효성검사, 기타 관련있는 기능들을 설명한다.
Schema 유효성 검사기: 텍스트 박스에 XML, 그리고 W3C XML 스키마를 붙여넣어서 XML 코드의 유효성을 검사할 수 있는 툴이다.
XML Nanny: a graphical tool for validating XML 과 XHTML의 유효성 검사를 할 수 있는 그래픽 도구이며, DTD, W3C XML 스키마, RELAX NG, Schematron(Max OX X)을 지원한다.
많은 프로그래밍 에디터, XML 에디터, 통합 개발 환경(IDE) 들이 XML 파일의 유효성을 검사할 수 있음을 참고하라. 이러한 것에는 아래의 무료, 그리고/또는 오픈소스인 도구들을 포함한다:
프로그래밍 에디터인 JEdit 는 XML과 SideKick 플러그인이며 DTD, W3C XML 스키마를 지원한다.
“workbench" Eclipse 와 Web Tools Platform,
웹 저작 도구인 SCREEM, Gnome 데스탑 환경 용이고 DTD를 지원한다
XML 에디터 Jaxe, Apache Xerces와 함께 XML 파일의 유효성 검사를 지원한다
XML 에디터 Xerlin, DTD와 W3C XML 스키마 일부를 지원한다
XML 에디터 xmloperator, DTD와 RELAX NG 스키마를 지원한다
nXML 모드의 Emacs (YahooGroup Emacs nXML Mode 를 보라),
XML 에디터 Pollo, DTD, W3C XML 스키마, RELAX NG 스키마를 지원하며, 트리와 같은 XML 파일들에 가장 잘 어울린다.
CSS 유효성검사
W3C CSS 유효성검사 서비스 에서 URI, 파일 업로드, 또는 CSS 코드의 직접 입력을 통해 유효성검사를 할 수 있다.
W3C CSS 유효성 검사 서비스: URI 는 확장된 인터페이스이며 CSS 스타일시트, 혹은 CSS가 포함된 HTML 파일, CSS 프로필과 매체를 지정할 수 있고, 표시되어야 할 경고의 형태를 선택할 수 있다.
CSSCheck Web Design Group 에서 제공하며, URI와 CSS 코드의 직접 입력을 통한 유효성검사를 지원한다. 이것은 기본적으로 CSS 1을 체크함을 유의하라.
CSSCheckUp Web Design Group 에서 제공하며, 파일 업로드를 통해 유효성 검사를 할 수 있다. 이것은 기본적으로 CSS 1을 체크함을 유의하라.
CSS (Cascading Style Sheets) 유효성 검사기 URI를 통한 유효성검사를 지원한다.
(현재 목록화된 것이 없다)
HTML, SGML 기반, XML 기반 기술들에서:
각각의 페이지 혹은 문서를 유효성 검사 파서에 로드한다.
유효성 검사 에러가 없는 것을 확인한다.
CSS에 대해:
CSS 유효성 검사기에 외부, 혹은 내부 스타일시트를 로드한다.
유효성 검사 에러가 없는 것을 확인한다.
다른 기술들에 대해:
그러한 것이 있다면, 사용하는 기술에 대해 정의된 유효성 검사 과정을 따른다.
HTML, SGML 기반, XML 기반 기술들에서:
#2를 만족한다.
CSS에 대해:
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
접근성 API와 상호작용하도록 프로그램되어진 표준 컴포넌트들을 갖는 프로그래밍 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 보조 기술이 웹 컨텐츠를 이해하고, 대체 사용자 인터페이스를 통해 동일한 정보를 사용자에게 전달할 수 있도록 하는 것이다.
이따금씩, 컨텐츠는 마크업 언어가 아니라 프로그래밍 언어 또는 도구에 의해 생성된다. 많은 경우, 이러한 기술들은 이미 접근성 API와 상호작용하도록 프로그램되어진 인터페이스 컴포넌트들을 가지고 있다. 저자가 이러한 컴포넌트들을 사용하고 속성(예를 들어, 이름, 기타)을 채워 넣는다면 그 결과인 사용자 인터페이스 컴포넌트는 보조 기술에서 접근할 수 있을 것이다.
웹 페이지에서 애플릿을 생성하기 위해 자바를 사용한다. 자바 스윙 객체(예를 들어, pushbutton)가 사용되었는데, 왜냐하면 이것들이 이미 만들어진 접근성 속성들을 가지고 있고 이러한 속성들은 자바로 작성된 보조 기술에서 접근할 수 있으며, 운영체제의 접근성 API를 사용하는, 다른 프로그램 언어로 작성된 것들 역시 자바 억세스 브릿지를 통해 이러한 속성들에 접근할 수 있기 때문이다. 저자는 컴포넌트의 값들을 채워 넣었고, 결과적으로 이것을 보조 기술에서 이용할 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
(현재 목록화된 것이 없다)
접근성있는 사용자 에이전트를 이용하여 컨텐츠를 렌더링한다.
사용자 에이전트의 접근성 API를 위해 디자인된 접근성 도구를 이용하여 각각의 사용자 인터페이스 컴포넌트를 펑가한다.
각각의 사용자 인터페이스 컴포넌트의 이름과 역할을 도구가 찾아내는지 확인한다.
각각의 사용자 인터페이스 컴포넌트에 대해 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
일차적인 내용이 WCAG 의 요구사항에 어긋나지만, 그에 부합하는 대체 버전이 존재하는 경우. 이 테크닉은 대체 버전으로의 접근 가능한 링크를 생성하는 것이 가능한 기술에서만 사용 가능하다.
이 테크닉은 다음과 연관된다:
(역주:이 테크닉에 대해, "올바른" 이라는 단어로 conforming to WCAG - WCAG의 요구사항에 부합하는 - 을 나타내고, "올바르지 않은" 이라는 표현으로 not conforming to WCAG - WCAG의 요구사항에 어긋난 점이 있는 - 을 나타낸다.)
이 테크닉의 목적은 사용자가 특정 URI를 방문하였을때 마주치는 일차 컨텐츠, 혹은 기본 컨텐츠가 올바르지 않은 경우 올바른 대체 페이지를 이용할 수 있도록 하는 것이다. 대체 페이지, 혹은 올바른 대체 버전은 요구사항에 부합하기 위해 몇가지 기능이나 디자인을 절충할 수 있지만, 올바른 대체 버전이 되기 위해 정의에서 설명된 요구사항을 반드시 만족해야 한다. "올바른 대체 버전"의 정의는:
다음을 만족하는 버전
지정된 레벨에서 요구사항에 부합하고,
올바르지 않은 컨텐츠와 동일하게 업데이트되었고,
다음중 최소 하나를 만족해야 한다:
노트 1: 이 정의에서, "을 통해서만 도달할 수 있다" 라 함은 예를 들어 조건부 리다이렉트와 같은 메커니즘이 있어서 사용자가 올바른 버전에서부터 오지 않았다면 올바르지 않은 페이지에 "도달"(로딩) 할 수 없음을 의미한다.
노트 2: 대체 버전은 원래의 페이지와 일치할 필요는 없다(예를 들어, 올바른 대체 버전은 여러개의 페이지로 구성될 수도 있다).
노트 3: 다양한 언어 버전들이 사용 가능하다면, 올바른 대체 버전은 매 언어에 대해 제공되어야 한다.
노트 4: 대체 버전은 다른 기술 환경이나 다른 사용자 그룹을 수용하도록 제공될 수 있다. 각각의 버전은 가능한 만큼 올바른 것이어야 한다. 적합성 요구사항 1 을 만족하기 위해, 그중 한가지 버전은 완전히 올바른 것이어야 한다.
노트 5: 올바른 대체 버전이 꼭 유효범위 내에 있어야 하는 것은 아니며, 다른 웹 사이트에 존재하여도 된다. 올바르지 않은 버전에서 자유롭게 이용할 수 있기만 하다면.
노트 6: 대체 버전과 보충적 컨텐츠를 혼동해서는 안된다. 보충 컨텐츠는 원래의 페이지를 지원하며 서술을 개선하는 것이다.
노트 7: 컨텐츠 내에 사용자 프리퍼런스 세팅을 두고, 그것을 통해 올바른 버전을 만드는 것은, 다른 버전에 도달하는 받아들일만한 메커니즘이다. 그러한 프리퍼런스를 설정하기 위해 사용한 방법이 접근성을 지원하기만 한다면.
올바른 대체 버전 에 대한 이해 를 보라
이 테크닉을 이용할 때, 올바른 대체 컨텐츠를 가리키는 링크를 페이지 맨 위에 둠으로서 사용자가 그러한 링크를 빨리 발견하고 올바른 대체 버전으로 이동할 수 있게 한다. 사용자가 사이트의 어디에 들어가든지 대체 버전을 항상 발견할 수 있도록, 명시된 레벨에 대해 올바르지 않은 모든 페이지들은 올바른 대체 페이지를 가리키는 링크를 포함할 것이다.
선언된 레벨에서 올바르지 않은 각각의 페이지들에서, 페이지의 첫번째 링크는 "대체 버전" 이라 불린다. 이 링크는 선언된 레벨에서 올바른 대체 버전의 페이지를 가리킨다.
요구된 레벨에서 올바르지 않은 페이지를 찾는다.
페이지에 올바른 대체 버전을 가리키는 링크가 포함되어 있는지 확인한다.
대체 버전이 원래 페이지의 올바른 대체 버전이고, 그것이 주장되는 레벨에서 WCAG 2.0의 요구사항을 만족하는지 확인한다.
#2 와 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
색상과 텍스트를 지원하는 모든 기술.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 색상과 의미있는 마크업을 조합하여 정보를 전달하는 것이다. 대부분의 사용자는 색상을 이용하여 전달되는 정보를 찾아내기 위해 컨텐츠를 빠르게 훑어볼 수 있다. 색상을 구별하지 못하는 사용자들을 위해, 의미있는 마크업은 다른 형태의 단서를 제공할 수 있다. 사용자 에이전트는 그러한 구조를 사용자가 지각하게끔 만들 수 있는데, 예를 들어 각각의 구조 형태에 대해 서로 다른 시각적 표현을 사용한다거나, 청각 표현에서 서로 다른 목소리 혹은 톤을 이용하는 것이다.
대부분의 사용자 에이전트는 의미있는 마크업을 통해 식별되는 텍스트를 시각적으로 구분할 것이다. 일부 보조 기술들은 적절게 의미있는 마크업을 이용해 생성된 컨텐츠의 특성을 판단하는 메커니즘을 제공한다.
HTML 폼에 몇가지 필수적인 필드들이 포함되어 있다. 필수적인 필드들의 라벨은 붉은색으로 표시된다. 이에 더해, 각각의 라벨들은 strong 요소로 마크업되어서 강한 강조를 나타낸다. 폼을 완성하기 위한 지침에는 이렇게 씌어 있다: "필수적인 필드들은 모두 빨갛게 표시되었으며 강조되어 있다" 그리고 예제가 그 뒤를 따른다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
색상 차이가 정보를 전달하기 위해 사용된 모든 컨텐츠에 대해:
동일한 정보가 의미 있는 마크업을 통해서도 전달되는지 확인한다.
#1 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자의 데이터 입력을 받아들이지만 그러한 입력의 형식, 값, 형태에 제한을 갖고 있는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 제공한 정보가 받아들여지지 않을 경우 입력 실수를 찾아내는 것을 돕는 것이다. 이것은 필수적인 정보가 누락된 필드, 그리고 부정확한 정보가 입력된 필드를 포함한다. 사용자가 입력한 데이터가 체크되고 입력 실수가 발견되었다면, 그러한 에러를 가리키는 링크가 제공되어 사용자가 그것을 찾아보지 않아도 되도록 한다. 한가지 접근방법은 서버사이드 유효성검사를 이용하여, 폼을 사용자에게 다시 보여주고(이전에 입력했던 모든 데이터를 포함하여), 페이지의 상단에 입력 실수가 있었으며 그 문제의 성질은 무엇인지 설명하는 텍스트를 포함시키고, 문제가 있는 필드를 가리키는 링크를 제공하는 것이다.
사용자가 폼 필드에 잘못된 데이터를 입력하고 폼을 전송하였다. 서버는 폼을 되돌리는데, 이 폼에는 사용자가 입력했던 데이터가 보존되어 있고, 페이지의 상단에는 그것이 수용되지 않았음을 명확하게 나타내는 텍스트가 있다. 텍스트는 에러의 성질을 설명하고, 문제가 있는 필드를 가리키는 링크를 제공해서 사용자가 그것을 통해 쉽게 그 필드로 이동하고 문제를 수정할 수 있도록 하고 있다.
사용자가 폼 필드에 잘못된 데이터를 입력하고 폼을 전송하려고 한다. 클라이언트 사이드 스크립트가 에러를 발견하여, 전송을 취소하고, 문서를 수정해서, 에러를 설명하고 또한 문제가 있는 필드를 가리키는 링크가 문서에 포함되도록 한다. 스크립트는 또한 문제가 있는 필드의 라벨을 수정해서 그것이 강조되도록 한다.
사용자가 폼을 전송하려고 할 때, 그것을 새로운 페이지로 가져가는 대신, 스크립트가 자동적으로 "에러가 발생하였음" 이라는 텍스트 링크로 포커스를 옮긴다. 이 링크는 설명적인 에러 메시지들의 순서있는 목록의 첫 아이템을 가리킨다. 각각의 목록 아이템은 에러가 발생한 컨트롤을 가리키는 링크이다. 또한 에러에서부터 설명적인 에러 메시지의 순서있는 목록으로 돌아오는 링크도 있다. 이러한 과정은 필요한 만큼 반복된다.
폼을 채워 넣는다. 필수적인 필드를 의도적으로 비워놓고, 다른 필드에서는 입력 실수를 만든 뒤 폼을 전송한다.
필수적인 데이터가 누락된 필드를 식별하는 텍스트 메시지가 제공되는지 확인한다.
입력 실수가 있는 필드를 식별하는 텍스트 메시지가 제공되는지 확인한다.
데이터가 누락되었다는 메시지로부터, 그 필드를 가리키는 링크가 있는지 확인한다.
에러 메시지로부터, 에러의 목록을 가리키는 링크가 있는지 확인한다.
노트: 성공기준 3.3.2 는 입력 에러가 발견되었고 수정에 대한 제안사항을 알고 있으며, 보안 혹은 컨텐츠의 목적을 엉크러뜨리지 않으면서 그러한 제안사항을 제공할 수 있다면, 그러한 제안사항을 사용자에게 제공할 것을 요구한다.
#2를 만족한다면, #4도 만족한다.
#3를 만족한다면, #5도 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
Any technology
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 컨텐츠의 구조적 인코딩을 표현적 인코딩으로부터 분리함으로서 보조 기술과 컨텐츠의 상호작용을 가능하게 하는 것이다. 구조적 인코딩이란 제목, 문단, 목록, 테이블 등과 같은 요소들을 나타내는 것이며, 기술에서 그러한 목적을 위해 예비된 기능을 통해 이루어진다. 대조적으로, 표현적 인코딩이란 폰트, 색상, 크기, 위치, 테두리 등과 같은 형태의 효과를 나타내는 것이며 역시 기술의 기능을 통해 지원된다.
표현적 기능이 시각적으로 구조를 암시하기는 하지만 - 사용자들은 제목, 문단, 목록, 기타를 형태로부터 인식한다 - 이러한 기능은 보조 기술들이 페이지와 효과적으로 상호작용할 수 있을만큼 구조를 명확하게 인코드하지 못한다. 분리된 구조, 기능, 표현 계층을 제공하는 것은 형태로부터 암시된 의미들이 구조 계층을 통해 프로그램적으로 판단될 수 있게끔 한다.
이 테크닉을 따라 하는 것은 사용자 에이전트로 하여금:
컨텐츠의 기존 구조에 기초하여 충분히 의미 있는 구조 변형을 수행하게 한다. 그러한 변형은 섹션들의 재정렬, 섹션의 목록 생성, 링크의 목록 생성과 같은 것이다.
보조 기술들이 표현적인 정보에만 기초해서는 판단할 수 없는 구조적 특성에 기반한, 컨텐츠와의 상호작용을 지원하게 한다. 예를 들어, 리스트 아이템의 번호를 알아내서 목록과 특별한 상호작용을 제공한다거나, 끝으로 건너뛴다거나 하게끔 하고 싶을 수 있지만, 이러한 것은 목록의 표현에 더해 구조가 인코드되었을때에만 가능하다.
구조의 기능에 첨부된 대체 표현 규칙들을 교체하여 컨텐츠의 표현을 수정할 수 있게 한다.
HTML 문서가 문단, 목록, 제목과 같은 HTML의 구조적 기능을 이용하지만 폰트 변경, 레이아웃 힌트 같은 표현적 기능들은 지양하고 있다. 문서의 구조적 속성에 기반하여 문서 형태를 잡기 위해 CSS를 사용하고 있다. 잘 만들어진 "class" 속성은 구조적 마크업의 의미를 확장하여 CSS를 이용해서 더 유연한 형태를 가능하게 하고 있다. 보조 기술은 CSS를 교체하거나 확장하여 표현을 수정하거나, CSS를 무시하고 직접적으로 구조적 인코딩과 상호작용할 수 있다.
대부분의 PDF 문서는 포맷 정보를 포함하는 컨텐츠로 구성된다. 구조에 관한 정보는 문서의 별도 섹션에서 XML 형태의 태그를 사용하여 제공된다; 이러한 것을 "태깅된tagged PDF"라고 부른다. 이러한 태그들에 포함된 정보는 보조 기술에 의해 표현을 적응시키거나, 또는 표현에 의해 암시된 구조를 이해하게 할 수 있다.
문서의 인코딩을 살펴본다.
구조 정보와 기능성이 명시적으로 제공되며, 표현적 정보와 논리적으로 분리되어 있는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
섹션으로 조직화된 컨텐츠를 가진 페이지.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 섹션들이 그것을 식별하는 제목을 갖게 하는 것이다.성공기준 1.3.1 은 제목들이 프로그램적으로 식별될 수 있게끔 표시되기를 요구한다.
HTML에서는, HTML heading 요소 (h1, h2, h3, h4, h5, h6)를 이용하여 그렇게 할 수 있다. 이것은 사용자 에이전트가 자동적으로 섹션 제목들을 식별할 수 있게 한다. 다른 기술들은 헤더를 식별하는 다른 테크닉을 사용한다. 전반적인 문서 구조를 이해하고 탐색하는 것을 가능하게 하기 위해, 저자들은 제목들이 올바르게 중첩되도록 사용해야 한다(예를 들어 h1 다음에 h2가 오고, h2 다음에 h3가 오고, h3 다음에 h4가 오는 식이다).
요리 테크닉에 관한 페이지가 전체 타이틀에 h1 요소를, 요리에 오일을 사용하는 것과 버터를 사용하는 것을 비교한 주 섹션에 h2 요소를, 오일 조리법 테크닉에 관한 서브섹션들에 h3 요소를 사용하고 있다.
예제 코드:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>요리 테크닉</title>
</head>
<body>
<h1>요리 테크닉</h1>
... some text here ...
<h2>오일을 이용한 조리법</h2>
... text of the section ...
<h3>Sautéeing</h3>
....
<h3>Deep frying</h3>
<h2>버터를 이용한 조리법</h2>
... text of the section ...
</body>
</html>
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
컨텐츠가 섹션으로 조직화되어 있는 페이지를 점검한다.
각각의 섹션에 제목이 있는지 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자 에이전트에서 줌 기능을 제공하는 모든 기술.
이 테크닉은 다음과 연관된다:
IE 7.0의 줌 기능은, 절대위치가 지정된 경우(역주:CSS, position:absolute)와, 축소되는 경우에는 항상 균등하게 크기조절이 되지는 않는다. 마이크로소프트의 IE 7.0은 줌과 함께 %, em, (named size)로 크기가 지정된 텍스트의 크기 변경을 지원한다.
Opera 9 는 줌을 지원한다.
Firefox 2 와 그 이하 버전은 텍스트 크기 변경만을 지원하지만, pt, px, %, em, (named size)로 크기가 지정된 폰트의 크기도 변경할 수 있다.
Firefox 3는 줌과 텍스트크기 변경을 모두 지원한다.
이 테크닉의 목적은 줌 도구를 통해 텍스트 크기를 변경하는 사용자 에이전트에서 지원되는 웹 기술을 통해 컨텐츠의 크기가 균등하게 조절될 수 있도록 하는 것이다.
컨텐츠의 크기를 균등하게 조절(즉, 컨텐츠 내부로 줌)할 수 있는 사용자 에이전트에서 지원되는 기술로 저작된 컨텐츠는 이 성공기준을 만족한다. 이 테크닉이 사용자 에이전트의 기능에 완전히 의존하기 때문에, 넓은 범위의 사용자 에이전트에서 테스트하는것이 아주 중요하다.
이 테크닉은 줌 기능이 페이지의 모든 공간적 관계들을 유지할 것, 그리고 모든 기능들이 여전히 사용 가능할 것을 요구한다.
Internet Explorer 7 과 Opera 9 는 HTML/CSS 페이지의 컨텐츠 크기를 균등하게 조절하는 줌 기능을 제공한다.
어도비 리더는 PDF 페이지의 크기를 균등하게 조절하는 확대경 도구를 이용하여 사용자가 텍스트의 크기를 조절할 수 있도록 하고 있다.
(현재 목록화된 것이 없다)
사용자 에이전트에 컨텐츠를 표시한다.
200%로 확대한다.
모든 컨텐츠와 기능들이 사용 가능한지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
(역주 : CAPTCHA란, 자동 가입을 방지하기 위해 몇개의 문자를 그림으로 표시하고, 사용자가 그것을 입력하여 사용자가 손으로 가입하고 있음을 증명하도록 하는 그림, 또는 그와 흡사한 것을 말한다. 적절히 짧은 우리말 표현이 없으므로 CAPTCHA를 그대로 사용한다.)
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자에게 모호하게 표현된 이미지나 오디오 파일로 주어진 텍스트를 입력하도록 요청하는 CAPTCHA 테스트와 같은 비 텍스트 컨텐츠를 식별할 수 있는 정보를 대체 텍스트를 통해 제공하는 것이다. 대체 텍스트로부터, 사용자는 CAPTCHA가 어떤 작업을 완결하기를 요구하고 있으며, 그 작업이 어떤 종류의 것인지 알 수 있다.
CAPTCHA의 대체 버전을 사용할 수 있다면, 대체 텍스트는 반드시 그러한 대체 버전을 어떻게 찾을 수 있는지에 관한 지침을 포함해야 한다.
CAPTCHA 테스트에서 사용자에게 모호하게 표시된 이미지의 텍스트를 입력하도록 요청하고 있다. 대체 텍스트는 "이미지의 단어를 입력하시오" 이다.
CAPTCHA 테스트에서 사용자에게 오디오 파일에서 재생된 텍스트를 입력하도록 요청하고 있다. 대체 텍스트는 "오디오로 말해진 단어를 입력하시오" 이다.
CAPTCHA를 제거하거나, 감추거나, 가린다.
그것을 대체 텍스트로 교체한다.
대체 텍스트가 CAPTCHA의 목적을 설명하는지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 장애를 가진 사용자가 CAPTCHA 작업을 완수하지 못하는 경우를 줄이는 것이다. 다른 방법을 사용하는 대체 CAPTCHA 작업이 있으므로, 사용자가 그중 한가지 작업을 성공적으로 완수할 가능성이 더 높을 것이다.
웹 페이지에, 사용자가 다음 단계로 진행하기 위해서 반드시 완수해야 하는 CAPTCHA 테스트가 포함되어 있다. 페이지에는 시각적 작업, 즉 이미지에 표시된 단어를 입력하는, 과 청각적 작업, 즉 오디오 파일에서 들려주는 단어를 입력하는, 두가지가 포함되어 있다. 청각 장애가 있어서 청각적 CAPTCHA 를 완수할 수 없는 사용자는 시각적 CAPTCHA 를 완수할 수 있을 것이다.
사용자가 첨언comment을 남기기 위해서는 반드시 시각적 CAPTCHA 테스트를 통과해야만 하는 블로그가 있다. 블로그는 시각적 CAPTCHA에 더해서, 폼 필드에 포함된 CAPTCHA 역시 포함하고 있으며, 후자의 것은 "2 더하기 7 은 무엇입니까?" 라는 질문을 하여, 사용자가 정확한 답을 텍스트 필드에 입력할 수 있게끔 하고 있다.
웹 페이지에 포함된 각각의 CAPTCHA에 대해
웹 페이지가 동일한 목적을 수행하지만 다른 양식을 통하는 또 다른 CAPTCHA를 포함하는지 확인한다.
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
시각적 출력을 생성하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 배경 위에 표시된 텍스트를 확실히 읽을 수 있도록 하는 것이다. 이 테크닉은 텍스트에 대한 4.5:1 의 대비 요구사항을 완화하는데, 대상 텍스트는 최소한 18포인트(볼드체가 아닌 경우), 또는 14포인트(볼드체인 경우)는 되어야 한다.
배경이 단일색(또는 전부 검거나, 또는 전부 희거나)이라면, 큰 글씨의 텍스트에 대한 대비는 배경과 비교했을때 각각의 글자가 3:1의 대비를 가지면 된다.
배경이나 글씨가 다양한 광도(혹은 패턴)를 가진다면, 글씨 주변의 배경은 글씨와 배경이 3:1의 대비를 갖도록 선택되거나, 또는 그림자처리될 수 있다. 글씨가 배경 전체와 대비를 가질 필요는 없다
배경의 상대적 광도가 페이지에 걸쳐서 변화한다면, 글씨의 상대적 광도를 변경함으로서 이러한 대비를 만족시킬수도 있다.
다른 방법은 텍스트 주변에 필요한 대비를 갖게끔 빛무리를 제공하는 것이다. 보통 방법으로는 배경 그림이나 색상이 상대적 광도에서 충분한 대비를 갖지 못하는 경우 이런 방법을 쓸 수 있다.
회사 로고에 맞춰서 밝은색으로 표시된 글씨를 사용하기 위해 검은색 배경이 선택되었다.
대학 캠퍼스의 사진 위에 큰 크기의 텍스트가 배치되어 있다. 배경의 사진에 다양한 색상과 어두운 부분이 존재하기 떄문에, 텍스트 아래의 영역은 흰 안개처럼 표시함으로서 원래의 사진 영역을 대단히 흐리게 하였고, 가장 어두웠던 부분도 검은색 텍스트와 3:1의 대비를 유지할 수 있을 정도의 밝기를 갖게끔 하였다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
(현재 목록화된 것이 없다)
다음의 식을 사용하여 각 글자의 상대적 광도를 측정한다(모두가 같은 경우는 제외하고):
R, G, B가 다음과 같이 정의되었을 때 광도 L = 0.2126 * R + 0.7152 * G + 0.0722 * B
RsRGB <= 0.03928 이라면 R = RsRGB/12.92, 그렇지 않다면 R = ((RsRGB+0.055)/1.055) ^ 2.4
GsRGB <= 0.03928 이라면 G = GsRGB/12.92 그렇지 않다면 G = ((GsRGB+0.055)/1.055) ^ 2.4
BsRGB <= 0.03928 이라면 B = BsRGB/12.92 그렇지 않다면 B = ((BsRGB+0.055)/1.055) ^ 2.4
또한 RsRGB, GsRGB, and BsRGB 은 다음과 같이 정의된다:
RsRGB = R8bit/255
GsRGB = G8bit/255
BsRGB = B8bit/255
"^" 기호는 이산 제곱 연산자이다.
노트: 글자가 별칭으로 사용되었을 경우, 글자의 경계선에서부터 2개의 픽셀 사이의 상대적 광도 값을 사용한다.
같은 식을 사용하여, 글자의 바로 다음에 있는 배경 픽셀의 상대적 광도를 측정한다.
다음의 식을 사용해서 광도 대비를 계산한다.
대비가 3:1 이상인지 확인한다.
#4 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용 가능한 가로 크기에 적응하는 레이아웃 테크닉을 이용함으로서 가로 스크롤바가 없게끔 컨텐츠를 표현하는 것이다. 유연한 레이아웃은 텍스트와 함께 크기가 조절되고, 화면 디스플레이에 걸맞게 다시 배치되도록 레이아웃 영역들을 정의한다. 그럼으로서 실제 레이아웃이 다양하게 나오기는 하지만, 요소들 사이의 관계와 읽는 순서는 그대로 유지된다. 이것은 다양한 장치들에서 잘 표현되는, 그리고 글씨 크기의 선호도가 다양한 사용자층을 위한 디자인에 효과적인 방법이다.
유연한 레이아웃의 기본 원칙들은:
텍스트 크기에 따라 변경될 수 있는 단위를 사용하여 레이아웃 영역들의 크기를 정의한다. 이렇게 하면 텍스트가 커지거나 작아짐에 따라 영역들의 크기도 변한다.
레이아웃 영역들을 적절하게 흐르는 박스들의 한 줄(행)으로 배치한다. 이러한 박스들은 문단에서 단어들이 줄바꿈하는 것과 마찬가지로, 필요한만큼 얼마든지 새로운 줄로 넘어간다.
복잡한 유연한 레이아웃은 레이아웃 영역들을 중첩함으로서 얻어진다. 즉, 유연한 지역 레이아웃 영역을 더 큰 유연한 레이아웃 영역 내에 만드는 것이다. 유연한 레이아웃은, 간단한 경우라고 하더라도, 넓은 범위의 텍스트 크기에서 좋게 보이는 결과를 얻기 위해서는 세심한 디자인을 필요로 하지만, 잘 디자인된 유연한 레이아웃은 가장 효과적인 페이지 디자인이 될 수 있다.
다음의 아주 간단한 예제는 유연한 레이아웃을 생성하기 위해 HTML과 CSS를 이용한다. 3개의 열 들은 텍스트 크기가 조절됨에 따라 자신의 크기를 조절한다. 전체 가로 크기가 사용가능한 가로 크기를 초과할 경우, 마지막 열은 그 앞의 열 다음이 아니라 아래에 위치하도록 줄바꿈된다. 이 예제는 열의 크기에 퍼센트를 사용하며, 그것들에 "float" 속성을 사용해서 흐르는 영역으로 만든다.
예제 코드:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>예제: Basic Liquid Layout</title>
<style type="text/css">
.column
{
border-left: 1px solid green;
padding-left:1%;
float: left;
width: 32%;
}
#footer
{
border-top: 1px solid green;
clear: both;
}
</style>
</head>
<body>
<h1>WCAG 예제</h1>
<h2>3개의 열에 있는 텍스트들</h2>
<div title="column one" class="column">
<h3>Block 1</h3>
<p> 이 테크닉의 목적은 사용 가능한 가로 크기에
적응하는 레이아웃 기법을 사용함으로서 가로 스크롤
바 없이 컨텐츠를 표시하는 것이다.
</p>
</div>
<div title="column two" class="column">
<h3>Block 2</h3>
<p> 이것은 텍스트 크기가 변함에 따라 적응하는 페이지 레이아웃의
아주 간단한 예제이다.
</p>
</div>
<div title="column three" class="column">
<h3>Block 3</h3>
<p> 더 복잡한 페이지 레이아웃을 지원하는 테크닉에 관해서는
아래에 목록화된 자원들을 참조하라.
</p>
</div>
<p id="footer">푸터 텍스트</p>
</body>
</html>
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
사용자 에이전트에 컨텐츠를 표시한다.
200%로 확대한다.
모든 내용과 기능들이 가로 스크롤 없이 이용 가능한지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
텍스트 색상과 배경색이 별도로 명시되고, 브라우저가 기본 색상을 조정할 수 있는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 배경 위에 표시된 텍스트를 확실히 읽을수 있도록 하는 것이다. 이 테크닉을 통해, 저자는 단순히 텍스트 색상과 배경을 명시하지 않는 것 만으로도, 대조를 확보하기 위해 더이상 할 일이 없게 된다. 결과적으로, 양자의 색상은 완전히 사용자 에이전트에 의해 판단된다.
예제 1: 저자가 텍스트 색상이나 배경을 명시하지 않았다. 또한 CSS도 사용하지 않는다. 결과적으로, 사용자는 자신의 브라우저 기본값을 사용하게 되므로 자신에게 잘 맞는 색상과 대조를 얻을 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트 색상이 명시될 수 있는 모든 곳을 살펴본다.
텍스트 색상이 명시되지 않았음을 확인한다.
배경색이나 배경 이미지가 명시될 수 있는 모든 곳을 살펴본다.
배경색이나 배경 이미지가 명시되지 않았음을 확인한다.
#2와 #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자 에이전트가 제공하는 포커스 강조가 가능한 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 포커스를 받은 컴포넌트를 시각적으로 식별할 수 있고, 그러한 과정을 사용자 에이전트의 지원에 의존하는 것이다. 표준적인 컨트롤이 포커스를 받았을 때, 그것을 어떤 방법으로든 강조해서 표시하는 사용자 에이전트가 많이 있다. UAAG의 요구사항에 부합하는 사용자 에이전트들은 체크포인트 10.2, "선택, 내용 포커스, 사용 가능해진 요소, 방문했던 링크들을 강조한다"를 만족했을 경우 그렇게 한다. 저자가 사용자 에이전트가 이러한 지원을 하는 표준적인 컨트롤들을 사용하면, 사용자들은 포커스의 위치에 대해 표준적이고, 예측가능한 방법으로 알림을 받는다.
HTML 텍스트 입력 필드가 포커스를 받으면, 브라우저들은 깜박이는 세로 막대를 텍스트 필드의 삽입 위치에 보여준다.
HTML 링크가 포커스를 받으면, 그것들은 점선으로 이루어진 포커스 강조 사각형으로 둘러싸인다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
웹 페이지에서 포커스를 받을 수 있는 각각의 컴포넌트에 대해:
컨트롤에 포커스를 준다
사용자 에이전트가 어떤 방법으로든 그 컨트롤을 강조하는지 확인한다
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
오디오만 있는 실황 정보를 표현하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 들을 수 없는 사용자들이 실시간 오디오 방송에 접근할 수 있도록 하는 것이다. 정확한 실시간 대체를 만드는 것은 매우 어려운데, 실수를 바로 잡거나, 한번 더 듣거나, 단어들이 정확하게 선택되었는지 누군가에게 조언을 구할 시간이 없기 때문이다. 또한, 매우 빠르게 진행되는 경우 정보를 단순화하거나 이해하기 쉬운 다른 말로 바꾸는것 역시 매우 어렵다.
현존하는 속기술과 빠른 타자 기술을 응용하는, 실시간 텍스트 삽입 기술이 존재한다. 텍스트로 변환된 음성을 다시 음성으로 바꾸는 기술(음성을 듣고 그것을 컴퓨터에 조심스럽게 말하는 기술자가 있다. 컴퓨터는 그 기술자의 음성에 최적화되어 있다)이 현재 전화 교환 서비스에서 사용되고 있으며, 이후에는 자막에서 사용될 수 있을 것이다. 언젠가는 대화를 텍스트로 정확하게 바꾸는것도 가능해질 것이다.
라디오 방송국에서 스포츠 이벤트 실황에 대한 대체를 제공하기 위해 웹 기반 캡션 서비스를 사용한다; 서비스의 출력은 스트리밍 오디오 컨트롤을 포함하고 있는 웹 페이지에 포함된다.
대체 텍스트가 실시간으로 전달될 것을 보장하는 과정과 정책이 사용되는지 확인한다
#1 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
오디오로만 제공되는 실황 정보를 표현하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 글로 옮긴 기록, 또는 오디오 실황 컨텐츠가 미리 짜여진 대본에 의한 것이라면 그러한 대본을 제공하는 것이다. 이것은 미리 준비된 것이므로, 대본은 실시간 기록보다 더 정확하고 완전할 수 있다. 그러나, 대본은 오디오가 재생되는 것에 동기화되지는 않을 것이다. 오디오 실황은 이 테크닉에 대해 대본을 벗어나서는 안된다.
이 테크닉에 의해, 기록, 혹은 대본이 제공되며 WCAG 2.0의 요구사항에 부합해야 하고, 또한 같은 웹 페이지의 다른 위치, 혹은 다른 URI에 포함될 수 있다.
언더그라운드fringe 그룹의 라디오 공연 실황이 웹에서 방송되려고 한다. 배우들이 대본에 크게 의존하고, 예산이 충분치 못하므로, 프로듀서는 공연 대본의 HTML 판을 가리키는 링크를 제공(대본 저자의 허락을 받고)한다.
정부 관료가 중요한 정책에 대한 연설을 웹에서 하고 있다. 연설이 시작될 때, 이 연설을 기록한 것이 웹 사이트에 게제된다.
대본, 혹은 기록을 직접 가리키는 링크가 있는지 확인한다.
오디오 실황이 그 대본을 따라가는지 확인한다.
대체 버전이 별도의 페이지에 있다면, 사용자가 그러한 버전으로 갈 수 있는 링크를 사용할 수 있는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
애니메이션 gif (GIF89a) 을 지원하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 애니메이션 gif 이미지가 5초 이내에 깜박임을 멈추게 하는 것이다. 이미지가 얼마나 오래 깜박이는지(아니면, 애니메이트되는지) 판단하는 기준으로는 애니메이션 gif 이미지 디자인의 3가지 관점을 고려한다:
이미지에 들어 있는 프레임의 숫자. 프레임이란 애니메이션 시퀀스에 들어 있는 개개의 이미지를 말한다.
프레임 레이트, 각각의 이미지가 얼마나 오래 표시되는지를 말한다.
반복 회수, 전체 애니메이션이 몇번이나 실행되는지를 말한다.
가장 간단히 말해, 애니메이션의 길이는 프레임의 숫자 * 프레임 레이트 * 반복 회수이다. 예를 들어, 간단한 애니메이션 이미지가 2개의 프레임으로 구성되고, 0.5초의 프레임 레이트를 가지며, 3회 반복되었다면 그것은 (2 * 0.5 * 3)초, 또는 정확히 3초의 시간에 해당하는 길이를 갖는 것이다.
많은 애니매이션 gig 이미지들은 일정한 프레임 레이트를 갖는다. 다시 말해, 각각의 프레임이 재생되는 시간의 양은 일정하다. 그러나, 각각의 프레임에 서로 다른 프레임 레이트를 설정함으로서, 특정 프레임이 다른것보다 더 오래 표시되도록 할 수 있다. 이러한 경우, 애니메이션의 길이는 프레임 레이트의 합계 * 반복 회수이다. 예를 들어, 2개의 프레임으로 구성된 간단한 애니메이션 이미지가 있고 그것의 첫 프레임이 .75초 동안 표시되며 두번째 것이 0.25초 동안 표시되고, 반복회수가 3회라면, 그것은 ((0.75 + 0.25) * 3) 초, 역시 3초의 길이를 갖는다.
이미지가 5초 이내에 깜박임을 멈추게 하려면, 세가지 변수들 중 하나가 조정되어야 한다. 가장 흔하게는, 5초를 프레임 숫자 * 프레임 레이트(또는, 프레임 레이트의 합계)로 나누고, 이 숫자가 가장 가까운 정수가 되게끔 소수점 아래를 버린 - 반올림하지 않는다 - 결과를 반복 회수로 삼는 것이다. 이렇게 하면 이미지는 5초 이내에 멈출 것이다.
만약 한번의 반복이 5초 이상이라면, 다른 것들 중 하나를 조절해야 한다. 이미지에서 프레임의 숫자를 줄이거나, 프레임 레이트를 늘린다. 프레임 레이트를 늘릴 때는 결과 이미지가 일반적인 번쩍임, 혹은 적색 번쩍임 한계를 넘지 않도록 주의해야 한다; 이미지가 큰 경우에 이것은 특히 중요하다.
간단한 깜박이는 이미지. 이미지가 2개의 프레임으로 구성되고, 0.5초의 프레임 레이트를 갖고 있으며, 3회 반복된다. 애니메이션은 (2 * 0.5 * 3) 초, 혹은 3초이며, 따라서 성공 기준의 요구사항을 만족한다.
애니메이션 gif을 표시하고 얼마나 오래 애니메이트되는지 지켜본다.
아니면, 이미지 에디터를 사용해서 프레임의 숫자, 프레임 레이트, 반복 회수를 판단한다. 프레임 수 * 프레임 레이트 * 반복 회수를 계산한다. 프레임 레이트가 균일하지 않다면, 프레임 레이트의 합계 * 반복회수를 계산한다.
둘중 한가지 방법을 사용해서 계산한 애니메이션 의 길이는 5초 이하여야 한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 페이지의 텍스트가 읽기에 어렵지 않도록 하는 것이다. 단어와 문장을 해석하는 것을 어렵게 하는 장애를 가진 사용자들은 복잡한 텍스트를 읽고 이해하는데에 어려움을 느낄 수 있다. 텍스트가 초급 교육 수준lower secondary education level 이상의 읽기 능력을 요구하지 않는다면, 보충설명이나 대체 버전은 필요하지 않다.
텍스트의 복잡성을 경감하려면:
문단 하나에 하나의 주제, 혹은 부주제를 놓는다.
컨텐츠의 목적과 일치하는, 가장 간단한 형태의 문장을 사용한다. 예를 들어, 영어에서 가장 간단한 형태의 문장은 주어-동사-목적어이며, 이러한 형태의 문장으로는 "John이 공을 친다", "웹 사이트가 WCAG 2.0을 만족한다" 등이 있다.
중등 교육 수준에서 일반적으로 사용되는 단어의 수를 초과하지 않는 문장을 사용한다. (노트: 영어에서는 25 단어이다)
긴 문장을 둘로 나누는 것을 고려한다.
문장에 3개 이상의 접속사가 있지 않도록 한다.
구문들, 문장들, 문단들, 텍스트 섹션들 사이의 논리적 관계를 표시한다.
전문용어, 비속어, 기타 사람들에게 명확하지 않은 특정한 의미를 가진 단어의 사용을 피한다.
길거나 친숙하지 않은 단어들을 짧고, 좀더 일반적인 단어들로 교체한다.
쓸모없는 단어들, 즉, 문장의 의미를 바꾸지 않는 단어들을 제거한다.
하나의 명사, 혹은 짧은 명사구를 사용한다.
문장의 의미를 해치지 않으면서 더 일반적으로 사용되는 단어로 교체할 수 있는 복잡한 단어나 구문들을 제거한다.
콤마로 구분된, 긴 단어들이나 구문들을 열거하는 문단을 사용하지 말고 불릿이 있는, 혹은 숫자가 매겨진 목록으로 대체한다.
대명사 참조, 그리고 문서의 다른 지점에 대한 참조가 명확하게끔 만든다.
수동태를 써야 하는 특별한 이유가 없다면, 영어나 몇가지 서구 언어로 작성된 문서들에서는 능동태를 사용한다. 능동태로 쓴 문장들은 대개 더 짧고 이해하기 쉽다.
동사의 과거형을 일관되게 사용한다.
이름과 라벨을 일관되게 사용한다.
웹 어플리케이션의 도움말 페이지가 초등 교육 수준을 초과하지 않는 영어로 씌어 있다.
텍스트의 읽힘성을 측정한다.
텍스트가 초등 교육 수준을 초과하는 읽기 능력을 요구하지 않는 것을 확인한다.
#2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 자신의 입력을 검토하였으며 이것을 최종 전송할 준비가 되었음을 표시하는, 사용자가 반드시 선택해야 하는 체크박스를 제공하는 것이다. 입력 실수가 나중에 발견되었더라도 작업의 성격상 되돌릴 수 없는 것이거나, 작업의 결과로 데이터가 삭제되거나 하는 경우에 이것은 더 중요하다. 페이지가 로드될때는 선택되지 않은 상태인 체크박스를 제공하고, 이런 라벨을 붙인다 : "입력이 올바르며, 최종 전송할 준비가 되었습니다." 또는, "이 데이터를 지우길 원하는 것을 확인합니다." 체크박스는 사용자가 제출 과정에서 발견할 수 있도록 제출 버튼 근처에 위치해야 한다. 폼을 제출할 때 이 체크박스가 선택되지 않았다면, 입력은 거부되며 사용자는 자신이 입력한 항목들을 검토하고 체크박스를 선택한 후 다시 제출할 것을 요청받는다. 체크박스가 선택되어야만 입력이 받아들여지고 작업이 진행된다.
이러한 체크박스는 실수로 폼을 전송하는 것을 막고, 또한 사용자에게 입력한 데이터가 정확한지 확인할 것을 요청하는 역할도 한다. 단순히 제출 버튼에 "입력이 정확하니, 제출한다" 라는 라벨을 붙이는 것 보다 더 안전하다. 제출 버튼에서 분리된 컨트롤로 체크박스를 제공하는 것은 사용자가 "두번 체크" 하도록 강제한다 - 사용자들은 작업을 진행시키기 위해 체크박스를 선택해야 하고, 제출 버튼을 눌러야 한다. 이와 같이, 이것은 제출을 완결짓기 전에 검토, 승인, 정보 수정을 하는 메커니즘이 된다.
노트: 사용자가 체크박스를 선택하지 않은 채로 정보를 제출할 경우, 다시 제출할 폼에는 전에 입력했던 정보들이 전부 있어야 한다.
(역주 : 이 테크닉에서 "작업"은 트랜잭션transaction, "최종적인 전송" 은 커밋commit 이다. 자세한 설명은 G98 : 제출 전 정정에 있다.)
온라인 뱅킹 서비스에서 사용자가 서로 다른 통화를 사용하는 계좌 사이의 이체를 허용하고 있다. 환율은 계속해서 변하기 때문에, 작업이 진행된 후에는 사용자가 입력 실수를 발견하였다고 하더라도 동일한 환율로 다시 이체하는 것은 불가능하다. "인출할 계좌", "이체받을 계좌", "이체할 금액" 필드들에 더해, "이체 금액을 확인하였으며 그만큼을 이체하려는 것이 정확합니다" 라는 레이블이 붙은 체크박스가 있다. 사용자가 폼을 제출하려고 할 때 이 체크박스가 선택되어 있지 않다면, 작업은 진행되지 않으며 사용자는 그러한 알림을 받는다. 체크박스가 선택되어 있다면, (되돌릴 수 없는) 작업이 진행된다.
온라인 결재 시스템에서 지불을 진행하기 위해 사용자의 은행 계좌 정보를 보관한다. 여기에는 사용자가 새로운 계좌를 입력하고, 사용자가 그 계좌의 소유주가 맞는지 확인하는 정교한 과정이 포함된다. 오래된 계좌를 삭제하는 기능이 있지만, 만약 실수로 계좌를 삭제하였다면, 그것을 복구하는 것은 어려우며, 그 계좌에 대한 작업 내역들은 손실될 것이다. 따라서, 사용자가 계좌를 삭제할 수 있는 페이지에는 체크박스가 있고 이런 라벨이 붙어 있다 : "이 계좌를 삭제하길 원하는 것을 확인합니다". 사용자가 폼을 제출할 때 체크박스가 선택되어 있지 않다면, 계좌는 삭제되지 않으며 사용자는 에러 메시지를 받는다. 체크박스가 선택된 경우에만 계좌가 삭제된다.
쇼핑 사이트의 폼에 주문, 선적, 지불 정보를 수집하는 폼이 있다. 폼을 제출한 후에, 사용자는 자신에 제출한 정보를 검토할 수 있는 요약 페이지로 이동한다. 요약의 아래에, 체크박스가 있고 이런 라벨이 붙어 있다 : "데이터를 검토하였으며 이것이 정확한 것을 확인합니다". 사용자는 작업을 완료하기 위해 반드시 체크박스를 선택해야 하며 "주문 완결" 버튼을 눌러야 한다.
되돌릴 수 없는 작업을 실행하는 입력 페이지에 대해:
제출 버튼에 더해, 사용자의 입력이나 행동에 대해 확인을 요청하는 체크박스가 있는지 확인한다.
체크박스가 선택되지 않은 상태에서 폼을 제출하면, 입력이 거부되고 사용자가 항목들을 검토한 후 체크박스를 선택하고 다시 제출할 것을 요청받는지 확인한다.
#1 과 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
대부분의 브라우저는 사용자가 웹 저자의 CSS, HTML 색상 스키마를 덮어써서 색상 설정을 변경할 수 있도록 허용한다. 이것은 IE, 모든 버전의 파이어폭스, 모질라, 그리고 버전 6 이후의 오페라 브라우저를 포함한다.
파이어폭스와 넷스케이프에서, 명시된 색상이 덮어써진 경우 대부분의 자바스크립트 팝업과 드롭다운 메뉴들이 사용할 수 없게 된다. 팝업 박스들은 투명한 배경을 갖게 되어서 페이지의 텍스트 위에 팝업 박스의 텍스트가 곂쳐지게 되고, 드롭다운 메뉴들은 투명해지거나 진회색 배경을 갖게 된다..
IE 6 의 경우에는 시스템 설정에서 역시 동일한 배경색이 선택되어 있지 않다면 브라우저의 배경 색상을 덮어쓰지 않을 것이다.
인식 장애를 가진 일부 사람들은 웹 페이지의 컨텐츠를 성공적으로 이해하기 위해 전경 텍스트와 배경 사이의 특정한 색상 조합을 필요로 한다. 대부분의 브라우저들은 브라우저 내에서 전역적으로 색상 세팅을 변경할 수 있는 옵션을 제공한다. 이러한 경우 사용자가 선택한 색상 설정으로, 웹 저자가 명시한 전경과 배경 색상을 덮어 쓸 수 있다.
이 성공 기준을 만족하려면, 저자는 이러한 컨트롤을 갖고 있는 브라우저에서 동작하게끔 페이지를 디자인해야 하며, 이러한 컨트롤을 덮어쓰지 말아야 한다.
페이지에 있는 모든 텍스트와 그 배경의 색상을 덮어 쓰게 되면, 웹 페이지의 그룹화, 조직화에 관한 시각적 단서들을 감출 가능성이 있고, 그렇게 되면 페이지를 이해하고 사용하기가 훨씬 어려워 질 수 있음을 유념하라. 이 테크닉은 페이지의 영역들을 상세하게 구분짓는 용도로 배경 색상을 이용하는 경우에는 적합하지 않다. 이 테크닉은 배경색이 덮어씌어졌을때 테두리 색상을 바꾸지 않는 사용자 에이전트와 기술에 적합할 수 있다. 만약 배경색이 페이지의 영역들을 상세하게 구분짓는 용도로 사용되었다면, "C23: 주된 컨텐츠의 텍스트와 배경 색상을 명시하지 않으면서 CSS를 이용해서 배너, 기능들, 내비게이션과 같은 2차 컨텐츠의 텍스트와 배경 색상 지정하기 (CSS)"를 이용하여 사용자가 웹 페이지의 시각적 구조 안에 머물러 있으면서 주된 텍스트의 색상을 조절하도록 할 수 있다.
웹 페이지가 전경과 배경 색상을 명시하도록 HTML과 CSS를 사용하여 디자인되었다. 사용자는 인터넷 익스플로러 7에서 자신의 색상을 설정해 두었으며, 자신이 선택한 전경과 배경 색상을 이용해서 컨텐츠를 볼 수 있다.
웹 페이지가 HTML과 CSS를 이용하여 디자인되었다. 페이지에는 다양한 브라우저에서 색상을 설정하는 방법에 관한 지침을 가리키는 링크가 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
사용자가 HTML 컨텐츠의 색상을 바꿀 수 있도록 허용하는 웹 페이지를 브라우저에서 연다.
컨텐츠에서 명시된 것 과는 다르게끔, 브라우저 설정에서 전경색과 배경색을 변경한다.
페이지로 돌아와서, 브라우저에서 새로 명시된 전경 텍스트 색상과 배경색이 컨텐츠에서 명시된 것과 다른지 확인한다.
#3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
오디오로만 제공되는 실황 정보를 표현하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 실시간 캡션 서비스를 사용해서 오디오 실황 컨텐츠의 텍스트 버전을 제공하는 것이다. 그러한 서비스는 무엇이 말해지고 있는지 듣고, 아주 작은 지연시간만으로 텍스트를 입력할 수 있도록 만들어진 특별한 키보드를 사용하는 훈련된 조작자를 통해 제공된다. 그들은 높은 정확도로 실황을 기록하고, 상황을 이해하는데에 필수적이지만 음성으로 제공되지는 않은 노트들을 삽입할 수 있는 능력이 있다. 캡션 텍스트는 오디오 실황 컨텐츠와 같은 웹 페이지에서 제공된다.
인터넷 라디오 방송국에서 뉴스 서비스 웹 페이지에 창을 제공한다. 실시간 뉴스 보고서, 특히 위험 보고서들은 실시간 캡션 서비스로 기록되고 그 창에서 보여진다.
회의, 또는 화면 공유 서비스에서 음성 표현의 실시간 기록을 실행하는 창을 포함하고 있다. 이것은 음성 원격 회의 캡션 중계 서비스를 통해서 이루어진다. 실황 텍스트를 위해 분리된 창을 이용하는 것은 상당한 사용성 장벽이 될 것이므로, 온라인 웹 회의, 또는 화면 공유 서비스는 이러한 사용을 염두에 두고 디자인되어야 한다.
반복되는 음성 회의에서 대기열을 지원하기 위해 온라인 거수 유틸리티를 이용하고 있다. 이 상품을 온라인 회의 캡션 중계 서비스와 연계하여 이용하기 위해, 대기열 유틸리티는 좁은 창에서도 완전한 기능을 수행하도록 디자인되었다. 부가적인 향상을 위해, 두개의 창을 하나의 웹 페이지에서 볼 수 있는 웹사이트가 생성되었다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
위키피디아의 CART 항목 (variously Computer Assisted Real-time Captioning or Communication Access Real-time Translation)
캡션 창 지원을 내장하고 있는 웹 회의 상품들
웹 페이지에 오디오 실황 컨텐츠와 연계된 창이 있는지 확인한다.
오디오 실황 컨텐츠의 텍스트가 그 창에 30초 미만의 지연을 갖고 나타나는지 확인한다.
위의 모든 확인을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
일반적인 테크닉. 모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 오디오로만 표현되는 정보에 접근성있는 대체적인 방법을 제공하는 것이다.
오디오만 있는 표현에서, 정보는 대화와 소리(인공적인것과 자연적인것 모두)를 포함하는 다양한 방법으로 표현된다. 동일한 정보를 접근성있는 형태로 제공하기 위해, 이 테크닉은 미리 녹음된 오디오만 있는 컨텐츠와 같은 이야기를 하고 같은 정보를 전달하는 문서를 생성하는 것을 포함한다. 이 테크닉에서, 문서는 컨텐츠에 대해 긴 설명의 역할을 하며, 중요한 대화들 전부와 함께 이야기의 일부가 되는 배경의 소리들 역시 포함한다.
오디오만 있는 컨텐츠를 만들기 위해 처음부터 실제 대본을 사용하였다면, 그것은 좋은 출발점이 될 수 있다. 하지만 실제 제작과 편집 과정에서 컨텐츠는 대본으로부터 조금씩 달라지는 일이 많다. 이 테크닉을 위해, 원래의 대본은 오디오 표현의 최종 수정판에서 실제로 일어나는 일들과 대화에 맞게끔 수정될 것이다.
팟캐스트에 최근의 소프트웨어 개정판의 신기술들에 대한 설명이 들어있다. 여기에는 두 명의 화자가 새롭고 업데이트된 기능들에 대해 특별한 형식 없이 자유롭게 대화하고, 그것들이 어떻게 사용되는지 설명하는 것이 포함된다. 한명의 화자가 녹음 전에 토의내용의 개요를 잡기 위해 작성한 질문들 목록을 이용한다. 녹음이 끝난 후, 개요는 실제 대화와 그밖의 것에 맞도록 수정되고, 보충된다. 결과인 기록물은 화자의 웹 사이트에서 오디오 파일과 함께 이용할수 있게 된다. 오디오로만 된 컨텐츠를 식별하는 대체 텍스트는 다음과 같이 읽힌다, "에피소드 42: Zap 버전 12 (텍스트 기록들이 뒤를 잇는다)" 또한 기록물을 가리키는 링크가 오디오 컨텐츠 바로 뒤에서 제공된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
시간에 기초한 미디어의 대체 버전을 참고하면서 오디오로만 된 컨텐츠를 지켜본다.
기록물에 있는 대화가 오디오만 있는 표현에서 전달하는 대화, 정보와 일치하는지 확인한다.
오디오에 여러가지 목소리가 있다면, 기록물에서는 대화 전체에 대해 누가 말하고 있는지 식별하고 있는지를 확인한다.
다음중 적어도 한가지를 만족하는지 확인한다:
오디오만 있는 컨텐츠의 대체 텍스트로부터 기록물 그 자체를 프로그램적으로 판단할 수 있다.
그 기록물은 오디오만 있는 컨텐츠의 프로그램적으로 판단된 대체 텍스트로부터 참조된다
대체 버전이 별도의 페이지에 있다면, 사용자가 그 대체 버전을 이용할 수 있게 하는 링크가 사용 가능한지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
일반적 테크닉. 모든 기술에 적용된다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 비디오만 있는 표현에 있는 정보들에 대해 접근성 있는 대체물을 제공하는 것이다.
비디오만 있는 표현에서, 정보는 애니메이션, 텍스트 또는 그래픽, 배경의 설정, 사람들의 행동과 표정, 동물들, 기타 여러가지 방법으로 표현된다. 같은 정보를 접근성있는 형태로 표현하기 위해, 이 테크닉은 비디오만 있는 미리 녹화된 컨텐츠와 동일한 이야기를 전달하고 동일한 정보를 표현하는 문서를 생성하는 것을 포함한다. 이 테크닉에서, 문서는 컨텐츠에 대한 긴 설명의 기능을 하며, 모든 중요한 정보들과 함께 그 표현의 일부가 되는 배경, 행동들, 표현들과 같은 것 역시 포함한다.
비디오만 있는 컨텐츠를 제작하기 위해 처음부터 시나리오가 사용되었다면, 이것은 좋은 출발점이 될 수 있다. 하지만 실제 제작과 편집 과정에서 컨텐츠는 시나리오로부터 조금씩 달라지는 일이 많다. 시나리오를 사용하려면, 그것은 비디오만 있는 표현의 최종 편집본과 일치하게끔 수정될 필요가 있을 것이다.
목공예 제품을 조립하는 방법을 보여주는 애니메이션이 있다. 여기에는 소리가 포함되지 않지만, 애니메이션은 과정의 각 단계를 나타내는 일련번호를 포함하며, 조립이 어떻게 완성되는지 묘사하는 그림 속의 강조된 그림과 화살표들 역시 포함한다. 또한 잘못 조립했을 경우 어떻게 되는지 묘사하는 짧은 발췌 애니메이션도 있다. 비디오만 있는 컨텐츠를 식별하는 대체 텍스트는 이렇게 씌어 있다: "빵 상자 조립 비디오 (텍스트 설명이 이어진다)" 그리고 비디오의 텍스트 설명은 비디오의 각 단계를 설명하는 완전한 텍스트를 포함한다.
이 테크닉에 연관된 자원이 없다.
시간에 기초한 미디어의 대체 버전을 참고하면서 비디오로만 된 컨텐츠를 지켜본다.
기록물에 있는 대화가 비디오만 있는 표현에서 전달하는 대화, 정보와 일치하는지 확인한다.
비디오에 여러 사람이 등장한다면, 기록물에서는 설명된 각각의 액션에 대해 누가 그것과 연관되어 있는지 식별하고 있는지를 확인한다.
다음중 적어도 한가지를 만족하는지 확인한다:
비디오만 있는 컨텐츠의 대체 텍스트로부터 기록물 그 자체를 프로그램적으로 판단할 수 있다.
그 기록물은 비디오만 있는 컨텐츠의 프로그램적으로 판단된 대체 텍스트로부터 참조된다
대체 버전이 별도의 페이지에 있다면, 사용자가 그 대체 버전을 이용할 수 있게 하는 링크가 사용 가능한지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
귀가 멀었거나 또는 특정한 인식 장애를 가진 사람들은 수화를 일차적인 의사소통 수단으로 사용할 수 있다. 그러한 사람들에게는 씌어진 언어보다 수화 버전의 페이지가 더 이해하기 쉬울 수 있다. 이 테크닉의 목적은 수화 사용자들이 컨셉이나 과정을 설명하는 어려운 텍스트를 이해하도록 돕는 수화 버전의 컨텐츠를 제공하는 것이다. 수화 언어 컨텐츠는 텍스트에 더해서 제공된다.
이것이 보충적인 컨텐츠이므로(또한 컨텐츠에 들어 있는 연설에 대한 수화 버전인 것은 아니므로), 이것은 컨텐츠와 별도로 보여져야 하며, 동기화될 필요는 없다. 그렇게 하는 것이 유용한 경우가 있을 수 있지만, 요구되는 것은 아니다.
웹 페이지 컨텐츠의 나머지에 대해서도 수화 버전이 사용 가능하도록 하려면, 그러한 비디오를 웹 페이지에 직접 포함시키거나, 별도의 창에서 비디오 플레이어를 띄우는 링크를 포함할 수 있다. 수화 버전은 또한 비디오를 보여주는 별도의 웹 페이지로, 링크를 통해 제공될수도 있다.
수화 언어는 화자의 손, 팔, 어깨, 머리, 얼굴, 입술, 혀를 사용하는 3차원적이고 시각적인 언어이다. 보는 이가 수화로 표현되는 것을 이해하도록 하기 위해, 비디오는 수화를 완전히 녹화하는 것이어야 한다. 일반적으로 말해서, 화자는 잘리는 부분(손이나 팔이 비디오 밖으로 나가는)이 생기지 않는 한도에서 카메라에 최대한 가까이 있어야 한다.
수화 언어 통역기를 어떻게 찾을 수 있는지에 대한 정보는 아래의 정보 섹션에 목록화되어 있다.
노트 1: 비디오 스트림이 너무 작다면, 수화 통역을 알아볼 수 없게 될 것이다. 수화 통역의 비디오를 포함하는 비디오 스트림을 만들때는, 접근성을 지원하는 컨텐츠 기술을 가지고 비디오 스트림을 풀스크린으로 보여줄 수 있는 메커니즘이 확실히 존재하도록 해야 한다. 그렇지 않다면, 비디오 스트림이 풀 스크린 크기였을때 수화 비디오가 차지했을만한 크기로 그것(수화 비디오)의 크기를 조정할 수 있도록 해야 한다.
노트 2: 일반적으로 수화는 프린트된 언어를 수화로 표현한 것과는 다르기 때문에, 저자는 어떠한 내용을 수화로 포함시킬것인지 결정해야 한다. 보통, 일차적인 청중의 수화 언어가 사용될 것이다. 다국어 버전으로 의도되었다면, 다양한 수화를 사용할수도 있다. 다양한 수화 언어를 사용하는 것에 관해 조언적 기술들을 참조하라.
지원받기 위해 연락하거나, 웹 사이트에 대한 질문을 보내는 방법이 텍스트와 함께 수화 비디오로도 제공된다.
웹 어플리케이션의 도움말 페이지가 텍스트와 함께 수화 비디오로도 제공된다.
기업 웹 사이트에서 각각의 상품의 기술 상세를 설명하는 수화 비디오를 제공한다.
종교와 관련된 웹 사이트에서, 그 사이트에서 사용할 수 있는 다른 수화 언어들 중에서도 영어의 수화 언어를 포함하고 있다. (? A religious Web site includes American Sign Language among the different languages in which it makes its site available).
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
National Institute on Deafness and other Communication Disorders: 영어의 수화 언어에 대한 정보
또한, 성공기준 1.2.6 - 수화 언어에 관계된 자원들 도 보라.
컨텐츠를 사용하기 위해 반드시 이해해야 하는 아이디어, 또는 과정을 다루는 텍스트를 찾아낸다.
그 텍스트에 대한 수화 언어 보충이 컨텐츠 내부에서, 혹은 컨텐츠 내의 링크를 통해서 이용 가능한지 확인한다.
수화 언어 보충이 텍스트에서 논의된 컨셉이나 과정을 보여주는지 확인한다.
#2 와 #3 을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
폼을 포함하는 모든 기술
이 테크닉은 다음과 연관된다:
당신의 웹 페이지를 검색하는 검색 기능을 제공하는 것은 사용자에게 컨텐츠를 찾을 방법을 제공하는 디자인 전략이다. 사용자는 특정한 단어 혹은 구절을 검색하여, 사이트 전체의 구조를 이해하거나 그것을 탐색할 필요 없이 컨텐츠의 위치를 찾을 수 있다. 특히 큰 규모의 사이트에서, 이러한 것은 컨텐츠를 찾아내는 빠르고 쉬운 방법이 될 수 있다.
몇몇 검색 회사들은 자신들의 검색 어플리케이션을 무료로 이용할 수 있는 사이트를 제공한다. 검색엔진은 당신 자신의 서버에 설치하여 운영할 수 있다. 대부분의 서비스는 더 나은 기능들을 갖고 있는 유료 버전 역시 제공한다.
검색 기능에 맞춤법 검사 기능, 같은 어휘에 다른 어미를 갖는 단어들(stemming) 포함하기, 다른 용법(동의어) 포함하기 등을 함께 구현한다면 검색 기능의 접근성을 더 증가시키게 될 것이다.
검색 기능은 웹 페이지에 간단한 폼 - 검색하려는 단어를 입력할 텍스트 필드와, 검색을 시작할 버튼 - 을 포함시키거나, 또는 검색 폼을 포함하는 페이지로의 링크를 추가함으로서 사이트에 더해진다. 물론, 검색 폼 자체 역시 접근성이 있어야 한다.
외부 검색을 위해서 검색 엔진에 최적화하는 테크닉들은 또한 내부 검색 엔진들도 지원하여 그것을 더 효율적이게 만든다: 키워드, META 태그, 접근성있는 내비게이션 구조를 사용하라. 검색 사이트는 검색에 최적화된 컨텐츠를 만드는 방법에 대한 가이드를 제공하는데, 예를 들어 성공적인 색인화를 위한 마이크로소프트의 가이드라인, 구글에 친근한 사이트 만들기, Yahoo! 검색 컨텐츠 품질 가이드라인 등이 있다.
쇼핑 사이트에서 상품을 서로 다른 카테고리들 - 예를 들어 남성복, 여성복, 아동복 등으로 분류하고 있다. 이것들은 부 카테고리들을 갖는데, 예를 들어 상의, 하의, 신발, 악세사리 등이다. 각각의 페이지는 또한 검색 폼을 포함하고 있다. 사용자들은 검색 필드에 품번이나 제품 설명을 입력해서, 상품 카테고리들을 따라가면서 찾을 필요 없이 그 상품으로 바로 갈 수 있다.
도움말 센터에 회사의 제품들에 관한 수천 페이지의 도움말 정보들이 있다. 사용자들은 검색 폼을 사용해서, 검색 단어를 포함하는 글을, 도움말 페이지에서만 검색할 수 있다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
웹 페이지에 검색 폼, 혹은 검색 페이지로의 링크가 포함되어 있는지 확인한다.
웹 페이지의 집합에 들어 있는 텍스트를 검색 폼에 입력한다.
검색기능을 작동시킨다.
검색한 단어를 포함하는 페이지로 사용자가 이동되었는지 확인한다.
검색한 단어를 포함하는 페이지를 가리키는 링크들의 목록으로 사용자가 이동되었는지 확인한다.
#1 을 만족하고, #4 또는 #5 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
폼을 지원하는 모든 기술
이 테크닉은 다음과 연관된다:
폼 필드의 라벨이 사용자가 그것을 볼 것으로 예상하는 곳에 위치한다면, 복잡한 폼을 이해하고 특정 필드를 찾는데 도움이 된다. 대부분의 필드 라벨은 필드 바로 앞에 위치한다. 이것은, 왼쪽에서 오른쪽으로 읽는 언어에서는 필드의 왼쪽, 혹은 위에 나타나게 되고, 오른쪽에서 왼쪽으로 읽는 언어에서는 필드의 오른쪽, 혹은 아래에 나타나게 된다. 라디오 버튼과 체크박스의 라벨은 필드 다음에 나타난다.
이렇게 포지션을 정의하는 이유는 그것이 필드, 라디오 버튼, 체크박스의 라벨의 보편적(따라서, 가장 예측하기 쉬운)인 위치이기 때문이다.
입력 필드의 앞에 라벨이 위치하는 이유는, 필드들이 서로 다른 길이를 갖기 때문이다. 라벨을 앞에 배치함으로서 줄지어 있게 할 수 있다. 또한 이렇게 함으로서 화면 확대기를 사용하는 경우에도 라벨을 쉽게 찾을 수 있는데, 그것들이 필드의 바로 앞에 있으며 세로 열(필드의 첫 부분이 세로로 줄지어 있는)에서도 찾을 수 있기 때문이다. 마지막으로, 필드에 데이터가 들어 있는 경우, 라벨을 먼저 읽고 데이터를 보면, 다른 경우들에 비해 그것을 체크하거나 이해하기가 훨씬 쉽다.
체크박스와 라디오 버튼들은 균일한 너비를 갖지만, 라벨은 보통 그렇지 않다. 따라서 라디오 버튼이나 체크박스를 먼저 놓으면 버튼과 라벨 모두가 세로로 줄지어 있게 된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
페이지에 있는 각각의 폼 필드에 대해:
폼 필드의 라벨이 보이는지 확인한다.
폼 필드가 체크박스이거나 라디오 버튼인 경우, 라벨이 필드 바로 다음에 있는지 확인한다.
폼 필드가 체크박스이거나 라디오 버튼이 아닌 경우, 라벨이 필드 바로 앞에 있는지 확인한다.
모든 확인사항을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 표준적인 발음 기호를 켜거나 끌 수 있는 메커니즘을 제공하는 것이다.
많은 언어들은 단어의 발음을 표시하거나, 단어들 사이의 구별을 돕는 발음기호를 사용한다. 일부 언어는 모음 표시, 곂자음 표시, 모음 또는 자음이 없음을 표시, 기타 다른 목적으로 발음기호를 사용한다. 그러한 발음기호가 없는 텍스트도 읽을 수 있지만, 발음기호를 추가하면 읽힘성을 증진시킬 수 있다.
하와이어로 되어 있으며, 기본적으로는 모든 발음기호를 표시하고, 사용자가 발음기호 표시를 조절할 수 있는 링크가 제공되는 웹 페이지가 있다:
발음기호를 표시하지 않음
ʻokina 처럼 풋마크 (‘)는 표시하지만, 장음 기호는 표시하지 않음
모든 발음기호를 표시함
방문자는 그(녀)가 선호하는 수준을 선택할 수 있으며, 이러한 선택은 세션 쿠키로 저장된다. 같은 세션에서 이후의 모든 페이지들은 이 쿠키를 사용하고, 선택된 수준에서 발음기호를 보이거나 감춘다.
서버에서는, 컨텐츠는 모든 발음기호를 가진 상태로 저장된다. 방문자가 발음기호가 적거나 또는 없는것을 선택한다면, 서버는 응답을 보낼 때에 사용자가 원하는만큼 발음기호를 교체하거나 없앤다.
화와이 언어 온라인 의 예제.
의미들을 구분하기 위해 발음기호를 사용하는 자연어로 된 모든 웹 페이지에서:
컨텐츠의 기본 버전이 발음기호들을 사용하는지 확인한다.
발음기호를 켜거나 끌 수 있는 메커니즘이 있는지 확인한다.
그러한 메커니즘을 껐을 때의 결과인 컨텐츠가 발음기호를 표시하지 않는 것을 확인한다.
그러한 메커니즘을 켰을 때의 결과인 컨텐츠가 발음기호를 표시는 것을 확인한다.
#1 - #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
폼을 제공하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자에게 명령을 취소하거나 변경할 수 있는 기간을 제공함으로서 에러를 복구할 수 있도록 하는 것이다. 일반적으로, 계약이나 주문은 법적인 것이며 취소할 수 없다. 그러나, 웹 사이트에서는 이러한 가능성을 제공할 수 있으며, 이렇게 함으로서 사용자가 에러로부터 복구할 수 있다.
웹 컨텐츠는 사용자에게 폼을 전송한 뒤 취소 가능 기간이 얼마나 되는지, 그리고 주문을 취소하는 과정은 어떤 것인지 알려줄 필요가 있을 것이다. 취소 과정은 온라인으로는 불가능할수도 있다. 예를 들어, 서류를 작성해서 웹 페이지에 기록된 주소로 보낼 것을 요구할수도 있다..
온라인 쇼핑 웹사이트에서 사용자가 구매한 물건을 24시간 이내에는 취소할 수 있도록 하고 있다. 웹사이트는 자신들의 정책을 설명하고, 구매 확인 이메일에 그러한 정책의 요약을 포함시킨다. 24시간이 지나면 상품은 사용자에게 발송되며 더이상은 취소할 수 없다.
웹 사이트에서 주문에 의해 제작되는 맞춤식 스포츠 재킷을 판매하고 있다. 고객은 원단을 선택하고, 재단사에게 자신의 신체 치수를 알려준다. 웹사이트는 고객에게 주문의 변경 혹은 취소가 3일간 가능하다고 알려준다. 일단 원단이 고객의 명세에 따라 재단되면, 주문을 변경하거나 취소할 수 없다. 회사의 정책은 웹사이트에 설명되어 있다.
웹 페이지에서 주문을 취소하거나 변경할 수 있는 기간을 설명하는지 확인한다.
웹 페이지에서 주문을 취소하거나 변경하는 과정을 설명하는지 확인한다.
#1 과 #2 를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
포커스를 가질 수 있는 요소를 포함하는 기술들
이 테크닉은 다음과 연관된다:
운영체제들은 포커스를 표시하는 내장된 메커니즘을 갖고 있으며, 많은 사용자 에이전트가 이것을 활용할 수 있다. 이러한 기본 렌더링은 항상 잘 보이는 것은 아니며, 특정한 배경 위에서는 잘 보이지 않을수도 있다. 하지만, 많은 플랫폼에서 사용자가 이러한 포커스 표시기의 렌더링을 개인화할 수 있도록 하고 있다. 보조 기술 역시 이러한 내장된 포커스 표시기의 외관을 변경할 수 있다. 만약 당신이 내장된 포커스 표시기를 사용한다면, 이것에 관한 시스템 전역적인 설정이 웹 페이지에도 반영될 것이다. 만약 당신이 개인적인 포커스 표시기 - 예를 들어 사용자의 행동에 대한 응답으로 페이지의 섹션에 색칠을 하는 - 이러한 설정은 반영되지 않을 것이며, 보조 기술이 당신의 포커스 표시기를 찾지 못할 수 있다.
마이크로소프트 윈도우즈의 기본 포커스 표시기는, 포커스를 받은 요소 주변에 1픽셀, 검은색 점선을 그리는 것이다. 어두운 배경을 가진 페이지에서는, 이것을 보기가 매우 어려울 수 있다. 페이지 저자는 기본값을 사용하고, 사용자가 윈도우즈에서 이것을 변경하여 밝은 색으로 표시되도록 한다.
HTML에서는, 기본적으로 폼 요소들과 링크들이 포커스를 받을 수 있다. 이에 더해, 0보다 크거나 같은 tabindex 속성을 가진 모든 요소가 포커스를 가질 수 있다. 포커스를 가진 요소는 시스템의 포커스 표시기를 사용하며, 스타일에서는 플랫폼의 변경 사항을 반영할 것이다.
플랫폼의 기능을 이용해서 포커스 표시기의 외형을 개인화한다.
탭 키를 이용해 페이지를 순회하면서 포커스의 경로를 관찰한다.
각각의 컨트롤에 대해 포커스 표시기가 보이는지 확인한다.
#3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
비디오 컨텐츠를 포함할 수 있는 모든 기술
이 테크닉은 다음과 연관된다:
맹인이거나 시력이 낮은 사용자들은 비디오로만 제공되는 컨텐츠를 이용할 수 없다. 따라서, 그들에게는 대체 오디오를 갖는 것이 중요하다. 이렇게 하는 한가지 방법은 비디오에 있는 정보를 설명하는 오디오 트랙을 제공하는 것이다. 오디오는 mp3처럼 인터넷에서 널리 사용되는 포맷이어야 한다.
웹 페이지에, 우주선이 화성에 착륙하는 것에 관한 비디오로만 표현된 컨텐츠에 대한 링크가 있다. 비디오를 가리키는 링크는 우주선의 사진이다. 비디오 가까이에는 비디오를 설명하는 오디오 파일에 대한 링크가 있다. 이러한 것은 다음의 HTML 코드와 비슷하게 보일 것이다:
예제 코드:
<a href="../video/marslanding.mp4"><img src="../images/spaceship.jpg"
alt="Mars landing, video-only" width="193" height="255"/></a>
<br />
<a href="Mars_landing_audio.mp3">"화성 착륙"의 오디오 설명</a>
비디오만 있는 컨텐츠를 포함하는 웹 페이지에 대해:
비디오로만 제공되는 컨텐츠의 바로 앞이나 뒤에 대체 오디오를 가리키는 링크가 있는지 확인한다.
#1을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
폼을 지원하는 모든 기술
이 테크닉은 다음과 연관된다:
버튼이 입력 필드에서 어떤 기능을 활성화시키고, 명확한 텍스트 라벨을 갖고 있고, 입력 필드에 인접하게 배치되었다면, 그 버튼은 입력 필드의 라벨 구실도 하게 된다. 이 라벨은 웹 페이지에 반복적인 텍스트를 사용하지 않고도, 사용자들이 필드의 목적을 이해하게끔 돕는다. 이처럼 텍스트 필드에 대한 라벨 구실을 하는 버튼은 보통 입력 필드 다음에 나타난다.
노트: 필드는 프로그램적으로 판정되는 이름 역시 반드시 가져야 한다; 성공기준 4.1.2.
웹 페이지에 사용자가 검색어를 입력하는 텍스트 필드가 있고, 검색을 수행하는 "검색"이란 라벨이 있는 버튼이 있다. 버튼은 텍스트 필드의 오른쪽에 위치하여, 사용자가 텍스트 필드에 검색어를 입력해야 함을 명확하게 나타낸다.
폼을 채워 넣어야 하는, 미국에 거주하는 사용자가 있다. 미국에서는 각 주 마다 법률과 요구사항들이 다르므로, 사용자는 자신이 거주하는 주 에 맞는 버전의 폼을 선택하여야 한다. 사용자가 주 를 선택할수 있게 하는 드롭다운 리스트가 제공된다. 가까이에 있는 버튼은 "주 에 맞는 폼을 선택하시오" 라는 라벨이 붙어 있다. 버튼을 누르면 사용자는 자신이 선택한 주 를 위한 폼이 들어있는 웹 페이지로 이동된다..
이러한 테크닉을 사용하는 필드와 버튼에 대해:
필드와 버튼이 프로그램적으로 식별할 수 있는 읽기 순서에 따라 인접하게 배치되어 있는지 확인한다.
필드와 버튼이 서로에게 인접하게 렌더링되는지 확인한다.
모든 확인사항을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉은 선택된 행동이 그(녀)가 의도한 행동인지 확인을 구한다. 한번 수행되면 다시 되돌릴 수 없는 액션에 대해 이 테크닉을 사용하라. 이렇게 하면 사용자가 실수로 폼을 전송하거나 데이터를 삭제하는 일을 피할 수 있도록 돕는다.
예를 들어, "제출" 버튼과 "취소" 버튼이 사용자가 예상한 것과는 반대의 순서로 배치되어 있는데, 사용자가 그것을 미처 의식하지 못하고 너무 빨리 버튼을 눌러 버린 경우가 있을 수 있다. 사용자에게 확인을 요청하면 사용자가 실수를 인식하고 데이터 제출을 멈추거나, 입력한 데이터의 손실을 막게 할 수 있다.
그러한 확인을 요청하는 것은 사용자에게 선택된 행동, 그리고 그것으로 계속했을 때의 결과를 주지시키는 것이어야 한다.
온라인 여행 웹 사이트에서 사용자가 서로 다른 항공사에서 좌석을 예약하는 여행 스케줄을 작성하도록 하고 있다. 사용자는 현재의 스케줄을 살펴보고, 수정하고, 취소할 수 있다. 사용자가 자신의 여행 계획을 취소할 필요가 있다면, 웹 페이지에서 스케줄을을 찾아보고, 자신이 현재 스케줄 목록에서 그것을 삭제한다. 이러한 것은 좌석 예약을 취소하게 되며, 되돌릴 수 없다. 사용자는 일단 이러한 것이 실행되면 현재의 좌석 예약을 취소하게 되며, 같은 비행기에서 이와 비교할만한 예약을 할 수 없을수도 있다는 알림을 받게 된다. 사용자는 이를 확인하거나 스케줄 삭제를 취소하도록 요청받는다.
웹메일 어플리케이션에서 사용자의 이메일을 서버에 저장하므로, 웹 어디에서든지 그것에 접근할 수 있다. 사용자가 이메일 메시지를 삭제하면, 실수로 지워졌을 경우 복구할 수 있는 휴지통 폴더로 옮겨지게 된다. 서버의 휴지통 폴더에서 메시지들을 삭제하는 "휴지통 비움" 이라는 명령이 있다. 일단 이 폴더가 비워지면, 더이상은 그 메시지들을 받을 수 없다. 휴지통 을 비우기 전에, 사용자는 이것을 확인하거나, 또는 휴지통 폴더에 들어있는 이메일의 삭제를 취소하라는 요청을 받는다.
시험의 답안을 수집하기 위해 폼이 사용되고 있다. 사용자가 '제출' 또는 '리셋' 버튼을 선택하면, 선택한 것을 보여주고 계속할 것에 대한 확인을 요청하는 페이지가 나타난다. 예제 1: "폼을 리셋하기를 요청하셨습니다. 이렇게 하면 이전에 입력한 모든 데이터를 삭제하며, 어떠한 답안도 전송하지 않을 것입니다. 폼을 리셋하기를 원하십니까? [yes button] [no button]" 예제 2: "폼을 전송하기를 요청하셨습니다. 이렇게 하면 입력된 데이터를 당신의 최종 답안으로 전송하며, 변경할 수 없습니다. 폼을 전송하시겠습니까? [yes button] [no button]"
중개 사이트에서 사용자들이 주식이나 기타 유가증권들을 거래할 수 있도록 하고 있다. 사용자가 거래시간동안 트랜잭션을 발생시키면, 대화상자가 나타나서 사용자에게 트랜잭션이 즉시 발생하며 되돌릴 수 없음을 알리고, "계속" 버튼과 "취소" 버튼이 보여진다.
되돌리거나 변경할 수 없는 행동을 초기화한다.
선택한 행동에 대한 확인 요청이 나타나는지 확인한다.
행동을 승인하거나 취소할 수 있는지 확인한다.
#2와 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
인식 장애를 가진 사람들 대다수는 양쪽 정렬(왼쪽과 오른쪽 모두로 정렬)된 텍스트 블럭에서 아주 큰 어려움을 느낀다. 단어들 사이의 공백은 페이지를 따라 내려가는 "흰 강"을 만들고, 일부 사용자들이 텍스트를 읽기 어렵게 만든다. 이러한 실패는 이렇게 혼란스러운 텍스트 레이아웃이 발생하는 상황을 설명한다. 이러한 문제를 피하는 최선의 방법은 완전히 정렬된 텍스트 레이아웃을 만드는 것이다.
대다수의 기술에서, 단순히 모든 정렬 선언을 없애라. 예를 들어, 다음의 텍스트는 오른쪽에서 왼쪽으로 읽는 언어로 작성된 HTML 페이지에서는 기본적으로 오른쪽 정렬되어 있을 것이다.
예제 코드:
<p>
Lorem ipsum dolor sit amet, ...
</p>
웹 페이지에 혼합된 정렬을 가진 섹션들이 있다. 페이지 본문의 문단들은 왼쪽으로 정렬되어 있다. 또한 몇몇 텍스트는 오른쪽으로 정렬되어 시선 집중을 유도한다.
일반적인 브라우저에서 페이지를 연다.
컨텐츠가 양쪽 정렬(왼쪽과 오른쪽 모두로 정렬)되어있지 않음을 확인한다.
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
자동으로 소리를 재생할 수 있는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 페이지가 로드될때 자동으로 재생되는 소리를 사용자가 끌 수 있게끔 하는 것이다. 소리를 끌 수 있는 컨트롤은 페이지의 시작 근처에 배치되어서, 사용자가 그것을 빠르고 쉽게 찾을 수 있어야 한다. 이러한 것은 보조 기술(스크린 리더, 화면 확대기, 스위치 메커니즘 등)을 활용하는 사람들에게 유용하며, 일부 사람들(인식 장애, 학습 장애, 언어 장애 등을 가진)에게는 그렇지 않을 수 있다.
이 테크닉에서는, 자동으로 재생되는 소리를 사용자가 끌 수 있는 컨트롤을 저자가 포함시킨다. 그러한 컨트롤은 키보드로 조작할 수 있는 것이어야 하고, 탭 포커스 순서 및 읽기 순서상 앞쪽에 있어야 하며, 현재 재생되는 소리를 끈다는 명확한 라벨이 붙어 있어야 한다.
웹 페이지에 오디오 트랙을 포함한 시간에 기초한 미디어 표현이 있고, 잔디깎는 기계의 엔진을 어떻게 수리하는지 설명하는 비디오도 포함되어 있다. 페이지에는 2개의 버튼이 있고 그것들은 "일시정지", "중지" 라고 씌어 있으며, 사용자가 시간에 기초한 미디어를 재생할지, 재생한다면 언제 할 지 조절할 수 있게끔 되어 있다.
웹 페이지에 짧은 영화가 포함되어 있다. 페이지에는 버튼이 있고 "영화 일시정지" 라고 씌어 있으며, 사용자가 이것을 눌러서 영화 재생을 일시정지시킬 수 있다.
페이지에 비디오와 오디오를 포함한 플래시 표현이 있다. 페이지에는 "멀티미디어 끄기" 라는 버튼이 있어서, 사용자가 그것을 눌러서 재생되고 있는 모든 비디오와 오디오를 멈출 수 있다.
웹 페이지를 로드한다.
음악이나 소리가 자동으로 시작하는지 확인한다.
페이지의 시작 부분에 사용자가 소리를 끌 수 있는 컨트롤이 제공되는지 확인한다.
#3을 만족한다
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
소리를 재생할 수 있는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 웹 컨텐츠에 포함된 소리의 제어권을 사용자에게 넘기는 것이다. 스크린 리더를 사용하는 사용자들은 웹 컨텐츠에서 소리가 나는 경우, 스크린 리더를 듣기가 매우 혼란되고 어렵게 느껴질 수 있다. 사용자의 요청에 의해서만 소리를 재생할 수 있는 방법을 제공하면, 스크린 리더의 출력을 방해받지 않고도 소리, 또는 다른 오디오를 듣는데 필요한 컨트롤을 사용자에게 줄 것이다.
회색 고래 보호 모임의 웹 페이지에서는 회색 고래의 울음소리를 계속해서 들려준다. 물이 찰랑거리는 소리도 있다. 이러한 소리는 자동으로 시작되지 않는다. 대신에, 웹 컨텐츠는 페이지의 상단에 사용자가 소리를 직접 재생할 수 있는 링크를 제공한다. 버튼에는 "소리를 켭니다" 라고 씌어 있다. 그 버튼을 누르면, 소리가 들린다. 사용자는 "소리를 끕니다" 는 옵션을 선택할 수 있게 된다.
회색 고래의 소리들을 포함하는 사운드 파일로의 링크가 제공된다. 링크 텍스트에는 "회색 고래의 노래소리를 들어보세요 (mp3)" 라고 씌어 있다.
3초, 혹은 그 이상 재생되는 소리를 포함하고 있는 것으로 알고 있는 웹 페이지를 로드한다.
자동으로 재생되는 소리가 없는 것을 확인한다.
사용자가 직접 소리를 켤 수 있는 방법이 있는지 확인한다.
#3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 양쪽 정렬(왼쪽과 오른쪽 모두로 정렬)을 갖지 않는 버전의 페이지를 제공하는 것이다.
레이아웃 목적으로, 텍스트를 양쪽 정렬하기를 원하는 경우가 있을 수 있다. 이러한 경우, 텍스트의 정렬을 제거하는 기능을 제공하는 것으로 충분하다. 그러한 컨트롤은 찾기 쉽고 사용하기 쉬워야 하며, 페이지의 시작 부분 근처에 있어야 한다.
노트: 이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
온라인 고전 소설이, 양쪽으로 정렬되어 있는 원래 출판본의 모양을 복제하고자 하는 사이트에 게제되어 있다. 페이지의 상단에는 "양쪽정렬 제거" 라는 버튼이 있어서, 스타일 스위치 테크닉을 이용하여 스타일시트를 바꾼다. 새로운 스타일시트는 텍스트를 왼쪽으로만 정렬한다.
양쪽으로 정렬된 페이지를 연다.
양쪽 정렬을 제거할 수 있는 기능이 있는지 확인한다.
그러한 기능이 실제로 양쪽정렬을 제거하는지 확인한다
#2와 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
오디오와 비디오를 지원하는 모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 볼 수 없는 사람들이 시청각 자료를 이해할 수 있도록, 비디오 컨텐츠의 오디오 설명을 포함하는 두번째 버전을 제공하는 것이다.
현재 대부분의 사용자 에이전트들이 여러개의 사운드 트랙을 병합할 수 없으므로, 이 테크닉은 사용자가 원래의 사운드트랙을 추가적인 오디오 설명이 더해진 것으로 교체하는 것을 허용하는 방법으로 동기화된 미디어에 추가적인 오디오 정보를 더한다. 이러한 추가적인 정보는 컨텐츠를 이해하는데 중요한 행동, 캐릭터, 장면 전환과 화면 텍스트(캡션이 아닌)들에 집중된다.
이러한 새 정보들이 원래의 사운드트랙에 있는 핵심적인 오디오 정보를 흐리게 하는 것(혹은 큰 소리때문에 흐려지는것)은 도움이 되지 못하므로, 새 정보들은 대화나 사운드 효과 사이의 잠시 멈추는 부분에 추가된다. 따라서 프로그램에 더해질 수 있는 보충적인 정보의 양은 제한된다.
오디오 설명을 일차적인 사운드 트랙으로 가진 두번째 버전의 영화를 제공하는 것은, 이 컨텐츠가 대화뿐만 아니라 배우의 대사만으로는 전달되지 않는 문맥과 기타 비디오의 양상들 역시 들어야만 하는 사람들에게도 접근성 있는 것이 되게끔 한다.
오페라 비디오의 두가지 버전이 제공된다. 첫번째 버전은 음악만을 포함한다. 두번째 버전은 음악에 더해, 무대에 있는 배우들의 동작을 묘사하는 음성 역시 포함한다.
어린이들 앞에서 공연하고 있는 요술쟁이의 비디오에, 오디오 설명이 있는 버전이 있다. 나레이터는 요술쟁이가 사용하는 도구들에 대한 설명과 함께, 공연이 진행되는 동안 어린이들의 반응 역시 설명한다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
주 사운드트랙만으로는 이해할 수 없는, 중요한 시각적 디테일들을 포함하는 버전의 미디어를 연다.
영화를 지켜본다.
대화 속의 공백들이 시각적 컨텐츠에 관한 중요한 정보를 전달하는데 사용되고 있는지 확인한다.
대체 버전이 분리된 페이지에 있다면, 사용자가 그러한 버전을 가리키는 링크를 이용할 수 있는지 확인한다.
#3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
페이지의 일부분에서 텍스트와 그 배경 사이의 대비가 성공기준 1.4.3 또는 1.4.6에서 제시하는 것을 만족하지 못한다면, 적합성 요구사항(적합성 요구사항 1)의 "대체 버전" 구절을 이용해서 이러한 가이드라인을 만족시킬 수 있다. 페이지에 링크 또는 컨트롤을 두고, 이것을 사용해서 모든 요구사항을 만족하도록 페이지를 변경하거나, 또는 원하는 레벨에서 요구사항을 충족하는 새로운 버전의 페이지로 이동하게끔 할 수 있다.
이 테크닉을 성공적으로 사용하려면, 세가지를 만족해야 한다.
원래 페이지의 링크, 또는 컨트롤 자체가 성공 기준의 대비 요구사항에 맞는 것이어야 한다. (사용자가 컨트롤을 볼 수 없다면, 새로운 페이지로 가기 위해 그것을 이용할 수 없을 것이다.)
새로운 페이지는 원래의 페이지와 동일한 모든 정보와 기능을 담고 있어야 한다.
새로운 페이지는 원하는 레벨에서 성공 기준의 모든것을 만족해야 한다. (즉, 새로운 페이지가 대비에 대한 요구사항만 만족하고 다른것은 만족하지 못하는 경우는 안된다).
이 테크닉은 대체 버전의 모든 텍스트(혹은 텍스트의 이미지)가 4.5:1의 대비를 갖고, 큰 텍스트(혹은 그 이미지)와 그 배경이 3:1의 대비를 갖게 함으로서 성공기준 1.4.3을 만족하게 하는 데 사용할 수 있다. 대체 버전의 모든 텍스트(혹은 텍스트의 이미지)가 7:1의 대비를 갖고, 큰 텍스트(혹은 그 이미지)와 그 배경이 4.5:1의 대비를 갖는다면 성공기준 1.4.3 과 1.4.6 양쪽을 만족하는 것이다.
노트: 이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
3:1의 대비 요구사항을 만족하지 않는 일부 헤드라인이 있는 페이지 상단에, 고대비(5:1)의 링크가 있어서 사용자를 새 버전으로 이동시킨다. 새 버전은 모든 텍스트와 이미지로 된 텍스트에서 최소한 4.5:1의 대비를 가진다.
페이지에서 효과를 위해 음영처리된 배경을 사용하지만, 결과적으로 텍스트와 배경의 대비가 4:1이다. 페이지의 상단에 "고대비" 라 씌어진 컨트롤이 있다. 그것을 누르면 다른 스타일이 사용되고, 배경색을 낮춰서 7:1의 대비를 갖게 된다.
원래의 페이지에 대체 버전을 이용할 수 있게 하는 링크 또는 컨트롤이 있는지 확인한다.
그 링크 또는 컨트롤이 테스트하고 있는 적합성 레벨에서의 모든 성공 기준들을 만족하고 있는지 확인한다.
대체 버전이 테스트하고 있는 적합성 레벨에서의 대비 및 다른 모든 성공 기준들을 만족하고 있는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
다른 페이지에서 다시 사용할 수 있도록 사용자 선호사항을 저장할 수 있도록 하는 모든 기술.
이 테크닉은 다음과 연관된다:
이 테크닉은 웹 페이지, 혹은 웹 페이지 집합에 사용자가 선호하는 배경색과 전경색을 명시할 수 있는 컨트롤을 제공하는 것이다. 이 테크닉은 사용자가 페이지들에 걸쳐 사용할 수 있는 선호사항을 저장할 수 있도록 하는 모든 기술을 사용하여 구현할 수 있다. 이 테크닉을 이용하여, 저자는 사이트에 사용자가 사이트의 다른 페이지에서도 사용할 수 있도록 전경색과 배경색을 선택하고 또한 저장하는 색상 선택 컨트롤을 포함시킨다. 페이지들은 이러한 선호사항이 있는지 살펴보고, 저장된 것이 있으면 그것에 적합하게 적응하도록 디자인된다.
인식 장애를 가진 대다수의 사용자들은 일반적인 흰 배경 위의 검은색 텍스트에서 어려움을 느낀다. 이따금씩, 그런 사람들은 텍스트와 배경에 다른 색상을 사용했을때에 훨씬 더 쉽게 텍스트를 읽으며, 그러한 색상 조합은 대단히 독특하여 다른 사람이 예측하기 어려운 것이다(예를 들어, 갈색 배경 위의 파란색 텍스트)
이러한 사용자들 중 일부는 운영체제의 색상 설정, 혹은 브라우저의 섹상 설정을 이용하여 색상을 설정하는데 어려움을 느낄수도 있다. 웹 페이지에 다양한 범위의 전경 및 배경색을 제공하는 도구를 제공하면 그들이 브라우저 설정을 들여다보지 않고서도 쉽게 색상을 바꿀 수 있게 될 것이다.
사용자는 텍스트 필드에 16진수 값을 입력할 수 있다. "pick" 링크는 연관된 필드에 대해 색상 선택 도구를 열 것이다.
색상 선택 도구가 열려 있다.
PHP, 자바스크립트, CSS, XHTML로 구현된 실제 동작하는 예제가 있다: 색상 선택기 예제.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
색상 선택 도구로 식별되는 컨트롤이 웹 페이지에 있는지 확인한다.
색상 선택 도구가 텍스트와 배경에서 사용할 수 있는 넓은 범위의 색상 옵션을 제공하는지 확인한다.
텍스트와 배경에 사용할 새로운 색상을 선택한다.
선택된 색상 조합으로 컨텐츠가 업데이트되었는지 확인한다.
#1과 #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
휴게실에서 보여지도록 특별히 디자인 된 것들 같은 특별한 경우를 포함하여, 모든 일반적인 웹 컨텐츠에 사용하기에 적합하다.
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 번쩍이지만, 좁은 영역에 국한되는 것들에 대해 성공 기준을 통과하는 쉬운 방법을 제공하는 것이다.
만약 당신이 1초의 단위시간동안 4회 이상 번쩍이는(따라서 G19는 이용할 수 없다) 무언가를 갖고 있지만, 번쩍이는 영역이 10도의 시각 영역(눈으로 보는 영역의 중앙을 의미한다)의 25% 미만이라면, 이것은 자동적으로 통과된다.
10도의 시각 영역은 눈으로 보는 영역의 중앙을 나타낸다. 이 영역은 시신경이 밀집되어있다. 광과민성 질환이 있는 사람들에게, 시각 피질에서의 이러한 번쩍임은 발작을 초래할 수 있다. 눈의 다른 영역(훨씬 적은 신경이 지나가는)에서의 번쩍임은 피질에 훨씬 적은 영향을 끼친다. 따라서, 시야 중앙의 10도 영역에만 집중하도록 한다.
컨텐츠가 일반적인 웹에서 사용될 것이라면,공식 1: 웹 컨텐츠를 위한 작고 안전한 영역을 사용할 수 있다.
컨텐츠가 알려진 매체 (예를 들어 회사의 휴게실)를 위한 것이라면, 공식 2: 알려진 디스플레이를 위한 작고 안전한 영역 을 사용해야 한다.
공식 1: 웹 컨텐츠를 위한 작고 안전한 영역
대부분의 웹 저자들은 시각 영역을 자신들이 늘상 다루고 있는 픽셀로 옮기는 방법을 모른다. 이 테크닉에서 그러한 번역을 제공한다.
이 시점에서, 가장 널리 퍼진 디스플레이는 15-17인치 사각형과 1024 x 768 해상도이다. 화면을 보는 일반적인 거리(11-26인치)에서 볼 경우, 10도의 시각 영역은 대략적으로 341 x 256 픽셀의 영역을 포착할 것이다. 이것은 원형이 아니고, 대부분의 사용자의 시야 중앙도 아니며, 그 차이는 매우 미미(신경이 적게 위치하는, 시야 중앙의 가장자리)하여 중요하지는 않다.(This is not circular, but neither is the central vision of most users, and the difference is so small (and at the edge of the central vision where sensors are fewer) that it is not important)
성공 기준이 10도의 시각 영역의 25%이므로, (화면에 다른 번쩍임이 없는 상태에서)21,824 픽셀보다 작은 연속된 영역에서의 번쩍임은 일반적인 번쩍임 한계치와 적색 번쩍임 한계치를 통과할 것이다.
1024 x 768이 가장 일반적인 화면 크기를 나타내므로 그것을 선택하였다. 이 공식은 더 높은 해상도의 화면에도 적용할 수 있는데, 촘촘한 픽셀 밀도는 결과적으로 더 작은, 따라서 더 안전한 이미지 사이즈가 될 것이기 때문이다.
낮은 해상도의 디스플레이를 사용하는 사용자, 또는 화면을 확대하거나 가까이에서 화면을 보는 사람들은 화면과의 거리에 따라 더 위험할 것이다. 이러한 그룹의 필요성을 만족시키려면, G19: 컨텐츠의 어떤 부분도 1초의 시간 내에 3회 이상 번쩍이지 않도록 확실히 하기 를 이용해야 한다. 그것은 화면 해상도나 화면을 보는 거리와는 무관하기 때문이다.
공식 2: 알려진 디스플레이를 위한 작고 안전한 영역
화면 크기, 해상도, 화면까지의 거리를 알고 있는 경우, 작고 안전한 영역을 (픽셀로) 계산하려면 다음의 과정을 사용하라.
노트: 몇가지 이유(중앙 시신경이 보통 원형이 아니며, 간단하게 하기 위해, 계산의 편리함을 위해, 관습적으로)로, 중앙의 10도 시각 영역의 4:3 사각 추정은 10도만큼의 너비로, 7.5도만큼의 높이로 간주된다. 이것은 75평방각이며, 10도의 완전한 원형은 78.5 평방각이다.
바라보는 거리를 사각의 크기로 변환하려면, 그 거리에 0.1745 (10 * Pi / 180) 를 곱하여 사각형의 너비를 얻고, 그 거리에 0.1309 (7.5 * Pi / 180) 를 곱하여 사각형의 너비를 얻는다. (이러한 계산은 인치, 밀리미터, 기타 어떠한 거리 단위로도 계산할 수 있다)
10도 각 시야의 크기를 픽셀로 계산한다.
이렇게 하려면, 1단계에서 얻은 사각형의 너비와 높이에 해상도를, 단위당 픽셀수로 곱해서 사각형의 너비와 높이를 픽셀 단위로 얻는다.
1080p 와이드 디스플레이 (1920 x 1080 픽셀)에서는, 인치당 픽셀수로 나타낸 화면 해상도는 2203을 화면 크기(인치)로 나눈 것이다.
720p 와이드 디스플레이 (보통 1365 x 768 픽셀)에서는, 인치당 픽셀수로 나타낸 화면 해상도는 1566을 화면 크기(인치)로 나눈 것이다.
픽셀크기를 밀리미터 단위로 나타내는 LCD 모니터에서는, 인치당 픽셀수로 나타낸 화면 해상도는 25.4를 픽셀 크기(밀리미터)로 나눈 것이다.
모든 디스플레이에 대해, 실제 화면 사이즈를 인치 단위로 알고 있다면, 그리고 가로 세로 해상도를 픽셀 단위로 알고 있다면, 인치당 픽셀수로 나타낸 화면 해상도는 ( 가로 해상도(픽셀) * 가로 해상도(픽셀) + 세로 해상도(픽셀) * 세로 해상도(픽셀) ) 의 제곱근이 된다.
사각형의 가로와 세로를 곱하고 4로 나눈다.
회사 라운지 입구에 디스플레이 될 애니메이션을 제작 중이다. 디스플레이의 크기, 해상도, 그리고 그 디스플레이를 보는 사람이 서있을 수 있는 가장 가까운 거리를 고려하여 시야 중앙 10도의 25%에 해당하는 크기를 픽셀로 계산하였다(위의 공식을 이용하여). 이것은 작고 안전한 영역일 것이다. 애니메이터들은 작고 안전한 영역보다 큰 영역에서 번쩍임이 있지 않도록 주의를 기울인다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
작고 안전한 영역을 계산한다.
화면에서 한번에 한 영역만 번쩍이는 것을 확인한다.
번쩍이는 컨텐츠가 작고 안전한 영역보다 작은 연속적인 컨테이너 안에 들어갈 만큼의 크기인지 확인한다.
#2와 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
사용자의 입력을 받아들이지만 그 형식, 값, 형태에 제한을 두는 컨텐츠
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 입력한 정보가 받아들여지지 않았으며, 그것을 수정할만한 텍스트를 알고 있는 경우, 그러한 텍스트를 제안하는 것이다. 그러한 제안은 가능한 텍스트의 집합에서 사용자 입력의 오타를 고친 것, 혹은 흡사한 텍스트를 포함할 수 있다.
폼에 따라, 제안은 에러가 발견된 필드의 다음에 위치할 수도 있고, 페이지의 다른 위치에 있을 수도 있으며, 다른 URI에 목록화된 것을 검색하는 메커니즘, 혹은 참조하는 형태일 수 있다. 가능하다면, 수정에 대한 제안들은 사용자에게 쉬운 형태로 제공되어야 한다. 예를 들어, 부정확한 제출이 있었을 경우 사용자에게 가능한 수정사항의 목록을 되돌려서 사용자가 그중에서 자신이 원했던 것을 선택할 수 있도록, 체크박스 또는 라디오버튼을 첨부하는 형태일 수 있다. 제안사항, 혹은 제안사항을 가리키는 링크는 그것과 연관된 필드 가까이, 즉 폼의 상단, 필드의 앞, 또는 수정을 요하는 필드의 다음 등에 위치해야 한다.
사용자가 시간의 길이를 입력해야 하는 폼이 있으며, 그 범위는 일단위부터 년단위까지 가능하다. 사용자는 숫자 "6"을 입력하였다. 서버는 사용자가 제출한 폼을 되돌리면서 폼 필드 다음에 제안 텍스트를 포함시키고 있다: "에러가 발견되었습니다. 의미하셨던 것이 6일, 6주, 6개월, 6년중 하나입니까?"
사용자가 도시 이름을 입력하면서 철자를 잘못 썼다. 서버는 사용자가 제출한 폼을 되돌리면서 그 상단에 사용자가 실수한 것이 있음을 알리는 메시지를 포함시키고, 사용자가 의도했을 것으로 짐작되는 도시 이름의 목록 - 도시 이름의 데이터베이스와, 사용자의 입력을 대조한 것을 통해 짐작한 - 을 가리키는 링크를 제공한다.
버스 여행 플래너가 사용자에게 목적지를 입력하도록 하는데, 거리 주소, 교차로, 도시 경계표 등을 입력할 수 있게끔 하고 있다. 사용자가 "kohl" 이라고 입력하면, 비슷한 항목을 검색한 결과 목록이 나타나며, 이렇게 읽혀진다: "kohl에 대해 검색한 결과가 다음과 같습니다." 목록 뒤에는 셀렉트 박스가 있고, 사용자는 "Kohl Center," "Kohl's Dept. Store-East", "Kohl's Dept. Store-West" 중에서 고를 수 있다.
검색에서 맞춤법 검사를 수행하고, 오타가 발견되었을 경우 대체할 수 있는 것의 링크를 제공한다. 사용자가 링크를 클릭하면, 검색은 정확한 스펠링으로 자동으로 재검색된다.
부정확한 텍스트로부터 정확한 텍스트를 추론할 수 있는 필드를 식별한다.
폼을 채워 넣으면서, 식별된 필드에 고의적으로 부정확한 텍스트를 입력한다.
사용자에게 정확한 텍스트가 제안되는지 확인한다.
그러한 제안이 폼 필드 다음에 제공되는지, 혹은 그러한 제안을 가리키는 링크가 폼 필드에 가까이 제공되는지 확인한다.
#3과 #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉은 웹 페이지에 텍스트의 크기를 점진적으로 증가시킬 수 있는 메커니즘을 제공하는 것이다. 시력이 나쁜 사람들 중 상당수는 화면 확대 소프트웨어를 사용하지 않으며, 그들은 브라우저의 텍스트 크기 조절기능에 익숙하지 않을 수 있다. 나이가 많이 든 상태에서 컴퓨터를 배우기 시작했으며, 고령으로 인한 시력 감퇴를 겪고 있는 노년층에서 이러한 현상이 두드러진다. 또한, 인식 장애를 겪고 있는 사람들 중 일부 역시 큰 폰트 사이즈를 필요로 할 수 있다.
이 테크닉은 몇몇 사용자들이 더 사용하기 쉽게 느낄 수 있는 메커니즘을 제공한다. 이 메커니즘은 시각적 표현을 다른 스타일시트로 교체하거나, 스크립트를 이용해서 텍스트 사이즈를 동적으로 변경하는 링크, 혹은 버튼을 포함할 수 있다.
이 테크닉을 구현하기 위해, 저자는 사용자가 페이지에 있는 모든 텍스트의 사이즈를, 점진적으로, 기본 텍스트 사이즈의 최소 2배 이상까지 확대하거나 축소할 수 있는 컨트롤을 제공한다.
이러한 것은 링크, 버튼, 혹은 링크된 이미지와 컨트롤을, 가능한 한 찾기 쉽게(예를 들어, 페이지에서 두드러지게 위치시키거나, 큰 텍스트 크기로 표시하거나, 고대비를 사용하거나 하는 등) 제공함으로서 구현할 수 있다.
이러한 테크닉은 가변 폰트를 사용할 수 없는 경우, 예를 들어 오래된 코드와 같은 상황에서도 사용될 수 있다.
노트: 이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
신문기사 페이지의 상단에 두개의 버튼이 있다. "텍스트 크기 증가" 버튼은 위 화살표와 함께 큰 글씨의 "T"가 있고, "텍스트 크기 축소" 버튼은 아래 화살표와 함께 작은 글씨의 "T"가 있다. 각각의 버튼에는 alt 텍스트가 있다.
사이트에 다양한 텍스트 사이즈가 설정된 많은 스타일시트가 있다. 사용자는 자신의 브라우저가 그러한 기능을 지원한다면, 그중 한가지를 선택할 수 있다. 각각의 페이지는 또한 "텍스트 크기 증가", "텍스트 크기 감소" 라는 링크가 있고, 이것은 현재 적용되어 있는 스타일시트를 적절한 대체 스타일시트로 교체할 것이다.
사이트의 모든 페이지에 "텍스트 크기 변경:" 이라는 텍스트가 있고, 그 뒤에는 "크게", "작게" 라는 링크가 있다. 링크는 자바스크립트를 작동시켜서 text-size 속성의 값을 그에 맞게 변경한다.
사이트의 모든 페이지에 "텍스트 크기 변경" 이라는 링크가 있다. 링크를 따라가서 만나는 페이지에는 여러개의 링크가 있고, 거기에는 이러한 옵션들이 포함된다: "가장 작은 폰트", "작은 폰트", "기본 폰트", "큰 폰트" 등이다. 목록의 앞에 있는 지침은 사용자가 원하는 폰트 사이즈로 변경하기 위해 링크를 선택하라고 되어 있다.
텍스트 사이즈를 증가시키고, 그렇게 되었는지 확인한다.
텍스트가 원래 크기의 200%까지 커질 수 있는지 확인한다.
텍스트 크기를 기본값까지 감소시키고, 실제로 그렇게 되었는지 확인한다.
#1과 #2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
창 크기가 변경되었을 때 텍스트를 다시 그리는 모든 기술
이 테크닉은 다음과 연관된다:
몇몇 사용자 에이전트는 텍스트 컨테이너의 다른 크기를 변경하지 않은 채 텍스트의 크기만 바꾸는 것을 지원한다. 텍스트가 자신이 할당되었던 공간을 벗어나서 넘치는 경우, 내용이나 기능의 손실이 발생할 수 있다. 그러나, 레이아웃 속성에서 내용을 계속해서 효과적으로 보여주는 방법을 제공할수도 있다. 블럭의 크기를, 텍스트가 200%까지 커지더라도 넘치지 않도록 충분히 넓게 정의했었을 수 있다. 텍스트는 블럭에 맞지 않을 경우 줄바꿈할 수 있으며, 블럭은 모든 텍스트가 블럭 안에 위치할 수 있도록 충분히 높았을 수 있다. 텍스트가 넘칠 경우 블럭은 스크롤바를 제공할 수 있다.
HTML과 CSS를 이용하여 2단 레이아웃을 만들었다. white-space 속성의 기본값인 normal을 사용하여, 텍스트가 줄바꿈하도록 만들었다. 따라서 텍스트의 크기가 200%로 증가됨에 따라, 텍스트는 다시 흐르고, 단은 길어진다. 저자가 CSS 규칙 overflow:scroll 또는 overflow:auto을 명시하였으므로, 단이 창에 비해 지나치게 클 경우, 사용자 에이전트는 스크롤바를 제공하여 사용자가 텍스트를 스크롤하여 볼 수 있도록 한다.
신문의 레이아웃이 컬럼속에 텍스트 블럭이 들어있는 형태이다. 블럭은 고정된 너비를 갖지만, 높이는 고정되지 않았다. 텍스트가 브라우저에서 크기 조절되면, 텍스트는 줄바꿈되고 블럭의 높이가 커진다.
텍스트와 그 컨테이너 모두에 상대적인 단위를 사용하면 컨테이너가 텍스트를 전혀 버리지 않으면서 그 크기에 맞추어서 커질 수 있다. 이 이미지는 인터넷 익스플로러에서 "보통" 폰트 크기를 사용한 것이다. 회색 박스는 div 컨테이너이다.
이 이미지는 인터넷 익스플로러에서 "최대" 크기를 사용한 동일한 텍스트, 컨테이너이다. 회색 컨테이너는 더 큰 텍스트를 수용할 수 있도록 커졌다.
예제 코드:
<style type="text/css">
div { background-color:#ccc; line-height:120%; position:relative; }
div.RelativeRelative { font-size:100%; width:8.1em; height:6.7em; }
</style>
<div class="RelativeRelative">
Now is the time for all good men to come to the aid of their country.
</div>
텍스트 크기를 200%로 증가시킨다.
모든 내용과 기능이 사용 가능한지 확인한다.
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 장애를 가진 사람들에게, 그렇지 않은 사람들보다 오래 걸리는 작업을 끝낼 수 있도록 충분한 시간을 제공하는 것이다. 선호사항 설정, 또는 페이지의 컨트롤 같은 메커니즘을 이용하여 사용자가 시간 제한을 기본값의 최소 10배까지 변경할 수 있게끔 한다. 선호되는 것은, 이러한 메커니즘이 변수를 갖게끔 하고, 사용자가 그러한 범위 내에서의 어떤 값으로든 시간 제한을 바꿀 수 있지만, 일정 간격으로 증가하는 시간 제한을 선택할 수 있는 방법 역시 제공하는 것이다. 사용자는 세션을 시작하면서, 시간 제한이 있는 일체의 행동 전에 시간 제한을 바꾼다.
항공사에 온라인 티켓 구입 프로그램이 있다. 기본값으로, 이 프로그램은 구입 과정의 각 단계에 1분의 시간 제한을 두고 이다. 세션의 시작 부분에서, 이러한 정보를 제공하는 웹 페이지가 나타난다: "우리는 고객이 구매 과정의 각 단계를 1분 이내에 마칠 것이라고 예상하고 있습니다. 이 시간 제한을 조절하시겠습니까?" 페이지에는 또한 몇개의 라디오 버튼들이 있다: "1분, 2분, 5분, 10분"
웹 기반의 이메일 프로그램에서 사용자가 30분간 아무 행동도 하지 않으면 자동으로 로그아웃된다. 프로그램에는 선호사항을 설정하는 기능이 있어서, 사용자가 시간 제한을 자유롭게 정할 수 있다.
시간제한을 기본값의 10배로 늘리는 메커니즘이 있는지 확인한다
시간제한을 기본값의 10배로 늘린다
시간제한이 있는 일을 한다.
기본 시간제한이 다 될까지 기다린다
2단계에서 명시한 시간이 될때까지 제한에 걸리지 않는지 확인한다.
#1과 #5를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
데이터 제출을 위한 시간이 제한되어 있으며 사용자 인증을 요구하는 페이지
이 테크닉은 다음과 연관된다:
사용자 인증을 요구하는 웹 서버들은 종종 사용자가 일정 시간동안 아무 행동이 없는 경우 세션을 종료한다. 사용자가 데이터를 충분히 빠르게 입력할 수 없었고 전송 전에 세션이 끝나버린 경우, 서버는 진행하기 전에 재인증을 요구할 것이다. 이렇게 되면, 서버는 폼의 정보를(숨겨진 데이터 처럼) 재인증에 사용된 페이지로 전달할 것이다. 그리고 사용자가 재인증하면, 서버는 재인증 페이지로부터 전달된 데이터를 이용해 폼을 다시 제출받거나, 제출될 데이터를 검토하는 페이지로 전달한다. 이 테크닉에서, 서버는 사용자가 제출한 데이터를 서버에 저장할 필요는 없다. 서버에 데이터를 임시적으로 저장하는 것이 불법이거나, 혹은 보안상 위험한 경우에는 이 테크닉이 중요하다. 또한 서버가 정보를 저장한 뒤 새롭게 인증된 세션으로 그것을 연결해야 하는 부담에서 자유로와진다는 점에서 유용하다.
노트: 사용자가 제출하고 있는 데이터가 민감한 것이거나 보안 위험이 잠재할 경우, 저자들은 데이터의 보호를 위해 데이터를 재인증 페이지로 전달한 후, 재인증이 완료되면, 원래의 데이터를 처리할 페이지로 다시 전달하는 과정을 고려해야 한다.
사용자가 위키에 로그인한 후 페이지를 편집하기 시작했다. 편집을 완료하는데 걸린 시간이, 서버에서 정한 타임아웃 시간을 초과하였다. 사용자가 편집한 것을 제출하려고 하면, 사용자는 세션이 타임아웃되었다는 알림을 받고, 로그인 페이지로 이동된다. 원래의 폼 제출을 담당하는 스크립트는 사용자의 편집 내역을 하나의 변수로서 로그인 페이지로 전달하고, 사용자가 성공적으로 로그인하게 되면, 사용자가 편집한 내용을 폼 제출을 담당하는 스크립트로 다시 전달하여, 이후의 과정은 세션 타임아웃이 일어나지 않았던 것 처럼 진행되게 된다.
사용자가 보안 쇼핑 사이트로 로그인하고 주문 폼에 정보를 입력하였다. 보안상의 이유로, 세션은 30분 후에 타임아웃되는데, 페이지가 로드된 후 사용자가 폼을 제출할떄까지는 45분이 경과하였다. 사용자는 타임아웃되었다는 알림을 받고, 다시 로그인하라는 요청을 받는다. 사용자가 정확하게 로그인하면, 주문 폼이 다시 나타나며 이전에 입력했던 모든 내용이 보존되어 있고, 사용자는 자신이 제출할 것을 검토한 후 폼을 전송할 수 있다. 로그인이 성공적으로 이루어지지 않으면, 서버는 폼 데이터를 거부할 것이다.
데이터를 제출하기 위해 사용자가 로그인해야 하는 사이트에서:
로그인하고, 시간제한이 있는 작업을 시작한다.
세션이 타임아웃되도록 한다.
데이터를 제출한다.
재인증한다.
과정이 진행될 수 있고, 데이터의 손실 없이 완료할 수 있으며, 그 데이터는 원래의 데이터 및 재인증후 변경한 모든 변경사항을 포함한 것임을 확인한다.
3단계에서 정보를 저장하기 위해 사용된 프로세스가 그 정보를 서버에 저장하지 않는 것을 확인한다. (노트:이 테크닉을 구현하기 위해 사용된 기술과 기능에 대한 지식을 필요로 한다.)
#5와 #6을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
정보를 전달하기 위해 색상을 사용하는, 색 있는 텍스트, 예를 들어:
문단에 들어 있는, 링크된 단어들
목록의 아이템, 다른것들과 뭔가 다르며, 색 있는 텍스트로 표현된 것
이 테크닉은 다음과 연관된다:
이 테크닉의 의도는 텍스트 색상의 차이를 구별하지 못할 수 있는 사용자들에게 충분한 시각적 단서를 제공하는 것이다. 문단 또는 다른 텍스트 블럭에 포함되어 있는 다른 상태의 단어들, 혹은 특수한 문자나 그래픽을 이용해서 다른 상태에 있는 단어들을 사용할 수 없는 경우에 종종 색상을 사용해서 이러한 것을 표시한다. 예를 들어, 문단 안에 흩어져 있는, 마치 다른 색상으로 프린트될것처럼 표시되어 있는 단어들은 하이퍼텍스트 링크일 수 있다. 이 테크닉은 색상의 차이를 인식하는데 어려움을 느끼는 사용자들이나, 시력이 낮아서 그러한 것을 식별하기 어려워 하는 사용자들을 위해 색상과 함께 이용할 수 있는 시각적 단서를 제공하는 방법을 설명한다.
이 테크닉을 사용하려면, 저자들은 정보를 전달하기 위해 색상만을 사용했던 모든 곳에서 색상에 더해 다른 시각적 단서를 합친다. 시각적 단서는 여러 형태가 있을 수 있는데, 예를 들어 폰트 스타일을 바꾸거나, 밑줄을 긋거나, 볼드체 혹은 이탤릭체로 표시하거나, 폰트 크기를 변경하거나 하는 것이다.
비슷한 요소들을 서로 다른 마크업 언어에서 사용하는 것을 비교하는 기사에서, 그러한 요소를 각각의 언어에서 식별하기 위해 색깔 있는 텍스트를 사용하고 있다. 그러한 요소는 첫번째 마크업 언어에서는 파란색의 굵은 글씨로 식별되고 있고, 두번째 언어에서는 붉은색의 이탤릭체로 표현되고 있다.
뉴스 사이트에서, 자신들의 사이트에 나타나는 기사들의 헤드라인을 목록화하고 있다. 그 기사가 있는 섹션, 기사가 포스트된 시간, 연관된 위치, 비디오 실황이 포함되어 있다는 등의 부가적인 정보가 있는 경우가 있다. 이러한 부가적인 정보들은 기사의 링크와는 다른 색깔로 표시되며, 각각의 링크들은 나머지 텍스트들보다 큰 글씨로 표시되기 때문에 사용자가 링크를 더 쉽게 식별할 수 있다.
짧은 뉴스 아이템에 더 많은 정보로 링크된 문장이 있을 수 있다. 그러한 문장은 색깔 있는 산세리프 폰트로 표시되며, 문단의 다른 부분은 검은색의 타임즈-로만 폰트로 표시된다.
텍스트의 색상이 정보를 전달하기 위해 사용되는 모든 곳을 찾는다.
그러한 텍스트 모두가 주변의 다른 텍스트와 시각적으로 구분되는 스타일, 혹은 폰트로 표시되었는지 확인한다.
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
문단에서 링크로 사용된 단어들 처럼 색상으로 정보를 전달하는, 색깔있는 텍스트
이 테크닉은 다음과 연관된다:
이 테크닉의 의도는 텍스트 색상의 차이를 구별하지 못할 수 있는 사용자들에게 충분한 시각적 단서를 제공하는 것이다. 문단 또는 다른 텍스트 블럭에 포함되어 있는 링크로 사용된 단어들을 표시하기 위해 종종 색상을 사용한다. 예를 들어, 문단 안에 흩어져 있는, 마치 다른 색상으로 프린트될것처럼 표시되어 있는 단어들은 하이퍼텍스트 링크일 수 있다. 이 테크닉은 색상의 차이를 인식하는데 어려움을 느끼는 사용자들이나, 시력이 낮아서 그러한 것을 식별하기 어려워 하는 사용자들을 위해 마우스가 올라갈 때, 그리고 포커스를 가질 때 추가적인 단서를 제공하는 방법을 설명한다.
이 테크닉에 대해, 사용자가 링크를 가리키거나 혹은 탭으로 이동했을 때 다른 시각적 확인을 사용할 수 있다면 주변 텍스트와 3:1 혹은 그 이상의 상대적 광도 (밝기) 차이를 이용할 수 있다. 예를 들어, 시각적 강조는 밑줄일 수 있고, 볼드나 이탤릭 같은 폰트 스타일의 차이일수도 있고, 폰트 크기가 커지는 것일수도 있다.
이러한 테크닉을 사용하는 것이 이 성공 기준을 만족하는데에는 충분하지만, 링크 텍스트를 구별하기 위해 선호되는 테크닉인 것은 아니다. 상대적 광도를 색상만으로 사용하는 링크들은 흑백색맹을 가진 사용자에게는 분명하지 않을 수 있다. 텍스트 블럭에 많은 양의 링크가 포함된다면, 링크에는 밑줄을 권장한다.
노트 1: 이 테크닉은 광도에 더해 색상을 사용하는 것에 관한 것이다. 이 테크닉에서 대비라 함은 링크와 그 주변 텍스트 사이의 대비를 말한다. 성공기준 1.4.3과 1.4.6에서, 대비라 함은 텍스트와 배경 사이의 대비를 말한다. 차이점이 있는 이유는 이 테크닉이 서로 다른 텍스트 사이의 차이(느낄만한 차이)를 드러내기 위한 것이며, 성공기준 1.4.3과 1.4.6은 다른 색으로 나타나는 배경 위의 텍스트의 읽힘성에 대한 것이기 때문이다.
노트 2:저자가 이 테크닉의 색상 부분을 사용하길 원하고(즉, 서로간에 충분한 대비를 갖는 색상들을 단어들에 사용하는 것), 또한 성공기준 1.4.3(단어와 그 배경 사이의 대비)를 만족하길 원한다면, 다음의 색상들을 사용할 수 있다. (예를 들어 흰 배경 위의 검은색 텍스트, 그리고 링크는 다음에 나열하는 색상 중 하나를 사용하는 것)
노트 3:어떤 시점에서 모든 보조 기술과 웹 브라우저들이 사용자를 위해 웹 페이지의 모든 링크들을 밑줄로 표시하는 옵션을 제공한다면, 링크를 강조하기 위해 저자가 제공하는 메커니즘 대신 그러한 옵션을 사용할 수 있을 것이다.
둘러싼 텍스트와 3:1의 대비를 갖는 링크들을 참조하라
문서의 하이퍼링크가 중간 밝기의 푸른색(#3366CC) 이고, 일반적인 텍스트는 검은색 (#000000)이다. 파란색 텍스트가 충분히 밝으므로, 그것은 주변의 텍스트와 3.9:1의 대비를 갖고, 모든 타입의 색맹 사용자 - 색깔을 전혀 구분하지 못하는 사람들을 포함해서 - 들에게 주변 텍스트와 다른 것으로 식별된다.
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
텍스트의 색상만으로 정보를 전달하는 모든 곳을 찾는다.
텍스트 색상의 상대적 광도 가 주변의 텍스트의 상대적 광도와 최소한 3:1의 차이를 갖는지 확인한다.
링크를 가리키는(마우스오버) 동작이 시각적 차이(밑줄, 폰트변경 같은)를 가져오는지 확인한다.링크를 가리키는(마우스오버) 동작이 시각적 차이(밑줄, 폰트변경 같은)를 가져오는지 확인한다.
키보드를 사용해서 링크에 포커스를 주는 동작이 시각적 차이(밑줄, 폰트변경 같은)를 가져오는지 확인한다.
#2, #3, #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 입력해야 하는 데이터의 형식에 관한 제한을 미리 알림으로서 사용자가 입력 에러를 피할 수 있도록 돕는 것이다. 그러한 제한에 관한 지침은 폼의 상단에 제공된다. 이 테크닉은 필드의 숫자가 적은 폼, 혹은 많은 필드들이 동일한 형식의 데이터를 요구하는 경우에 가장 적절하다. 이러한 경우, 동일한 형식 제한을 갖는 각각의 필드에 대해 똑같은 정보를 되풀이하는 것 보다는, 지침에서 그러한 형식을 한번 설명하는 것이 더 효과적이다.
네트워크 비즈니스 사이트에서 사용자들이 업무에 대한 설명을 포스팅할 수 있도록 허용하고 있다. 정보를 수집하는 폼에는 회사 이름, 업무 타이틀, 기간, 업무 설명이 포함된다. 폼의 상단에는 다음과 같은 지침이 있다:
요청된 정보들을 당신이 프로필에 더하길 원하는 위치에 입력하십시오. 날짜는 mm/dd/yyyy 형식으로 입력해야 합니다."
회사 디렉토리에 사용자들이 자신의 프로필을 수정함으로서 전화번호와 업무구분 등의 정보를 개인화할 수 있다. 폼의 상단에 다음과 같은 지침이 있다:
어떤 필드의 정보든지 업데이트 할 수 있습니다. 완료를 선택하면, 변경한 것이 저장되며 프로필을 게제할 수 있습니다. 변경한 것을 저장하지 않기로 했다면 취소 버튼을 누르십시오.
프로필에서 시스템 텍스트로 표시된 것 (즉, 필드에 들어있지 않은 것)은 수정할 수 없습니다. 이 정보는 회사의 인재 정보에서 가져온 것입니다. 당신이 수정할 수 없는 것 중에서 틀리거나 오래된 정보가 있다면 도움말 아이콘을 클릭하여 어떻게 정정할 수 있는지 알아보십시오..
전화번호에는 숫자와 - 만 사용할 수 있습니다.
필수적인 필드들은 아스테리스크 (*) 표시가 있으며, 폼을 완성하기 위해서는 반드시 입력해야 합니다.
주어진 형식으로만 사용자의 입력을 받아들이는 폼 컨트롤을 식별한다.
1단계에서 식별된 각각의 폼 컨트롤에 대해 기대되는 형식에 관한 지침이 폼의 상단에 제공되는지 확인한다.
#2를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 작은 사이트에서 모든 웹 페이지에 대한 링크를 홈 페이지에 제공함으로서 사용자들이 모든 정보를 찾을 수 있도록 하는 것이다. 사이트에 포함된 페이지의 숫자가 충분히 적다면, 홈 페이지는 사이트맵 정보를 직접적으로 담을 수 있다. 웹 사이트의 다른 페이지들은 홈 페이지로 가는 링크를 포함한다.
이러한 방법으로, 홈 페이지는 두가지 메커니즘을 제공한다. 이것은 페이지들로 가는 일상적인 내비게이션이며, 사실상의 사이트맵이다.
사이트의 모든 웹 페이지들은 모든 다른 페이지들로의 링크를 포함하며, 그러한 링크 집합들은 성공기준 3.2.3 (계속적인 내비게이션) 을 만족한다.
컨설턴트를 위한 작은 상업적인 웹 사이트에 홈 페이지, 컨설턴트와 연락하기 위한 페이지, 컨설턴트의 배경을 설명하는 페이지, 컨설턴트의 업무의 예를 드는 페이지가 있다. 각각의 페이지에는 내비게이션 바가 있어서 사이트의 다른 모든 페이지들에 대한 링크를 담고 있다.
홈 페이지에, 웹 사이트에 있는 다른 모든 페이지들에 대한 링크들이 있는지 확인한다.
웹 페이지에 있는 모든 다른 페이지들이 홈 페이지를 가리키는 링크를 포함하는지 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자가 컨텐츠의 움직임이나 깜박임을 멈출 수 있는 컨트롤을 제공하는 것이다. 컨트롤이 웹 페이지 안에 있기 때문에, 컨트롤 자체는 적합한 레벨의 WCAG 적합성, 예를 들어 적당한 대비를 가질 것, 자신을 식별하는 이름을 가질 것, 키보드로 접근 가능할 것 등을 만족한다. 컨트롤은 페이지의 상단에 있거나, 움직이는 컨텐츠 근처에 있다. 하나의 컨트롤로 페이지에 있는 모든 컨텐츠의 움직임이나 깜박임을 멈출수도 있으며, 컨텐츠 각각의 부분에 대해 별도의 컨트롤이 있을 수도 있다.
웹 페이지에서 가장 최근의 주식 시장 결과를 "ticker tape", 화면의 맨 아래까지 자동으로 스크롤하는 것, 에 표시한다. 사용자가 이것을 멈출 수 있는 "일시정지" 버튼이 있다. 테이프의 일시정지 상태를 취소하면, 테이프는 현재 주식시장 정보 표시를 계속한다.
원격회의 웹 페이지에서 발언하기를 원하는 사람들의 대기열을 보여준다. 페이지에는 체크박스가 있어서, 새로운 발언 희망자가 추가되거나 제거되었을 때 대기열을 자동으로 갱신할지, 아니면 사용자가 "갱신" 버튼을 눌렀을때에만 그렇게 할 지 선택할 수 있다. 대기열이 자동으로 갱신되게 되면, "갱신" 버튼은 비활성화된다.
웹 페이지에 움직임을 멈출 수 있는 컨트롤이 있는지 확인한다.
컨트롤을 활성화한다.
움직임, 깜박임, 자동 업데이트가 멈추는지 확인한다.
#1과 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 사용자 에이전트의 기능을 이용하여 컨텐츠의 깜박임을 멈출 수 있도록 하는 것이다. 사용자 에이전트는 사용자가 특정 기술로 된 컨텐츠의 애니메이션을 멈출 수 있도록 한다. 사용자 에이전트가 이러한 기능을 작동시키면, 깜박임을 포함한 모든 애니메이션이 멈춘다.
사용자가 애니메이션을 멈출 수 있는 가장 일반적인 방법은 "escape" 키를 누르는 것이다. 이 키의 이벤트 대기열에 앞서 있는 다른 작업이 존재하지 않는 한, 이렇게 하는 것은 컨텐츠의 움직임이나 깜박임을 멈추는 명령어로 인식된다.
일반적으로 이것이 동작하는 것으로 알려진 기술들은 다음을 포함한다:
Graphics Interchange Format (GIF)
Animated Portable Network Graphics (APNG)
페이지에 사용자의 주의를 끌 목적으로 깜박이는 배너가 있다. 배너는 무한히 반복되는 애니메이션 gif 이미지이다. 사용자는 "escape" 키를 누르는데, 이것은 사용자 에이전트가 페이지에 있는 모든 애니메이션 gif 이미지의 애니메이션을 멈추게 한다.
깜박이는 컨텐츠를 포함하고 있는 웹 페이지를 로드한다.
브라우저의 애니메이션 멈춤 명령(보통 escape 키)을 작동시킨다.
깜박임이 멈추는지 확인한다.
Check #3 is true.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
인식 장애를 가진 사람들 중 대다수는 한가지 간격을 가진 텍스트를 읽는데 어려움을 느낀다. 행간을 증가시키는 버튼은 이러한 사람들이 컨텐츠를 읽는 데 도움을 준다. 문단의 구분을 보존하기 위해, 문단 사이의 간격 역시 줄 간격의 1.5배만큼 커져야 한다.
노트: 이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
일반적인 스타일 페이지 스위칭을 사용하고, 스타일시트를 교체할 수 있는 버튼이나 링크를 페이지에 둔다. 새로운 스타일시트는 줄간격을 늘리는 규칙과, 문단 간격을 늘리는 class를 포함한다.
예제 코드:
p {line-height: 150%; margin-bottom: 2em;}
자원들은 오직 정보 목적만을 갖고 있으며, 어떠한 암시적인 보증도 포함하지 않는다.
페이지에 줄간격과 문단간격을 늘릴 수 있으며 그런 라벨을 가진 버튼이나 링크가 있는지 확인한다.
그 버튼이나 링크를 사용한다.
그 기능이 줄간격과 문단간격을 늘리는지 확인한다.
문단간격이 줄간격의 최소한 1.5배 이상 큰지 확인한다.
#1, #3, #4를 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
링크를 포함하는 모든 기술들
이 테크닉은 다음과 연관된다:
이 테크닉의 목적은 각각의 링크 텍스트가 문맥과 관계 없이 그 자체만으로 링크의 목적을 판단하기에 충분한, 웹 페이지의 요구사항에 부합하는 대체 버전으로 사용자를 인도하는 컨트롤을 웹 페이지의 시작 부분 근처에 제공하는 것이다.
일부 유저들은 링크가 자기 자신을 나타내어, 그 의미를 파악하기 위해 링크의 문맥을 탐색할 필요가 없는 것을 선호한다. 다른 사용자들은 문맥 정보를 각각의 링크에 포함시키는 것은 반복적이며, 사이트를 이용할 능력을 감소시킨다고 생각한다. 보조 기술의 사용자들 가운데, 어느쪽을 선호하는지에 대해 워킹 그룹에 전달된 피드백은 나뉘어졌다. 이 테크닉은 사용자들이 자신에게 가장 적합한 접근방법을 선택하도록 한다. 좀 길 수 있지만 완전한 링크 텍스트를 선호하거나, 필요로 하는 사용자들은 이 버전을 사용한다.
대체 버전으로 교체하는 컨트롤이 링크라면, 그 컨트롤의 목적을 링크의 텍스트만으로 직접 이해할 수 있는 것이어야 한다.
이 테크닉은 현재 페이지의 대체 버전을 제공한다. 이러한 선호사항을 쿠키, 혹은 서버사이드 사용자 프로필에 저장하여, 사용자가 이러한 선택을 사이트당 한번만 하면 이후부터는 자신이 선호하는 버전으로 자동으로 이동하게 하는 것이 가능할 수 있으며, 일부 경우에는 이러한 것을 권장한다.
노트: 이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
웹 페이지에서 다운로드 할 수 있는 도서의 목록을 서로 다른 형태로 제공한다. 웹 페이지의 대체 버전은 링크 텍스트로 도서 형식만을 사용하거나, 도서 제목과 형식 타입을 사용한다.
짧은 링크 텍스트를 사용하는 버전:
예제 코드:
...
<h1>다운로드할 수 있는 도서들</h1>
<p><a href="books-full-links.html" >풀 링크 버전</a></p>
<ul>
<li>웹의 역사:
<a href="history.docx" class="hist">Word</a>,
<a href="history.pdf" class="hist">PDF</a>,
<a href="history.html" class="hist">HTML</a>
</li>
...
</ul>
완전한 링크 텍스트를 사용하는 버전:
예제 코드:
...
<h1>Books for download</h1>
<p><a href="books-short-links.html" >짧은 링크 버전:</a></p>
<ul>
<li>웹의 역사:
<a href="history.docx" class="hist">웹의 역사(Word)</a>,
<a href="history.pdf" class="hist">웹의 역사(PDF<)/a>,
<a href="history.html" class="hist">웹의 역사(HTML)</a>
</li>
...
</ul>
페이지의 시작 부분에 링크 텍스트를 변경하는 컨트롤이 있는지 확인한다.
컨트롤을 동작시킨다.
결과로 나타난 웹 페이지의 링크 텍스트가 자신의 목적을 설명하는지 확인한다.
#1과 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
(역주:이 테크닉에 대해, "올바른" 이라는 단어로 conforming to WCAG - WCAG의 요구사항에 부합하는 - 을 나타내고, "올바르지 않은" 이라는 표현으로 not conforming to WCAG - WCAG의 요구사항에 어긋난 점이 있는 - 을 나타낸다.)
페이지에 있는 모든 객체들이 올바른 것이 좋지만, 그것이 불가능한 경우가 있다. 어떤 객체나 컨텐츠 섹션이 특정한 장애를 가진 사람들을 위해 의도되었는데, 동일한 속성 때문에 다른 누군가는 그것에 접근할 수 없게 되는 경우가 있을 수 있다. 웹 페이지에 올바른 객체를 사용하지 못하는 다른 이유들이 있을 수 있다. 객체가 올바르지 않다면, 올바른 대체 버전을 가리키는 링크가 그 올바르지 않은 객체 가까이에, 읽는 순서로, 제공되거나, 그 올바르지 않은 객체와 연결된다. 올바른 대체 버전은 올바르지 않은 버전과 동일한 정보를 전달한다.
"The Hip Hop Kid" 라는 제목의 랩 음악 비디오에는 음악적인 배경이 있다. 노래가 잠시 멈추는 동안 "오디오 설명"을 제공하게 되면, 이러한 것이 연주자가 전달하고자 하는, 기타 소리와 드럼소리 등을 방해할 수 있다. 웹 페이지에서는, 비디오 객체의 바로 다음에, 이렇게 씌어진 링크가 있다: "'The Hip Hop Kid'의 오디오 설명이 있는 버전" 대체 버전에는 비디오에서 시각적으로 일어나고 있는 일들에 대한 오디오 설명이 포함되어 있다.
독립 선언에 관한 웹 페이지에 그 문서의 이미지가 포함되어 있다. (이미지의)텍스트와 배경 사이의 대비가 충분치 못하며, 문서에 손으로 쓴 글씨들은 읽기가 어렵다. 이 문서의 HTML 버전을 가리키는 링크가 제공된다.
접근성이 지원되지 않는 웹 기술을 통해 인터랙티브 애니메이션이 제작되었다. 올바르지 않은 컨텐츠 가까이에, 올바른 대체 버전을 가리키는 링크가 있다.
페이지에 있는 각각의 올바르지 않은 객체들에 대해:
웹 페이지에 올바르지 않은 객체가 있는지 확인한다.
올바르지 않은 객체의, 읽는 순서 상으로 바로 뒤에, 식별가능한 올바른 버전에 대한 링크가 있는지 확인한다.
그 링크가 올바른 버전을 가리키는지 확인한다.
#2와 #3을 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
모든 기술
이 테크닉은 다음과 연관된다:
이것은 깜박이는 컨텐츠가 있는 페이지를 사용할 수 없는 사용자들이 그러한 깜박임을 끌 수 있도록 하는 일반적인 테크닉이다. 적합성 요구사항 1은 요구사항에 만족하기 위해 대체 페이지를 이용하는 것을 허용한다. 이 테크닉은 성공 기준 2.2.2에 적용되는 접근방법의 한 예이다.
깜박이는 컨텐츠를 가진 페이지에 있었던 모든 정보가, 그러한 컨텐츠를 갖지 않은 페이지에 전부 포함되도록 하는 것이 중요하다.
노트 1:깜박이는 컨텐츠를 페이지에서 제거하는 것은, 그 컨텐츠가 원래의 페이지에서 필요 없는 것이었을 경우에만 가능하다.
노트 2:이 테크닉은 요구사항에 부합하지 않는 컨텐츠의, 요구사항에 부합하는 대체 버전을 제공하는 스타일 스위치 테크닉과 함께 사용할 수 있다. 더 알아보려면 C29: 요구사항에 부합하는 대체 버전을 제공하기 위해 스타일 교체기 사용하기 (CSS) 와, and 요구사항에 부합하는 대체 버전을 참조하라.
페이지의 상단에, 먼저 등록하기 전에는 페이지를 제출할 수 없다는 깜박이는 경고가 있다. 페이지의 상단에는 깜박이는 텍스트를 아주 잘 보이지만 깜박이지는 않는 스타일을 가진 텍스트로 교체하여 페이지를 다시 로드하는 링크가 있다.
깜박임을 끄고 페이지를 다시 로드하는 메커니즘이 있는지 확인한다.
다시 로드된 페이지에 깜박임이 없는 것을 확인한다.
다시 로드된 페이지가 원래 페이지의 모든 정보와 기능을 갖고 있는 것을 확인한다.
위를 모두 만족한다.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.
명세를 가진 모든 마크업 언어
이 테크닉은 다음과 연관된다:
마크업 언어들이 자신의 명세를 완전히 만족하는 방향으로 사용되면, 4.1.1의 모든 요구 사항 역시 만족된다. 따라서, 비록 명세를 완전히 만족하는 것이 WCAG 2.0의 요구사항을 따르는 필수 조건인 것은 아니지만, 가장 좋은 방법이며, 성공기준 4.1.1을 만족하는 방법이다.
모든 기술들이 명세에 확실히 맞도록 주의깊게 제작된 페이지가 있다. 유효성 검사를 거쳤고, 발견된 모든 에러들을 수정하였다. 유효성 검사에서 식별할 수 없는 요구사항들 역시 체크되었으며, 모든 결격사유들이 수정되었다.
모든 기술들이 명세에 맞게 사용되었는지 확인한다.
노트: 유효성 검사기가 에러를 잡아내는 훌륭한 도구일 수 있지만, 컨텐츠가 명세를 완전히 만족하지 못하는 모든 경우를 잡아낼 수 있는 것은 아니다.
Check #1 is true.
이 테크닉이 성공 기준에 대한 충분조건이라면, 이 테스트 과정에 실패한 것이 성공 기준이 다른 방법으로 충족되어졌다고 말할 수 있는 근거가 될 수는 없으며, 이 테크닉은 성공적으로 구현되어지지 않은 것이고 요구사항에 충족했다고 말할 수 없는 것이다.