접근성 지원 세트 — WCAG 3가 한국에 남긴 빈칸

웹 접근성 검사 도구를 돌리다 보면 결과 화면 어딘가에 이런 문구가 붙어 있는 걸 본 적이 있을 겁니다. “이 결과는 특정 브라우저·스크린 리더 조합에서 확인됐습니다.” 접근성 평가는 늘 어떤 환경을 기준으로 삼을지에서 출발합니다. 그런데 그 “기준 환경"이 정확히 뭔지, 표준 문서가 명확히 정의한 적은 사실 많지 않았습니다.

WCAG 3(3.0)의 2026년 3월 Working Draft는 이 빈틈에 “접근성 지원 세트(accessibility-support set)“라는 이름을 붙이고, 정식 조항(§3.2.2)으로 구조화했습니다. 용어 자체는 그 전 초안에도 있었지만, 기본 세트와 대안 세트를 나누고 조항 번호를 매겨 적합성 요구사항 안에 자리를 잡아준 건 이번 초안입니다. 그런데 정의를 들여다보면, 그 기준이 영어 콘텐츠를 향해 있다는 문장이 나옵니다. 이 글은 그 조항이 정확히 뭘 말하는지, 그리고 센스리더 같은 국내 보조기술 환경에서는 이게 어떤 의미인지 정리한 글입니다.

미리 밝혀두면, 이 글은 결론이나 대응 방안을 제시하지 않습니다. 스펙에 이런 빈칸이 있고, 한국은 이런 상황에 놓여 있다는 사실 확인까지만 다룹니다.

표기 하나만 먼저. 아래에서 §3.2.2 같은 표기가 나옵니다. §는 절 기호(section sign)로, 문서의 몇 번째 절인지 가리킵니다. §3.2.2는 “3.2.2절"이라는 뜻이에요. W3C 명세를 인용할 때 흔히 쓰는 방식인데 한국어 문서에는 드물어서, 처음 보면 특수문자처럼 느껴집니다. 그냥 “몇 절"이라고 읽으시면 됩니다.

“accessibility supported"라는 오래된 애매함

사실 이 고민 자체는 새롭지 않습니다. WCAG 2.x도 적합성 요구사항 안에 “접근성이 지원되는 방식으로 기술을 사용해야 한다"는 조건을 두고 있었습니다. 문제는 “접근성이 지원된다"는 게 정확히 어떤 브라우저와 어떤 보조기술 조합을 기준으로 하는 말인지, 표준 문서 자체는 구체적으로 못 박지 않았다는 점입니다.

그래서 실무에서는 조직마다 “우리는 크롬+NVDA를 기준으로 삼는다” 같은 식으로 각자 지원 범위를 정해왔습니다. 같은 콘텐츠를 두고도 어떤 조합을 기준으로 삼느냐에 따라 접근성 지원 여부 판단이 달라질 수 있었던 거죠.

WCAG 3가 이걸 정식 조항으로 만들었다

장면 하나를 먼저 그려보겠습니다. 어떤 기준이 “이렇게 만들면 접근성을 충족한 것으로 본다"고 말하려면, 누군가는 그걸 실제로 시험해봐야 합니다. 그런데 시험하려면 결정할 게 있어요. 어떤 브라우저에서? 어떤 스크린 리더로? 확대나 고대비 같은 설정은 어떤 상태로? 이 세 가지를 정하지 않으면 “동작한다"는 말 자체가 성립하지 않습니다. 크롬+NVDA에서는 잘 읽히는데 사파리+보이스오버에서는 안 읽힐 수 있으니까요.

이 시험 환경 한 벌에 이름을 붙인 게 접근성 지원 세트입니다.

3월 초안의 §3.2.2 “Accessibility supported"가 이 애매함에 이름을 붙였고, 그 아래 §3.2.2.1이 개념을 정의합니다. 접근성 지원 세트(accessibility-support set)는 어떤 요구사항을 충족하는 구현 방법을 정할 때 시험 기준으로 삼는 브라우저·보조기술·접근성 설정의 조합입니다.

용어가 몇 개 붙어 다니니 여기서 한 번에 풀어두겠습니다.

