들어가며

Atomic Tests vs. Holistic Tests: 새로운 테스트 방법론에서는 Atomic/Holistic 테스트의 균형을 이야기했습니다. 이제 그 결과를 어떤 방식으로 ‘주장’하고 ‘기록’할 것인지가 남습니다. 이 역할을 맡는 것이 바로 Assertions입니다.

WCAG 3.0 적합성 모델: A/AA/AAA 이후의 변화에서 다룬 점수/적합성 모델도 Assertions와 연결됩니다. 정량 테스트로 커버하지 못하는 영역을 조직의 절차와 근거로 보완하는 방식이기 때문이에요.

중요: 이 글은 WCAG 3.0 Editor’s Draft(2026-01-05)를 바탕으로 작성되었습니다. Draft는 언제든 변경될 수 있으며, 현재 문서 자체도 Draft가 변경되면 수정될 수 있습니다.

WCAG 3.0 Assertions를 상징하는 썸네일 이미지 - 문서화된 접근성 절차와 책임을 시각화
WCAG 3.0 Assertions를 상징하는 썸네일 이미지 - 문서화된 접근성 절차와 책임을 시각화
이미지: Nanobanana AI로 생성

Assertions란 무엇인가

WCAG 3.0 Explainer는 Assertion을 접근성 향상을 위해 수행한 절차를 책임 주체가 문서화하여 사실로 진술하는 것으로 설명합니다.

즉, 테스트 결과 그 자체가 아니라, 조직이 수행한 접근성 절차에 대한 선언이에요. 예를 들어, 다음과 같은 항목이 Assertion이 될 수 있습니다.

  • 접근성 교육을 정기적으로 시행했다
  • 사용자 테스트(보조기기 포함)를 수행하고 결과를 반영했다
  • 접근성 검토를 위한 스타일 가이드를 운영하고 있다

Assertions는 Foundational Requirements를 대체할 수 없습니다. 즉, 핵심 요구사항을 충족하지 않고 Assertion만으로 적합성을 주장할 수는 없어요.

접근성 절차를 기록하고 문서화하는 과정이 중요해졌습니다.
접근성 절차를 기록하고 문서화하는 과정이 중요해졌습니다.
사진: Unsplash의 Gianluca Cinnante

WCAG 2.2와의 차이

WCAG 2.2에는 Assertions 개념이 없습니다. 대신 **Conformance Claim(적합성 선언)**에 필요한 정보를 명시하도록 되어 있죠.

  • 적합성 수준(Level A/AA/AAA)
  • 표준 버전
  • 범위(페이지/URL 목록)
  • 선언 날짜

WCAG 3.0의 Assertions는 이보다 한 단계 더 나아가 조직의 절차 자체를 적합성에 포함시키려는 시도입니다. 즉 “우리가 어떤 방식으로 접근성을 유지하는가”까지 평가 범위에 넣는 셈이죠.

Assertions는 왜 필요한가

Atomic 테스트와 자동화 도구만으로는 설명하기 어려운 영역이 있습니다.

  • 사용자 테스트를 했는가?
  • 실제 보조기기 환경에서 문제를 확인했는가?
  • 콘텐츠 제작 단계에서 접근성 검토가 이루어지는가?

이런 영역은 독립된 테스트로 검증하기 어렵지만, 사용성에는 큰 영향을 줍니다. WCAG 3.0은 이 부분을 Assertions로 드러내자는 방향입니다.

즉, Assertions는 “검사 결과”가 아니라 “조직의 책임과 절차”를 기록하는 장치에 가깝습니다.

테스트 결과와 조직 절차가 연결되는 흐름을 보여주는 다이어그램 - Assertions의 역할
테스트 결과와 조직 절차가 연결되는 흐름을 보여주는 다이어그램 - Assertions의 역할
이미지: Nanobanana AI로 생성

Assertions 문서화 요구사항

