# Assertions: 접근성 평가의 새로운 단위

> WCAG 3.0의 Assertions 개념을 WCAG 2.2와 비교하며 설명합니다. 접근성 절차 문서화의 새로운 기준과 실무 적용 전략을 알아봅니다.

**Published:** 2026-02-01 | **Updated:** 2026-02-01

---


## 들어가며

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

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

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

{{< img src="images/contents/og_bg_thumb.png" alt="WCAG 3.0 Assertions를 상징하는 썸네일 이미지 - 문서화된 접근성 절차와 책임을 시각화" caption="이미지: Nanobanana AI로 생성" >}}

---

## Assertions란 무엇인가

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

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

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

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

{{< img src="images/contents/accessibility-process-log.jpg" alt="접근성 절차를 기록하고 문서화하는 과정이 중요해졌습니다." caption="사진: <a href='https://unsplash.com/ko/사진/서로-위에-놓인-서랍-더미-brOOz19UzQg' target='_blank' title='새 창에서 열림'>Unsplash</a>의 <a href='https://unsplash.com/ko/@gluca' target='_blank' title='새 창에서 열림'>Gianluca Cinnante</a>" >}}

---

## 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는 **“검사 결과”가 아니라 “조직의 책임과 절차”를 기록하는 장치**에 가깝습니다.

{{< img src="images/contents/assertions-flow.png" alt="테스트 결과와 조직 절차가 연결되는 흐름을 보여주는 다이어그램 - Assertions의 역할" caption="이미지: Nanobanana AI로 생성" >}}

---

## Assertions 문서화 요구사항

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

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

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

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

{{< img src="images/contents/documentation-requirements.jpg" alt="Assertions 문서화에 필요한 항목들을 판단해야 합니다." caption="사진: <a href='https://unsplash.com/ko/사진/펜으로-클립보드에-글을-쓰는-손-IPeGLFSyhzg' target='_blank' title='새 창에서 열림'>Unsplash</a>의 <a href='https://unsplash.com/ko/@zulfugarkarimov' target='_blank' title='새 창에서 열림'>Zulfugar Karimov</a>" >}}

---

## Assertions 예시 (초안)

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

**Assertion A: 접근성 테스트 절차**

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

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

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

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

{{< img src="images/contents/team-accountability.jpg" alt="팀이 함께 논의하고 책임 주체를 명확히 하는 것이 중요합니다." caption="사진: <a href='https://unsplash.com/ko/사진/다양한-팀이-사무실-테이블을-둘러싸고-협업합니다-fm4B1xWEIsU' target='_blank' title='새 창에서 열림'>Unsplash</a>의 <a href='https://unsplash.com/ko/@silverkblack' target='_blank' title='새 창에서 열림'>Vitaly Gariev</a>" >}}

---

## 실무 적용 전략

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

1. **접근성 프로세스 문서화부터 시작**
   - 교육, 리뷰, 테스트 절차 정리
2. **주장 가능한 범위를 좁게 설정**
   - 전체 사이트가 아니라 특정 프로세스부터
3. **책임 주체를 명확히 기록**
   - 담당 조직과 연락처를 분명히
4. **정량 테스트 결과와 연결**
   - Assertions가 "빈 말"로 보이지 않도록

{{< img src="images/contents/process-strategy.jpg" alt="Assertions 실무 적용을 위해 단계별 접근하는게 안정적이죠. 화이트보드 같은 공동의 캔버스에서 함께 적용하고 설계하면 좋을 것 같습니다." caption="사진: <a href='https://unsplash.com/ko/사진/유리벽에-스티커-메모를-붙인-팀-브레인스토밍-UtIr_UaiDmg' target='_blank' title='새 창에서 열림'>Unsplash</a>의 <a href='https://unsplash.com/ko/@silverkblack' target='_blank' title='새 창에서 열림'>Vitaly Gariev</a>" >}}

---

## 정리하며

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

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

---


---

## 이 시리즈의 다른 글

- [WCAG 3.0 시대의 시작: 왜 새로운 가이드라인이 필요한가?]({{< relref "/posts/wcag-3-era-why-new-guidelines" >}})
- [WCAG 3.0 구조 해부: Success Criteria에서 Outcomes로]({{< relref "/posts/wcag-3-structure-outcomes" >}})
- [WCAG 3.0 적합성 모델: A/AA/AAA 이후의 변화]({{< relref "/posts/wcag-3-scoring-conformance" >}})
- [Atomic Tests vs. Holistic Tests: 새로운 테스트 방법론]({{< relref "/posts/wcag-3-atomic-holistic-tests" >}})
- [WCAG 3.0 확장된 적용 범위: 웹을 넘어서]({{< relref "/posts/wcag-3-expanded-scope-beyond-web" >}})

## 참조 자료

- [WCAG 3.0 Editor's Draft](https://w3c.github.io/wcag3/guidelines/) - W3C 공식 문서
- [WCAG 3.0 Assertions](https://www.w3.org/TR/wcag-3.0-explainer/#assertions) - WCAG 3.0 Assertions
- [WCAG 2.2](https://www.w3.org/TR/WCAG22/) - 현재 권고안
- [Understanding Conformance](https://www.w3.org/WAI/WCAG22/Understanding/conformance) - WCAG 2.2 적합성 이해

---

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