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

> WCAG 3.0의 혁신적인 구조 변화를 깊이 파헤칩니다. Guidelines에서 Outcomes로, 체크리스트에서 사용자 경험 중심 평가로의 전환을 실전 예제와 함께 알아보세요.

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

---


## 들어가며

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

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

하지만 [지난 글](/posts/wcag-3-era-why-new-guidelines/)에서 살펴봤듯이, 이 방식에는 한계가 있었어요. "체크박스는 통과했지만 실제로는 사용할 수 없는" 웹사이트들이 그 증거입니다.

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

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

{{< img src="images/contents/wcag-structure-comparison.png" alt="WCAG 2.2와 3.0의 구조 비교 다이어그램. 왼쪽 파란색 박스는 WCAG 2.2 구조로 Principles(POUR 4개) → Guidelines(13개) → Success Criteria(87개) → 3 Levels(A/AA/AAA)의 순차적 계층 구조를 표현. 오른쪽 보라색 박스는 WCAG 3.0 구조로 Guidelines → Outcomes(170+개) → Methods의 네트워크 형태를 보여주며, 하나의 Outcome이 여러 Methods로 연결되어 유연성을 강조" caption="" >}}

## 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)
```

### 명확함의 장점과 한계

이 구조의 가장 큰 장점은 **명확성**입니다. 각 성공 기준은:
- 객관적으로 테스트 가능
- 합격/불합격을 명확히 판단 가능
- 법적 요구사항으로 사용하기 적합

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

{{< img src="images/contents/success-criteria-limitations.jpg" alt="태블릿 화면에 스타일러스 펜으로 체크박스를 표시하는 손의 클로즈업. 여러 개의 체크박스가 있고 일부는 체크되었으며, 한 항목을 체크하려는 순간을 포착. WCAG 2.2의 체크리스트 기반 평가 방식의 한계를 상징적으로 표현" caption="사진: <a href='https://unsplash.com/ko/사진/손이-체크리스트의-항목을-표시합니다-yKnIbJV0RbY' target='_blank' title='새 창에서 열림'>Unsplash</a>의<a href='https://unsplash.com/ko/@jakubzerdzicki' target='_blank' title='새 창에서 열림'>Jakub Żerdzicki</a>" >}}

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

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

### Guidelines → Outcomes → Methods

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

**1단계: Guidelines (가이드라인)**
- WCAG 2.x와 비슷하지만, 더 넓은 개념
- 사용자 니즈 중심으로 재구성
- 예: "Clear Words", "Flexible Target Sizes"

**2단계: Outcomes (결과)**
- 이것이 핵심입니다!
- 사용자가 달성해야 하는 실제 결과를 기술
- 170개 이상의 Outcomes가 정의됨 (2026년 1월 Editor's Draft 기준, 변동 가능)
- "어떻게"가 아닌 "무엇을" 달성해야 하는지 명시

**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은 **"있다/없다"에서 "효과적이다/아니다"**로 평가 기준이 바뀐 겁니다.

{{< img src="images/contents/outcomes-concept-diagram.png" alt="WCAG 3.0 Outcomes 개념 다이어그램. 중앙에 'USER' 아이콘이 있고 주변에 6개의 기능별 카테고리가 배치됨: Sensory(노란색, 발작 예방·모션 축소·타이밍 조절), Vision(보라색, 대체 텍스트·색상 대비·텍스트 크기 조절), Hearing(청록색, 자막·수어·오디오 제어), Motor(주황색, 키보드 접근·터치 타겟 크기·포인터 제스처), Speech(분홍색, 음성 입력 지원·음성 대체 수단·음성 탐색), Cognitive(초록색, 명확한 언어·일관된 탐색·에러 예방). 각 카테고리가 사용자 중심으로 연결되어 사용자 니즈 기반 구조를 표현" caption="" >}}

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

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

### 예제: 기본 로그인 폼

```html
<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: "사용자가 폼을 성공적으로 완료할 수 있어야 함"**

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

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

