들어가며

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

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

기준 문서: 이 글은 2026년 3월 3일 W3C Working Draft를 바탕으로 합니다. 초안은 대체로 6개월 주기로 갱신되니 읽는 시점에 따라 세부가 달라질 수 있습니다.

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

Assertions란 무엇인가

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

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

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

Assertions는 Core Requirements를 대체할 수 없습니다. 즉, 핵심 요구사항을 충족하지 않고 Assertion만으로 적합성을 주장할 수는 없어요. (2026년 3월 초안에서 Foundational이 Core로 이름이 바뀌었습니다.)

접근성 절차를 기록하고 문서화하는 과정이 중요해졌습니다.
접근성 절차를 기록하고 문서화하는 과정이 중요해졌습니다.
사진: 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

한 장 요약

  • Assertion은 테스트 결과가 아니라 조직이 수행한 접근성 절차를 문서화해 “사실로 진술"하는 것입니다.
  • Assertions는 Core Requirements를 대체할 수 없습니다 — 핵심 요구사항 미충족 상태에서 Assertion만으로 적합성을 주장할 수 없어요.
  • WCAG 2.2에는 이 개념이 없습니다. 2.2는 적합성 수준·표준 버전·범위·날짜를 담는 Conformance Claim까지만 요구합니다.
  • 문서화 항목은 주장 내용·날짜·수행 기간·적용 범위·책임 조직·지원 Outcome 6가지이고, Assertion 자체는 True/False로 판정됩니다(증빙 문서는 권장 사항).
  • 2026년 3월 초안 기준 Assertions는 28개로, 등급을 가를 때 Supplemental과 함께 “얼마나 충족했는지"의 대상이 됩니다.
  • 실무에서는 좁은 범위(전체 사이트가 아니라 특정 프로세스)부터 문서화하고, 책임 주체를 명확히 하며, 정량 테스트 결과와 연결하는 전략이 안정적입니다.

정리하며

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

3월 초안 기준으로 Assertions는 28개로 늘었고, 등급을 가를 때 Supplemental과 함께 “얼마나 충족했는지"의 대상이 됩니다. 자세한 구조는 적합성 모델 편에 정리해뒀습니다.

이 시리즈의 다른 글

참고 자료

주의: 이 글은 2026년 3월 3일 W3C Working Draft 기준입니다. WCAG 3은 아직 개발 중이라 최종 권고안까지 내용이 바뀔 수 있고, 특히 적합성 모델은 초안 안에서도 성숙도가 가장 낮은 단계입니다. 실제 판단이 필요할 땐 W3C 원문을 확인하세요.