WCAG 3.0 구조 해부: Success Criteria에서 Outcomes로

들어가며

“1.3.1 정보와 관계(Info and Relationships) - Level A”

WCAG 2.2를 다뤄본 분이라면 이런 형식의 성공 기준(Success Criteria)에 익숙하실 겁니다. 번호가 있고, 레벨이 있고, 명확한 테스트 조건이 있죠. 이 구조는 15년 넘게 웹 접근성의 표준이었습니다.

하지만 지난 글에서 살펴봤듯이, 이 방식에는 한계가 있었어요. “체크박스는 통과했지만 실제로는 사용할 수 없는” 웹사이트들이 그 증거입니다.

WCAG 3.0은 이 문제를 해결하기 위해 구조 자체를 완전히 재설계했습니다. 단순히 항목을 추가한 게 아니라, 접근성을 평가하는 방식 자체를 바꾼 거죠.

이번 글에서는 WCAG 3.0의 새로운 구조를 깊이 파헤쳐 보겠습니다. 실무자의 관점에서, 실제로 어떻게 적용할 수 있는지 구체적으로 알아볼게요.

WCAG 2.2의 구조: 익숙한 계층

새로운 구조를 이해하기 전에, 먼저 우리가 익숙한 WCAG 2.2의 구조를 되짚어 볼게요.

4-13-86의 공식

WCAG 2.2는 다음과 같은 계층 구조를 가지고 있습니다:

4개의 원칙(Principles) - POUR

• Perceivable (인식 가능)
• Operable (운용 가능)
• Understandable (이해 가능)
• Robust (견고함)

13개의 가이드라인(Guidelines)

• 예: “텍스트 대체물 제공”, “시간 기반 미디어 대체물 제공” 등

86개의 성공 기준(Success Criteria)

• WCAG 2.1의 78개에서 WCAG 2.2로 8개 추가
• 각 기준은 A, AA, AAA 레벨로 분류됨
• 명확하게 테스트 가능한 조건으로 작성됨

실무에서는 주로 이렇게 참조합니다:

1.1.1 Non-text Content (Level A)
1.3.1 Info and Relationships (Level A)
2.4.7 Focus Visible (Level AA)

명확함의 장점과 한계

이 구조의 가장 큰 장점은 명확성입니다. 각 성공 기준은:

• 객관적으로 테스트 가능
• 합격/불합격을 명확히 판단 가능
• 법적 요구사항으로 사용하기 적합

하지만 이 명확성이 오히려 함정이 되었어요. “대체 텍스트가 존재하는가?“는 쉽게 판단할 수 있지만, “대체 텍스트가 유용한가?“는 판단하기 어렵죠.

WCAG 3.0의 새로운 구조: 사용자 중심으로

WCAG 3.0은 완전히 다른 접근 방식을 취합니다. “무엇을 준수해야 하는가"에서 “사용자가 무엇을 달성할 수 있어야 하는가"로 초점을 이동한 거죠.

Guidelines → Outcomes → Methods

새로운 3단계 구조를 살펴볼게요:

1단계: Guidelines (가이드라인)

• WCAG 2.x와 비슷하지만, 더 넓은 개념
• 사용자 니즈 중심으로 재구성
• 예: “Clear Words”, “Flexible Target Sizes”

2단계: Outcomes (결과)

• 이것이 핵심입니다!
• 사용자가 달성해야 하는 실제 결과를 기술
• 174개의 Outcomes가 정의됨 (2025년 9월 기준)
• “어떻게"가 아닌 “무엇을” 달성해야 하는지 명시

3단계: Methods (방법)

• Outcome을 달성하기 위한 구체적 방법
• 여러 방법 중 선택 가능
• 기술과 상황에 맞게 유연하게 적용

Outcomes: 새로운 평가의 중심

Outcomes는 WCAG 3.0의 가장 혁신적인 개념입니다. 기존의 성공 기준과 어떻게 다른지 실제 예제로 비교해볼게요.

WCAG 2.2 방식:

1.1.1 Non-text Content (Level A)
"모든 비텍스트 콘텐츠는 대체 텍스트를 제공해야 함"

✅ 테스트: <img> 태그에 alt 속성이 있는가?

• 있음 → 통과
• 없음 → 실패

WCAG 3.0 방식:

Outcome: Text alternatives for images
"사용자가 이미지의 목적과 내용을 이해할 수 있어야 함"