처음 보는 약어가 나올 때마다 되짚어보시면 됩니다. 외울 필요는 없어요. 문서는 이 세트를 두 종류로 나눠 씁니다 — 기본 접근성 지원 세트(default accessibility-support set)와 대안 접근성 지원 세트(alternative accessibility-support set)로요. 기본 세트는 영어 콘텐츠를 지원하는, 흔히 쓰이는 브라우저와 보조기술의 조합으로 설명되고, 우선 HTML 구현 방법을 위한 것이라고 못 박혀 있습니다(모바일이나 VR 같은 기술을 위한 세트는 나중에 추가될 수 있다고만 적혀 있어요).

여기에 조건이 하나 더 붙습니다. Core는 WCAG 3에서 가장 기본이 되는 요구사항 묶음인데, AGWG는 여기에 항목을 넣을 때 규칙을 하나 두고 있습니다. 기본 세트 안에서 실제로 동작하는 HTML 구현 방법이 최소 하나는 있어야 한다는 것이죠. 그것도 발행 시점 기준으로요.

말을 바꾸면 이렇습니다. “이론상 맞는 요구사항"은 Core에 못 들어갑니다. “기본 세트에서 실제로 해봤더니 되더라"가 확인된 것만 들어갑니다.

합리적인 원칙인데, 여기서 앞의 문제와 만납니다. 그 검증의 잣대가 영어 콘텐츠 기준이라는 것이죠.

실무자에게 직접 닿는 대목도 있습니다. 초안은 적합성 선언에 어떤 접근성 지원 세트를 썼는지 반드시 밝히라고 요구합니다. “우리는 접근성 기준을 지켰습니다"로 끝낼 수 없고, “어떤 환경에서 확인한 것인지"까지 적어야 한다는 뜻이에요.

한 발 더 나아가, 이런 경우에는 공개 접근성 선언문에도 그 세트를 밝히기를 권합니다.

• 외부에서 접근할 수 없는 폐쇄망에서 돌아가는 서비스
• HTML이 아닌 기술(예: 네이티브 앱, PDF)로 만든 콘텐츠
• 기본 세트 바깥의 브라우저·보조기술에 의존하는 지역

마지막 줄이 한국어 환경을 다루는 국내 서비스에는 남의 이야기가 아닙니다.

“방법(method)“이라는 말도 짚고 가겠습니다. WCAG 3는 요구사항마다 “이렇게 하면 충족한 것으로 본다"는 구체적인 구현 방법을 기술별로 따로 제공하려 합니다. 같은 요구사항이라도 HTML로 만드는 방법과 PDF로 만드는 방법이 다를 수 있으니까요.

그런데 그 방법이 “실제로 동작한다"고 인정받으려면 어딘가에서 시연해야 합니다. 그 어딘가를 정하는 게 접근성 지원 세트입니다.

그래서 이 개념들은 서로 물려 있습니다. 지원 세트가 정해져야 방법을 검증할 수 있고, 방법이 검증돼야 Core에 요구사항을 넣을 수 있습니다. 첫 단추가 비어 있으면 뒤가 전부 붕 뜨는 구조예요.

그런데 정작 그 기본 세트가 뭔지는 편집자 노트로 이렇게만 적혀 있습니다. 아직 정의되지 않았다. 개념은 만들어졌는데 알맹이는 비어 있는 상태예요.

이걸 명시적인 개념으로 만든 이유도 짐작해볼 수 있습니다. 자동화 접근성 검사 도구를 써본 분이라면, 같은 페이지인데도 도구마다 — 심지어 같은 도구라도 버전이나 실행 환경에 따라 — 결과가 조금씩 다르게 나온 경험이 있을 겁니다. 어떤 브라우저·보조기술 조합을 기준으로 검사했는지가 결과에 영향을 주기 때문인데, WCAG 2.x는 이 기준을 문서화하도록 요구하지 않았습니다. 접근성 지원 세트라는 개념을 명시적으로 규정하면, 적어도 “어떤 기준으로 검증했는지"를 문서로 남기고 비교할 수 있는 토대는 마련되는 셈입니다.

영어 중심 기본값이 던지는 질문

