접근성 적합성 테스트(ACT) 규칙 형식 1.1

1. 소개

현재 웹 콘텐츠 접근성 지침 [WCAG22]와 같은 접근성 표준에 부합하는지 웹 콘텐츠를 테스트할 수 있도록 돕는 다양한 테스트 절차와 도구들이 있습니다. 웹이 그 규모와 복잡성이 증대되면서, 이러한 절차와 도구는 웹에 존재하는 리소스의 접근성을 관리하기 위해 필수적입니다.

ACT 규칙 형식은 WCAG 및 기타 접근성 요구 문서의 적합성 테스트 방법에 대해 일관된 해석을 가능하게 하며, 접근성 테스트 결과의 일관성을 높이기 위한 지침을 제공합니다. ACT 규칙 형식은 접근성 테스트 도구에 의해 수행되는 수동 및 자동 테스트 모두를 기술하도록 설계되었습니다.

접근성 요구사항 테스트 방법을 문서화하면 반복 가능한 테스트 결과를 가진 투명한 접근성 테스트가 이루어집니다. ACT 규칙 형식은 접근성 적합성 테스트 규칙(ACT 규칙)이라 불리는 이 테스트 설명에 필요한 요구사항을 정의합니다.

ACT 규칙은 특정한 접근성 요구사항의 특정 콘텐츠 유형을 테스트하는 방법에 대해 평이한 언어로 설명한 것입니다. ACT 규칙은 어떤 종류의 콘텐츠에 적용되는지와 해당 규칙의 기대 조건을 모두 충족하기 위해서 적용 대상 요소에 어떤 조건이 참이어야 하는지 기술합니다. WCAG 맥락에서 ACT 규칙은 성공 기준을 만족하지 못하는 실패를 테스트합니다. 이러한 실패는 종종 WCAG의 일반적인 실패로 문서화됩니다. ACT 규칙은 테스트 과정에 초점을 맞추어 작성되며 일반적인 실패보다 더 구체적일 수 있습니다.

ACT 규칙 형식은 ACT 규칙이라 불릴 수 있으려면 각 규칙에 어떤 정보가 반드시 포함되어야 하는지 요구사항과 규칙 구조를 정의합니다. 규칙의 구조는 ACT 규칙 구조 섹션에서 정의됩니다. 각 ACT 규칙에는 시험 대상 콘텐츠 유형, 수행할 테스트, 기대 결과에 대한 평이한 언어 설명도 포함됩니다. 테스트 결과가 적합성에 영향을 미치는 경우, 해당 규칙은 시험 중인 특정 요구사항을 문서화합니다. 테스트에서 나온 결과는 요구사항의 적합성 또는 부적합성을 판단할 때 활용할 수 있습니다. 규칙 구현이 기대 결과를 올바르게 도출하는지 검증할 수 있도록 예시도 ACT 규칙의 일부로 작성합니다.

2. 적용 범위

이 명세에서 정의된 ACT 규칙 형식은 하이퍼텍스트 마크업 언어 [HTML], 계단식 스타일 시트(CSS) [css-2018], 접근 가능한 리치 인터넷 애플리케이션 [WAI-ARIA], 확장형 벡터 그래픽스 [SVG2], EPUB 3 [epub-33] 등 웹 기술을 사용하여 생성된 콘텐츠를 테스트할 수 있는 규칙에 적합하도록 설계되었습니다. ACT 규칙 형식은 기술 독립적으로 설계되어 있어 다양한 기술의 테스트 규칙을 설명하는 데도 활용될 수 있습니다.

ACT 규칙 형식은 웹 콘텐츠에 특화된 웹 콘텐츠 접근성 지침 접근성 요구사항에 대해 테스트하는 ACT 규칙을 설명할 때 사용할 수 있습니다. 웹 기술에 적용되는 기타 접근성 요구사항도 ACT 규칙으로 테스트가 가능합니다. 예를 들어, 웹 기반 사용자 에이전트가 사용자 에이전트 접근성 지침 [UAAG20]의 적합성을 갖추고 있는지 ACT 규칙을 만들어 시험할 수 있습니다. ACT 규칙 형식이 모든 종류의 접근성 요구사항 테스트에 항상 적합하지는 않을 수 있습니다.

2.1. 하위 호환성

ACT 규칙 형식 1.1은 대부분 1.0과 하위 호환되지만 완전히 동일하지는 않습니다. 1.1에서는 1.0에는 없던 일부 요구사항을 도입했으며, 1.0에서 허용하지 않았던 몇 가지(예: 주관적 적용성)를 허용합니다. 자세한 변경 내역은 변경 이력에서 확인할 수 있습니다.

3. ACT 규칙 유형

접근성에서는 동일한 유형의 콘텐츠에 대해 다양한 기술적 해결법이 존재할 수 있습니다. 예를 들어, HTML의 img 요소에 접근성 이름을 부여하는 방법은 여러 가지가 있습니다. 이러한 다양한 해결책은 하나의 규칙에서 테스트할 수도 있지만, 그러할 경우 규칙이 복잡해져서 이해나 유지보수가 어려워집니다. ACT 규칙 형식은 다음 두 가지 규칙 유형을 제공합니다:

• 원자 규칙 은 특정 해결책을 테스트하는 방법을 기술합니다. 이 규칙은 테스트 대상의 요소, 노드, 기타 "부분"이 무엇을 포함하는지와, 해당 대상이 언제 규칙을 만족 또는 실패하는지에 대한 정확한 정의를 포함합니다. 이러한 규칙은 작고 원자적이어야 하며, 각 원자 규칙은 단일 "조건"만을 테스트하며 다른 규칙의 결과를 사용하지 않습니다.

• 복합 규칙 은 여러 원자 규칙의 결과를 테스트 대상별로 하나의 결과로 결합하는 방법을 기술합니다. 복합 규칙은 여러 "조건"을 가지며, 각각은 별도의 원자 규칙으로 테스트됩니다. 복합 규칙의 논리는 여러 조건 중 하나 혹은 조합이 단일 결과를 결정하는 방법을 설명합니다.

복합 규칙은 다른 복합 규칙을 포함할 수 없습니다. 복합 규칙이 중첩되어야 하는 상황에는 관련된 모든 원자 규칙을 직접 새 복합 규칙에 결합하면 됩니다.

