아티클

WCAG 3.0 해설 2부 WCAG 3.0의 구조: 성공 기준에서 사용자 요구와 결과로

엔비전스 접근성 2026-06-26 12:57:20

안녕하세요.엔비전스입니다.

1부에서는 WCAG 3.0이 아직 작업 초안(Working Draft) 단계이고, WCAG 2가 여전히 실무의 중심이라는 점을 짚었습니다. 그 위에서 WCAG 3가 더 넓은 기술 범위와 다양해진 사용자 요구를 담으려 한다는 큰 방향도 함께 살펴봤습니다.

2부에서는 한 걸음 더 들어갑니다. WCAG 3 문서를 펼쳐 보면 익숙한 '성공 기준' 대신 처음 보는 용어가 줄지어 등장합니다. 기능적 요구(Functional needs), 지침(Guidelines), 핵심 요구사항(Core Requirements), 보충 요구사항(Supplemental Requirements), 사실 기술(Assertions), 방법(Methods), 모범 사례(Best practices)입니다. 이 글은 용어를 하나하나 깊게 해설하기보다, 이들이 어떻게 연결되는지 정리해 문서를 읽을 때 길을 잃지 않게 돕는 데 목적이 있습니다. 다만 구조를 설명하는 부분 자체가 아직 '탐색(Exploratory)' 단계라 이후 변경될 수 있습니다. 그래서 이 글도 지금 논의되는 큰 방향으로 읽어 주시면 좋겠습니다.

WCAG 2의 구조를 먼저 떠올려 봅니다

새 구조를 이해하려면 익숙한 구조에서 시작하는 게 빠릅니다. WCAG 2는 네 단계로 짜여 있습니다. 맨 위에 원칙(Principles)이 있습니다. 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성이라는 네 가지이지요. 그 아래에 지침(Guidelines), 다시 그 아래에 실제 점검 항목인 성공 기준(Success Criteria)이 놓이고, 각 성공 기준에는 A, AA, AAA 등급이 붙습니다.

실무자에게 중요한 것은 결국 성공 기준입니다. 개별 항목을 하나씩 통과 또는 실패로 판정하는 방식이라 명확하고 검증하기 쉽습니다. 1부에서 짚었듯 페이지 단위 점검과도 잘 맞아떨어졌습니다. WCAG 3는 이 뼈대를 통째로 버리지 않습니다. 오히려 출발점을 한 칸 앞으로 옮깁니다. 어떤 항목을 점검하는가보다 사용자가 무엇을 필요로 하는가를 먼저 묻는 쪽으로 말입니다.

WCAG 3는 '사용자 요구'에서 시작합니다

WCAG 3 본문은 각 지침이 장애인의 문서화된 사용자 요구를 다룬다고 설명합니다. 이때의 사용자 요구를 기능적 요구(Functional needs)라고 부릅니다. 기능적 요구는 특정 장애 진단명이 아니라, 사용자가 콘텐츠를 쓰기 위해 실제로 필요로 하는 능력과 조건을 가리킵니다. 소리에만 의존하지 않고 정보를 얻을 수 있어야 한다, 색에만 기대지 않고도 의미를 구분할 수 있어야 한다 같은 진술이 그 예입니다. 진단명 대신 요구에서 출발하면, 시각·청각·인지·운동처럼 서로 다른 장애의 요구가 한자리에서 다뤄지고, 여러 장애가 겹치는 복합 장애 사용자의 상황도 더 자연스럽게 담깁니다.

이 출발점의 차이가 생각보다 큽니다. WCAG 2는 점검 항목에서 시작해 사용자에게 가닿지만, WCAG 3는 사용자 요구에서 시작해 점검 항목으로 내려갑니다. 사용자 요구 위에 놓이는 것이 지침(Guidelines)인데, WCAG 3의 지침은 기술 중립적입니다. 특정 기술을 지목하지 않고 대비·양식·읽기 쉬움처럼 주제별로 사용자 요구를 묶어 다룹니다.

지침은 결과를 말하고, 요구사항이 판단합니다

여기서 1부에서 예고한 용어 변화를 짚어야 합니다. 예전 초안은 지침 아래의 판단 단위를 'Outcomes'라고 불렀고, 그래서 한동안 WCAG 3는 성과(Outcomes) 중심이라는 설명이 많았습니다. 하지만 지난 2026년 3월 3일 갱신본은 이 표현을 다시 다듬었습니다.

이제 지침(Guidelines)은 결과 진술(outcome statement) 형식으로 적습니다. 사용자가 무엇을 할 수 있어야 하는가를 쉬운 말로 밝히는 문장이지요. 관리자나 정책 담당자처럼 기술 세부를 몰라도 개념을 이해해야 하는 사람을 위한 층입니다. 지침은 규범(normative)에 속하지만, 실제 합격 여부를 가르는 잣대는 아닙니다.