✅ 평가:

1. 대체 텍스트가 이미지의 목적을 전달하는가?
2. 맥락에 적절한 정보를 제공하는가?
3. 사용자가 실제로 이해할 수 있는가?

차이가 보이시나요? WCAG 3.0은 **“있다/없다"에서 “효과적이다/아니다”**로 평가 기준이 바뀐 겁니다.

실전 예제: 로그인 폼으로 비교하기

이론적인 설명보다는 실제 예제를 보는 게 이해가 빠르죠. 간단한 로그인 폼을 WCAG 2.2와 3.0 방식으로 각각 평가해볼게요.

예제: 기본 로그인 폼

<form>
  <div>
    <label for="username">사용자명</label>
    <input type="text" id="username" name="username">
  </div>
  <div>
    <label for="password">비밀번호</label>
    <input type="password" id="password" name="password">
  </div>
  <button type="submit">로그인</button>
</form>

WCAG 2.2 평가 방식

체크리스트 접근:

✅ 1.3.1 Info and Relationships (A)

• <label>과 <input>이 for/id로 연결됨
• 판정: 통과

✅ 3.3.2 Labels or Instructions (A)

• 모든 입력 필드에 레이블 있음
• 판정: 통과

✅ 4.1.2 Name, Role, Value (A)

• 적절한 HTML 요소 사용
• 판정: 통과

결론: WCAG 2.2 AA 완전 준수 ✅

WCAG 3.0 평가 방식

Outcomes 기반 접근:

Outcome 1: “사용자가 각 입력 필드의 목적을 이해할 수 있어야 함”

평가:

• 레이블이 명확한가? ✅
• 필수/선택 여부가 표시되었는가? ❌
• 입력 형식이 설명되었는가? ❌
• 에러 발생 시 명확한 안내가 있는가? ❌

Outcome 2: “사용자가 폼을 성공적으로 완료할 수 있어야 함”

평가:

• 키보드만으로 모든 기능 사용 가능한가? ✅
• 스크린 리더가 폼 구조를 이해하는가? ✅
• 비밀번호 표시/숨김 기능이 있는가? ❌
• 자동완성이 지원되는가? ❌

결론: 기술적으로는 통과하지만, 사용자 경험 측면에서 개선 필요 🟡

개선된 버전: WCAG 3.0 Outcomes 충족

<form aria-labelledby="login-heading">
  <h2 id="login-heading">로그인</h2>

  <div>
    <label for="username">
      사용자명 <span aria-label="필수 입력">*</span>
    </label>
    <input
      type="text"
      id="username"
      name="username"
      autocomplete="username"
      required
      aria-required="true"
      aria-describedby="username-format">
    <p id="username-format" class="input-hint">
      이메일 또는 전화번호를 입력하세요
    </p>
  </div>

  <div>
    <label for="password">
      비밀번호 <span aria-label="필수 입력">*</span>
    </label>
    <div class="password-wrapper">
      <input
        type="password"
        id="password"
        name="password"
        autocomplete="current-password"
        required
        aria-required="true"
        aria-describedby="password-requirement">
      <button
        type="button"
        aria-label="비밀번호 표시"
        aria-pressed="false"
        onclick="togglePassword()">
        👁️
      </button>
    </div>
    <p id="password-requirement" class="input-hint">
      8자 이상, 영문/숫자/특수문자 포함
    </p>
  </div>

  <button type="submit">로그인</button>

  <div role="alert" aria-live="polite" class="error-message" hidden>
    <!-- 에러 메시지가 여기에 표시됨 -->
  </div>
</form>

이 버전은:

• 필수 입력 표시
• 입력 형식 안내
• 비밀번호 표시/숨김 기능
• 자동완성 지원
• 에러 메시지 영역
• 명확한 폼 구조

이제 실제로 사용자가 쉽게 로그인할 수 있는 폼이 되었습니다.

170+개의 Outcomes: 전체 구조 이해하기

WCAG 3.0 Working Draft (2025년 9월 기준)에는 170개 이상의 Outcomes가 정의되어 있습니다. 이 모든 걸 외울 필요는 없지만, 어떻게 구성되어 있는지는 알아두면 좋아요.

주요 카테고리별 Outcomes

1. 텍스트 대체물 (Text Alternatives)