모든 원자 규칙이 꼭 복합 규칙의 일부일 필요는 없습니다. 복합 규칙은 여러 원자 규칙의 결과를 결합해야 할 때 사용됩니다. 즉, 테스트 대상이 접근성 요구사항을 충족하지 못하는지를 판정할 때 활용됩니다.

원자 규칙과 복합 규칙 간의 분리는 역할의 분담을 만듭니다. 원자 규칙은 웹 콘텐츠가 특정 해결책으로 올바르게 구현되었는지를 검사합니다. 복합 규칙은 다른 원자 규칙의 결과 조합이 접근성 요구사항을 일부 또는 전체적으로 만족하는지 검사할 수 있습니다.

4. ACT 규칙 구조

ACT 규칙은 최소한 다음 항목을 포함해야 합니다:

• 설명적 제목

• 규칙 식별자

• 규칙 설명

• 규칙 유형

• 접근성 요구사항 매핑

• 규칙 입력 (다음 중 하나):

  • 입력 측면 (원자 규칙용) 또는

  • 입력 규칙 (복합 규칙용)

• 적용성

• 기대사항

• 배경

  • 가정

  • 접근성 지원

  • 관련 규칙(선택 사항)

  • 기타 리소스(선택 사항)

• 예시

• 규칙 버전

• ACT 규칙 형식 버전

• 용어집

ACT 규칙은 다음을 추가로 MAY 포함할 수 있습니다:

• 관련 규칙 (배경 섹션, 선택 사항)

• 기타 리소스 (배경 섹션, 선택 사항)

• 이슈 목록 (선택 사항)

• 구현 예시 (선택 사항)

• 감사의 글 (선택 사항)

ACT 규칙 형식은 규칙이 어떤 형식(예: HTML, DOCX, PDF 등)으로 작성되어야 하는지 규정하지 않습니다. 그러나 ACT 규칙은 반드시 웹 콘텐츠 접근성 지침 [WCAG22] 또는 동등한 접근성 표준을 준수하는 문서에 작성되어야 합니다. 이는 ACT 규칙이 장애가 있는 사람에게도 접근 가능하게 함을 보장합니다. ACT 규칙 예시에는 접근하지 못하는 콘텐츠가 포함될 수도 있습니다. 만약 예시에 WCAG 2.2 5.2.5 비간섭에 해당하는 접근성 문제가 포함된 경우, 사용자에게 미리 경고해야 합니다. ACT 규칙은 현지화 가능한 형식을 사용하는 것이 좋으며, 이를 통해 규칙에 여러 언어 표현을 담거나 번역이 가능하게 할 수 있습니다.

4.1. 규칙 식별자

ACT 규칙은 규칙 집합 내에서 고유해야 하는 식별자를 반드시 가져야 합니다. 식별자는 텍스트, URL, 데이터베이스 식별자 등 어떠한 형태든 가능합니다.

식별자 외에도, ACT 규칙의 각 신규 릴리스는 날짜 또는 번호로 버전 관리되어야 합니다. 이전 버전에 대한 참조 또한 반드시 제공되어야 합니다. 규칙이 업데이트될 때 식별자는 변경되어서는 안 됩니다. 대규모 변경이 있을 경우에는 새 식별자를 가진 새로운 규칙을 만들고, 이전 규칙은 더 이상 사용하지 않아야 합니다.

4.2. 규칙 설명

ACT 규칙은 규칙이 무엇을 하는지 간략하게 설명하는 평이한 언어의 설명을 반드시 포함해야 합니다.

규칙이 어떤 데이터 형식으로 작성되었든, 설명에는 언어와 기본 문단 방향을 지정하는 메타데이터가 포함되어야 합니다. 대부분의 마크업 또는 문서 형식에는 이 정보를 표시하는 기능이 내장되어 있습니다. 자세한 내용은 [string-meta]를 참고하세요.

4.3. 규칙 유형

ACT 규칙은 다음 중 하나의 규칙 유형을 반드시 가져야 합니다:

• 원자 규칙
• 복합 규칙

자세한 정의는 규칙 유형 섹션을 참고하세요.

4.4. 접근성 요구사항 매핑

ACT 규칙이 하나 이상의 접근성 요구 문서의 적합성을 테스트하도록 설계된 경우, 그 규칙은 해당 문서에서 해당 규칙의 결과 중 하나 이상이 failed일 때 충족되지 않는 모든 접근성 요구사항을 반드시 나열해야 합니다. 규칙은 결과가 failed일 때 충족되지 않을 수 있는 접근성 요구사항도 나열할 수 있습니다. 접근성 요구사항에는 두 가지 유형이 있습니다:

• 적합성 요구사항

• 부차적 요구사항

매핑된 각 접근성 요구사항은 아래 항목을 반드시 포함해야 합니다:

1. 접근성 요구사항의 이름, 제목, 식별자 또는 요약 중 하나

2. 접근성 요구 문서의 이름

3. 해당 문서의 링크 또는 참조(존재하는 경우)

4. 접근성 요구사항에 연계된 적합성 수준(존재하는 경우)

5. 이 요구사항이 적합성 요구사항인지, 부차적 요구사항인지 여부

4.4.1. 결과 매핑

4.4.1.1. 적합성 요구사항

규칙이 특정 접근성 요구사항을 테스트하도록 설계된 경우, 다음 두 조건을 모두 만족할 때 접근성 요구사항은 적합성 요구사항으로 매핑합니다:

• 실패 결과: 테스트 대상에서 하나 이상의 결과가 failed일 경우, 해당 접근성 요구사항은 그 테스트 대상에서 충족되지 않음입니다.

• 통과 또는 해당 없음 결과: 모든 결과가 passed 또는 inapplicable일 경우, 해당 접근성 요구사항은 충족됨 또는 추가 테스트 필요일 수 있습니다.

접근성 요구사항이 충족됨을 판정할 수 있는 규칙을 충족성 테스트라 부릅니다.

• 통과: 모든 결과가 passed일 경우, 해당 테스트 대상의 접근성 요구사항은 충족됨입니다.

4.4.1.2. 부차적 요구사항