{{< img src="images/contents/wcag-evaluation-comparison.png" alt="WCAG 2.2와 3.0의 평가 방식 비교 인포그래픽. 왼쪽 WCAG 2.2는 이진 평가(통과/실패 아이콘), Success Criteria(86개 기준), A/AA/AAA 준수 레벨 구조를 표현. 오른쪽 WCAG 3.0은 점수 기반의 다층 평가(0~4점 스케일), Outcomes(170개 이상, 사용자 니즈 기반), Bronze/Silver/Gold 등급 체계를 보여줌. 핵심 차이점: WCAG 2.2는 하나라도 실패하면 해당 레벨 부적합, WCAG 3.0은 Critical Error가 있으면 적합성 차단(점수 0점), 그 외 사소한 이슈는 점수에 반영되지만 적합성을 막지 않을 수 있음" caption="" >}}

### 개선된 버전: WCAG 3.0 Outcomes 충족

```html
<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 Editor's Draft (2026년 1월 기준)에는 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"

{{< img src="images/contents/outcomes-categories-map.png" alt="174개 Outcomes의 기능별 카테고리 분포 다이어그램. 중앙에 '174 Outcomes (Draft)'라는 텍스트와 'Grouped by Functional Categories (conceptual)'라는 부제. 6개의 원형 아이콘이 원형으로 배치됨: Sensory(노란색, 손바닥 위 파동 아이콘), Vision(보라색, 눈 아이콘), Hearing(청록색, 귀 아이콘), Motor(주황색, 손가락 터치 아이콘), Speech(분홍색, 마이크 아이콘), Cognitive(초록색, 뇌와 톱니바퀴 아이콘). 하단에 '분포는 탐색적이며 변경될 수 있음'이라는 주석 표시" caption="" >}}

### 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 속성 사용**
```html
<img src="chart.png" alt="2024년 매출 현황: 1분기 120억, 2분기 145억">
```

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

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

**Method 4: 장문 설명 링크**
```html
<img src="complex-diagram.png" alt="시스템 아키텍처 다이어그램">
<a href="/diagram-description">상세 설명 보기</a>
```

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

{{< img src="images/contents/methods-flexibility.jpg" alt="WCAG 3.0의 Methods 유연성을 상징적으로 표현 - 목적지(Outcome)에 도달하기 위한 여러 경로(Methods) 선택 가능" caption="사진: <a href='https://unsplash.com/ko/사진/신호등의-로우-앵글-사진-hNBBZ5HH0xM' target='_blank' title='새 창에서 열림'>Unsplash</a>의<a href='https://unsplash.com/ko/@tom32i' target='_blank' title='새 창에서 열림'>Thomas Jarrand</a>" >}}

### Foundational vs. Supplemental Requirements

WCAG 3.0은 요구사항을 두 가지로 분류합니다:

**Foundational Requirements (기초 요구사항)**
- Bronze 등급 획득에 **필수**
- WCAG 2.2 AA와 유사한 수준의 기본 접근성
- 모든 Foundational 요구사항을 충족해야 Bronze 획득 가능
- 예: 이미지 대체 텍스트, 키보드 접근성, 기본 색상 대비

**Supplemental Requirements (보충 요구사항)**
- Silver/Gold 등급 획득에 필요
- 기본 수준을 넘어서는 향상된 접근성
- 예: 고급 인지 지원, 추가적인 사용자 맞춤 설정

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

> **참고**: Methods는 특정 Outcome을 달성하기 위한 구체적인 기술 방법을 의미하고, Requirements는 등급 획득을 위한 요구사항 분류입니다. 두 개념은 다른 레벨에서 작동합니다.

## Functional Categories: 사용자 니즈 기반 분류

WCAG 3.0은 POUR 원칙(Perceivable, Operable, Understandable, Robust)과 함께 **Functional Categories(기능별 카테고리)**라는 새로운 분류 체계를 도입했습니다. 이는 기술적 원칙이 아닌 **사용자의 장애 유형과 니즈**를 기준으로 합니다.

### 6가지 Functional Categories

**1. Vision (시각)**
- 시각 장애, 저시력 사용자를 위한 요구사항
- 대체 텍스트, 색상 대비, 텍스트 크기 조절 등

**2. Hearing (청각)**
- 청각 장애, 난청 사용자를 위한 요구사항
- 자막, 수어, 오디오 제어 등

**3. Sensory (감각)**
- 발작 예방, 모션 축소, 타이밍 조절 등
- 감각적 민감성이 있는 사용자 지원

**4. Motor (운동)**
- 운동 장애 사용자를 위한 요구사항
- 키보드 접근성, 터치 타겟 크기, 포인터 제스처 등

**5. Speech (음성)**
- 음성 입력을 사용하는 사용자 지원
- 음성 명령, 음성 대체 수단 등

**6. Cognitive (인지)**
- 인지 및 학습 장애 사용자를 위한 요구사항
- 명확한 언어, 일관된 탐색, 에러 예방 등
- **WCAG 3.0에서 크게 강화된 영역**

### POUR와 Functional Categories의 관계

POUR 원칙은 여전히 유효하지만, Functional Categories는 다른 관점에서 접근합니다:

| POUR | 관점 | Functional Categories | 관점 |
|------|------|----------------------|------|
| Perceivable | 기술적 원칙 | Vision, Hearing, Sensory | 사용자 니즈 |
| Operable | 기술적 원칙 | Motor, Speech | 사용자 니즈 |
| Understandable | 기술적 원칙 | Cognitive | 사용자 니즈 |

이 새로운 분류는 **"이 기술 요구사항을 충족했는가?"**에서 **"이 사용자 그룹이 사용할 수 있는가?"**로 관점을 전환합니다. 특히 Cognitive 카테고리의 강화는 WCAG 2.x에서 상대적으로 소외되었던 **인지 접근성**에 대한 W3C의 강력한 의지를 보여줍니다.

{{< img src="images/contents/functional-categories-diagram.png" alt="WCAG의 진화: 원칙 기반에서 사용자 니즈 기반으로 전환을 보여주는 비교 다이어그램. 왼쪽 원형 차트(WCAG 2.x)는 4개의 POUR 원칙을 동등한 크기로 표현: Perceivable(청록색, 눈 아이콘), Operable(초록색, 마우스 아이콘), Understandable(노란색, 물음표 아이콘), Robust(보라색, 톱니바퀴 아이콘). 오른쪽 원형 차트(WCAG 3.0)는 사용자 중심 재구성: Vision(파란색), Hearing(청록색), Sensory(노란색), Motor(주황색), Speech(분홍색), 그리고 크게 확대된 Cognitive(연두색) 영역. 중앙 화살표는 'Evolution'을 표시하며 인지 및 감각 니즈에 대한 강화된 초점을 나타냄" caption="" >}}

## Tests: 실제로 평가하는 방법

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

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

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

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

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

```javascript
// 자동화 테스트 예제
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**

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

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