실제 판단 단위는 요구사항(Requirements)입니다. 하나의 지침은 여러 요구사항을 가로지릅니다. 요구사항은 개발자와 테스터가 손에 쥐고 점검하는 항목으로, WCAG 2의 성공 기준이 맡던 역할에 가장 가깝습니다. 요구사항은 두 갈래로 나뉩니다. 핵심 요구사항(Core Requirements)은 최소 수준의 적합성을 판단할 때 바탕이 되는 항목입니다. W3C는 핵심 요구사항이 WCAG 2.2의 AA 수준과 똑같지는 않지만 비슷한 범위의 요구를 다룬다고 설명합니다. 보충 요구사항(Supplemental Requirements)은 모든 수준에서 쓸 수 있되, 어떤 항목을 적용할지 테스터나 정책 담당자가 고를 수 있습니다. 더 높은 접근성을 향한 선택지인 셈입니다.

방법, 사실 기술, 모범 사례는 어디에 놓일까요

지침과 요구사항만으로는 실제 구현이 어렵습니다. 그래서 그 아래와 옆에 세 가지가 더 붙습니다.

먼저 방법(Methods)입니다. 모든 요구사항에는 최소 하나의 방법이 연결됩니다. 방법은 요구사항을 충족하는 구체적 기법과 예시, 자료, 테스트를 담습니다. HTML처럼 특정 기술에 맞춘 방법도 있고, 명확한 언어처럼 기술을 가리지 않는 방법도 있습니다. 다만 방법은 참고(informative) 자료입니다. 요구사항과 같은 층위가 아니라, 요구사항을 어떻게 만족시킬지 안내하는 길잡이라고 생각하시면 됩니다.

다음은 사실 기술(Assertions)입니다. 사실 기술은 사람이나 조직이 접근성을 위해 어떤 절차를 실제로 수행했다고 문서로 밝히는 기록입니다. 접근성 교육이나 사용자 테스트, 보조기술 점검을 거쳤다는 기록이 여기에 들어갑니다. 독립된 테스터가 코드만 봐서는 확인하기 어려운 작업을 기록으로 남기는 장치이지요. 한 가지는 분명히 해 두어야 합니다. 사실 기술은 핵심 요구사항 위에 더해지는 것이지, 핵심 요구사항을 대신하는 우회 수단이 아닙니다. 이 점은 3부의 적합성 모델에서 다시 다룹니다.

마지막은 모범 사례(Best practices)입니다. 접근성을 분명히 개선하지만, 객관적으로 시험하기 어렵거나 적용 상황이 또렷하지 않아 요구사항으로 삼기는 힘든 항목입니다. 모범 사례 역시 참고 자료이고, 적합성 판정에는 영향을 주지 않습니다.

이 층위들이 실제로 어떻게 맞물리는지 한 줄기로 따라가 보면 이해가 쉽습니다. 앞서 든 색에만 의존하지 않고 의미를 구분할 수 있어야 한다는 기능적 요구를 예로 들어 보겠습니다. 이 요구는 '단일 감각(Single sense)' 같은 지침으로 묶이고, 그 아래 '색상에만 의존하지 않기' 같은 요구사항으로 구체화됩니다. 그리고 그 요구사항을 HTML 같은 특정 기술에서 어떻게 구현하고 점검할지는 방법이 안내합니다. 사용자 요구에서 시작해 지침, 요구사항, 방법으로 내려오는 한 줄기입니다.

용어가 많아 보여도 한 가지 기준으로 정리됩니다. 규범이냐 참고냐입니다. 지침과 핵심·보충 요구사항, 사실 기술은 규범이라 적합성을 따질 때 직접 작동하고, 방법과 모범 사례는 참고라 도움은 되지만 적합성을 좌우하지는 않습니다. 문서를 읽다 길을 잃을 것 같으면 지금 보는 것이 합격을 가르는 규범인가, 그것을 돕는 참고인가만 물어도 의미가 또렷해집니다.

2부를 마치며

WCAG 3는 WCAG 2의 성공 기준을 새 이름으로 바꾼 문서가 아닙니다. 사용자의 기능적 요구를 먼저 놓고, 그 요구를 지침과 요구사항, 방법, 조직의 실천으로 이어 가려는 구조입니다.

이 변화는 점검표를 넘어 기획서와 개발 명세에도 영향을 줍니다. 접근성 요구를 출시 후 점검할 체크리스트로만 두지 말고, 사용자 요구와 컴포넌트 상태, 입력 방식, 오류 회복 흐름까지 설계 단계에서 함께 정의해 두는 편이 좋습니다.

다음 3부에서는 가장 오해하기 쉬운 적합성 모델에 관해 함께 알아보겠습니다. 핵심·보충 요구사항과 사실 기술이 어떻게 결합하는지, Bronze·Silver·Gold라는 새 수준이 WCAG 2의 A·AA·AAA와 무엇이 다른지, 그리고 평가 범위가 페이지에서 사용 흐름과 제품으로 어떻게 넓어지는지 살펴보겠습니다.

참고 문서

조회수846
댓글 0
댓글을 작성하려면 해주세요.