부차적 접근성 요구사항은 규칙과 연관되어 있지만 규칙이 그 적합성을 테스트하도록 설계되지 않은 요구사항입니다. 규칙의 결과가 접근성 요구사항의 결과에 영향을 줄 수 있지만, 규칙은 해당 요구사항의 적합성을 테스트하는 것을 의도하지 않습니다. 이러한 연관성 때문에 일부 예시는 부차적 접근성 요구사항을 만족하지 않을 수 있습니다.

규칙이 접근성 요구사항을 테스트하도록 설계되지 않았거나 규칙의 실패 결과가 해당 접근성 요구사항에 대해 추가 테스트를 필요로 하는 경우, 규칙은 접근성 요구사항을 부차적으로 매핑할 수 있습니다. ACT 규칙이 부차적 요구사항에 매핑될 때, 규칙에는 해당 요구사항이 부차적인 이유에 관한 설명이 반드시 포함되어야 합니다.

규칙이 접근성 요구사항을 테스트하도록 설계된 경우, 접근성 지원의 차이는 해당 요구사항을 부차적 접근성 요구사항의 사유가 되어서는 안 됩니다.

특정 상황에서 규칙에 부차적 요구사항이 포함되는 경우는 다음과 같습니다:

상황 1: 규칙이 요구사항만큼 엄격하지 않음

규칙은 최소 접근성 요구사항을 테스트하도록 설계되어 있고 더 엄격한 요구사항이 존재합니다. 규칙의 실패 결과는 더 엄격한 접근성 요구사항이 만족되지 않음을 결정할 수 있으며, 규칙의 성공 결과는 더 엄격한 요구사항이 만족됨을 결정하지 못할 수 있습니다. 규칙의 성공 결과임에도 접근성 요구사항이 만족되지 않을 수도 있습니다. 더 엄격한 요구사항은 부차적 요구사항입니다.

상황 2: 규칙이 요구사항보다 더 엄격함

규칙이 특정 접근성 요구사항에 대한 구체적 해결책을 테스트하도록 설계되었지만, 해당 요구사항은 규칙에 포함되지 않은 다른 해결책으로도 만족될 수 있습니다. 이런 경우, 규칙의 실패 결과만으로 접근성 요구사항이 만족되지 않았음을 결정할 수 없고 추가 테스트가 필요합니다. 규칙의 성공 결과로만 접근성 요구사항이 만족됨을 결정할 수 있습니다. 해당 접근성 요구사항은 부차적 요구사항입니다.

규칙이 접근성 요구사항을 테스트하도록 설계되고, 더 덜 엄격한 접근성 요구사항이 존재하는 경우도 있습니다. 이때 규칙의 성공 결과로 더 덜 엄격한 요구사항이 만족됨을 결정할 수 있고, 규칙의 실패 결과로 더 덜 엄격한 요구사항이 만족되지 않았음을 결정할 수 없습니다. 규칙의 실패 결과임에도 접근성 요구사항이 만족될 수 있습니다. 더 덜 엄격한 접근성 요구사항은 부차적 요구사항입니다.

상황 3: 규칙이 접근성 요구사항의 결과에 영향을 줄 수 있지만 규칙의 의도가 해당 요구사항의 적합성 테스트가 아님

규칙이 접근성 요구사항을 테스트하도록 설계되었으나 특정 조건에서는 다른 접근성 요구사항이 적용될 수 있습니다. 이때, 다른 접근성 요구사항이 규칙에서 항상 적용되는 것이 아니므로 때로는 만족/불만족될 수 있습니다. 이러한 다른 접근성 요구사항은 부차적 요구사항입니다.

4.4.2. WCAG 외부 매핑

ACT 규칙은 하이퍼텍스트 마크업 언어 [HTML] 같은 W3C 접근성 표준 외의 접근성 요구사항이나, RGAA 3 2016과 같은 방법론의 테스트도 평가할 수 있습니다. ACT 규칙은 그 매핑 대상인 접근성 요구사항이 해당 접근성 요구 문서에서 적합성에 요구되는지 아닌지 반드시 명시해야 합니다. 예를 들어, WCAG 충분 기법이나 회사 스타일 가이드의 "베스트 프랙티스"는 적합성에 필수가 아닙니다. 필수와 선택 사항 구분은 분명해야 합니다.

4.4.3. 접근성 요구사항이 없는 규칙

규칙이 어떤 접근성 요구사항에도 대응하지 않는 경우, 접근성 요구사항 매핑에는 해당 접근성 요구 문서에 적합성에 필수가 아님을 설명하는 안내만 포함합니다. 이는 복합 규칙에서 쓰이는 원자 규칙에서 흔히 볼 수 있습니다.

failed 결과가 접근성 요구사항에 매핑될 수 없는 경우, 접근성 요구사항 매핑에는 접근성 요구사항이 포함되어서는 안 됩니다. 선택적 배경 섹션에는 규칙이 실패 테스트는 아니더라도 주제적으로 관련된 접근성 요구 문서를 나열할 수 있습니다.

4.4.4. 외부 접근성 요구사항 매핑

이 섹션은 비규범적입니다.

규칙은 종종 하나 또는 몇 개의 접근성 요구 문서를 위해 설계되어 있지만, 실제로는 다른 접근성 요구 문서에도 해당 ACT 규칙을 매핑할 수 있습니다. 예를 들어, 규칙이 웹 콘텐츠 접근성 지침 [WCAG22]을 위해 작성되어도, 내부 정책에 매핑될 수 있습니다. 이런 경우, 외부 접근성 요구사항 매핑을 추가할 수 있습니다. 외부 접근성 요구사항 매핑은 ACT 규칙에 다른 접근성 요구 문서의 매핑을 추가하여 중복 작성을 방지합니다.

4.5. 규칙 입력

ACT 규칙을 이용해 콘텐츠를 평가하려면 규칙이 테스트 대상에서 일부 정보를 입력값으로 요구합니다. 어떤 입력이 필요한지 명확히 하여, 평가자가 규칙을 사용할 때 필요한 역량을 알 수 있습니다. 원자 규칙과 복합 규칙은 요구하는 입력이 다릅니다.

• 원자 규칙은 입력 측면을 가집니다

• 복합 규칙은 입력 규칙을 가집니다

4.5.1. 입력 측면(원자 규칙만 해당)