기본 세트가 “영어 콘텐츠를 지원하는” 조합으로 정의된다는 문장은 그 자체로 실무적인 함의를 갖습니다. 어떤 요구사항이 검증됐다고 인정받으려면 기본 세트 안에서 동작해야 하는데, 그 기본 세트가 영어 콘텐츠 환경을 기준으로 짜인다면 한국어 콘텐츠 특유의 문제 — 예를 들면 한국어 스크린 리더가 자소 단위를 읽는 방식, 한글 입력 흐름에서의 포커스 이동 같은 것들 — 은 같은 방식으로 검증되지 않을 가능성이 있습니다. 자막 없는 외화를 보는 기분이랄까요. 화면은 잘 보이는데, 정작 필요한 설명이 다른 언어 환경을 기준으로 쓰여 있는 느낌 말이에요.

한국은 센스리더가 지역적으로 널리 쓰이는 스크린 리더입니다. 국제적으로 흔히 언급되는 JAWS나 NVDA, VoiceOver 목록과는 별개로 존재하는 도구죠. 브라우저·보조기술 조합의 구성 자체가 영어권 표준 목록과 다르다는 뜻입니다. 그리고 한국에는 이미 국가 표준인 KWCAG 2.2(KS X OT0003, 2022년 12월 개정, WCAG 2.1 기반)가 있고, 이를 기준으로 삼는 웹 접근성 품질인증 제도도 별도로 운영되고 있습니다. “기준 환경을 누가 정하느냐"는 질문이 국내에서 처음 등장하는 것도 아니라는 뜻이에요 — 이미 국가 표준과 그걸 검증하는 인증 체계가 나란히 존재해온 셈입니다.

물론 이건 지금 시점에 확답할 수 있는 문제는 아닙니다. 기본 세트가 뭘로 구성될지 W3C가 아직 밝히지 않았으니, “센스리더가 포함되느냐 마느냐"조차 지금은 답할 수 없는 질문입니다.

“지역 규제기관이 대안을 정의할 수 있다"는 조항

여기서 3월 초안에 눈에 띄는 문장이 하나 더 있습니다. 기본 접근성 지원 세트가 필요한 지원을 제공하지 못할 때, 개인이나 조직뿐 아니라 지역 규제기관(regional regulators)도 대안적인 접근성 지원 세트를 지정할 수 있다는 조항입니다.

이 조항이 뜻하는 바를 풀어보면 이렇습니다. WCAG 3는 “영어 콘텐츠 기준 기본 세트 하나로 전 세계를 다 커버하겠다"고 주장하지 않습니다. 대신 그 기본값이 맞지 않는 지역이나 조직은 자체적으로 다른 기준을 세울 수 있는 문을 열어뒀습니다. 국가 표준기관이든 산업 협회든, 이론적으로는 “우리 환경에서는 이 브라우저·보조기술 조합을 기준으로 삼는다"고 선언할 근거가 스펙 안에 이미 마련돼 있는 셈이에요.

여기서 “지역 규제기관"이라는 말도 짚어볼 필요가 있습니다. 특정 국가나 지역에서 접근성 관련 법과 제도를 관장하는 기관을 가리키는 표현인데, 한국으로 치면 KWCAG를 관리·개정하는 기관 같은 존재가 여기에 해당할 수 있습니다. 사실 이런 식의 지역화는 웹 접근성 표준에서 낯선 일이 아닙니다. WCAG 2 자체도 국가·지역마다 KWCAG, 미국의 Section 508, 유럽의 EN 301 549처럼 각자의 맥락에 맞춰 파생된 표준을 낳았거든요. WCAG 3의 “지역 규제기관” 조항은 그 흐름을 접근성 지원 세트라는 새 개념 안에서도 이어가겠다는 신호로 읽힙니다.

다만 이 조항은 “할 수 있다"는 가능성을 열어둔 것이지, 실제로 누군가 그렇게 하겠다고 밝힌 건 아닙니다. 이 글을 쓰는 시점 기준으로 한국의 어떤 기관도 WCAG 3의 대안 접근성 지원 세트를 만들겠다고 공개적으로 발표한 적은 없습니다. 조항이 문을 열어뒀을 뿐, 그 문으로 누가 들어갈지는 아직 아무도 정하지 않은 상태입니다.