• 이미지, 아이콘, 차트 등의 대체 텍스트
• 오디오/비디오 콘텐츠의 자막 및 대본
• 예: “Text alternatives for images”, “Captions for audio”

2. 입력 및 제어 (Input and Controls)

• 키보드 접근성
• 터치 타겟 크기
• 포커스 관리
• 예: “Keyboard accessible”, “Target size sufficient”

3. 시각적 표시 (Visual Presentation)

• 색상 대비
• 텍스트 크기 조절
• 레이아웃 적응성
• 예: “Contrast sufficient”, “Text resizable”

4. 이해 가능성 (Understandability)

• 명확한 언어
• 일관된 내비게이션
• 에러 예방 및 복구
• 예: “Clear language”, “Consistent navigation”

5. 견고성 (Robustness)

• 보조 기술 호환성
• 구조적 마크업
• 상태 및 속성 정보
• 예: “Compatible with assistive technology”

Outcomes 네이밍 패턴

Outcomes의 이름을 보면 일정한 패턴이 있어요:

패턴 1: [대상] + [동작]

• “Text alternatives provided”
• “Captions included”
• “Labels visible”

패턴 2: [형용사] + [대상]

• “Sufficient contrast”
• “Clear headings”
• “Consistent navigation”

패턴 3: [능력] + [가능성]

• “Keyboard accessible”
• “Pointer cancelable”
• “Content hideable”

이 패턴을 알아두면 새로운 Outcomes를 접했을 때 빠르게 이해할 수 있습니다.

Methods: Outcomes를 달성하는 방법

Outcomes가 “무엇을” 달성해야 하는지 정의한다면, Methods는 “어떻게” 달성할 것인지를 보여줍니다.

Methods의 유연성

WCAG 3.0의 큰 장점은 여러 방법 중 선택할 수 있다는 점입니다.

예를 들어 “Text alternatives for images” Outcome을 달성하기 위한 Methods:

Method 1: HTML alt 속성 사용

<img src="chart.png" alt="2024년 매출 현황: 1분기 120억, 2분기 145억">

Method 2: aria-label 사용

<svg aria-label="원형 차트: 제품 A 40%, 제품 B 35%, 제품 C 25%">
  <!-- SVG 콘텐츠 -->
</svg>

Method 3: 주변 텍스트로 설명

<figure>
  <img src="data-viz.png" alt="">
  <figcaption>
    위 그래프는 지난 5년간 사용자 증가율을 보여줍니다.
    2020년 10만 명에서 시작하여 2024년 현재 250만 명까지 증가했습니다.
  </figcaption>
</figure>

Method 4: 장문 설명 링크

<img src="complex-diagram.png" alt="시스템 아키텍처 다이어그램">
<a href="/diagram-description">상세 설명 보기</a>

어떤 방법을 쓰든, Outcome(“사용자가 이미지 내용을 이해할 수 있다”)만 달성하면 됩니다.

Critical vs. Supplemental Methods

Methods는 두 가지로 분류됩니다:

Critical Methods (필수 방법)

• 반드시 구현해야 하는 핵심 방법
• 이것 없이는 Outcome 달성 불가
• 예: 키보드 접근성을 위한 기본 HTML 요소 사용

Supplemental Methods (보충 방법)

• 추가적인 개선 방법
• 사용자 경험을 더욱 향상
• 예: 추가적인 ARIA 속성, 고급 인터랙션

실무에서는 Critical Methods부터 구현하고, 점진적으로 Supplemental Methods를 추가하는 전략을 추천합니다.

Functional Categories: 새로운 분류 체계

WCAG 3.0은 POUR 원칙을 대체하는 새로운 분류 체계를 도입했습니다. 바로 **Functional Categories(기능별 카테고리)**입니다.

5가지 Functional Categories

1. Perceivable (인식 가능)

• WCAG 2.x의 Perceivable과 유사
• 사용자가 콘텐츠를 인식할 수 있어야 함

2. Operable (운용 가능)

• WCAG 2.x의 Operable과 유사
• 사용자가 인터페이스를 조작할 수 있어야 함

3. Understandable (이해 가능)

• WCAG 2.x의 Understandable과 유사
• 사용자가 정보와 UI 작동을 이해할 수 있어야 함

4. Robust (견고함)

• WCAG 2.x의 Robust와 유사하지만 확장됨
• 다양한 기술과 보조 기술에서 작동해야 함

5. Cognitive Support (인지 지원) - 새로 추가!