입력 측면은 테스트 대상의 독립적인 부분입니다. 최종 사용자에게 특정 콘텐츠를 렌더링하는 과정에서는 다양한 기술이 사용되며, 이 중 일부 또는 전체가 원자 규칙의 입력으로 요구될 수 있습니다. 예를 들어, 일부 규칙은 하이퍼텍스트 전송 프로토콜 [http11] 메시지(서버/클라이언트 간 교환)를 필요로 하고, 다른 규칙은 DOM 트리 [DOM](브라우저 노출 트리)를 필요로 할 수 있습니다.

원자 규칙은 적용성과 기대사항에 입렵으로 사용되는 측면을 반드시 나열해야 합니다. 규칙은 HTTP 메시지와 DOM 트리처럼 여러 측면에서 동작할 수 있습니다.

입력 측면 중 일부는 공식 명세에서 명확히 정의되어 있습니다(HTTP 메시지, DOM 트리, CSS 스타일링 [css-2018] 등). 이런 경우, Common Input Aspects note의 해당 부분 참조로 설명을 대체할 수 있습니다. 정의가 불명확한 입력 측면에 대해서는, ACT 규칙에 상세 설명이나 적절한 참조를 반드시 포함해야 합니다.

입력 측면이 어떻게 전달되는지는 중요하지 않습니다. 예를 들어 DOM 트리는 HTML 형식으로 HTTP를 통해 전달될 수도 있고, 여러 페이지가 EPUB 출판물로 묶이거나 JSX 소스 파일에서 추론될 수도 있습니다. 입력 측면이 DOM 트리뿐인 규칙은 모든 기술에 적용될 수 있습니다.

4.5.2. 입력 규칙(복합 규칙만 해당)

복합 규칙은 원자 규칙의 결과를 사용하고 이에 로직을 적용하여 각 테스트 대상마다 단일 결과를 결정합니다. 식별자와 설명적 제목을 기대사항에 쓰인 모든 원자 규칙에 대해 반드시 나열해야 하며, 입력 규칙은 복합 규칙의 입력을 설명합니다. 원자 규칙의 입력 측면이 원자 규칙의 입력을 설명하는 방식과 유사합니다.

4.6. 적용성

적용성은 테스트 대상의 어떤 부분이 테스트되는지 설명합니다.

4.6.1. 원자 규칙의 적용성

적용성 섹션은 원자 규칙에 반드시 포함되어야 합니다. 정확하게 이 규칙이 적용되는 테스트 대상의 부분을 명시해야 합니다. 예를 들어 DOM [DOM] 트리의 특정 노드나, HTML [HTML] 문서에서 잘못 닫힌 태그 등입니다. 이런 부분을 테스트 대상(target)이라 합니다. 적용성은 반드시 규칙에 나열된 입력 측면에서 제공되는 정보만 사용해야 합니다. 다른 정보는 쓰일 수 없습니다.

적용성은 명확해야 하며, 한 가지 방식으로만 해석될 수 있어야 합니다. 예를 들어, heading이나 이미지와 같은 개념은 태그명, 의미역할, 웹페이지 목적 등으로 의미가 달라질 수 있어 모호합니다. 반대로 heading 태그가 있는 요소에만 적용하는 규칙은 명확 조건을 만족합니다.

추가로, 적용성은 객관적으로, 평이한 언어로 설명되어야 합니다. 객관적 설명이란 해당 기술에서 불확실성 없이 판별 가능한 설명입니다. HTML에서 객관적 속성 예시는 태그명, 계산된 역할, 두 요소간 거리 등입니다.

주관적 속성은 장식용, 내비게이션 수단, 사전녹음 등 다양한 해석이 가능하고 사람 판단에 의존할 수 있습니다. 가능하면 주관적 정의는 피해야 하며, 불가피하게 적용해야 할 경우에는 적용성 내에서 객관/주관 부분을 별도 규칙으로 분리하는 것이 좋습니다. 예시: 올바른 시맨틱 마크업을 쓴 heading은 하나의 규칙, 시맨틱 마크업 없이 heading 스타일만 쓴 경우는 다른 규칙으로 분리.

정의는 용어집에 쓸 수 있고, 그 부분에서 즉시 정의해도 됩니다.

4.6.1.1. 적용성 유형 지정(선택 사항)

규칙은 적용성이 객관적인지 또는 주관적인지 여부를 나타내는 적용성 유형 식별자를 선택적으로 포함할 수 있습니다. 이 식별자는 규칙 독자와 구현자에게 규칙 작성자의 의도를 명확히 전달하고, 독자 및 구현자의 해석차로 인한 혼란을 줄여주는 데 도움이 됩니다.

4.6.2. 복합 규칙의 적용성

복합 규칙의 적용성은 입력 규칙에 나열된 모든 규칙의 적용성 정의의 합집합으로 정의됩니다. 규칙 작성자는 복합 규칙의 적용성에 대한 설명을 생략할 수도 있습니다. 이는 결합된 적용성을 평이한 언어로 표현하기 어려울 때 유용합니다. 만약 복합 규칙에 적용성이 포함된다면, 반드시 입력 규칙의 모든 적용성의 합집합이어야 합니다.

복합 규칙의 입력 규칙들은 서로 다른 적용성을 가질 수 있다는 점에 유의하세요. 따라서 복합 규칙에서 적용되는 모든 테스트 대상이 모든 입력 규칙에 의해 테스트되는 것은 아닙니다.

4.6.2.1. 적용성 유형 지정(선택 사항)

복합 규칙은 적용성이 객관적인지, 주관적인지를 나타내는 적용성 유형 식별자를 선택적으로 포함할 수 있습니다. 복합 규칙의 적용성 유형은 입력 규칙 중 하나라도 주관적 적용성을 포함하면 주관적으로, 그렇지 않으면 객관적으로 계산됩니다.

4.7. 기대사항

ACT 규칙에는 하나 이상의 기대사항이 반드시 포함되어야 합니다. 기대사항은 적용성에서 파생된 테스트 대상에 대한 요구 사항을 설명합니다. 기대사항은 테스트 대상에 대한 단언(assertion)입니다. 테스트 대상이 모든 기대사항을 만족하면, 해당 테스트 대상은 규칙을 passed로 처리합니다. 모든 기대사항을 만족하지 않으면 규칙을 failed로 처리합니다. 테스트 대상이 없으면, 해당 규칙의 결과는 inapplicable이 됩니다.