접근성 지원 세트의 빈칸이 채워지는 시나리오들

정리하면 지금 스펙 위에 놓인 빈칸은 이런 모양입니다.

• 기본 세트 자체가 비어 있음: 영어 콘텐츠 기준이라는 방향성만 있고, 구체적인 브라우저·보조기술 목록은 아직 없습니다. W3C가 이 목록을 어떻게 채울지 — 예를 들어 사용 통계를 기준으로 삼을지, 주요 플랫폼 벤더와 협의해 정할지 — 도 지금 초안에는 나와 있지 않습니다.
• 누가 채울 수 있는가는 넓게 열려 있음: 개인, 조직, 지역 규제기관까지 대안 세트를 지정할 수 있는 주체로 명시돼 있습니다. 한 회사가 내부 QA 기준으로 자체 지원 세트를 정해 쓰는 것부터, 국가 표준기관이 공식적으로 대안 세트를 지정하는 것까지 범위가 넓습니다.
• 실제로 채워진 사례는 아직 없음: 기본 세트도, 대안 세트도 지금 시점에는 어느 쪽도 구체화되지 않았습니다. 이 세 빈칸이 동시에 비어 있다는 게 지금 초안의 정직한 상태입니다.

빈칸 세 개를 나란히 놓고 보면, 지금은 “누가 채워야 하느냐"를 논하기보다 “빈칸이 있다는 사실 자체를 알고 있느냐"가 더 중요한 단계라는 생각이 듭니다. 채워지지 않은 칸을 두고 미리 답을 정해버리면, 정작 W3C가 기본 세트를 발표했을 때 다시 뒤집어야 할 수도 있으니까요.

한 장 요약

• 접근성 지원 세트는 WCAG 2.x부터 있었던 “접근성이 지원되는 방식"이라는 애매한 개념을, WCAG 3(3.0) §3.2.2가 명시적으로 정의하려는 시도입니다.
• 기본 세트는 영어 콘텐츠를 지원하는 공통 브라우저·보조기술 조합으로 방향만 잡혀 있고, 구체적인 정의는 편집자 노트로 아직 비어 있습니다.
• Core 요구사항은 기본 세트에서 동작하는 HTML 방법이 최소 하나 있어야 채택되는데, 그 검증 기준이 영어 중심이라는 점은 짚어둘 만합니다.
• 초안은 지역 규제기관을 포함해 개인·조직도 대안 접근성 지원 세트를 지정할 수 있다는 조항을 두고 있습니다.
• 한국은 센스리더 중심의 AT 지형과 기존 국가 표준 KWCAG 2.2를 갖고 있어, 이 빈칸이 남의 이야기는 아닙니다.
• 다만 국내 어떤 기관도 대안 세트를 만들겠다고 공개 발표한 적은 없습니다 — 지금은 결론을 낼 단계가 아니라 지켜볼 단계입니다.

이 시리즈의 다른 글

• WCAG 3.0 시대의 시작: 왜 새로운 가이드라인이 필요한가?
• WCAG 3.0 구조 해부: Success Criteria에서 Outcomes로
• WCAG 3.0 적합성 모델: A/AA/AAA 이후의 변화
• Atomic Tests vs. Holistic Tests: 새로운 테스트 방법론
• Assertions: 접근성 평가의 새로운 단위
• WCAG 3.0 확장된 적용 범위: 웹을 넘어서
• WCAG 3 마이그레이션, 지금 필요할까 — WCAG 2.2에서 넘어가는 전략
• WCAG 3, 지금 어디까지 왔나 — 2026년 3월 초안 총정리

참고 자료

• W3C Accessibility Guidelines (WCAG) 3.0 Working Draft (2026-03-03)
• WCAG 3.0 Explainer
• 한국형 웹 콘텐츠 접근성 지침 2.2 — KS X OT0003 (국립전파연구원)
• KWCAG 2.2 완전 해설 — 4원칙 14지침 33검사항목

주의: 이 글은 2026년 3월 3일 W3C Working Draft 기준입니다. 접근성 지원 세트는 문서 안에서도 기본값 자체가 정의되지 않은 초기 단계 개념이라, 이후 초안에서 내용이 크게 바뀔 수 있습니다.