본 문서, “웹이 아닌 정보통신기술에 대한 WCAG 2 적용 안내 (WCAG2ICT)”는 웹 콘텐츠 접근성 지침(WCAG) 버전 2.0[WCAG20], 2.1[WCAG21] 및 2.2[WCAG22] 원칙, 지침 및 성공 기준이 웹이 아닌 정보 및 통신 기술(ICT), 특히 웹이 아닌 문서 및 소프트웨어에 어떻게 적용될 수 있는지 설명한다. 이는 정보성 안내(규범적이지 않고 요구 사항을 설정하지 않는 지침)를 제공한다.
본 문서는 WCAG 2.1과 2.2에서 추가된 새로운 지침, 성공 기준 및 정의를 포함하기 위해 W3C 실무 그룹 노트를 업데이트한 것이다.
2013년 9월에 승인된 웹이 아닌 정보통신기술에 WCAG 2.0 적용 지침(WCAG2ICT)은 WCAG 2.0이 웹이 아닌 문서 및 소프트웨어에 어떻게 적용될 수 있는지 기술하였다. WCAG2ICT는 WCAG의 구조인 인지 가능(인식의 용이성), 운용 가능(운용의 용이성), 이해 가능(이해의 용이성), 견고함(견고성)을 반영하여 구성되었다. WCAG2ICT는 WCAG 성공 기준이 웹이 아닌 문서와 소프트웨어에 언제, 어떻게 적용될 수 있는지 명확히 하였다. 일부는 수정 없이 적용 가능하였으며, 일부는 편집 및(또는) 주석과 함께 적용이 가능하였다. 용어집 용어들도 검토되었다. 2013년 WCAG2ICT 실무 그룹 노트에서는 레벨 AAA 성공 기준은 다루지 않았다.
2013년 WCAG2ICT는 규정 및 법률의 기준이 되었다. 그 예로는 [etsi-en-301-549](유럽) 및 EN 301 549를 참조하거나 통합하는 기타 표준(예: 인도, 케냐, 호주)이 있다. 또 다른 예로는 미국 연방정부의 전자정보 접근성 규정(이하 Section 508)의 웹이 아닌 ICT의 WCAG 2.0 적용으로, 웹이 아닌 기술에 적용되는 특정 기준에 대한 구체적인 지침과 예외를 제공하기 위해 WCAG2ICT를 참조하였다. Section 508은 웹이 아닌 문서에 적용 가능한 접근성 표준으로 WCAG를 참조로 통합하고 웹이 아닌 소프트웨어에 대한 WCAG 준수를 요구한다.
본 문서는 웹 콘텐츠 접근성 지침(WCAG)을 웹이 아닌 정보통신기술(ICT)에 해석하고 적용하는 것과 관련하여 정보 제공 지침(규범적이지 않고 요구사항을 설정하지 않는 지침)을 제공한다. 본 문서는 실무 그룹 노트(W3C 권고안인 WCAG 2.0, WCAG 2.1, WCAG 2.2와 대비해)이다. 구체적으로, 본 문서는 WCAG 2.0, 2.1, 2.2의 레벨 A 및 AA 성공 기준을 웹이 아닌 ICT, 특히 웹이 아닌 문서 및 소프트웨어에 적용하는 것에 대한 정보성 안내를 제공한다.
본 문서는 WCAG 2를 사용하여 웹이 아닌 문서와 소프트웨어를 장애가 있는 사람들에게 더 접근 가능하게 만드는 방법을 명확히 하는 데 도움을 주기 위한 것이다. 접근성 문제를 다루는 것은 청각, 인지, 신경학적, 신체적, 언어 및 시각 장애가 있는 사람들의 요구, 그리고 노화 효과로 인한 사람들의 접근성 요구를 다루는 것을 포함한다. WCAG 2는 인지 및 학습 장애와 정신 건강 관련 장애가 있는 사람들의 일부 사용자 요구를 다루고 있지만, 이러한 그룹의 사용자 요구를 다루기 위해 웹이 아닌 ICT에 대해서는 WCAG 보충 자료인 인지 및 학습 장애인이 사용할 수 있는 콘텐츠 만들기(Making Content Usable for People with Cognitive and Learning Disabilities)를 따르는 것을 권장한다. 개발자 역시 애플리케이션과 콘텐츠를 사용하는 장애가 있는 사람들로부터 테스트 의견을 받는 것을 권장한다.
본 문서는 광범위한 문제를 다루고 있지만, 장애가 있는 사람들의 모든 요구를 다룰 수는 없다. WCAG 2가 웹을 위해 개발되었기 때문에, 웹이 아닌 문서와 소프트웨어의 접근성을 다루는 것은 본 문서에 포함된 것 이상의 요구사항과 고려사항을 포함할 수 있다. 저작자와 개발자들은 웹이 아닌 문서와 소프트웨어가 가능한 한 장애인들에게 접근성을 보장하기 위해 현재의 모범 사례에 관한 조언을 구하는 것을 권장한다. 다음의 지원 문서들은 더 넓은 범위의 장애가 있는 사람들을 지원하기 위한 사용자 요구, 의도 및 일반화된 구현 기술에 대해 배우는 데 도움이 되는 정보를 포함하고 있다:
WCAG 2는 기술 중립적으로 설계되었지만, 웹 콘텐츠에 접근하는 수단으로 브라우저, 미디어 플레이어 또는 보조 기술과 같은 “사용자 에이전트”의 존재를 가정하고 있다. 그 결과, 웹이 아닌 환경에서의 문서와 소프트웨어에 WCAG 2를 적용하기 위해서는 WCAG 2 각 성공 기준의 의도가 이러한 다양한 사용 환경에서 어떻게 준수할 수 있는지 결정하기 위해 일부 해석이 필요하다. 따라서, 태스크 포스 작업의 대부분은 WCAG 2의 각 성공 기준이 웹이 아닌 ICT에 적용될 때 어떻게 적용될 것인지 평가하는 것이었다.
태스크 포스는 WCAG 2의 성공 기준 대부분이 변경 없이 또는 최소한의 변경으로 웹이 아닌 문서 및 소프트웨어에 적용될 수 있다는 것을 발견하였다. 많은 레벨 A 및 AA 성공 기준은 웹 관련 용어를 포함하지 않기 때문에, 이는 WCAG 2.2 이해[UNDERSTANDING-WCAG22] 자료의 “의도”에 기술된 대로 직접 적용된다. 웹이 아닌 문서와 소프트웨어에 적용하는 데 도움을 제공하기 위해 필요에 따라 추가적인 주석이 제공되었다.
성공 기준에서 “웹 페이지” 같은 특정 웹 관련 용어나 문구가 사용된 경우, 이들은 “웹이 아닌 문서 및 소프트웨어”와 같은 웹이 아닌 용어나 문구로 대체되었다. 용어 대체를 설명하기 위한 추가 주석도 제공되었다.
소수의 성공 기준은 “웹 페이지 세트” 또는 “여러 웹 페이지”에 적용되도록 작성되었으며 세트 내의 모든 페이지가 일부 특성이나 동작을 공유하는 것을 기준으로 한다. WCAG 2에서 적합성의 단위는 단일 웹 페이지이므로, 태스크 포스는 웹이 아닌 문서에 대한 동등한 적합성 단위가 단일 문서라는 데 동의하였다. 이에 따라 “웹 페이지 세트”에 대한 동등한 평가 단위는 “문서 세트”가 될 것이다. 웹이 아닌 소프트웨어를 명확하게 개별 부분으로 나누는 것이 불가능하므로, 단일 “웹 페이지”는 “소프트웨어 프로그램”에, “웹 페이지 세트”는 “소프트웨어 프로그램 세트”에 대응되었다. 이 두 용어는 모두 본 문서의 주요 용어 섹션에 정의되어 있다. 문서 그룹이나 소프트웨어 조각이 언제 세트로 간주되는지 확인하려면 “문서 세트”와 “소프트웨어 프로그램 세트”를 참조하라.
일부 성공 기준은 모든의 지역 규정 및 법률에 완전히 반영되지 않았고, 모든 기술에 적용될 수는 없다. WCAG2ICT는 특정 성공 기준의 적용 여부를 결정하는 데 일부 규정에서 활용되고 있다. 예를 들어, 미국의 Section 508 및 유럽의 EN 301 549와 같은 일부 지역 표준에서는 WCAG 2.0의 성공 기준 중 2.4.1(블록 건너뛰기), 2.4.5(다양한 방법 제공), 3.2.3(일관된 탐색), 3.2.4(일관된 식별)을 웹이 아닌 문서 및 소프트웨어에는 적용하지 않는다고 명시하고 있다. 또한 EN 301 549는 2.4.2(페이지 제목 제공) 및 3.1.2(부분 언어 표시) 기준이 웹이 아닌 소프트웨어에는 적용되지 않는다고 규정하고 있다. 반면, 미국 법무부의 장애를 이유로 한 차별 금지 규정 - 주 및 지방 정부 기관의 웹 정보 및 서비스 접근성(89 FR 31320, 2024년 4월 24일)은 본 문서의 지침을 활용하여 모바일 애플리케이션에 대한 요구 사항의 적용 여부 및 적용 방식을 결정하도록 명시하고 있다. 본 문서(WCAG2ICT)에서는 특정 기준이 반드시 적용되어야 하는지 여부를 구체적으로 규정하지 않으므로, 이를 구현하는 담당자는 개별 성공 기준이 웹이 아닌 문서 및 소프트웨어에 적용될 수 있는지를 신중히 고려해야 한다.
용어집의 항목 또한 검토되었으며, 대부분은 웹이 아닌 문서 및 소프트웨어에도 원문 그대로 적용될 수 있었다. 일부 항목은 “웹 페이지” 등의 표현과 관련하여 추가적인 설명이나 수정이 이루어진 경우에만 적용되었다. 또한, 일부 용어는 WCAG2ICT 참고 문서에서 현재 다루지 않는 AAA 수준의 성공 기준에서만 사용되므로, 이에 대해서는 별도로 언급하지 않았다.
본 문서는 WCAG 2의 조항(원칙, 지침, 성공 기준)이 웹이 아닌 문서 및 소프트웨어에 적용되어야 하는지 여부를 결정하는 것이 아니라, 적용될 경우 그 적용 방식에 대해 설명하는 것을 목표로 한다.
본 문서는 WCAG 2 또는 그 지원 문서의 변경을 제안하지 않으며, WCAG 2를 웹 기술에 구현하는 방식에 대한 해석도 포함하지 않는다. 다만, 본 문서 개발 과정에서 WCAG2ICT 태스크포스는 일부 성공 기준의 의도에 대해 명확한 설명을 구하고자 했으며, 이는 Understanding WCAG 2 문서의 설명으로 이어졌다.
본 문서만으로는 웹이 아닌 문서 및 소프트웨어의 접근성이 보장되지 않는다. WCAG는 웹 표준으로써 플랫폼의 비사용자 인터페이스 측면, 개별 사용자 인터페이스 구성 요소, 폐쇄형 제품 소프트웨어(보조 기술과 프로그램적 정보를 교환할 수 없는) 등의 접근성 요구 사항을 완전히 포함하지 않는다.
본 문서는 제품의 하드웨어 측면에 대해 다루지 않으며, 이는 WCAG 2의 기본 개념이 하드웨어에 적용되지 않기 때문이다.
본 문서는 웹이 아닌 문서 및 소프트웨어에서 WCAG 2를 구현하는 데 필요한 기법(techniques)을 제공하지 않는다.
본 문서는 웹이 아닌 정보통신기술(ICT)에 대한 정보 제공을 목적으로 하는 참고 문서(Note)이며, 표준이 아니므로 웹이 아닌 ICT가 본 문서에 따라 준수해야 하는 방식에 대해 기술하지 않는다.
본 문서는 WCAG 2.2의 원칙, 지침, 성공 기준 및 용어 정의에서 인용된 내용을 변경 없이 포함하고 있다. 각 원칙, 지침, 성공 기준 및 용어 정의에 대한 본 문서의 지침은 ”… 적용(하기)“으로 마치는 제목 아래에 제시된다. 해당 지침은 WCAG2ICT 태스크포스에서 작성한 후, 접근성 지침 실무 그룹(Accessibility Guidelines Working Group)의 검토 및 승인을 거쳤다.
역자주 원문은 “Applying…”으로 시작하는 제목을 말하지만 한국어 어순상 ”…적용 또는 …적용하기”로 마치는 제목으로 변경하였다.
제목에서 “성공 기준(Success Criterion)“이라는 용어는 간결하게 “SC”로 축약해 사용한다.
WCAG 2의 인용문은 <blockquote> 요소 안에 있으며, 왼쪽에 회색 막대가 있는 스타일로 시각적으로 표현되고, 원칙, 지침 또는 성공 기준의 제목 바로 다음에 나타난다.
이 문서에서 제공하는 추가 지침은 “적용하기(Applying)”라는 문구로 시작되며, 특별한 시각적 스타일은 적용되지 않는다.
이 문서의 조언에 따라 수정된 SC가 어떻게 표시되는지 보여주기 위해 제시된 대체 텍스트는 <ins> 요소 안에 있으며, 점선 밑줄이 있는 굵은 녹색 텍스트로 시각적으로 스타일이 지정된다.
참고 사항은 약간 들여쓰기되어 있으며, “참고(NOTE)”라는 문구로 시작된다. 각 참고 사항은 자체 들여쓰기 상자에 표시되며, 옅은 녹색으로 스타일이 지정되고 상자 왼쪽에는 더 어두운 녹색 선이 있다.
WCAG 2의 용어집 항목에 대한 참조는 <cite> 요소 안에 있으며, 점선 밑줄이 있는 일반 텍스트로 시각적으로 스타일이 지정되고, 이것이 WCAG 정의임을 나타내는 title 속성을 포함한다. 마우스 또는 키보드 초점을 받으면 파란색으로 바뀌고 노란색 배경이 표시된다.
이 문서의 용어집 항목에 대한 참조는 <cite> 요소 안에 있으며, 어두운 회색 밑줄이 있는 일반 텍스트로 시각적으로 스타일이 지정된다.
dragging movements, encloses, focus indicator, minimum bounding box, pointer input, process, single pointer, state, status message 는 모든 기술에 적용되는 용어 항목에 추가되었다.
WCAG2ICT는 웹 맥락과 웹이 아닌 맥락 간의 차이를 다루고, WCAG에는 없지만 웹이 아닌 맥락을 정의하는 데 중요한 몇 가지 주요 용어집 용어를 제공한다. “콘텐츠(Content)“와 “사용자 에이전트(user agent)“는 WCAG 2의 용어집 용어로서, 웹이 아닌 정보통신기술(ICT)에 적용할 때는 상당히 다르게 해석해야 한다.
WCAG 2의 용어집 용어 “웹 페이지(Web page)“는 정의된 용어인 “문서(document)” 및 “소프트웨어(software)“로 대체되었으며, “웹 페이지 세트(set of web pages)“과 “여러 웹 페이지(multiple web pages)“는 모두 정의된 용어인 “문서 세트(set of documents)“와 “소프트웨어 프로그램 세트(set of software programs)“로 대체되었다.
WCAG2ICT에서 도입한 용어는 “플랫폼 소프트웨어의 접근성 서비스(accessibility services of platform software)“인데, 이는 웹이 아닌 소프트웨어가 사용자 에이전트에 대한 WCAG의 개념을 활용하지 않기 때문이며, “폐쇄형 기능(closed functionality)“은 웹이 아닌 소프트웨어에만 적용된다.
WCAG 2의 나머지 용어집 용어들은 7장 WCAG 2 용어 정의에 대한 설명에서 다룬다. WCAG2ICT에서 정의되어 사용된 용어들은 본 문서의 지침 해석에만 적용된다. 이 특정 정의들은 WCAG2ICT의 범위를 벗어나는 상황에 적용 가능하다고 해석해서는 안 된다. 이러한 용어의 사용에 대한 추가 정보는 아래를 따른다.
WCAG2ICT에서 사용되는 소프트웨어 프로그램 세트라는 용어는 다음과 같은 의미를 가진다.
소프트웨어 프로그램 세트(WCAG2ICT에서 사용)
공통된 목적을 공유하며 동일한 작성자, 그룹 또는 조직에 의해 제작된 [소프트웨어 프로그램] 모음. [함께 배포되며 각각 독립적으로 실행 및 사용될 수 있지만, 세트 내 모든 프로그램이 서로 연결되어 있어 사용자가 일관된 방식으로 한 프로그램에서 다른 프로그램으로 이동할 수 있다].
예시
예: 소프트웨어 프로그램 세트의 한 예는 각각 독립적으로 실행하고 사용할 수 있지만 함께 배포되며, 모든 프로그램이 그룹 내의 다른 프로그램을 실행하거나 전환할 수 있는 메뉴를 가지고 있는 프로그램 그룹이다.
반례: 소프트웨어 프로그램 세트가 아닌 사례
다양한 유형의 문서(텍스트, 스프레드시트, 프레젠테이션 등)를 작성할 수 있는 프로그램 모음이지만, 해당 프로그램들이 명확하고 일관된 방식으로 서로 실행하거나 전환하는 방법을 제공하지 않는 경우.
쓰기, 스프레드시트 등의 여러 기능을 제공하는 단일 프로그램으로 실행되는 오피스 패키지이지만, 프로그램 간 이동 방법이 해당 프로그램에서 문서를 여는 것뿐인 경우.
함께 판매되는 소프트웨어 프로그램 번들이지만, 프로그램 간 이동하는 유일한 방법이 플랫폼 소프트웨어 수준의 메뉴를 사용하는 (것이고 이 번들의 다른 프로그램으로만 이동할 수 있는 메뉴를 각 프로그램이 제공하지 않는) 경우
한때 세트였던 프로그램 그룹이지만, 프로그램들이 별도의 위치로 이동되어 “세트” 동작이 중단되고 더 이상 작동하지 않는 경우. 한때 세트_였다 하더라도_ 더 이상 세트로 설치되어 있지 않기 때문에 소프트웨어 세트에 적용되는 성공 기준을 충족할 필요가 없다.
예시: 웹 브라우저, 미디어 플레이어, 플러그인 및 기타 프로그램 — 보조 기술 포함 — 웹 콘텐츠를 검색, 렌더링 및 상호 작용하는 데 도움이 되는 프로그램.
웹이 아닌 ICT의 경우, “사용자 에이전트”는 다른 관점에서 살펴볼 필요가 있다. WCAG 2에서 “사용자 에이전트”라는 용어는 웹 콘텐츠의 검색 및 표시에만 국한된다. 웹이 아닌 ICT의 경우, “사용자 에이전트”는 웹에 존재하지 않는 별도의 콘텐츠를 검색하고 표시하는 것을 지칭하며, WCAG2ICT에서는 이를 “문서”라고 한다. WCAG2ICT에서 “사용자 에이전트”는 다음과 같이 사용된다.
서론에서 언급된 바와 같이, WCAG 2는 브라우저, 미디어 플레이어 또는 보조 기술과 같은 “사용자 에이전트”를 통해 웹 콘텐츠에 접근하는 것을 전제로 한다. WCAG 2의 많은 성공 기준은 보조 기술을 연결하거나 설치할 수 있는 ICT 환경에서 웹 콘텐츠에 접근할 수 있다고 가정한다. 보조 기술은 이러한 환경에서 장애가 있는 사용자에게 접근 가능한 형태로 웹 콘텐츠를 제공하는 역할을 한다.
그러나 폐쇄형 기능을 가진 ICT는 일부 또는 모든 기능에서 보조 기술을 사용할 수 없도록 제한한다. 이러한 ICT는 종종 사용자 에이전트 또는 그와 동등한 기능도 제공하지 않는다. 따라서 ICT가 폐쇄적일수록, WCAG의 성공 기준을 따르는 것만으로는 웹이 아닌 소프트웨어의 접근성을 보장할 수 없다.
웹 콘텐츠와 달리 다양한 보조 기술이나 사용자 에이전트가 제공되지 않는 환경에서는, WCAG 2가 의도한 접근성을 실현하기 위해 다른 대안을 제공하거나 요구해야 한다. 추가적으로 필요한 조치를 결정하는 것은 WCAG2ICT 태스크 포스의 역할이 아니지만, 보조 기술에 의존하는 성공 기준을 식별하고, 이러한 기준이 폐쇄형 기능을 가진 ICT 환경에서 문제가 될 수 있음을 지적한다.
예시
예제: 폐쇄형 기능과 관련된 접근성 지침을 개발하는 과정에서, 태스크 포스는 역사적으로 보조 기술을 부분적으로 또는 완전히 차단해 온 ICT의 구체적인 사례를 검토하였다.
폐쇄형 기능을 가진 ICT의 하드웨어 및 소프트웨어 접근성 요구 사항을 명시한 기존 표준이 존재한다. 본 문서는 이러한 표준에 대한 의견을 제시하지 않지만, WCAG 성공 기준을 폐쇄형 기능을 가진 ICT의 하드웨어 측면에 적용해서는 안 된다는 점을 언급한다.
WCAG2ICT는 폐쇄형 기능을 가진 ICT의 소프트웨어에 WCAG 성공 기준을 적용할 때 고려해야 할 사항을 제공하며, 특정 성공 기준이 웹이 아닌 소프트웨어 환경에서 문제가 될 수 있는 이유를 설명한다. 폐쇄형 기능과 관련하여 문제가 될 수 있는 성공 기준 목록은 부록 A: 폐쇄형 기능에서 문제가 될 수 있는 성공 기준에서 확인할 수 있다.
텍스트 애플리케이션은 수십 년 전에 등장한 소프트웨어 ICT의 한 종류로, 그래픽 사용자 인터페이스(GUI: graphical user interface)와 웹이 등장하기 이전에 존재했다. 텍스트 애플리케이션의 인터페이스는 텍스트 문자만을 사용하여 생성되며, 하드웨어 터미널 또는 소프트웨어 터미널 애플리케이션이 텍스트 애플리케이션의 렌더링을 처리한다. 이는 웹 사용자 에이전트가 웹 애플리케이션의 렌더링을 처리하는 방식과 유사하다. 텍스트 애플리케이션은 텍스트 입력만을 허용하지만, 일부는 마우스나 기타 입력 장치의 사용도 지원할 수 있다.
최근에는 GUI에서 텍스트 애플리케이션을 렌더링하는 터미널 애플리케이션이 자동 음성 인식(ASR: Automated Speech Recognition)을 통해 음성 입력을 활용할 수 있게 되었다. GUI와 네이티브 텍스트 환경 인터페이스 모두 이제 일반적으로 단어 완성 예측 기술을 지원한다. 명령줄 애플리케이션(Command-line applications)은 텍스트 애플리케이션의 하위 집합으로, 추가적인 특정 속성을 가진다.
역사적으로, 보조 기술은 텍스트 애플리케이션의 발전과 함께 개발되면서, 텍스트 애플리케이션의 접근성을 보장하는 역할을 해왔다. 새로운 GUI 또는 웹 애플리케이션에 비해 새로 개발되는 텍스트 애플리케이션은 훨씬 적지만, 여전히 널리 사용되고 있다. 실제로, 명령줄 인터페이스(이하 CLI: command-line interfaces)는 최근 몇 년 동안 특히 인기 있는 프로그래밍 및 버전 관리 환경에서 다시 주목받고 있으며, 지속적인 개발을 통해 더 많은 기능을 제공하고 있다. 일부 경우에는 이러한 흐름이 텍스트 애플리케이션에 대한 보조 기술 지원의 새로운 발전을 촉진하기도 했다.
오늘날의 텍스트 애플리케이션의 보조 기술 지원은 계속 진화하고 있다. 주요 사례는 다음과 같다.
CLI에서는 맥락에 따라 달라지는 도움말 기능이 자주 제공된다. 예를 들어, 하나의 명령 인수 뒤에 표시되는 도움말과 두 개의 인수 뒤에 표시되는 도움말, 세 개의 인수 뒤에 제공되는 도움말이 서로 다를 수 있다. 이는 사용자의 효율성을 높이는 데 도움이 되며, 보조 기술에 대한 추가적인 요구 사항을 발생시키지 않는다.
출력 옵션은 기존의 강력하고 널리 사용되는 입출력 리디렉션 및 파이핑 기능 외에도 기계적 판독이 가능한 구조화된 텍스트 형식(JSON 같은)을 포함하는 경우가 많다. 이러한 환경에서는 보조 기술 사용자도 CLI 환경을 선호하는 다른 사용자들과 동일한 범위의 출력 옵션을 활용할 수 있다.
부록 B. 텍스트/명령줄/터미널 애플리케이션 및 인터페이스 배경에서 설명한 바와 같이, WCAG를 텍스트/명령줄 애플리케이션에 적용하려면 텍스트 애플리케이션이 렌더링되는 방식, 보조 기술을 통해 접근성을 보장하는 방법, 그리고 “접근성 지원” 및 “프로그램적으로 판별됨” 개념을 텍스트 애플리케이션에 적용하는 방식을 이해해야 한다.
WCAG2ICT는 표준이 아니므로, WCAG2ICT 자체에 대해 준수(conformance)할 수는 없다. 그러나 일부 기관에서는 WCAG 2를 기반으로 한 ICT 접근성 표준이나 규정을 마련하는 데 WCAG2ICT의 정보를 활용하고자 할 수 있다. 이러한 표준이나 규정은 자체적으로 준수 요건을 정의해야 하지만, WCAG 2를 웹이 아닌(non-web) 문서 및 소프트웨어에 적용하려는 경우 다음과 같은 점이 도움이 될 수 있다.
WCAG 2의 성공 기준과 준수 요건은 상호 연계되도록 설계되었다. 성공 기준의 문장은 준수 요건을 반영하여 작성되었으며, 특정 기준(A, AA, AAA)을 어떤 수준으로 분류할지에 대한 결정은 웹 도메인과 관련된 다양한 요인에 영향을 받는다. 이에 대한 자세한 내용은 WCAG 준수 수준 이해(Understanding Levels of Conformance)를 참고할 수 있다.
WCAG 2 준수 모델에서 특정 항목이 평가될 때, 해당 항목이 성공 기준을 위반하지 않으면 해당 기준을 충족한 것으로 간주된다. 만약 평가 대상에 존재하지 않는 요소와 관련된 성공 기준(예: 자막 제공 요구가 포함된 오디오 관련 기준)이 있다면, 이를 “적용되지 않음(not applicable)“으로 간주할 수도 있지만, WCAG 2에서는 자동으로 충족된 것으로 본다. 이러한 접근 방식은 WCAG 성공 기준의 구조와 서술 방식의 기본 원칙이다.
WCAG 2의 준수 여부는 평가 대상 전체(예: 웹 페이지)를 기준으로 한다. 다만, 특정 프로세스가 여러 개의 항목을 포함하는 경우, 해당 프로세스를 완료하는 데 필요한 모든 항목이 WCAG 2를 준수해야 한다.
WCAG 2에서는 플랫폼의 접근성 기능(예: 웹 콘텐츠용 브라우저)이나 보조 기술에 의존하는 경우, 해당 기술이 제품(웹 페이지)과 함께 정상 작동해야 한다고 요구한다. 즉, WCAG 2 준수를 위해서는 접근성 지원(accessibility-supported)되는 기술만을 사용하여 성공 기준을 충족해야 한다.
WCAG 2는 페이지의 일부 정보가 성공 기준을 준수하지 않더라도, 동등한 정보가 페이지 내에서 성공 기준을 준수하는 방식으로 제공된다면 이를 허용한다. 그러나 다음 네 가지 성공 기준은 사용자가 페이지의 다른 부분을 접근하고 활용하는 데 방해가 될 수 있기 때문에, 페이지의 모든 영역에서 반드시 준수해야 한다.
또한, 서론에서 언급한 바와 같이, 소프트웨어를 명확하게 독립적인 개별 단위로 나누는 것은 어렵다. 따라서 웹이 아닌 소프트웨어의 평가 단위는 전체 소프트웨어 프로그램이 된다. 이는 일반적인 소프트웨어 테스트와 마찬가지로 매우 큰 평가 단위를 의미할 수 있으며, 표준적인 소프트웨어 테스트 방법이 필요할 수도 있다.
이후 섹션은 WCAG 2의 원칙, 지침, 성공 기준에 따라 구성되어 있다. 각 성공 기준의 원문은 인용 형식으로 제공되며, 그 뒤에 WCAG2ICT 가이드가 제시된다. WCAG2ICT 가이드는 “적용(하기)“으로 끝나는 제목의 섹션에서 찾을 수 있다. 이 섹션은 이 문서에 특화된 내용임을 강조하기 위해 표시되었다. 이 섹션에서 WCAG2ICT가 추가한 사용자 지정 노트는 “추가됨” 텍스트로 표시된다.
사용자에게 제공되는 모든 텍스트 아닌 콘텐츠는 동등한 목적을 수행하는 대체 텍스트를 가져야 하며, 예외는 다음과 같다.
컨트롤, 입력(Controls, Input)
텍스트 아닌 콘텐츠가 컨트롤이거나 사용자 입력을 받는 경우, 해당 목적을 설명하는 이름이 있어야 한다. (컨트롤과 사용자 입력을 받는 콘텐츠에 대한 추가 요구 사항은 성공 기준 4.1.2 참고)
시간 기반 미디어(Time-Based Media)
텍스트 아닌 콘텐츠가 시간 기반 미디어인 경우, 텍스트 아닌 콘텐츠에는 최소한 동등한 설명의 대체 텍스트를 제공해야 한다. (미디어에 대한 추가 요구사항은 지침 1.2를 참고)
시험(Test)
텍스트 아닌 콘텐츠가 시험이나 연습 문제로, 텍스트로 제시될 때 무효화 되는 경우, 최소한 해당 콘텐츠를 설명하는 대체 텍스트를 제공해야 한다.
감각(Sensory)
텍스트 아닌 콘텐츠가 특정 감각에 기반한 경험을 제공하는 것이 주 목적일 경우, 최소한 해당 콘텐츠를 설명하는 대체 텍스트를 제공해야 한다.
[캡챠(CAPTCHA)](../glossary/captcha ""Completely Automated Public Turing test to tell Computers and Humans Apart”에 대한 두문자어”)
텍스트 아닌 콘텐츠의 목적이 컴퓨터가 아닌 사람이 콘텐츠에 접근하고 있는지 확인하는 것이라면, 해당 콘텐츠의 목적을 설명하는 대체 텍스트를 제공해야 한다. 또한, 다양한 감각 인식을 지원하는 출력 모드(output modes)를 사용하는 대체 CAPTCHA를 제공하여 다른 유형의 감각적 접근 방식을 필요로 하는 사용자도 이용할 수 있도록 해야 한다.
장식(Decoration), 형식(Formatting), 보이지 않음(Invisible)
텍스트 아닌 콘텐츠가 순수한 장식 요소, 시각적 형식 요소, 또는 사용자에게 표시되지 않는 콘텐츠인 경우, 보조 기술이 이를 무시할 수 있도록 구현해야 한다.
이는 원문 그대로 적용하되, 성공 기준 1.4.2 이해의 의도에 설명한 것 중 “웹 페이지에서”를 “웹이 아닌 문서나 소프트웨어에서”로, “어떤 콘텐츠”를 “웹이 아닌 문서나 소프트웨어의 일부”로, “전체 페이지”를 “전체 문서나 소프트웨어”로,“웹 페이지에 있는”을 “문서나 소프트웨어에 있는”으로 대체한다. 또한, “준수 요구사항 5: 불간섭”을 삭제한다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
1.4.2 오디오 제어: [웹이 아닌 문서나 소프트웨어]에서 오디오가 자동으로 3초 이상 재생되는 경우, 사용자가 오디오를 일시 정지하거나 중지할 수 있는 매커니즘을 제공하거나, 전체 시스템 볼륨과는 별도로 오디오 볼륨을 조절할 수 있는 매커니즘을 제공해야 한다.
키보드 인터페이스를 사용하여 키보드 초점을 페이지의 구성요소로 이동할 수 있는 경우, 키보드 인터페이스만으로도 해당 구성요소에서 초점을 이동시킬 수 있어야 한다. 수정되지 않은 화살표, 탭 키, 또는 다른 표준 종료 방법이 필요한 경우, 사용자에게 초점을 이동시키는 방법에 대해 안내해야 한다.
참고
이 성공기준을 충족하지 못하는 콘텐츠는 모든 페이지를 사용하는 사용자들의 능력을 방해할 수 있다. 웹 페이지의 모든 콘텐츠는 다른 성공기준의 충족 여부와 관계없이 반드시 이 성공기준을 준수해야 한다. 준수 요구사항 5: 불간섭을 참고하라.
이는 원문 그대로 쓰이며, 성공 기준 2.1.2 이해의 의도에서 설명한 것 중 “페이지”는 “웹이 아닌 문서 또는 소프트웨어”로, “웹 페이지에서”는 “웹이 아닌 문서 또는 소프트웨어에서”로 대체되고, “준수 요구사항 5: 불간섭을 참고하라.”는 삭제된다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
2.1.2 키보드 함정 방지: 키보드 인터페이스를 사용하여 [웹이 아닌 문서나 소프트웨어]의 구성 요소로 초점을 이동할 수 있는 경우, 동일한 키보드 인터페이스만으로 초점을 해당 구성 요소에서 벗어나게 이동할 수 있어야 한다. 만약 수정되지 않은 방향키나 Tab 키 또는 기타 표준 종료 방법 이상의 조작이 필요하다면, 사용자는 초점을 이동하는 방법에 대한 안내를 받아야 한다.
이 성공기준을 준수하지 못하는 콘텐츠는 사용자가 전체 페이지를 사용하는 것을 방해할 수 있으므로, 웹 페이지의 모든 콘텐츠는 (다른 성공기준의 준수 여부와 상관없이) 이 성공기준을 준수해야 한다. 준수 요구사항 5: 불간섭을 참고하라.
참고 3
소프트웨어에 의해 정기적으로 업데이트되거나 사용자 에이전트로 스트리밍되는 콘텐츠의 경우, 일시정지의 시작 시점부터 재시작 시점 사이에 생성되거나 수신되는 정보를 보존 또는 제시하는 것이 기술적으로 가능하지 않을 수 있으며, 많은 경우 사용자가 오도할 수 있으므로 요구사항이 아니다.
참고 4
프리로드 단계나 유사한 상황에서 발생하는 애니메이션은 그 단계에서 모든 사용자가 상호작용할 수 없고, 진행 상황을 표시하지 않으면 사용자들이 혼란을 겪거나 콘텐츠가 고정되었거나 깨졌다고 생각할 수 있는 경우에는 필수적인 것으로 간주될 수 있다.
이는 원문 그대로 사용되며, 성공 기준 2.3.1 이해의 의도에서 설명한 것 중 “웹 페이지들(Web pages)“과 “특정 웹 페이지(the Web page)“를 “웹이 아닌 문서 또는 소프트웨어”로, “전체 페이지”를 “웹이 아닌 전체 문서 또는 소프트웨어”로 대체하고, “준수 요구사항 5: 불간섭을 참고하라.”는 삭제하여 적용한다.
이는 원문 그대로 쓰이며, 성공 기준 2.4.1 이해의 의도에서 설명한 것 중 “웹 페이지”를 “웹이 아닌 문서 세트 내의 웹이 아닌 문서”나 “소프트웨어 프로그램 세트 내의 소프트웨어 프로그램”으로 대체하여, 여러 개의 문서(또는 소프트웨어 프로그램)가 단순히 임의의 두 문서나 소프트웨어가 아닌, 하나의 세트에 속하는 것임을 명확히 한다.
이는 원문 그대로 쓰되 성공 기준 2.5.1 이해의 의도에서 설명한 것 중 웹이 아닌 문서에 대해서는 “웹 콘텐츠”를 “콘텐츠”로, 웹이 아닌 소프트웨어 애플리케이션에 대해서는 “웹 콘텐츠를 해석하는”을 “소프트웨어 애플리케이션을 해석하는”으로, “사용자 에이전트”를 “기반 플랫폼 소프트웨어”로 변경하여 수정한다.
이는 원문 그대로 쓰이며, 성공 기준 2.5.2 이해의 의도에서 설명한 것 중 웹이 아닌 문서에 대한 주석에서는 “웹 콘텐츠”를 “콘텐츠”로, 웹이 아닌 소프트웨어 애플리케이션에 대한 주석에서는 “웹 콘텐츠를 해석하는”을 “소프트웨어 애플리케이션을 해석하는”으로, “사용자 에이전트”를 “기반 플랫폼 소프트웨어”로 대체한다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
(웹이 아닌 문서의 경우)
(웹이 아닌 소프트웨어의 경우)
예시(추가됨)
웹이 아닌 소프트웨어의 필수 기능 예시는 친환경 에너지 사용 요구 사항을 충족하기 위한 기능(예: 장치를 잠자기에서 깨우기, 절전 모드 및 저전력 모드 등)이다.
이는 원문 그대로 쓰이며, 성공 기준 2.5.7 이해의 의도에서 설명한 것 중 “사용자 에이전트”를 “사용자 에이전트 또는 플랫폼 소프트웨어”로, 웹이 아닌 문서에 대한 주석에서는 “웹 콘텐츠”를 “콘텐츠”로, 웹이 아닌 소프트웨어 애플리케이션에 대해서는 “웹 콘텐츠를 해석하는”을 “소프트웨어 애플리케이션을 해석하는”으로, “사용자 에이전트”를 “기반 플랫폼 소프트웨어”로 대체한다.
웹 페이지에 다음 도움말 매커니즘 중 하나가 포함되어 있고, 해당 매커니즘이 웹 페이지 세트 내의 여러 웹 페이지에서 반복되는 경우, 사용자가 변경을 시작하지 않는 한 다른 페이지 콘텐츠와 상대적으로 동일한 순서로 제공되어야 한다.
사람의 연락처 정보
사람의 연락 방법
자가 도움말 옵션
완전 자동화된 연락 방법
참고 1
도움말 메커니즘은 페이지에서 직접 제공되거나 정보가 포함된 다른 페이지에 대한 직접 링크를 통해 제공될 수 있다.
참고 2
이 성공 기준의 경우 “다른 페이지 콘텐츠와 상대적으로 동일한 순서”는 페이지가 직렬화될 때 콘텐츠가 정렬되는 방식으로 생각할 수 있다. 도움말 메커니즘의 시각적 위치는 동일한 페이지 변형(예: CSS 중단점)에 대해 페이지 전체에서 일관될 가능성이 높다. 사용자는 페이지의 확대/축소나 방향 변경과 같은 변경 작업을 시작할 수 있으며, 이로 인해 다른 페이지 변형이 발생할 수 있다. 이 기준은 동일한 페이지 변형(예: 동일한 확대/축소 수준 및 방향)에 표시되는 페이지 간의 상대적 순서와 관련이 있다.
이는 원문 그대로 쓰이며, 성공 기준 3.2.6 이해의 의도에서 설명한 대로 “웹 페이지”와 “페이지”를 “웹이 아닌 문서 또는 소프트웨어 프로그램”으로, “웹 페이지 세트”를 “웹이 아닌 문서 세트 또는 소프트웨어 프로그램 세트”로, “페이지 콘텐츠”를 “콘텐츠”로, “페이지에서”를 “웹이 아닌 문서나 소프트웨어에서”로, “페이지가 직렬화(serialized)될 때”를 “웹이 아닌 문서나 소프트웨어 콘텐츠가 직렬화될 때”로, “다른 페이지”를 “다른 웹이 아닌 문서, 소프트웨어 또는 웹 페이지”로, “페이지 변형”을 “콘텐츠 레이아웃 변형”으로 대체하여 그대로 적용된다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
3.2.6 일관된 도움말: [웹이 아닌 문서나 소프트웨어]가 다음의 도움말 메커니즘을 포함하고, 그 메커니즘들이 [웹이 아닌 문서 세트나 소프트웨어 프로그램 세트] 내의 [웹이 아닌 여러 문서 또는 소프트웨어]에서 반복된다면, 사용자가 변경을 시작하지 않는 한 다른 [콘텐츠]에 대해 동일한 순서로 제공되어야 한다.
이는 원문 그대로 쓰이며, 성공 기준 3.3.4 이해의 의도에 설명한 내용에 따라 “웹 페이지”를 “웹이 아닌 문서 또는 소프트웨어”로 치환하여 적용한다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
3.3.4 오류 예방 (법률, 금융, 데이터): 사용자에게 법적 구속력 또는 금융 거래를 발생시키거나, 데이터 저장 시스템 내에서 사용자가 제어 가능한 데이터를 수정 또는 삭제하거나, 사용자 테스트 응답을 제출하게 하는 [웹이 아닌 문서나 소프트웨어]의 경우, 다음 중 적어도 하나가 참이어야 한다.
되돌릴 수 있는
제출 내역을 되돌릴 수 있어야 한다.
점검된
사용자가 입력한 데이터는 입력 오류를 점검하고 사용자에게 오류를 수정할 수 있는 기회를 제공해야 한다.
마크업 언어를 사용하여 구현된 콘텐츠에서, 요소는 완전한 시작 태그와 종료 태그를 가지며, 요소의 중첩은 해당 명세를 준수하고, 중복된 속성을 포함하지 않으며, 모든 ID는 고유해야 한다. 단, 해당 명세에서 이러한 특성을 허용하는 경우는 예외로 한다.
참고 1
이 성공 기준은 HTML이나 XML을 사용하는 모든 콘텐츠에 대해 항상 충족된 것으로 간주된다.
참고 2
이 기준이 작성된 이후, HTML Living Standard는 불완전한 태그, 올바르지 않은 요소 중첩, 중복 속성, 비고유 ID를 사용자 에이전트가 처리하는 방식을 규정하는 구체적인 요구사항을 채택하였다. [HTML]
HTML 표준에서는 일부 사례를 저작자에게 미준수(non-conforming)로 간주하지만, 해당 명세가 사용자 에이전트가 이러한 사례를 일관되게 처리하도록 요구하고 있으므로, 이 성공 기준의 목적상 “이러한 특성을 허용한다”고 간주된다. 실제로 이 기준 자체가 장애인을 위한 추가적인 이점을 제공하지는 않는다.
부적절한 요소 중첩으로 인한 역할(role) 누락, 중복된 ID로 인한 잘못된 상태(state)나 이름(name)과 같은 문제는 별도의 성공 기준에서 다루므로, 이러한 문제는 4.1.1의 문제로 보고하기보다는 해당 기준에 따라 보고해야 한다.
4.1.1 파싱 (WCAG 2.0 and 2.1) 성공 기준을 웹이 아닌 문서 및 소프트웨어에 적용
이는 원문 그대로 쓰이며, 성공 기준 4.1.1 이해의 의도에서 설명한 바와 같이, “마크업 언어를 사용하여 구현된 콘텐츠”를 “보조 기술 및 소프트웨어의 접근성 기능 또는 사용자가 선택 가능한 사용자 에이전트에 마크업이 별도로 노출되고 접근 가능한 방식으로 마크업 언어를 사용하는 웹이 아닌 문서 또는 소프트웨어”로 대체하고, WCAG의 주석을 웹이 아닌 문서 및 소프트웨어에 적절한 주석으로 바꾸어 그대로 적용할 수 있다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
4.1.1 파싱: [보조 기술 및 소프트웨어의 접근성 기능 또는 사용자가 선택 가능한 사용자 에이전트에 마크업이 별도로 노출되고 접근 가능한 방식으로 마크업 언어를 사용하는 웹이 아닌 문서나 소프트웨어의 경우], 요소에는 완전한 시작 및 종료 태그가 있어야 하며, 요소는 명세에 따라 중첩되어야 하고, 중복 속성을 포함하지 않아야 하며, 모든 ID는 고유해야 한다. 단, 명세에서 이러한 예외를 허용하는 경우는 제외한다.
이 기준은 원래 보조 기술이 HTML을 직접 파싱(Parsing)하는 문제를 해결하기 위해 채택되었다. 보조 기술은 더 이상 HTML을 직접 파싱할 필요가 없다. 결과적으로 이러한 문제는 더 이상 존재하지 않거나 다른 기준으로 해결된다. 이 기준은 더 이상 유용성이 없으므로 제거되었다.
4.1.1 파싱(무효화 및 삭제) (WCAG 2.2) 성공 기준을 웹이 아닌 문서 및 소프트웨어에 적용
모든 사용자 인터페이스 구성요소(서식 요소, 링크, 스크립트에 의해 생성된 요소를 포함하되, 이에 국한되지 않음)의 경우, 이름과 역할은 프로그래밍 방식으로 판별되어야 한다. 사용자에 의해서 설정될 수 있는 상태(states), 속성(properties) 및 값(values)은 프로그래밍 방식으로 설정될 수 있어야 한다. 이러한 항목의 변경사항은, 보조 기술을 포함하여, 사용자 에이전트에 제공되어야 한다.
참고
이 성공기준은 주로 사용자 인터페이스 구성요소를 개발하거나 스크립팅하는 웹 개발자를 위한 것이다. 예를 들어, 표준 HTML 컨트롤은 명세서에 따라 사용되었을 때, 이미 이 성공기준을 준수한 것이다.
이는 성공 기준 4.1.2 이해의 의도에서 설명한 바와 같이 원문 그대로 적용되며, 기존 참고 문구를 다음과 같이 대체한다. “이 성공 기준은 주로 사용자 정의 인터페이스 구성요소를 개발하거나 사용하는 소프트웨어 개발자를 위한 것이다. 예를 들어, 대부분의 접근성 지원 플랫폼에서 제공하는 표준 사용자 인터페이스 구성요소는 사양에 따라 사용하면 이미 이 성공 기준을 충족한다.”
다음 섹션은 WCAG 2의 용어집 순서에 따라 구성되어 있다. 각 항목에는 WCAG 2의 용어 정의가 인용문 형태로 포함되어 있으며, 그 뒤에 WCAG2ICT의 해석이 제시된다. WCAG2ICT의 해석은 “적용(하기)“으로 마치는 제목 아래에 있으며, 이 문서에 고유한 내용을 나타낸다. 해당 섹션 내에서 WCAG2ICT에서 새롭게 추가한 주석은 “추가됨”으로 표시된다.
아래는 WCAG 2 용어집의 정의 전체 목록이다. 일부 항목은 모든 기술에 적용되며 본 문서에서 별도의 해석이 필요하지 않다. 나머지 항목에 대해서는 본 문서에서 추가적인 해석을 제공한다.
사용자의 보조 기술뿐만 아니라 브라우저와 다른 사용자 에이전트에 있는 접근성 특성들에 의해 지원된
웹 콘텐츠 기술(또는 어떤 기술의 특성)이 접근성이 지원하는 것으로 인정을 받으려면, 해당 웹 콘텐츠 기술(또는 특성)은 다음의 1과 2를 모두 충족해야 한다.
웹 콘텐츠 기술이 사용되는 방법은 사용자의 보조 기술(AT)에 의해 지원되어야 한다. 이는 기술이 사용되는 방법이 콘텐츠의 인간 언어에서 사용자의 보조 기술과의 상호운용성이 테스트되었음을 의미한다.
그리고
웹 콘텐츠 기술은 사용자가 사용할 수 있는, 접근성을 지원하는 사용자 에이전트를 가지고 있어야 한다. 이는 다음 4개의 항목 중 최소 하나를 준수해야 함을 의미한다.
해당 기술은 접근성이 지원되면서 널리 사용되는 사용자 에이전트에서 기본적으로 지원(예: HTML과 CSS)한다.
또는
해당 기술은 접근성이 지원되면서 널리 사용되는 플러그인에서도 지원한다.
또는
콘텐츠는 대학교 또는 기업 네트워크와 같은 폐쇄된 환경에서 사용할 수 있는데, 이때 폐쇄된 환경이란 해당 기술이 요구하고 조직이 사용하는 사용자 에이전트 또한 접근성이 지원되는 곳이다.
또는
해당 기술을 지원하는 사용자 에이전트는 접근성이 지원되고, 다음과 같은 방법으로 다운로드 또는 구입할 수 있다.
장애인이 비장애인보다 더 많은 비용을 지불하지 않는다. 그리고
비장애인처럼, 장애인도 쉽게 찾고 다운로드/구매할 수 있다.
참고 1
WCAG 실무그룹과 W3C는 웹 기술을 접근성이 지원되는 것으로 분류하기 위해 보조 기술에 의해 지원되는 어떤 특정 웹 기술을 사용해야 하는지 또는 얼마나 많이 지원되어야 하는지를 명시하지 않는다. (“접근성 지원”에 필요한 보조 기술의 수준을 참고하라.)
참고 2
웹 기술이 의존하지 않고, 그리고 전체 페이지가 준수 요구사항 4와 준수 요구사항 5를 포함한 준수 기준을 충족하는 한 접근성이 지원되지 않는 방식으로 사용될 수 있다.
참고 3
웹 기술이 의존하지 않고, 그리고 전체 페이지가 준수 요구사항 4와 준수 요구사항 5를 포함한 준수 기준을 충족하는 한 접근성이 지원되지 않는 방식으로 사용될 수 있다.
참고 4
여러 버전이 있는 웹 콘텐츠 기술을 인용할 경우, 지원되는 버전을 구체적으로 명시해야 한다.
참고 5
개발자가 접근성이 지원되는 기술의 사용을 찾는 한, 가지 방법은 접근성이 지원되는 것으로 문서화된 사용 책자를 참고하는 것이다. (접근성이 지원되는 웹 기술 활용 이해를 참고하라.) 웹 콘텐츠 저작자, 회사, 기술공급업체 또는 기타 업체가 웹 콘텐츠 기술을 사용하는 접근성이 지원되는 방법을 문서화할 수 있다. 그러나 문서에서 기술을 사용하는 모든 방법은 위의 접근성이 지원되는 웹 콘텐츠 기술의 정의를 충족해야 한다.
이 내용은 원문 그대로 적용되며, WCAG 2 용어집에서 설명된 대로, “브라우저 및 기타 사용자 에이전트”를 “사용자 에이전트 또는 기타 소프트웨어”로, “사용자 에이전트”를 “사용자 에이전트 또는 기타 소프트웨어”로, “웹 콘텐츠 기술”을 “웹이 아닌 문서 또는 소프트웨어 기술”로 대체하고, “플러그인” 뒤에 “또는 기타 소프트웨어 확장”을 추가하며, 다섯 개의 노트 대신 하나의 노트를 추가합니다: “노트: 다섯 개의 노트와 ‘접근성 지원됨’에 대한 이해에서 다룬 개념은 웹 기술에 적용된다. 동일하거나 유사한 요소들이 웹이 아닌 기술에도 적용된다.”
링크와 함께 사용자에게 동시에 제시되는 웹 페이지의 모든 정보에서 링크의 목적을 파악할 수 없는 경우(즉, 장애가 없는 독자도 링크를 활성화하기 전까지는 링크가 무엇을 할지 모르는 경우)
예제
예시: “주목할 만한 수출품 중 하나는 구아바이다”라는 문장에서 “구아바”라는 단어가 링크이다. 이 링크는 구아바의 정의나, 구아바 수출량을 보여주는 도표, 또는 구아바를 수확하는 사람들의 사진으로 연결될 수 있다. 링크가 활성화되기 전까지는 모든 독자가 불확실하며, 장애가 있는 사람이 특별히 불리한 상황에 있지 않다.
이 정의는 WCAG 2 용어집에서 “웹 페이지”를 “웹이 아닌 문서나 소프트웨어”로 대체하여 적용된다.
이러한 대체 용어를 적용하여 다음과 같이 서술한다.
일반적으로 사용자에게 애매한
링크와 함께 사용자에게 동시에 제시되는 [웹이 아닌 문서나 소프트웨어]의 모든 정보에서 링크의 목적을 파악할 수 없는 경우(즉, 장애가 없는 독자도 링크를 활성화하기 전까지는 링크가 무엇을 할지 모르는 경우)
예시: “주목할 만한 수출품 중 하나는 구아바이다”라는 문장에서 “구아바”라는 단어가 링크이다. 이 링크는 구아바의 정의나, 구아바 수출량을 보여주는 도표, 또는 구아바를 수확하는 사람들의 사진으로 연결될 수 있다. 링크가 활성화되기 전까지는 모든 독자가 불확실하며, 장애가 있는 사람이 특별히 불리한 상황에 있지 않다.
사용자 에이전트 역할을 하거나 주류 사용자 에이전트와 함께 작동하며, 주류 사용자 에이전트가 제공하는 것 이상의, 장애가 있는 사용자의 요구사항을 충족하는 기능을 제공하는 하드웨어나 소프트웨어
참고 1
보조 기술이 제공하는 기능에는 대체 표현(예: 합성 음성이나 확대된 콘텐츠), 대체 입력 방법(예: 음성), 추가적인 탐색이나 방향 찾기 기능, 콘텐츠 변환(예: 표를 더 접근성 있게 만들기) 등이 포함된다.
참고 2
보조 기술은 API를 사용하고 모니터링하여 주류 사용자 에이전트와 데이터 및 메시지를 주고받는 경우가 많다.
참고 3
주류 사용자 에이전트와 보조 기술의 구분이 절대적인 것은 아니다. 많은 주류 사용자 에이전트가 장애가 있는 개인을 지원하는 일부 기능을 제공한다. 기본적인 차이는 주류 사용자 에이전트가 일반적으로 장애가 있는 사람과 없는 사람을 모두 포함하는 광범위하고 다양한 사용자를 대상으로 한다는 점이다. 보조 기술은 특정 장애가 있는 사용자의 좁게 정의된 집단을 대상으로 한다. 보조 기술이 제공하는 지원은 대상 사용자의 요구에 더 구체적이고 적절하다. 주류 사용자 에이전트는 프로그램 객체에서 웹 콘텐츠를 검색하거나 마크업을 식별 가능한 번들로 구문 분석하는 것과 같이 보조 기술에 중요한 기능을 제공할 수 있다.
예제
예제: 이 문서의 맥락에서 중요하게 여겨지는 보조 기술은 다음과 같은 것을 포함한다.
시각장애, 지각장애, 인쇄물 판독 장애를 지닌 사용자가 렌더링된 텍스트 및 이미지의 시각적 가독성을 개선하기 위해 텍스트 글꼴, 크기, 간격, 색상, 음성 동기화 등을 변경하기 위하여 사용하는 화면 확대기와 기타 시각적 읽기 보조장치
시각장애인이 합성된 음성 또는 점자를 통해 텍스트 정보를 읽기 위해 사용하는 화면낭독기
인지장애, 언어장애, 학습장애를 지닌 사용자가 텍스트를 합성 음성으로 변환하기 위하여 사용하는 문자를 음성으로 변환해 주는(TTS) 소프트웨어
특정 신체장애를 지닌 사용자가 사용할 수 있는 음성 인식 소프트웨어
특정 신체장애를 지닌 사용자가 키보드를 시뮬레이션하기 위하여 사용하는 대체 키보드(헤드 포인터, 단일 스위치, 들여마시기/불기(sip/puff) 입력 보조 장치 및 기타 특수 입력 장치를 사용하는 대체 키보드 포함)
특정 신체장애를 지닌 사용자가 마우스 포인팅 및 버튼 작동을 시뮬레이션하기 위하여 사용하는 대체 포인팅 장치
명도대비율은 1에서 21까지(일반적으로 1:1에서 21:1로 기술함)의 범위에 있을 수 있다.
참고 2
저작자는 텍스트 렌더링 방법[예: 글꼴 다듬기(smoothing) 또는 안티앨리어싱(anti-aliasing)]에 대한 사용자 설정을 제어할 수 없기 때문에, 텍스트의 명도대비율은 안티앨리어싱이 꺼진 상태에서 평가할 수 있다.
참고 3
성공기준 1.4.3 명도대비(최소)와 1.4.6 명도대비(향상된)의 목적을 달성하기 위하여, 명도대비는 텍스트가 정상적으로 사용될 때 렌더링되는 특정 배경과 관련하여 측정된다. 어떠한 배경색도 지정되지 않은 경우, 흰색으로 가정한다.
참고 4
배경색은 텍스트가 정상적으로 사용될 때 렌더링되는 특정 콘텐츠의 색상이다. 사용자의 기본 배경색을 알 수 없고 충분한 명도대비를 평가할 수 없기 때문에, 텍스트 색상을 지정할 때 어떠한 배경색도 지정되지 않은 경우, 준수하지 못한 것이다. 동일한 이유로, 배경색을 지정할 때 어떠한 텍스트 색상도 지정하지 않은 경우도 준수하지 못한 것이다.
참고 5
문자 주위에 테두리가 있으면, 테두리는 명도대비를 추가할 수 있으며, 문자와 배경 간의 명도대비를 계산하는 데 사용된다. 문자 주위의 좁은 테두리는 문자로 사용될 것이다. 문자의 안쪽 세부사항을 채우는 문자 주위의 넓은 테두리는 후광 역할을 하며, 배경으로 간주된다.
참고 6
저작자가 일반적인 표현(presentation)에 인접하여 나타날 것으로 예상되는 콘텐츠에 지정된 색상 쌍을 대상으로 WCAG 준수 여부를 평가해야 한다. 저작자의 코드에 인해 발생하는 상황을 제외하고, 사용자 에이전트에 의해 발생한 색상 변경과 같은 특이한 표현을 고려할 필요가 없다.
CSS 픽셀은 CSS의 모든 길이와 측정을 위한 표준 측정 단위이다. 이 단위는 밀도와 무관하며, 디스플레이에서 제시되는 실제 하드웨어 픽셀과는 구별된다. 사용자 에이전트와 운영체제는 CSS 픽셀이 디스플레이의 물리적 치수 및 예상 시청거리(콘텐츠 개발자가 결정할 수 없는 요소)를 고려한 CSS 값 및 단위 모듈 레벨 3 준거 픽셀 [css3 값(css3-values)]에 최대한 가깝게 설정되었는지 확인해야 한다.
번쩍임 또는 연속된 이미지의 빠른 변화가 다음 중 하나에 해당되는 경우 임계값 이하(즉, 콘텐츠 통과)이다.
1초 이내에 3회 이하의 일반 번쩍임과 적색 번쩍임이 있다.
동시에 발생하는 번쩍임의 결합 영역이 일반적인 시야 거리의 화면에서 10도 시야 범위 내에서 총 0.006의 스테라디안(10도 시야 범위 내 화면의 25%)보다 적게 차지한다.
여기서:
일반 번쩍임은 더 어두운 이미지의 상대 휘도가 0.80 이하일 때 최대 상대 휘도(1.0) 기준으로 10% 이상의 변화가 있는 한 쌍이 상반되게 전환하는 상태로 정의한다. “한 쌍이 서로 상반되게 전환하는 상태”는 휘도가 증가했다가 감소하거나 감소했다가 증가하는 경우를 말한다.
적색 번쩍임은 강렬한 적색을 포함해 상반되는 전환의 쌍으로 정의한다.
예외: 백색잡음(white noise)이나 측면에 0.1도(일반적인 시야 거리의 가시범위)보다 더 작은 “사각형” 모양으로 교차하는 바둑판 패턴과 같은 미세하고 균형 잡힌 패턴으로 번쩍이는 경우는 임계값을 위반한 것이 아니다.
[역자주] 백색잡음(white noise)은 송출 중이 아닌 TV 화면 전체에 작은 불규칙적인 점들이 고르게 분포된 모습처럼 모든 색상의 빛이 고르게 혼합된 무작위 패턴을 말하기도 한다.
참고 1
일반 소프트웨어 또는 웹 콘텐츠의 경우, 콘텐츠를 1024×768픽셀에서 볼 때 디스플레이된 화면 영역의 어느 곳에서나 341×256픽셀의 직사각형을 사용하면 표준 화면크기와 시청거리(예: 22-26인치 거리에 있는 15-17인치 크기의 화면)에 대해 10도의 시야각을 예측할 수 있다. (동일한 콘텐츠 렌더링을 보여주는 고해상도 디스플레이는 더 작고 안전한 이미지를 산출하므로 임계값을 정의하는 데 사용되는 해상도가 더 낮다.)
참고 2
전환(transition)이란 시간 대비 상대 휘도(또는 적색 번쩍임에 대한 상대 휘도/색상) 측정 도표에서 인접한 최대값과 최소값 간의 상대 휘도(또는 적색 번쩍임에 대한 상대 휘도/색상)의 변화를 말한다. 번쩍임은 두 개의 상반되는 전환으로 구성된다.
참고 3
**“강렬한 적색이 포함된 상반되는 전환의 쌍”**에 대한 (WCAG 2.2에서) 새로운 정의는 다음과 같다. 한 쪽의 R/(R + G + B) 값이 0.8이상이고 CIE 1976 UCS 색도도(chromaticity diagram)에서 반대 쪽과의 차이가 0.2(단위 없음)보다 큰 한 쌍의 전환이다. [ISO_9241-391]
참고 4
비디오 화면 캡처에서 분석을 수행할 수 있는 도구가 있다. 그러나 깜빡임이 1초에 3회 이하인 경우, 이 상태를 평가하기 위해서는 어떠한 도구도 필요하지 않다. 콘텐츠는 자동으로 통과된다(위의 1번과 2번 참고).
키보드 인터페이스는 기본 기술이 키보드를 포함하지 않더라도 사용자가 프로그램에 키 입력 정보를 제공할 수 있도록 해준다.
예제
예제: 터치스크린 PDA에는 외부 키보드 연결부와 운영체제에 내장된 키보드 인터페이스가 있다. PDA의 애플리케이션은 외부 키보드나 “키보드 에뮬레이션” 기능이 있는 손글씨 변환기 또는 음성-문자 변환 애플리케이션과 같이 시뮬레이션된 키보드 출력을 제공하는 다른 애플리케이션으로부터 키보드 입력을 받을 수 있다.
참고 2
마우스키(MouseKeys)와 같은 키보드 작동 마우스 에뮬레이터를 통한 애플리케이션(또는 애플리케이션의 일부)의 조작은 프로그램의 조작이 키보드 인터페이스가 아닌 포인팅 장치를 통해 이루어지기 때문에 키보드 인터페이스를 통한 조작으로 보지 않는다.
최소 18포인트 또는 14포인트의 볼드체(bold), 또는 한국어, 중국어, 일본어(CJK) 글꼴에서 이에 상응하는 크기의 글꼴
참고 1
획이 매우 가늘거나 문자 형태의 친숙성을 감소시키는 특이한 특징과 특성이 있는 글꼴은 특히 명도대비율이 낮을 경우 읽기 더 어렵다.
참고 2
글자 크기는 콘텐츠를 전달할 때의 크기이다. 그것은 사용자가 행할 수 있는 크기 조정은 포함하지 않는다.
참고 3
사용자가 보는 문자의 실제 크기는 개발자 정의 크기와 사용자의 디스플레이 또는 사용자 에이전트 설정에 따라 달라진다. 대부분의 주류 본문 텍스트의 경우, 14와 18pt는 대략 1.2em과 1.5em 또는 본문 텍스트의 기본 크기의 120% 또는 150%(본문 글자 크기를 100%로 가정했을 때)와 동일하지만, 저작자는 사용 중인 특정 글꼴에 대해서도 확인해야 한다. 글자 크기가 상대 단위로 정의된 경우, 실제 포인트 크기는 디스플레이용 사용자 에이전트에 의해 계산된다. 이 성공 기준을 평가할 때 포인트 크기는 사용자 에이전트에서 얻거나 사용자 에이전트처럼 글꼴 메트릭(font metrics)을 기반으로 계산해야 한다. 저시력 사용자는 적절한 설정을 선택할 책임이 있다.
[역자주] 글꼴 메트릭(font metrics)이란 글자 크기, 자간, 줄 높이, 기준선, 알파벳 등에서 위아래로 처리되는 높이 등을 포함한 글꼴의 구조적 정보이다. 따라서 14pt로 지정되어도 글꼴의 특성에 따라 사용자에게는 충분히 크게 보이지 않을 수 있다.
참고 4
글자 크기를 지정하지 않고 텍스트를 사용할 때, 주요 브라우저에서 지정되지 않은 텍스트로 사용되는 가장 작은 글자 크기를 적용하는 것이 적절한 크기일 것이다. 만약 주요 브라우저에서 제목 1 수준(level 1 heading)이 14pt 이상 볼드체로 랜더링다면, 이 제목은 큰 텍스트라고 볼 수 있다. 상대적 크기는 기본 크기에서 비슷한 방식으로 계산할 수 있다.
참고 5
로마자 텍스트의 18pt와 14pt 크기는 대형 인쇄물(14pt)과 대형 표준 글꼴 크기(18pt)의 최소 크기로부터 도출되었다. 한국어, 중국어, 일본어와 같은 기타 글꼴의 경우, “동등한” 크기는 해당 언어에 사용되는 가장 작은 대형 인쇄 크기와 그다음으로 더 큰 표준 대형 인쇄 크기의 최소 크기가 될 것이다.
2021년 5월 이전에는 정의의 0.04045 값이 달랐다(0.03928). 이는 이전 버전의 명세서에서 가져와 업데이트되었다. 이는 본 지침의 맥락에서 계산에 실질적인 영향을 미치지 않는다.
참고 3
오늘날 웹 콘텐츠를 보는 데 사용하는 거의 모든 시스템은 sRGB 인코딩을 사용한다고 가정한다. 콘텐츠를 처리하고 표시하기 위하여 다른 색 공간이 사용되지 않는 한, 웹 콘텐츠 저작자는 sRGB 색 공간을 사용하여 평가해야 한다. 다른 색 공간을 사용하는 경우, “성공기준 4.1.3 이해”를 참고하라.
참고 4
전달 후 디더링이 발생할 경우, 원본 색상 값이 사용된다. 원본에서 디더링되는 색상의 경우, 디더링되는 색상의 평균값(평균 R, 평균 G, 평균 B)을 사용해야 한다.
예제: 한 웹 페이지의 “검색(search)” 버튼과 다른 웹 페이지의 “찾기(find)” 버튼은 모두 검색어를 입력할 수 있는 양식(field)을 가지고 있고, 입력한 검색어와 관련된 주제를 웹사이트 내에 나열한다. 이 경우, 두 버튼은 동일한 기능을 가지고 있지만 레이블이 일관성 있게 부여되지 않은 것이다.
WCAG 2 용어집에 기술된 내용을 따르되 두 번째 예제를 추가하고 첫 번째 예제에 번호를 부여한다.
이 추가 사항을 반영하면 다음과 같이 해석된다.
동일한 기능
사용했을 때 동일한 결과가 도출되는
예제 1
한 웹 페이지의 “검색(search)” 버튼과 다른 웹 페이지의 “찾기(find)” 버튼은 모두 검색어를 입력할 수 있는 양식(field)을 가지고 있고, 입력한 검색어와 관련된 주제를 웹사이트 내에 나열한다. 이 경우, 두 버튼은 동일한 기능을 가지고 있지만 레이블이 일관성 있게 부여되지 않은 것이다.
예제 2
리본 아이콘 중 하나는 폴더에 화살표가 들어가는 모양이고, 다른 하나는 하드 드라이브에 화살표가 들어가는 모양일 수 있다. 둘 다 문서를 저장하는 기능을 한다면, 동일한 기능이지만 시각적 레이블에 일관성이 없는 경우다.
출판물이 여러 웹 페이지에 걸쳐 나누어져 있고, 각 페이지에는 작품의 한 장(chapter) 또는 다른 주요 섹션이 포함되어 있다. 출판물은 논리적으로 하나의 연속적인 단위이며, 전체 페이지 세트에 액세스할 수 있는 탐색 기능을 포함하고 있다.
전자상거래 웹 사이트에서 제품을 일련의 웹 페이지로 보여주며, 모든 페이지는 동일한 탐색 및 식별 방식을 공유한다. 그러나 결제 과정으로 진행하면 템플릿이 변경되어 탐색과 다른 요소가 제거되므로 해당 과정의 페이지는 기능적으로나 시각적으로 다르다. 결제 페이지는 제품 페이지 세트의 일부가 아니다.
하위 도메인(예: blog.example.com)의 블로그는 기본 도메인(example.com)의 페이지와 다른 탐색 체계를 가지며, 별도의 저자 그룹에 의해 작성된다.
이 정의는 WCAG 2 용어집에 기술된 내용을 그대로 따르되, 다음과 같은 대체어를 적용하여 사용한다: “사용자 에이전트”는 “사용자 에이전트 또는 플랫폼 소프트웨어”로, “웹 콘텐츠”는 “콘텐츠”로, “인라인 스타일 및 저작자 스타일 시트”는 “프로그램 방식으로 설정된 스타일”로, 그리고 “사용자 에이전트 인터페이스 설정”은 “사용자 에이전트, 플랫폼 소프트웨어 또는 기타 소프트웨어 인터페이스 설정”으로 대체한다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
스타일 속성
콘텐츠 요소가 렌더링될 때(예: 화면 표시, 스피커 출력, 점자 디스플레이를 통해) [사용자 에이전트s나 플랫폼 소프트웨어]가 해당 요소를 어떻게 표현할지를 결정하는 속성. 예를 들어 글꼴, 색상, 크기, 위치, 여백, 음량, 합성 음성 운율 등이 이에 해당한다.
스타일 속성은 다음의 요소에서 설정될 수 있다.
[사용자 에이전트나 플랫폼 소프트웨어]의 기본 스타일: 저작자나 사용자의 스타일이 없는 경우 적용되는 기본 스타일 속성 값. 일부 [콘텐츠] 기술은 기본 렌더링을 명시하지만, 그렇지 않은 기술도 있다.
저작자 스타일: [[프로그램 방식으로 설정된 스타일]과 같이 콘텐츠 일부로서 작성자가 설정한 스타일 속성 값.
사용자 스타일: 사용자에 의해 설정된 스타일 속성 값(예: [사용자 에이전트, 플랫폼 소프트웨어 또는 기타 소프트웨어 인터페이스 설정, 또는] 사용자 스타일 시트 등을 통해 설정된 경우).
이 지침에서 사용된 “웹 기술(Web Technology)”과 “기술(technology)”(독자적으로 사용될 때)이라는 단어는 모두 웹 콘텐츠 기술(Web Content Technologies)을 의미한다.
참고 2
웹 콘텐츠 기술에는 정적 웹 페이지에서부터 동기화된 미디어 표현(presentation), 동적 웹 애플리케이션에 이르기까지 최종 사용자 경험을 조성하기 위해 개발자가 단독으로 또는 함께 사용할 수 있는 마크업 언어, 데이터 형식 또는 프로그래밍 언어가 포함될 수 있다.
예제
예제: 웹 콘텐츠 기술의 몇 가지 일반적인 예로는 HTML, CSS, SVG, PNG, PDF, Flash, JavaScript가 있다.
이 항목은 WCAG 2 용어집에 기술된 내용을 그대로 따르되, ‘웹 콘텐츠’를 ‘웹 기반이 아닌 문서 또는 소프트웨어’로, ‘사용자 에이전트’를 ‘사용자 에이전트 또는 기타 소프트웨어’로 대체하고, 주석은 제거하며, 예시는 “예: 웹 기반이 아닌 문서 및 소프트웨어 기술의 예로는 ODF, OOXML, Java, C++ 등이 있다”로 교체한다.
이 정의는 WCAG 2 용어집에 기술된 내용을 그대로 따르되, 예시를 “예시: 한 소프트웨어 프로그램에 파일 이름을 입력하는 텍스트 필드와 폴더를 선택하는 드롭다운 리스트 박스가 있다. 각각은 소프트웨어에서 이름을 설정할 수 있는 사용자 인터페이스 구성요소이다.”로 대체한다.
이러한 용어를 반영하여 다음과 같이 적용할 수 있다.
사용자 인터페이스 구성요소
특정 기능을 위해 사용자에게 하나의 제어 요소로 인식되는 콘텐츠의 일부
예제
한 소프트웨어 프로그램에 파일 이름을 입력하는 텍스트 필드와 폴더를 선택하는 드롭다운 리스트 박스가 있다. 각각은 소프트웨어에서 이름을 설정할 수 있는 사용자 인터페이스 구성요소이다.
사용자 에이전트는 하나 이상의 뷰포트를 통해 콘텐츠를 제시한다. 뷰포트는 창(windows), 프레임, 스피커, 가상 확대기를 포함한다. 뷰포트는 다른 뷰포트(예: 중첩된 프레임)를 포함할 수 있다. 프롬프트, 메뉴 및 경고와 같은 사용자 에이전트에 의해 생성된 인터페이스 구성요소는 뷰포트가 아니다.
HTTP를 사용하여 단일 URI에서 얻어진 내포되지 않은 리소스(non-embedded resource)과 렌더링에 사용되거나 사용자 에이전트에서 렌더링되도록 의도된 모든 다른 리소스
참고 1
모든 “다른 리소스(other resources)”는 주요 리소스와 함께 랜더링되지만, 반드시 서로 동시에 렌더링되지는 않는다.
참고 2
이러한 지침을 준수하려면, 리소스는 웹 페이지로 간주되기 위해 준수 범위 내에 “포함되지 않은(non-embedded)” 상태여야 한다.
예제 1
예제 1: 삽입된(embedded) 모든 이미지 및 미디어를 포함하는 웹 리소스
예제 2
예제 2: AJAX(Asynchronous JavaScript and XML)를 사용하여 작성된 웹 메일 프로그램. 이 프로그램은 http://example.com/mail에 전부 있지만, 받은 편지함, 연락처 영역 및 캐린더를 포함한다. 받은 편지함, 연락처 또는 캘린더를 표시하는 링크나 버튼이 제공되지만, 전체 페이지의 URI를 변경하지는 않는다.
예제 3
예제 3: 사용자가 일련의 다른 콘텐츠 모듈에서 표시할 콘텐츠를 선택할 수 있는 사용자 지정 가능한 포털 사이트
예제 4
예제 4: 브라우저에 “http://shopping.example.com/”을 입력하면, 영화에서처럼 상호 작용할 수 있는 쇼핑환경으로 들어갈 수 있다. 즉, 시각적으로 상점에 들어가서 돌아다니다가 주변의 선반에서 제품을 끌어와 앞에 있는 쇼핑 카트에 넣을 수 있다. 제품을 클릭하면, 해당 제품 옆에 명세서서가 함께 제시된다. 이것은 한 페이지로 된 웹 사이트일 수도 있고, 웹 사이트 내의 한 페이지일 수도 있다.
이 실무 그룹 노트는 새로운 개인정보 보호 고려사항을 도입하지 않는다. 그러나 WCAG 2 성공 기준을 웹이 아닌 ICT 환경에 적용할 때, 사용자의 접근성 요구나 선호에 대한 정보가 노출될 수 있으며, 이러한 정보가 공개되거나 악용될 경우 사용자에게 해가 될 수 있다.
사용자 식별이나 추적(fingerprinting 등)의 가능성을 줄이는 방식으로 구현하는 것이 바람직하며, 접근성 기능을 활성화하는 데 반드시 필요한 데이터만 수집해야 한다.
폐쇄형 기능을 갖춘 ICT 개발자에게 문제가 될 수 있는 성공 기준이 있다. 일부 기준은 정보를 텍스트로 제공하여 보조 기술이 읽을 수 있도록 하거나, 정보를 “프로그래밍 방식으로 판별 가능하게” 하거나(사용자 에이전트가 렌더링하고 보조 기술이 읽을 수 있도록), 그 밖의 방법으로 콘텐츠를 보조 기술과 호환되도록 만드는 것을 요구한다. 그러나 폐쇄형 기능을 가진 ICT에서는 보조 기술의 사용을 지원하지 않거나, 플랫폼에 접근성 API가 없는 경우가 있다. 이런 경우에는 보조 기술처럼 작동하는 소프트웨어 내장 기능 등 다른 메커니즘을 통해 동등한 정보와 조작을 제공함으로써 해당 성공 기준의 의도를 충족할 수 있다. 관련 내용은 폐쇄형 기능에 대한 의견 섹션도 참고하라.
또 다른 성공 기준들은 시스템이 완전히 폐쇄형이 아니거나 특정 유형의 장치 연결을 허용하는 경우에는 해당될 수 있다. 예를 들어, 성공 기준 2.1.1 키보드는 스크린 리더에는 폐쇄적이지만 물리적 키보드가 있거나 표준 키보드 연결을 허용하거나 대체 키보드 설치를 허용하는 시스템에는 적용된다. 이러한 성공 기준은 작성된 그대로 폐쇄형 기능에 항상 적용되지는 않지만, 폐쇄형 기능을 가진 제품에 접근성을 제공하기 위해 필요한 내장 기능 개발에 참고가 될 수 있다.
폐쇄형 기능을 갖춘 제품의 웹이 아닌 소프트웨어의 경우, 이 문서(WCAG2ICT)를 구현하는 사람은 각 WCAG 2 성공 기준의 적용 가능성을 개별 기준별로 고려해야 한다. 아래에 제시된 성공 기준들이 다루는 사용자 요구를 충족하기 위해서는 대체 접근성 제공 방식이 필요할 수 있다.
1.1.1 텍스트 아닌 콘텐츠 — 텍스트(또는 대체 텍스트)가 프로그래밍 방식으로 판별 가능한 형식이어야 적용 가능하다.
1.2.1 사전 녹화된 동영상 — 이 성공 기준에서는 저자가 미디어 대체 수단으로 텍스트를 제공하는 것이 하나의 옵션인데, 보조 기술이 연결되지 않은 경우, 이 텍스트는 다양한 방식으로 제공되어야 한다.
1.2.3 오디오 해설이나 미디어 대체수단 — 이 성공 기준에서도 저자가 미디어 대체 수단으로 텍스트를 제공할 수 있으며, 보조 기술이 연결되지 않은 경우, 이 텍스트는 다른 방식(청각 등)으로 제공되어야 한다.
1.3.1 정보와 관계 — 정보가 프로그래밍 방식으로 판별 가능한 형식 또는 텍스트 형식(역시 프로그래밍 방식으로 판별 가능)이어야 한다.
1.3.2 의미있는 순서 — 정보(즉, 올바른 읽기 순서)가 프로그래밍 방식으로 판별 가능한 형식으로 제공되어야 한다. 폐쇄형 기능을 가진 소프트웨어에서는 청각 출력 등 시각 이외의 방식으로 의미 있는 읽기 순서를 제공함으로써 해당 정보를 사용자에게 인식 가능하도록 지원해야 한다.
1.3.5 입력 목적 식별 — 프로그래밍 방식으로 판별 가능한 정보에 의존한다. 프로그래밍 기능이 없는 경우에는 텍스트 레이블이 구체적이어야 하며, 청각 등 다른 방식으로 사용자에게 제공되어야 한다.
1.4.2 오디오 제어 — 이 성공 기준의 취지는 보조 기술의 사용을 방해하지 않도록 오디오 출력을 제어하는 것이다. 보조 기술이 없는 폐쇄형 시스템에는 직접 적용되지 않지만, 내장된 접근성 기능(예: 음성 출력)이 있다면 방해가 발생할 수 있으므로 적용 대상이 된다. 또한, EN 301 549, 미국의 개정된 508 표준 등 여러 규정에서 폐쇄형 기능 제품의 볼륨 제어에 대한 요구사항을 다루고 있다.
1.4.3 명도대비 (최소) — 폐쇄형 기능을 가진 제품의 웹이 아닌 소프트웨어에 본 성공 기준을 적용하는 데에는 문제가 되는 경우가 있다.
콘텐츠의 대비가 소프트웨어 저자가 수정할 수 없는 하드웨어에 의해 결정되는 경우, 이 성공 기준을 충족하기 어려울 수 있다.
시스템 제한(예: 잠금 설정)으로 인해 색상 대비 비율을 프로그래밍 방식으로 측정할 수 없는 경우, 제3자가 색상 대비를 정량적으로 시험하는 것이 불가능하다. 이러한 경우에는 소프트웨어 저자가 사용한 색상 조합이 대비 요건을 충족함을 직접 확인해야 한다.
1.4.4 텍스트 크기 조정 — 폐쇄형 기능 제품의 웹이 아닌 소프트웨어는 웹의 사용자 에이전트에서 제공되는 수준만큼 텍스트 렌더링 지원 기능이 충분하지 않을 수 있다. 따라서 폐쇄형 환경에서 본 성공 기준을 충족하려면 콘텐츠 저자에게 더 큰 부담이 될 수 있다.
1.4.5 텍스트 이미지 — 보조 기술이 표시된 텍스트를 수정할 수 있도록 하려면(예: 대비 조정, 글꼴 크기 확대), 단순한 텍스트 이미지가 아닌 기계 판독 가능한 텍스트가 필요하다. 그러나 폐쇄형 기능을 가진 모든 ICT가 보조 기술과의 상호 운용성 또는 플랫폼 지원 부재로 인해 텍스트나 텍스트 이미지의 시각적 수정 기능을 지원하지 않을 수 있다.
1.4.10 재정렬 — 폐쇄형 기능을 가진 ICT의 일부 소프트웨어는 스크롤, 확대/축소, 뷰포트 또는 스크롤 영역 크기 조정을 지원하지 않는다. (예: 무인 거래 단말기, 키오스크 등). 이러한 경우에는, 이차원 스크롤 없이 저시력 사용자가 콘텐츠를 읽을 수 있도록 보장하기 위해 WCAG 이외의 다른 요구사항이 필요하다.
2.1.1 키보드 — 본 성공 기준은 키보드 인터페이스를 통한 조작을 전제로 하며, 이는 대체 입력 장치도 포함할 수 있다. 그러나 ICT에 내장 키보드가 없고, 모든 기능에 접근 가능한 키보드 유사 입력 방식(하드웨어 또는 소프트웨어)도 지원하지 않는 경우, 본 성공 기준을 충족하기 어려울 수 있다.
2.1.2 키보드 함정 방지 — 이 성공 기준은 키보드 인터페이스를 사용하여 초점을 이동할 수 있는 경우에 적용된다. 일부 폐쇄형 시스템에서는 숫자 키패드나 기능별 키 그룹과 같은 촉각 입력 장치는 제공되지만, 화면상의 초점을 이동시키는 메커니즘은 존재하지 않을 수 있다. 예를 들어, 각 키가 화면의 컨트롤 사이에서 초점을 이동시키는 것이 아니라 특정 기능에 직접 연결되어 작동하는 경우가 있다. 이러한 경우에는 초점의 개념 자체가 존재하지 않으므로, 키보드 함정도 존재할 수 없으며, 따라서 본 성공 기준은 충족된 것으로 간주된다.
2.1.4 문자 단축키 — 일부 폐쇄형 시스템에는 문자 단축키를 사용할 수 있는 메커니즘이 존재하지 않으며, 이러한 시스템은 하나의 키가 하나의 기능만 수행하는 방식으로 작동한다. 이와 같은 시스템에서는 본 성공 기준이 충족된 것으로 간주된다.
2.4.1 블록 건너뛰기 — 이 성공 기준에 대한 WCAG2ICT 해석에서는 “웹 페이지 세트”를 “소프트웨어 프로그램 세트”로 대체하지만, 폐쇄형 기능을 갖는 소프트웨어에서 이러한 소프트웨어 프로그램 세트는 매우 드물다. 그럼에도 불구하고, 소프트웨어 내에서 반복되는 콘텐츠 블록을 건너뛸 수 있도록 하는 기능은 일반적으로 바람직한 구현 방식으로 간주된다.
2.4.2 페이지 제목 제공 — 소프트웨어가 단일 기능을 제공하는 제품의 일부이거나, 메뉴 기반 인터페이스를 갖는 경우, 명시적인 제목을 제공하지 않더라도 본 성공 기준의 의도는 충족될 수 있다.
2.4.4 링크 목적(맥락 상의) — 이 성공 기준은 텍스트 및 맥락 정보가 프로그래밍 방식으로 판별 가능한 형태로 제공되는 것을 전제로 한다.
2.4.7 초점 시각화 — 이 성공 기준은 초점을 키보드로 이동하고 제어할 수 있는 조작 방식이 존재함을 전제로 한다. 일부 폐쇄형 시스템은 숫자 키패드나 기능별 키 그룹처럼 촉각으로 식별 가능한 입력 방식을 제공할 수 있지만, 사용자 인터페이스 설계상 초점을 시각적으로 전달할 필요가 없도록 되어 있을 수 있다. 예를 들어, 키가 화면상의 여러 옵션 간 초점을 이동하는 방식이 아니라, 음성 메뉴에서 옵션을 직접 선택하는 방식으로 작동하는 경우가 이에 해당한다. 이러한 경우에는 초점의 개념이 존재하지 않으므로, 시각적 초점 표시도 필요 없으며, 본 성공 기준은 충족된 것으로 간주된다.
2.5.3 이름 안의 레이블 — 이 성공 기준은 프로그래밍 방식으로 판별 가능한 형태로 정보가 제공되어야 함을 요구한다. 구체적으로는, 프로그래밍 방식의 이름(name) 속성에 시각적으로 표시된 레이블의 텍스트가 포함되어야 한다.
2.5.8 타겟 크기 (최소) — 이 성공 기준에서는 타겟 크기를 정의할 때 CSS 픽셀을 사용한다. 폐쇄형 기능을 갖는 ICT에서는 CSS 픽셀이 표준 측정 단위로 사용되지 않을 수 있으나, 웹이 아닌 문서 및 소프트웨어에서 “CSS 픽셀” 적용에서 정의하는 방식에 따라 여전히 유효하다. 시스템이 밀도 독립 픽셀(density-independent pixel) 기반 측정을 지원하는 경우, CSS 픽셀 대신 해당 측정 단위를 사용하는 것이 바람직하다.
3.1.1 페이지 언어 표시 — 올바른 발음을 유도하기 위해 언어 정보가 프로그래밍 방식으로 판별 가능한 형태로 제공되어야 함을 전제로 한다. 폐쇄형 기능을 갖춘 제품의 경우, 자체 음성 출력(self-voicing) 등 대체 메커니즘을 통해 정확한 발음을 제공할 수 있다면, 본 성공 기준의 의도는 충족된 것으로 간주될 수 있다.
3.1.2 부분적인 언어 표시 — 발음을 정확하게 수행하기 위한 언어 정보가 프로그래밍 방식으로 판별 가능한 형태로 제공되어야 함을 전제로 한다. 폐쇄형 기능을 갖춘 정보통신기술 제품에 있어서도, 자체 음성 출력과 같은 메커니즘을 통해 해당 기능이 구현된다면, 본 성공 기준의 의도는 충족된 것으로 해석할 수 있다.
3.2.6 일관된 도움말 — WCAG2ICT에서는 본 성공 기준의 “웹 페이지 세트”를 “소프트웨어 프로그램 세트”로 대체하여 해석하며, 폐쇄형 기능 소프트웨어에서 이러한 세트는 매우 드물다. 그럼에도 불구하고, 사용자에게 일관된 접근 방식으로 도움말을 제공하는 것은 바람직한 구현 방식으로 간주된다.
3.3.1 오류 식별 — 이 성공 기준은 오류 정보를 텍스트로 제공할 것을 요구한다. 여기서 텍스트는 “프로그래밍 방식으로 판별 가능한” 형태여야 한다는 WCAG 정의에 따른다.
텍스트 애플리케이션의 인터페이스는 서버 애플리케이션이 화면에 어떤 문자를 배치할지를 지시하고, 이를 하드웨어 터미널 또는 문자 출력을 표시하는 터미널 애플리케이션이 출력하는 방식으로 구현된다. 이러한 텍스트 애플리케이션의 클라이언트 터미널 애플리케이션은 웹 페이지의 사용자 에이전트에 해당하며, 텍스트 애플리케이션 역시 웹 애플리케이션과 마찬가지로 원격 서버에서 실행되거나 로컬에서 실행될 수 있다.
일부 텍스트 애플리케이션은 텔레타이프(TeleTYpewriter, TTY) 방식처럼 출력 내용을 순차적으로 추가하며, 이는 마치 계속 확장되는 파일과 같다. 이러한 유형의 텍스트 애플리케이션은 일반적으로 “명령줄 애플리케이션(command-line applications)” 또는 경우에 따라 “TTY 애플리케이션”이라 불리며, 그 출력은 파일로 리디렉션하여 나중에 검토할 수도 있다. 반면, 다른 애플리케이션은 고정 폭의 문자 셀로 구성된 행렬에 텍스트를 명시적으로 배치하며, 경우에 따라 전경색 및 배경색도 지정된다.
역사적으로 텍스트 애플리케이션의 입력은 키보드 인터페이스를 통해서만 제공되었으나, 최근에는 특히 모바일 기기에서 음성인식(Automatic Speech Recognition, ASR) 기반의 음성 입력이 대체 수단으로 제공되기도 한다.
보조 기술을 활용하여 텍스트 애플리케이션의 접근성을 확보하기 위한 전략은 다음의 두 가지 핵심 과업으로 구성된다. (1) 인터페이스에 표시된 모든 텍스트를 획득하는 것, 그리고 (2) 해당 텍스트를 분석하여 화면 갱신을 감지하고 구조적 요소를 식별하려는 시도이다.
예를 들어, 텍스트 애플리케이션용 스크린 리더는 인터페이스에 존재하는 문자 셀 매트릭스에 직접 접근하여, 해당 문자 행렬을 음성 합성 출력이나 점자 디스플레이를 통해 사용자가 검토할 수 있도록 화면 검토(screen review) 기능을 제공할 수 있다. 또는, 텍스트 애플리케이션 스크린 리더는 터미널 애플리케이션의 역할을 수행하거나 “TTY” 출력 자체를 분석함으로써 렌더링된 출력을 직접 수신할 수도 있다. 일부 스크린 리더는 문자 셀 매트릭스 내 텍스트의 간격과 배치를 분석하여 다단 구성의 텍스트 열을 읽는 기능, 줄 간격·들여쓰기·대문자 사용 등을 통해 헤더를 식별하는 기능, 역영상(inverse video), 괄호로 둘러싸인 텍스트, 혹은 문자 그래픽 코드페이지(ASCII 코드 0x7F 이상의 문자 등)를 활용하여 입력 필드나 사용자 인터페이스 구성요소를 감지하는 기능을 제공하기도 한다. 이러한 분석 작업은 프로그램의 출력을 필터링하거나 재구성하는 도구를 통해 수행될 수도 있으며, 예컨대 “TTY” 출력을 파일로 저장하거나 필터 도구에 직접 전달하여 가공하는 방식이 이에 해당한다.
이와 유사하게, 텍스트 애플리케이션용 화면 확대기(screen magnifier)는 문자 셀 매트릭스에 접근하여 해당 셀을 확대하거나 더 큰 글꼴로 재표시한다. 이때 화면 갱신 및 업데이트를 탐지하고, 변경된 내용을 기반으로 어떤 문자 셀의 하위 행렬(sub-matrix)을 확대하여 보여줄지를 결정하기 위해 다양한 휴리스틱을 적용한다. 또한 역영상이나 움직이는 텍스트 커서를 감지하여 사용자가 입력 중인 내용을 추적하며, 문자 셀 매트릭스 분석과 키보드 입력 분석을 결합하여 사용자의 입력과 화면에 나타나는 내용을 일치시키는 방식으로 구현되기도 한다.
역자주 문자 셀 매트릭스(Character Cell Matrix)는 전통적인 터미널에서 행과 열로 구성된 문자 단위의 격자 구조를 의미하지만, 접근성 보조 기술, 특히 화면 확대기의 관점에서는 텍스트의 시각적이면서도 논리적인 위치 정보를 파악하고 해석하는 단위로 이해할 수 있다.
많은 접근성 보조 기술의 분석 기법은 텍스트 입력 커서의 위치를 판별하는 데 기반하고 있기 때문에, 터미널 응용프로그램이 사용하는 소프트 커서(soft cursor) 또는 강조 표시(highlight bar)는 이러한 분석 기법을 우회하게 되어 성공 기준 충족에 실패할 수 있다.
텍스트 응용프로그램에 있어서 접근성 지원과 프로그래밍 방식으로 판별이라는 개념은 다소 다르게 느껴질 수 있으나, 이 용어의 정의 자체는 변하지 않는다.
그래픽 사용자 인터페이스나 웹페이지의 시맨틱 객체와는 달리, 텍스트 기반 응용프로그램의 출력은 단순 텍스트로 구성되어 있다. 터미널 에뮬레이터는 텍스트 기반 응용프로그램의 사용자 에이전트 역할을 하며, 이 과정에서 일부 이스케이프 코드(escape code)를 시맨틱 요소로 렌더링할 수 있지만, 대부분 보조 기술에 노출되는 것은 텍스트 줄에 불과하다. 보조 기술이 이 텍스트와 시맨틱 요소를 정확히 해석할 수 있다면, 해당 콘텐츠는 프로그래밍 방식으로 판별 가능한 것으로 간주되며, 이는 반드시 명시적 마크업을 사용해야 한다는 의미는 아니다.
Shadi Abou-Zahra, Bruce Bailey, Judy Brewer, Michael Cooper, Pierce Crowell, Allen Hoffman, Kiran Kaja, Andrew Kirkpatrick, Peter Korn, Alex Li, David MacDonald, Mary Jo Mueller, Loïc Martínez Normand, Mike Pluke, Janina Sajka, Andi Snow-Weaver, Gregg Vanderheiden
이 문서는 미국 보건복지부 산하 장애인 자립생활 및 재활연구소(NIDILRR)의 연방 자금 일부로 제작되었으며, 최초에는 계약 번호 ED-OSE-10-C-0067에 따라, 이후에는 계약 번호 HHS75P00120P00168에 따라 지원을 받았다. 본 문서의 내용은 미국 보건복지부나 미국 교육부의 견해나 정책을 반드시 반영하는 것은 아니며, 특정 상표명, 상업 제품 또는 기관의 언급이 미국 정부의 지지를 의미하지는 않는다.
이 문서 작업은 유럽연합 집행위원회(EC)가 공동 자금을 지원한 WAI-CooP 프로젝트의 일환으로 수행되었으며, 해당 프로젝트는 Horizon 2020 프로그램(101004794)에 의해 지원되었다.