각 기대사항은 서로 명확히 구분되고, 모호하지 않아야 하며, 평이한 언어로 작성되어야 합니다.

4.7.1. 원자 규칙의 기대사항

원자 규칙의 모든 기대사항은 테스트 대상에 대해 하나의 passed 또는 failed 결과를 결정하는 데 사용되는 논리를 반드시 설명해야 합니다. 기대사항은 입력 측면, 적용성, 동일 규칙 내의 다른 기대사항에서만 정보를 사용할 수 있습니다. 다른 정보는 기대사항에서 사용할 수 없습니다. 예를 들어, "기대사항 1이 참이고 ..." 같은 표현은 가능하지만 "규칙 XYZ가 통과되고 ..."와 같은 표현은 사용 불가합니다. 이를 통해 원자 규칙의 캡슐화를 보장합니다.

4.7.2. 복합 규칙의 기대사항

복합 규칙의 모든 기대사항은 입력 규칙의 규칙 결과를 바탕으로 테스트 대상에 대해 하나의 passed 또는 failed 결과를 결정하는 논리를 반드시 설명해야 합니다. 복합 규칙의 기대사항은 입력 측면 정보를 사용해서는 안 됩니다. 모든 입력 규칙이 적용 불가(inapplicable)이면, 복합 규칙의 결과도 inapplicable입니다.

4.8. 배경

ACT 규칙의 배경 섹션에는 가정과 접근성 지원 항목이 반드시 포함되어야 합니다. 규칙 개발 배경, 참고자료, 관련 규칙 등 추가 정보는 선택적으로 포함할 수 있습니다. 규칙에 참고자료가 포함될 때 해당 참고자료와의 관계를 명시할 수 있습니다. 예를 들어, 특정 웹 콘텐츠 접근성 지침 [WCAG22] 성공 기준을 위한 배경 자료로 WCAG 2.2 이해 문서, WCAG 2.2 기술 문서, WAI-ARIA 1.2, CSS [css-2018], HTML [HTML] 기술 명세 등이 참고자료가 될 수 있습니다.

4.8.1. 가정

ACT 규칙은 평가, 테스트 환경, 사용 기술 또는 시험 대상과 관련된 모든 알려진 가정, 제한 사항 또는 예외사항을 반드시 나열해야 합니다. 예를 들어, CSS 속성 검사로 WCAG 2.2 성공 기준 1.4.3 Contrast (Minimum)를 부분적으로 테스트하는 규칙의 경우, CSS로 스타일링된 HTML 텍스트에만 적용되며 이미지 내 텍스트는 지원하지 않음을 명시할 수 있습니다.

접근성 요구사항 해석 방법이 여러 가지가 있을 수도 있습니다. 예를 들어, 웹 콘텐츠 접근성 지침 [WCAG22]에서 이모지 문자가 "텍스트"인지 "비문자 콘텐츠"인지 명확하지 않을 수 있습니다. 어떤 해석을 택하더라도 반드시 규칙에 문서화해야 합니다.

가정 항목은 ACT 규칙에 반드시 포함되어야 하나, 알려진 가정, 제한, 예외가 없는 경우에는 비워둘 수 있습니다.

4.8.2. 접근성 지원

콘텐츠는 다양한 지원 기술과 사용자 에이전트에서 특정 접근성 기능에 대한 지원에 의존할 수 있습니다. 예를 들어, 특정 WAI-ARIA 1.2 기능을 사용하는 콘텐츠는 해당 기능을 지원하는 지원 기술과 사용자 에이전트에 의존합니다. 이런 콘텐츠는 WAI-ARIA를 지원하지 않는 환경에선 작동하지 않을 수 있습니다. WCAG의 접근성 지원 정의를 참고하세요.

ACT 규칙에는 알려진 접근성 지원의 제한점을 반드시 포함해야 합니다.

접근성 지원 섹션은 ACT 규칙에 반드시 포함되어야 하나, 알려진 접근성 지원 문제가 없는 경우에는 비워둘 수 있습니다.

4.8.3. 관련 규칙(선택 사항)

관련 규칙은 동일한 접근성 요구사항을 테스트하는 다른 규칙입니다. 예를 들어, 복합 규칙의 두 관련 규칙은 결과에 기여하는 두 원자 규칙이 될 수 있습니다. 마찬가지로, 이 예시의 각 원자 규칙도 서로와 복합 규칙을 관련 규칙으로 나열할 수 있습니다.

4.8.4. 기타 자료(선택 사항)

규칙에 참고자료가 포함될 때 관련 읽기자료와의 관계를 명시할 수 있습니다. 예를 들어, 특정 웹 콘텐츠 접근성 지침 [WCAG22] 성공 기준에서 WCAG 2.2 이해 문서, WCAG 2.2 기술 문서, WAI-ARIA 1.2, CSS [css-2018], HTML [HTML] 기술 명세 등이 관련 자료가 될 수 있습니다.

4.9. 예시

예시는 ACT 규칙 구현을 검증할 때 사용할 수 있는 콘텐츠(코드 일부분 등)입니다. 각 규칙에는 passed, failed, inapplicable 결과에 대한 예시가 하나 이상 반드시 있어야 합니다. 예시는 각 규칙의 입력 측면별 코드 일부와 해당 규칙의 기대 결과 등 두 부분으로 구성됩니다. 예시는 규칙 결과가 passed, failed, inapplicable이 언제 나오는지 독자가 이해하는 예시 시나리오의 역할도 하고, 접근성 테스트 도구 및 방법론의 개발자나 사용자에게 규칙이 올바르게 구현되었는지 검증하는 역할도 합니다.

ACT 규칙의 모든 passed 및 inapplicable 예시는 규칙의 모든 적합성 요구사항을 반드시 만족해야 합니다. 각 failed 예시에 대해서도 모든 적합성 요구사항은 반드시 충족되지 않아야 합니다. 복합 규칙의 경우, 입력 규칙의 모든 예시도 복합 규칙의 적합성 요구사항을 반드시 만족해야 합니다.

4.10. 규칙 버전

ACT 규칙의 버전을 관리하는 것은 규칙 사용자들이 테스트 결과의 변화가 사용된 규칙의 변경에서 비롯된 것인지, 아니면 실제 콘텐츠의 변화인지 이해하는 데 중요합니다. 모든 이전 ACT 규칙 버전은 규칙 문서에 기록하거나 규칙 문서에서 참조할 수 있도록 반드시 관리되어야 합니다.