### 평가 기준

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

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

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

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

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

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

{{< img src="images/contents/holistic-testing-scenario.jpg" alt="흰색 헤드폰을 착용하고 소파에 편안히 앉아 태블릿을 사용하는 남성. WCAG 3.0의 Holistic Tests가 강조하는 실제 사용자 경험과 자연스러운 사용 맥락을 상징화" caption="사진: <a href='https://unsplash.com/ko/사진/소파에서-태블릿을-사용하여-헤드폰을-착용한-남자-MvuG6uGwC7k' target='_blank' title='새 창에서 열림'>Unsplash</a>의<a href='https://unsplash.com/ko/@silverkblack' target='_blank' title='새 창에서 열림'>Vitaly Gariev</a>" >}}

### Critical Errors: 적합성 차단 조건

WCAG 3.0은 점수 체계와 함께 **Critical Errors(치명적 오류)** 개념을 도입합니다. 이는 점수와 관계없이 적합성을 **즉시 차단**하는 심각한 접근성 장벽입니다.

**Critical Error가 있으면:**
- 해당 Outcome의 점수는 **자동으로 0점** 처리
- 다른 Outcome의 점수가 아무리 높아도 **적합성 불가**
- 사용자가 핵심 작업을 완료할 수 없는 장벽

```
예시:
- 로그인 버튼이 키보드로 접근 불가 → Critical Error
- 결제 과정에서 스크린 리더가 필수 정보를 읽지 못함 → Critical Error
- 주요 네비게이션에 포커스가 갇힘 → Critical Error
```