• WCAG 3.0의 혁신적인 추가 사항
• 인지 및 학습 장애가 있는 사용자 지원
• 명확한 언어, 단순한 구조, 에러 예방 등

이 새로운 카테고리는 WCAG 2.x에서 상대적으로 소외되었던 인지 접근성에 대한 W3C의 강력한 의지를 보여줍니다.

Tests: 실제로 평가하는 방법

Outcomes와 Methods까지 이해했다면, 이제 중요한 질문이 남았습니다: “어떻게 테스트하나요?”

WCAG 3.0은 두 가지 테스트 방법을 제공합니다.

Atomic Tests: 자동화 가능한 기술적 테스트

특징:

• 명확하고 객관적
• 자동화 도구로 테스트 가능
• 이진 판정 (통과/실패)

예제: 이미지 대체 텍스트 Atomic Test

// 자동화 테스트 예제
function testImageAlternatives() {
  const images = document.querySelectorAll('img');
  const results = [];

  images.forEach(img => {
    const test = {
      element: img,
      passed: false,
      reason: ''
    };

    // Atomic Test 1: alt 속성 존재
    if (!img.hasAttribute('alt')) {
      test.reason = 'alt 속성 없음';
      results.push(test);
      return;
    }

    // Atomic Test 2: 장식 이미지가 아니면 alt 내용 존재
    if (img.getAttribute('alt') === '' && !isDecorative(img)) {
      test.reason = 'alt 속성이 비어있음 (장식 아님)';
      results.push(test);
      return;
    }

    test.passed = true;
    results.push(test);
  });

  return results;
}

Atomic Tests는 WCAG 2.x의 성공 기준과 비슷한 역할을 합니다. 기본적인 기술 준수를 확인하는 거죠.

Holistic Tests: 사용자 경험 중심 평가

특징:

• 실제 사용 맥락 고려
• 사람의 판단 필요
• 점수 기반 평가 (0-4점)

예제: 로그인 폼 Holistic Test

## Holistic Test: 로그인 폼 사용성

### 테스트 시나리오
스크린 리더 사용자가 처음 방문한 사이트에서 로그인을 완료한다.

### 평가 기준

**4점 (Excellent):**
- 폼 구조가 명확하게 전달됨
- 모든 필드의 목적과 형식을 쉽게 이해
- 에러 발생 시 명확한 수정 방법 제시
- 키보드만으로 모든 기능 사용 가능
- 자동완성으로 입력 간소화

**3점 (Good):**
- 폼을 사용할 수 있으나 일부 불편함
- 필드 설명이 다소 모호
- 에러 메시지가 있으나 개선 여지 있음

**2점 (Fair):**
- 기본적인 로그인은 가능
- 여러 번 시도 후 성공
- 도움 없이는 어려움

**1점 (Poor):**
- 로그인 가능하나 매우 어려움
- 외부 도움 필요

**0점 (Failed):**
- 로그인 불가능

Holistic Tests는 WCAG 3.0의 핵심 혁신입니다. 실제 사용자가 작업을 완료할 수 있는지를 평가하는 거죠.

실무 적용: 어디서부터 시작할까?

“좋아요, 구조는 이해했는데… 실제로 어떻게 시작하죠?”

이런 질문이 당연합니다. WCAG 3.0은 아직 Working Draft 단계이고, 공식 권고안이 나오려면 수년이 걸릴 예정입니다(목표: 2025년 말 정도). 하지만 지금부터 준비할 수 있는 일들이 있어요.

1단계: 사고방식 전환하기

가장 먼저 할 일은 평가 방식을 바꾸는 겁니다.

기존 질문:

• “이 체크박스를 통과했나?”
• “alt 속성이 있나?”
• “color contrast가 4.5:1 이상인가?”

새로운 질문:

• “사용자가 이 콘텐츠를 이해할 수 있나?”
• “사용자가 이 작업을 완료할 수 있나?”
• “실제로 사용하기 편한가?”

당장 내일부터 코드 리뷰할 때 이런 질문을 던져보세요. 별도의 도구나 교육 없이도 시작할 수 있습니다.

2단계: Outcomes 기반으로 체크리스트 재작성

기존 WCAG 2.2 체크리스트를 Outcomes 관점으로 재구성해보세요.

Before:

- [ ] 1.1.1 Non-text Content
- [ ] 1.3.1 Info and Relationships
- [ ] 1.4.3 Contrast (Minimum)