이 섹션 이름은 이전에 "변경 로그"였습니다. 두 이름 모두 사용 가능합니다.

4.11. ACT 규칙 형식 버전

ACT 규칙은 특정 버전의 ACT 규칙 형식에 맞춰 작성됩니다. 각 ACT 규칙은 어떤 버전의 ACT 규칙 형식으로 작성됐는지 반드시 표시해야 합니다. 이는 ACT 규칙 형식이 완전히 하위 호환성을 가지지 않기 때문에 중요합니다.

4.12. 용어집

ACT 규칙에는 반드시 용어집 섹션이 있어야 합니다. 용어집에는 결과(outcome) 정의와, 적용성과 기대사항 섹션에서 사용된 모든 정의가 포함되어야 합니다. 정의 변경은 규칙 그 자체를 변경하는 것이므로, 규칙과 독립적으로 수정할 수 없습니다. 여러 규칙이 공유 용어집을 사용하는 경우 정의 변경이 있으면 해당 정의를 사용하는 모든 규칙의 규칙 버전도 새로 만들어야 합니다.

4.13. 이슈 목록(선택 사항)

ACT 규칙에는 알려진 이슈 목록이나 목록 참조를 선택적으로 포함할 수 있습니다. 이슈 목록은 ACT 규칙의 결과가 실제로는 passed 또는 inapplicable여야 하는데 failed가 되거나, 반대의 경우를 기록합니다. 이런 일이 생기는 이유는 여러 가지가 있습니다. 자세한 내용은 규칙 정확성을 참고하세요.

이슈 목록은 두 가지 역할을 합니다. ACT 규칙 사용자에게는 부정확한 결과가 발생한 원인 정보와, 해당 규칙의 결과를 신뢰할 수 있는 근거를 제공합니다. 규칙 설계자에게는 규칙의 향후 업데이트 계획에도 도움이 됩니다. 규칙 새 버전 출시 시, 해결된 이슈는 변경 로그로 이동합니다.

4.14. 구현 사례(선택 사항)

ACT 규칙에는 구현 사례 목록을 선택적으로 포함할 수 있으며, 각 구현 사례는 그 규칙과 일치하거나 부분적으로 일치하는 체크를 하나 이상 제공합니다. 구현은 접근성 테스트 방법론이나 테스트 도구를 의미하며, 체크를 사용해 결과를 계산하여 접근성 요구사항이 만족되는지 판정합니다. 체크는 완전 자동, 완전 수동, 또는 이 둘 혼합 방식일 수 있습니다.

체크는 반드시 ACT 규칙에 일대일로 매핑될 필요는 없습니다. 하나의 체크가 여러 ACT 규칙과 일치하거나, 여러 체크 집합이 하나의 ACT 규칙과 함께 일치할 수도 있습니다.

각 구현에서는 예를 들어 다음과 같은 정보를 포함할 수 있습니다:

• 일치 또는 부분 일치하는 체크의 이름, 제목 또는 식별자

• 일관성

• 테스트 모드 (예: 자동, 수동, 반자동) 정보

• 구현 이름

• 일관성과 커버리지 테스트에 사용한 버전

• 공급업체 이름

4.14.1. 일관성

일관성(consistency)은 check가 ACT 규칙의 의도와 얼마나 잘 맞는지를 설명합니다. ACT 규칙에 일관성이 포함되는 경우, 반드시 이 섹션에 정의된 대로 결정되어야 합니다. ACT 규칙에서 일관적인 체크란 규칙에서 설명하는 일부 또는 모든 비적합 사안을 식별하는 데 사용할 수 있는 체크를 의미합니다. 체크가 다음 모든 조건을 만족할 때 일치함(consistent)이라고 합니다:

1. 진양성(True positives): 예시와 불일치가 없는 경우를 의미합니다:

   1. passed와 inapplicable 예시는 절대 failed로 보고되지 않아야 하며,

   2. failed 예시는 절대 passed 또는 inapplicable로 보고되지 않아야 합니다.

2. 완전성(Completeness): 커버리지 누락이 없어야 한다는 뜻입니다:

   1. check의 결과에 untested가 없어야 하며,

   2. failed 예시 중 적어도 하나가 failed로 보고되어야 합니다.

3. 규칙 매핑(Rule Mapping): 접근성 요구사항이 일관성 있게 보고되어야 한다는 뜻입니다:

   1. check가 그 규칙의 모든 적합성 요구사항을 테스트한다고 보고해야 하며, 다만 해당 구현에서 지원하지 않는 등급이나 표준의 요구사항은 제외할 수 있습니다.

   2. 규칙이 포함한다고 보고하는 모든 접근성 요구사항은 적합성 요구사항 또는 부차적 요구사항이어야 하며, 해당 규칙에 명시되지 않은 접근성 요구 문서의 요구사항은 제외합니다.

check가 한 예시에 대해 둘 이상의 결과를 보고할 경우, 아래 순서대로 가장 먼저 나오는 결과를 일관성 판단에 사용합니다:

1. failed

2. untested

3. cantTell

4. passed

5. inapplicable

4.14.2. 부분적 일관성

check가 일치함이 아닐 때는, 부분적으로 일치함(partially consistent)으로 간주합니다. 진양성(true positive) 조건이 참이고, 규칙의 예시에 대해 보고되는 모든 결과가 cantTell이나 untested만은 아닐 때 부분적으로 일치함으로 간주합니다.

4.14.3. 다중 체크의 일관성

implementation은 하나의 ACT 규칙의 일부만을 테스트하는 check를 여러 개 포함할 수 있습니다. 이 체크들을 조합하면 ACT 규칙 전체를 다 커버하면 일관적이라고 볼 수 있습니다. 체크 집합의 일관성은 모든 부분적으로 일치하는 체크를 하나의 체크로 간주하여 판단합니다.

체크 집합이 ACT 규칙에 일치함이라고 판단하려면 일치하는 체크의 모든 요건을 충족해야 합니다. 이 체크 집합에 대한 결과는 ACT 규칙에 부분적으로 일치하는 체크의 모든 결과 목록입니다. 체크 집합의 접근성 요구사항도 ACT 규칙에 부분적으로 일치하는 체크의 모든 접근성 요구사항 목록으로 정의됩니다.