Draft 문서는 Assertion을 사용할 때 문서화 항목을 요구합니다. 대표 항목은 다음과 같습니다.

  1. 주장하는 내용(무엇을 했는지)
  2. Assertion 날짜
  3. 절차 수행 기간
  4. 적용 범위(어떤 제품/서비스/프로세스에 해당하는지)
  5. 책임 조직 또는 담당자 정보
  6. 어떤 Outcome/Guideline을 지원하는지

여기서 중요한 점은, Assertion은 True/False로 판단된다는 것입니다. 즉, “문서화가 제대로 되었는가?”가 최소 기준이 됩니다.

추가 자료(증빙 문서)는 권장되지만, Draft는 이를 필수 요구사항으로 두지 않습니다.

Assertions 문서화에 필요한 항목들을 판단해야 합니다.
Assertions 문서화에 필요한 항목들을 판단해야 합니다.
사진: Unsplash의 Zulfugar Karimov

Assertions 예시 (초안)

다음은 Draft의 취지를 반영한 예시입니다.

Assertion A: 접근성 테스트 절차

  • 내용: “2025년 12월~2026년 1월 동안 스크린 리더 사용자 테스트를 6회 진행했고, 모든 발견 사항을 반영했다.”
  • 범위: 회원가입/결제 프로세스
  • 담당: 접근성 팀 / QA 팀
  • 지원 대상: 관련 Outcomes 및 테스트 절차

Assertion B: 콘텐츠 스타일 가이드

  • 내용: “사내 콘텐츠 스타일 가이드에 대체 텍스트 작성 규칙을 포함하고 있으며, 모든 편집자는 해당 가이드를 따른다.”
  • 범위: 블로그 및 마케팅 페이지
  • 담당: 콘텐츠 팀

이런 Assertion은 점수 모델에서 보조 증거로 활용될 수 있습니다.

팀이 함께 논의하고 책임 주체를 명확히 하는 것이 중요합니다.
팀이 함께 논의하고 책임 주체를 명확히 하는 것이 중요합니다.
사진: Unsplash의 Vitaly Gariev

실무 적용 전략

Assertions는 문서화 품질이 핵심입니다. 다음 방식으로 접근하면 안정적이에요.

  1. 접근성 프로세스 문서화부터 시작
    • 교육, 리뷰, 테스트 절차 정리
  2. 주장 가능한 범위를 좁게 설정
    • 전체 사이트가 아니라 특정 프로세스부터
  3. 책임 주체를 명확히 기록
    • 담당 조직과 연락처를 분명히
  4. 정량 테스트 결과와 연결
    • Assertions가 “빈 말"로 보이지 않도록
Assertions 실무 적용을 위해 단계별 접근하는게 안정적이죠. 화이트보드 같은 공동의 캔버스에서 함께 적용하고 설계하면 좋을 것 같습니다.
Assertions 실무 적용을 위해 단계별 접근하는게 안정적이죠. 화이트보드 같은 공동의 캔버스에서 함께 적용하고 설계하면 좋을 것 같습니다.
사진: Unsplash의 Vitaly Gariev

정리하며

WCAG 3.0의 Assertions는 접근성 ‘성과’가 아니라 ‘프로세스’까지 평가에 포함하려는 시도입니다. 이는 좋은 방향이지만, 동시에 문서화와 책임성을 요구합니다.

다음 글에서는 Assertions가 점수 모델에서 어떤 역할을 하며, Foundational/Supplemental Requirements와 어떻게 결합되는지를 더 구체적으로 살펴보겠습니다.

참조 자료

주의 사항: 이 글은 2026-01-05 WCAG 3.0 Editor’s Draft를 기준으로 작성되었습니다. WCAG 3.0은 아직 개발 중이며, 최종 권고안 이전까지 내용이 변경될 수 있습니다. 특히 적합성 모델은 확정되지 않았으므로 최신 W3C 문서를 확인하시기 바랍니다.