After:

- [ ] 모든 이미지의 내용을 사용자가 이해할 수 있다
- [ ] 폼 구조와 관계를 모든 사용자가 인식할 수 있다
- [ ] 텍스트가 배경과 명확히 구분되어 읽을 수 있다

작은 변화같지만, 팀의 관점을 바꾸는 첫걸음입니다.

3단계: 사용자 테스트 도입

Holistic Tests를 실무에 적용하는 가장 좋은 방법은 실제 사용자 테스트입니다.

시작하기 좋은 방법:

1. 장애가 있는 동료 초대하기

   • 회사 내부 또는 지인 네트워크 활용
   • 30분~1시간 테스트 세션
   • “이 기능을 사용할 수 있나요?” 물어보기

2. 보조 기술 직접 사용해보기

   • Windows Narrator, macOS VoiceOver 켜보기
   • 마우스 없이 키보드만으로 1시간 작업하기
   • 화면 확대 150%로 하루 사용하기

3. 다양한 상황 시뮬레이션

   • 밝은 햇빛 아래에서 화면 보기
   • 소음이 많은 카페에서 비디오 시청하기
   • 한 손만 사용 가능한 상황 상상하기

4단계: 점진적으로 문서화하기

팀에 새로운 개념을 도입할 때는 문서화가 중요합니다.

추천 문서 구조:

# [프로젝트명] 접근성 가이드

## 우리의 Outcomes
1. 사용자가 모든 콘텐츠를 인식할 수 있다
2. 사용자가 키보드만으로 모든 작업을 완료할 수 있다
3. 사용자가 에러 없이 폼을 제출할 수 있다
...

## Outcome별 Methods
### Outcome 1: 콘텐츠 인식
- 이미지: alt 속성 또는 aria-label
- 동영상: 자막 제공
- 차트: 텍스트 요약 또는 데이터 테이블

### Outcome 2: 키보드 접근
- 모든 버튼: <button> 요소 사용
- 커스텀 위젯: tabindex 및 키보드 이벤트 구현
...

## 테스트 방법
### Atomic Tests (자동화)
- npm run test:accessibility

### Holistic Tests (수동)
- 분기마다 사용자 테스트 진행
- 체크리스트: [링크]

다음 단계: 점수 시스템 이해하기

WCAG 3.0의 구조를 이해했다면, 이제 다음 질문이 생깁니다:

“A/AA/AAA가 Bronze/Silver/Gold로 바뀐다는데, 구체적으로 어떻게 평가하나요?”

이것이 바로 다음 글의 주제입니다. 시리즈 3편에서는:

• 0-4점 점수 시스템의 상세 설명
• Bronze/Silver/Gold 등급 기준
• WCAG 2.2 AA와 비교
• 실무에서 점수 계산하는 방법

을 다룰 예정입니다.

정리하며

WCAG 3.0의 구조는 처음엔 복잡해 보일 수 있지만, 핵심은 단순합니다:

체크리스트에서 사용자 경험으로

• Guidelines → Outcomes → Methods의 3단계 구조
• 170+ Outcomes가 사용자 니즈를 정의
• 여러 Methods 중 상황에 맞게 선택
• Atomic + Holistic Tests로 종합 평가

이 구조는 더 나은 접근성을 위한 도구입니다. 숫자와 레벨에 갇히지 않고, 실제로 사용자가 웹사이트를 사용할 수 있는지에 집중할 수 있게 해주죠.

WCAG 3.0이 공식 권고안이 되려면 아직 시간이 걸립니다. 하지만 지금부터 이 철학을 실무에 적용하기 시작하면, 그때가 되었을 때 훨씬 수월할 거예요.

다음 편에서는 점수와 등급 시스템을 상세히 파헤쳐 보겠습니다. 실제로 Bronze/Silver/Gold를 어떻게 달성하는지, 구체적인 계산 방법까지 알아볼게요!

참고 자료

• WCAG 3.0 Working Draft (2025년 9월)
• W3C Accessibility Guidelines (WCAG) 3.0 Explainer
• WCAG 3.0 Outcomes List
• Understanding WCAG 3 Methods
• WCAG 2 to WCAG 3 Transition Resources

다음편 예고:

• 점수와 등급: A/AA/AAA에서 Bronze/Silver/Gold로 (다음 편)