4.15. 감사의 글(선택 사항)

ACT 규칙에는 감사의 글을 선택적으로 포함할 수 있습니다. 여기에는 다음과 같은 내용이 포함될 수 있습니다(이에 국한되지 않음):

• 규칙 작성자 목록

• 규칙 리뷰어/기여자 목록

• 후원 또는 기타 지원

5. 규칙 정확성

이 섹션은 비규범적입니다.

예시를 활용하여 ACT 규칙이 올바르게 구현됐는지 판단할 수 있지만, 이로 구현물이 항상 정확하다는 보장은 없습니다. ACT 규칙을 작성할 때는 경계 상황(edge case)이 누락되는 일이 거의 불가피합니다. 기술은 계속 진화하고, 콘텐츠 작성자는 예측하지 못한 방법으로 기술을 사용할 수 있습니다. 정확성이 떨어질 수 있는 원인 예시는 다음과 같습니다:

• 가정이 테스트 대상에 대해 틀렸음이 밝혀진 경우

• 기술이 평소와 다르게, 예측하기 어려운 방식으로 사용된 경우

• 기술이 변경되었거나, 어떤 요소가 간과된 경우

• 접근성 요구사항을 잘못 해석한 경우

부정확성에는 두 가지 유형이 있어 잘못된 결과가 나올 수 있습니다. 구현에서의 부정확성은 예시만으로 해결할 수 있지만, ACT 규칙 자체에서의 부정확성은 예시만으로 해결할 수 없습니다. 결국 규칙의 부정확성은 규칙 작성자가 특정한 경계 상황을 인지하지 못한 데서 비롯됩니다.

테스트 결과가 접근성 요구사항의 비적합을 잘못 표시하면 이것은 false positive(오탐)라고 하며, 반대로 규칙이 적합함을 잘못 표시하는 경우는 false negative(미탐)입니다. 오탐 및 미탐의 비율은 실제 접근성 감사(audit) 결과와 비교하여 다음과 같이 산출할 수 있습니다:

• 오탐(False positive): 규칙이 failed로 표시한 테스트 대상 중 실제로 접근성 요구사항을 만족하는 비율

• 미탐(False negative): 규칙이 passed로 표시한 테스트 대상 중 실제로 접근성 요구사항을 만족하지 않는 비율

ACT 규칙 활용 시 오탐 및 미탐의 가능성은 항상 존재하므로 지속적인 유지보수가 필요할 수 있습니다. ACT 규칙 유지 과정 설계는 ACT 규칙 형식의 범주에 포함되지 않습니다. 하지만, 규칙 작성자가 자체적인 유지 관리를 위한 과정을 마련할 것을 권장합니다.

6. 조화(정합)

이 섹션은 비규범적입니다.

ACT 규칙 형식은 조화를 촉진하도록 설계되었지만, 기존 ACT 규칙과 불일치하는 규칙 작성을 직접적으로 막는 요구사항은 없습니다. 또 ACT 규칙이 반드시 특정수의 구현을 가져야 하거나 일정 수준의 정확도를 확보해야 한다는 요구사항도 없습니다. 따라서 품질 요건은 각 규칙 집합마다 상이할 수 있고, 시간이 지나면서 발전할 수 있습니다.

조화란 여러 규칙 구현자가 어떤 ACT 규칙의 유효성을 집단적으로 인정할 때 발생합니다. 예를 들어, 접근성 테스트 도구 벤더의 커뮤니티 그룹이 특정 ACT 규칙 집합에 대해 조화를 선언할 수 있습니다. 이런 그룹은 규칙의 승인 기준을 설정하고, ACT 규칙 형식보다 높은 품질 요건을 가질 수도 있습니다.

이런 과정 예시는 WCAG ACT 검토 프로세스에도 나와 있습니다.

7. 개인정보 보호 고려사항

이 명세는 웹 콘텐츠 접근성 지침 적합성 테스트(ACT) 규칙을 통해 콘텐츠의 적합성을 시험합니다. 이 명세는 사용자 정보를 접근하거나 사용자 에이전트 또는 지원 기술에 직접 사용자 정보를 노출하는 것을 목적으로 하지 않습니다.

8. 보안 고려사항

이 명세는 프로토콜, 도메인, 포트가 브라우저 및 운영체제 등 기반 플랫폼과 직접 통신하는 수단을 제공하지 않으며, 기기 센서 접근도 허용하지 않습니다. 명세는 스크립트 실행/로딩의 새로운 수단을 제공하지 않습니다. 본 그룹은 추가적인 보안 고려사항을 인지하지 못했습니다.

9. 정의

접근성 요구사항

접근성 요구사항이란 장애인들이 ICT 제품에 접근하도록 돕기 위한 요건입니다. ACT 규칙 매핑 맥락에서는 필수 또는 권고일 수 있습니다. 필수 요건이면 표준 준수나 계약, 정책, 법규 준수에 반드시 만족해야 하며, 권고인 경우 만족하지 않아도 비적합이나 불이행이 되지 않습니다.

접근성 요구사항의 대표적 예는 WCAG 성공 기준입니다. 그 외에도 W3C 표준을 포함한 다양한 표준에서 WAI-ARIA, HTML 등 접근성을 위한 권고가 있습니다. 회사 정책, 지역 표준, 법률에도 접근성 요구사항이 포함될 수 있습니다.

접근성 요구 문서

접근성 요구사항이 포함된 문서(표준, 계약, 정책, 법규 등). 예: WCAG 2.2, WAI-ARIA 1.2, HTML 5.2, EPUB Accessibility 1.0, BBC HTML 접근성 표준 v2.0 등

체크

웹페이지 또는 기타 테스트 대상의 접근성을 평가할 때 한 개 이상 결과를 산출하는 절차. 절차는 수동 테스트 방법의 단계별 설명, 완전 자동 테스트, 또는 수동+자동 혼합 방식일 수 있습니다.

구현

체크 집합이 포함되어 접근성 요구사항의 (비)적합 여부를 판정할 수 있는 접근성 테스트 방법론 또는 테스트 도구입니다.

결과

ACT 규칙을 테스트 대상이나 테스트 대상 내 테스트 타겟에 대해 평가한 결론을 말합니다. 결과에는 다음 5가지 유형이 있습니다:

• inapplicable: 테스트 대상의 어떤 부분도 적용성 요건에 해당하지 않을 때
• passed: 테스트 타겟이 모든 기대사항을 만족할 때
• failed: 테스트 타겟이 모든 기대사항을 만족하지 못할 때
• cantTell: 해당 규칙이 적용되는지, 기대사항이 모두 만족됐는지 평가자가 완전히 판단할 수 없는 경우
• untested: 규칙에 대해 테스트 대상이 평가되지 않은 경우

참고: 규칙은 각 테스트 타겟마다 하나의 passed 또는 failed 결과를 가집니다. 평가자가 테스트 타겟을 평가할 때, 기대사항을 수동으로 평가해야 할 경우 cantTell로 보고될 수 있습니다.

테스트 타겟이 없는 경우 그 규칙은 하나의 inapplicable 결과를 가집니다. 평가자가 테스트 타겟의 존재 여부를 판단할 수 없는 경우 하나의 cantTell 결과가 생깁니다. 평가가 없었으면 테스트 타겟에 untested 결과가 남습니다. 즉, 각 테스트 대상에 항상 하나 이상의 결과가 있습니다.

ACT 규칙의 결과는 EARL의 outcome 속성을 써 표현할 수 있습니다. [EARL10-Schema]

테스트 대상

ACT 규칙으로 평가할 수 있는 자원 또는 자원 집합

참고: [EARL10-Schema] 활용 구현자는 subject 속성으로 테스트 대상을 명시할 수 있습니다.

테스트 타겟

테스트 대상 내에서 적용성에 의해 정의되는 개별 부분.

참고: [EARL10-Schema] 활용 구현자는 pointer 속성으로 테스트 타겟을 명시할 수 있습니다.

부록 1: ACT 규칙 결과를 JSON-LD와 EARL로 표현하기

이 섹션은 비규범적입니다.

이 섹션에서는 EARL 및 JSON-LD를 활용해 ACT 규칙 결과를 표현하는 예시를 보여줍니다. 자세한 내용은 Evaluation and Report Language 및 A JSON-based Serialization for Linked Data (JSON-LD)를 참고하세요. 더 많은 예시와 배경 내용은 EARL의 JSON-LD serialization GitHub 저장소에 있습니다.

이 섹션의 예시:

• 하나의 단언(assertion)에서 나온 최소 결과

• 둘 이상의 단언에서 나온 결과

• 요구사항 기준으로 집계한 결과

• 테스트 대상 기준으로 집계한 결과

• 이 섹션의 가정된 컨텍스트

부록 2: 감사의 글

이 섹션은 비규범적입니다.

본 문서의 개발에 기여한 AG WG 참가자

Shadi Abou-Zahra, Trevor Bostic, Helen Burge, Tom Brunet, Romain Deltour, Catherine Droege, Kathy Eng, Wilco Fiers, Alistair Garrison, Kasper Isager, Shunguo Yan, Todd Libby, Chris Loiselle, Sage Keriazes, Maureen Kraft, Daniel Montalvo, Mary Jo Mueller, Jey Nandakumar, Charu Pandhi, Stein Erik Skotkjerra, Suji Sreerama, Anne Thyme Nørregaard, and Kathleen Wahlbin.

지원 기관

이 간행물은 WAI-Tools Project의 지원을 받아 개발되었으며, Horizon 2020 프로그램(보조금 계약 780057)에 따라 유럽위원회(EC)의 공동 자금 지원을 받았습니다. 이 간행물의 내용은 반드시 유럽위원회(EC) 또는 어떤 유럽 연합(EU) 회원국의 견해나 정책을 반영하는 것은 아닙니다.

부록 3: 변경 이력

이 섹션은 비규범적입니다.

ACT 규칙 형식 1.1 최초 공개 작업 초안 이후 변경점

• 2 적용 범위 ACT 규칙 형식 1.1이 1.0과 완전히 하위 호환되지 않음을 명확히 함
• 4.9 예시 입력 규칙의 테스트 사례는 적합성 요구사항과 일치해야 함을 명확히 함
• 모든 테스트 케이스가 예시로 이름 변경됨
• 모든 예시는 이제 Bikeshed의 자동 번호 매기기만 따름
• 부록 1: ACT 규칙 결과를 JSON-LD 및 EARL로 표현하기 이 섹션의 예시들이 올바르게 렌더링되도록 마크업 추가
• 4.2 규칙 설명 텍스트에 언어 및 문단 방향을 지정하는 메타데이터가 있다는 가정 추가
• 4. ACT 규칙 구조 ACT 규칙이 현지화 가능하다는 점 강화
• 4.1 규칙 식별자 규칙 식별자가 고유한지 결정하는 방법에 대한 설명 보강
• 4.4.1.2 부차적 요구사항 부차적 요구사항 설명이 더 이상 배경 섹션에 필수로 요구되지 않음.
• 9 정의 cantTell 및 Untested 정의 업데이트.
• 4.12 용어집 내부 및 외부 용어집 허용
• 7 개인정보 보호 고려사항 추가
• 8 보안 고려사항 추가

ACT 규칙 형식 1.0 이후 변경점

• 4 규칙 구조 접근성 지원 및 가정 섹션이 이제 배경의 하위 섹션이 됨.
• 4.4 접근성 요구사항 매핑 접근성 요구사항이 적합성 요구사항 또는 부차적 요구사항으로 분류됨.
• 4.6 적용성 주관적 적용성 진술이 허용됨. 객관적이고 평이한 언어 요구사항은 must에서 should로 완화됨.
• 4.8 배경 새로운 선택적 관련 규칙 및 기타 자료 하위 섹션 추가
• 4.10 변경 로그 변경 로그가 규칙 버전으로 이름 변경
• 4.11 ACT 규칙 형식 버전 ACT 규칙 형식 버전 호환성을 식별하는 새 요구사항
• 4.14 구현 새 섹션 추가, ACT 규칙과의 일관성을 판정하는 방법 포함
• 7 정의 결과 정의가 cantTell 및 untested를 포함하도록 업데이트됨
• 전체 W3C 명세에 대한 링크가 최신 권고안으로 업데이트됨

이전에 게시된 버전과의 모든 변경 사항은 편집자 초안과 규칙 형식 1.0 권고안의 차이 링크를 통해 확인할 수 있습니다