Critical Errors는 WCAG 2.2의 "하나라도 Fail이면 부적합" 규칙을 **핵심 장벽에만** 적용하는 방식입니다. 경미한 문제는 점수로 반영하되, 치명적인 문제는 즉시 차단합니다.

> **핵심**: 아무리 전체 평균 점수가 높아도 Critical Error가 **하나라도** 있으면 Bronze 등급도 받을 수 없습니다. 따라서 Critical Errors를 먼저 해결하는 것이 우선입니다.

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

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

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

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

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

**기존 질문:**
- "이 체크박스를 통과했나?"
- "alt 속성이 있나?"
- "color contrast가 4.5:1 이상인가?"

**새로운 질문:**
- "사용자가 이 콘텐츠를 이해할 수 있나?"
- "사용자가 이 작업을 완료할 수 있나?"
- "실제로 사용하기 편한가?"

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

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

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

**Before:**
```markdown
- [ ] 1.1.1 Non-text Content
- [ ] 1.3.1 Info and Relationships
- [ ] 1.4.3 Contrast (Minimum)
```

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

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

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

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

**시작하기 좋은 방법:**

1. **장애가 있는 동료 초대하기**
   - 회사 내부 또는 지인 네트워크 활용
   - 30분~1시간 테스트 세션
   - "이 기능을 사용할 수 있나요?" 물어보기

2. **보조 기술 직접 사용해보기**
   - Windows Narrator, macOS VoiceOver 켜보기
   - 마우스 없이 키보드만으로 1시간 작업하기
   - 화면 확대 150%로 하루 사용하기

3. **다양한 상황 시뮬레이션**
   - 밝은 햇빛 아래에서 화면 보기
   - 소음이 많은 카페에서 비디오 시청하기
   - 한 손만 사용 가능한 상황 상상하기

{{< img src="images/contents/diverse-user-testing.jpg" alt="청록색 조명이 있는 사무실에서 여러 모니터 앞에 함께 작업하는 개발 팀. 뒤에서 포착한 장면으로 3명이 협업하며 화면을 집중해서 보고 있음. 다양한 사용자 관점을 고려한 협업적 접근성 테스트와 팀 기반 품질 보증을 표현" caption="사진: <a href='https://unsplash.com/ko/사진/노트북-컴퓨터를-사용하여-책상에-앉아-있는-남자-e7TIvspb-Dg' target='_blank' title='새 창에서 열림'>Unsplash</a>의<a href='https://unsplash.com/ko/@jaypme4' target='_blank' title='새 창에서 열림'>Joao paulo m ramos paulo</a>" >}}

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

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

**추천 문서 구조:**

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

## 우리의 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 Editor's Draft (최신)](https://w3c.github.io/wcag3/guidelines/)
- [WCAG 3.0 Working Draft](https://www.w3.org/TR/wcag-3.0/)
- [WCAG 3.0 Explainer](https://www.w3.org/TR/wcag-3.0-explainer/)
- [WCAG 3 Introduction (W3C WAI)](https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/)
- [W3C Accessibility Guidelines (AG) Working Group](https://www.w3.org/WAI/GL/)

---

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