WCAG 성공 기준 · Level AAA

WCAG 1.2.9: 오디오 전용(실시간)

WCAG 1.2.9는 실시간 라디오 방송이나 오디오 전용 스트림과 같은 모든 실시간 오디오 전용 콘텐츠에 대해, 실시간 자막 피드나 동기적으로 업데이트되는 텍스트 대본과 같은 동등한 실시간 텍스트 대체 수단을 제공할 것을 요구합니다. 이는 청각 장애가 있거나 난청이 있는 사용자가 오디오 트랙 자체에 의존하지 않고도 실시간 오디오 콘텐츠에 접근할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 성공 기준 1.2.9, 오디오 전용(실시간)은 AAA 수준의 지침 1.2(시간 기반 미디어)에 속합니다. 이 기준은 다음과 같이 규정합니다. “실시간 오디오 전용 콘텐츠에 대해 동등한 정보를 제공하는 시간 기반 미디어의 대체 수단이 제공된다.” 실무적으로는, 웹사이트나 애플리케이션이 실시간 오디오 콘텐츠를 스트리밍하거나 제공할 때 — 그리고 그 콘텐츠에 비디오 구성 요소가 전혀 없을 때 — 사용자는 동일한 정보를 충실하게 전달하는 실시간 텍스트 대체 수단을 제공받아야 한다는 의미입니다.

실시간 오디오 전용 프레젠테이션은 동기화된 비디오 트랙 없이 실시간으로 방송되는 모든 오디오 스트림을 말합니다. 일반적인 예로는 웹페이지에 삽입된 실시간 라디오 프로그램, 스포츠 경기 중 실시간 오디오 해설, 오디오 형식으로 스트리밍되는 실시간 기자회견, 실시간 실적 발표나 투자자 브리핑, 비디오 피드 없이 오디오만 제공되는 실시간 오디오 팟캐스트나 토크쇼 스트림 등이 있습니다.

이 기준에서 요구하는 텍스트 대체 수단은 동등한 것이어야 합니다. 즉, 말로 된 내용뿐 아니라 군중 소리, 경보, 효과음, 정보적 가치를 지닌 음악 등 관련 비음성 오디오 정보도 포착해야 합니다. 부분적이거나 지연된 전사는 이 기준을 충족하지 못합니다. 대체 수단은 실시간 스트림과 동기(또는 거의 동기)에 맞춰 업데이트되어, 농인 및 난청 사용자가 실시간으로 콘텐츠를 따라갈 수 있어야 합니다.

이 기준을 충족하기 위한 허용 가능한 기법으로는, 실시간 텍스트를 생성하는 실시간 속기(예: CART — Communication Access Realtime Translation) 제공, 자격을 갖춘 자막 서비스가 생성하는 동기화된 실시간 자막을 삽입하는 것, 오디오 방송과 동시에 실행되는 실시간 텍스트 피드를 표시하는 것 등이 있습니다. 음성 인식 소프트웨어가 생성한 자동 자막도, 정확도가 충분히 높고 출력이 거의 실시간으로 제공되는 경우에는 이 기준을 충족할 수 있습니다.

통과로 인정되는 경우: 페이지가 눈에 보이는 동기식 텍스트 대체 수단을 제공하며, 이는 오디오 플레이어와 명확히 연결되어 있거나 인접해 표시되고, 실시간 오디오 스트림이 진행되는 대로 동등한 정보를 제시합니다. 이 대체 수단은 오디오를 들을 수 없는 사용자도 인지할 수 있어야 합니다.

실패로 인정되는 경우: 텍스트 대체 수단이 전혀 제공되지 않는 경우, 텍스트 대체 수단가 크게 지연되는 경우(예: 이벤트 후에 게시되는 전사본), 텍스트 대체 수단이 오디오의 일부만 다루는 경우(예: 발표자의 발언만 있고 청중 질문은 없음), 또는 텍스트 대체 수단이 존재하지만 보조 기술 사용자에게 접근 불가능한 경우(예: 포커스를 받을 수 없는 캔버스 요소로 렌더링되거나 Flash 위젯 내부에 잠겨 있는 경우)입니다.

공식 예외: WCAG는 1.2.9에 대해, 이 요구 사항이 실시간 오디오 전용 콘텐츠에만 적용된다는 일반 원칙 외에 별도의 구체적 예외를 두지 않습니다. 사전 녹음된 오디오 전용 콘텐츠는 별도의 기준 1.2.1에서 다룹니다. 짧은 오디오 클립이나 간단한 공지에 대해서도 예외는 없습니다. 콘텐츠가 실시간이면서 오디오 전용이라면 이 기준이 적용됩니다.

왜 중요한가

세계보건기구(WHO)에 따르면 전 세계적으로 약 4억 6,600만 명이 장애 수준의 청각 손실을 가지고 있으며, 이 수치는 2050년까지 9억 명을 넘어설 것으로 예상됩니다. 이 사용자들에게 실시간 오디오 전용 콘텐츠는 텍스트 대체 수단이 없으면 전혀 접근할 수 없습니다. 사전 녹음된 콘텐츠는 전사본을 미리 준비해 나중에 첨부할 수 있지만, 실시간 오디오는 정보가 시간에 민감하고 일시적이라는 고유한 문제를 갖습니다. 농인 사용자는 실시간 스트림을 나중에 다시 재생한다고 해서 같은 경험을 기대할 수 없습니다. 정의상, 실시간 콘텐츠는 그 순간이 지나면 즉시성이 사라지기 때문입니다.

구체적인 실제 상황을 생각해 봅시다. 상장 기업이 투자자 관계 페이지에서 실시간 실적 발표 전화를 오디오 전용으로 스트리밍한다고 가정합니다. 농인 또는 난청인 애널리스트, 기자, 개인 투자자는 실시간 텍스트 피드가 없으면 이 콜에 참여하거나 심지어 수동적으로 따라갈 수도 없습니다. 중요한 재무 공시, 가이던스 업데이트, 애널리스트 질문에 대한 답변이 실시간으로 전달되며, 이 정보를 받는 데 지연이 생기면 이 사용자들은 상당한 정보적 불이익을 겪게 됩니다. 규제 산업에서는 이러한 상황이 공공 정보에 대한 공평한 접근이라는 측면에서 문제를 제기할 수도 있습니다.

농인에 국한되지 않고, 이 기준은 더 넓은 사용자층에 혜택을 줍니다. 청각 처리 장애가 있는 사용자는 소리를 들을 수는 있지만 말을 충분히 빠르게 해독하지 못해 실시간 스트림을 따라가기 어려울 수 있습니다. 동기화된 텍스트 피드는 이들이 오디오가 재생되는 동안 자신의 이해 속도에 맞춰 읽을 수 있게 해 줍니다. 소음에 민감한 환경 — 예를 들어 오픈 오피스, 도서관, 대중교통 — 에서 소리를 크게 틀 수 없는 사용자도 텍스트 대체 수단의 혜택을 봅니다. 방송 언어가 제2언어인 사용자에게도 빠르게 진행되는 실시간 음성보다 텍스트 대체 수단이 더 따라가기 쉽습니다.

SEO와 콘텐츠 검색 가능성 측면에서 보면, 실시간 텍스트 전사본이나 자막 피드는 검색 엔진이 크롤링할 수 있는 인덱싱 가능한 텍스트를 생성합니다. 실시간 텍스트를 생성하는 라이브 이벤트는 검색 결과와 뉴스 집계 서비스에 노출될 가능성이 더 높아져, 원래 방송 시간대를 훨씬 넘어선 시점까지도 잠재 시청자 범위를 확대합니다.

규제 산업 — 금융 서비스, 의료, 정부 — 에서 활동하는 조직의 경우, 실시간 오디오 정보에 대한 공평한 접근을 제공하는 것은 점점 더 선택이 아닌 기대 사항이 되고 있습니다. 이 기준을 충족하지 못하면 민원, 평판 리스크, 그리고 일부 관할 구역에서는 법적 책임에 노출될 수 있습니다.

관련 Axe-core 규칙

WCAG 1.2.9는 수동 테스트를 요구하며, 어떤 자동화된 axe-core 규칙도 실시간 오디오 전용 스트림에 동기식 텍스트 대체 수단이 있는지를 신뢰할 수 있게 감지할 수 없습니다. 이러한 한계의 이유는 이 기준의 특성에 근본적으로 기인합니다.

  • 자동화로 이 위반을 잡을 수 없는 이유: axe-core와 같은 자동화 도구는 특정 시점의 정적인 DOM 스냅샷이나 페이지 상태를 기반으로 동작합니다. 이 도구들은 <audio> 요소나 미디어 플레이어의 존재는 감지할 수 있지만, 해당 콘텐츠가 실시간인지 사전 녹음인지, 페이지에 보이는 텍스트 영역이 실제로 오디오 스트림과 동기적으로 업데이트되는지, 텍스트 콘텐츠가 오디오와 의미적으로 동등한지(모든 음성 및 비음성 오디오 정보를 포함하는지), 연결된 외부 자막 서비스가 실제로 활성 상태이며 정확한지 등을 판단할 수 없습니다. 이러한 모든 판단은 실시간 방송 자체에 대한 사람의 검토가 필요합니다.
  • 수동 감사자가 확인해야 할 사항: 감사자는 실시간 오디오 스트림이 활성화된 동안 페이지에 접속해, 텍스트 대체 수단이 어떻게(또는 실제로) 제공되는지 확인하고, 오디오가 진행됨에 따라 텍스트 대체 수단이 실시간으로 업데이트되는지, 텍스트가 화자 식별, 비음성 소리, 전환을 포함한 모든 의미 있는 오디오 콘텐츠를 포괄하는지 검증해야 합니다. 또한 텍스트 대체 수단이 보조 기술에 접근 가능한지 — 예를 들어 aria-live='polite' 또는 aria-live='assertive'를 사용하는 라이브 영역이 스크린 리더 사용자에게 적절히 업데이트를 알리고 있는지 — 를 확인해야 합니다.
  • 부분 자동화 신호: axe-core는 누락된 실시간 텍스트 대체 수단을 직접 표시할 수는 없지만, 문제를 악화시키는 관련 이슈는 표시할 수 있습니다. 예를 들어 텍스트 전사 영역이 display:none으로 숨겨져 있거나, 미디어 플레이어에 접근 가능한 컨트롤이 없는 경우입니다. 이러한 플래그는 수동 검토를 시작할 때 유용한 출발점이 됩니다.

테스트 방법

  1. 기본선으로서의 자동 스캔: 실시간 오디오 스트림을 호스팅하는 페이지에 대해 axe DevTools 또는 Lighthouse를 실행합니다. 미디어 요소, 누락된 레이블, 접근 불가능한 컨트롤과 관련해 표시된 이슈를 확인합니다. 두 도구 모두 누락된 실시간 텍스트 대체 수단을 직접 표시하지는 않지만, 접근 가능한 이름이 없는 오디오 플레이어나 접근성 트리에서 숨겨진 전사 컨테이너 등 관련 장벽을 드러낼 수 있습니다. 이러한 결과를 문서화하고 전체 접근성 평가의 일부로 취급합니다.
  2. 실시간 오디오 콘텐츠 식별: 실시간 방송이 진행되는 동안, 오디오 스트림이 실시간(녹음이 아님)이며 비디오 트랙이 없다는 것을 확인합니다. 페이지 소스와 네트워크 요청을 확인해 단서를 찾습니다. 실시간 스트림은 일반적으로 HLS(.m3u8), MPEG-DASH, WebSocket 기반 전송을 사용합니다. 콘텐츠가 오디오 전용인지 확인합니다.
  3. 텍스트 대체 수단 확인: 페이지에 보이는 텍스트 영역, 자막 오버레이, 또는 명확히 라벨링된 전사 피드를 찾습니다. 이는 페이지에 직접 있거나 페이지에서 즉시 연결되어 있어야 합니다. 대체 수단은 설정 메뉴 깊숙이 숨겨져 있거나 요청해야만 제공되는 형태가 아니라, 눈에 띄게 노출되어야 합니다. 텍스트 대체 수단이 보이지 않으면 이 기준은 즉시 실패입니다.
  4. 동기성 검증: 실시간 텍스트 대체 수단이 보이는 상태에서, 오디오 스트림을 들으면서 동시에 텍스트 피드를 읽습니다. 텍스트가 합리적인 지연 내(일반적으로 CART나 전문 자막 서비스의 경우 몇 초 이내)에 업데이트되는지 확인합니다. 몇 분마다 한 번씩 업데이트되거나 방송이 끝난 후에야 업데이트되는 텍스트 피드는 이 기준을 충족하지 못합니다.
  5. 동등성 검증: 텍스트 대체 수단이 모든 의미 있는 오디오 콘텐츠를 포착하는지 확인합니다. 즉, 말로 된 내용, 여러 화자가 있을 경우 화자 식별, 관련 비음성 오디오(예: “[박수]”, “[경보음]”, “[음악 재생 중]”), 방송 중 공지나 중단 사항 등을 포함해야 합니다.
  6. 스크린 리더 테스트 — NVDA + Firefox: NVDA를 활성화한 상태에서 페이지를 엽니다. 실시간 텍스트 영역으로 이동합니다. 영역이 aria-live를 사용한다면, NVDA는 새 텍스트 삽입을 자동으로 알려야 합니다. 스크롤되는 텍스트 영역인 경우, 포커스를 둘 수 있고 내용을 읽을 수 있는지 확인합니다. 오디오 플레이어 컨트롤도 키보드로 조작 가능한지 확인합니다.
  7. 스크린 리더 테스트 — VoiceOver + Safari(macOS/iOS): VoiceOver를 활성화하고 실시간 텍스트 영역으로 이동합니다. 새 텍스트가 나타날 때 VoiceOver가 이를 읽어주는지 확인합니다. iOS에서는 모바일 환경에서도 경험을 검증합니다. 라이브 이벤트는 모바일 브라우저를 통해 접속되는 경우가 많습니다.
  8. 스크린 리더 테스트 — JAWS + Chrome: JAWS를 활성화한 상태에서 페이지로 이동해 라이브 영역 알림이 제대로 작동하는지 확인합니다. JAWS는 aria-live='polite'aria-live='assertive'를 다르게 처리하므로, 콘텐츠 유형에 적합한 상세도 설정인지 확인합니다(빠르게 업데이트되는 자막 피드는 대기열 지연을 피하기 위해 assertive가 더 적합할 수 있습니다).
  9. 모바일 및 저대역폭 테스트: 사이트가 모바일 사용자를 대상으로 하는 경우, 중급 사양의 Android 기기에서 제한된(스로틀링된) 연결로 실시간 텍스트 대체 수단을 테스트합니다. 제약된 환경에서도 텍스트 피드가 동기성을 유지하고 접근 가능한지 확인합니다.

해결 방법

시나리오 1: 텍스트 대체 수단이 없는 실시간 오디오 플레이어 — 잘못된 예

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

시나리오 1: ARIA 라이브 영역 전사를 포함한 실시간 오디오 플레이어 — 올바른 예

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

시나리오 2: 이벤트 종료 후에만 게시되는 전사본 — 잘못된 예

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

시나리오 2: 플레이어 옆에 연결된 실시간 CART 피드 — 올바른 예

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

시나리오 3: 설정 토글 뒤에 숨겨진 자동 생성 자막 — 잘못된 예

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

시나리오 3: 명확한 토글과 함께 기본적으로 활성화된 자막 — 올바른 예

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

자주 발생하는 실수

  • 이벤트 후 전사본을 게시하고 1.2.9를 충족한다고 주장하는 경우: 라이브 방송 후 몇 시간 또는 며칠 뒤에 게시되는 전사본은 실시간 텍스트 대체 수단이 아닙니다. WCAG 1.2.9는 대체 수단이 실시간 오디오와 동시에 제공될 것을 명시적으로 요구하며, 사후 제공을 허용하지 않습니다.
  • 빠르게 업데이트되는 자막 피드에 aria-live='polite'를 사용하는 경우: polite 라이브 영역은 사용자가 상호작용을 마칠 때까지 새 콘텐츠 알림을 기다립니다. 빠르게 업데이트되는 자막의 경우, 이로 인해 스크린 리더 사용자가 알림을 놓치게 됩니다. 각 업데이트가 시간에 민감한 실시간 자막 스트림에는 aria-live='assertive'를 사용해야 합니다.
  • 새 콘텐츠만 추가하는 대신 매 업데이트마다 전체 자막 기록을 주입하는 경우: aria-atomic='true'가 설정된 상태에서 매 업데이트마다 전체 텍스트 블록을 교체하면, 스크린 리더는 영역 전체를 다시 읽으려 하여 불쾌한 경험을 유발합니다. aria-atomic='false'를 사용하고 새 텍스트 노드를 추가해, 새 부분만 알리도록 해야 합니다.
  • <canvas> 요소나 비디오 오버레이 그래픽으로 자막 피드를 임베드하는 경우: 캔버스에 픽셀로 렌더링되거나 비디오 프레임에 번인된 자막 텍스트는 보조 기술에 보이지 않습니다. 텍스트 대체 수단은 실제 DOM 텍스트 노드로 제공되어야 합니다.
  • position:absolute; left:-9999px로 실시간 자막 영역을 화면 밖에 배치하는 경우: 이 방식은 콘텐츠를 접근성 트리에 남겨두지만, 난청이 있는 시각 사용자에게 자막을 읽을 수 있는 기회를 박탈합니다. 텍스트 대체 수단은 스크린 리더 사용자뿐 아니라 모든 사용자가 시각적으로도 볼 수 있어야 합니다.
  • 다수 화자가 있는 방송에서 화자를 식별하지 않는 경우: 발화를 특정 화자에게 귀속시키지 않고 전사만 하는 자막 피드는(예: “[사회자]:”, “[CEO]:”, “[청중]:” 등) 완전히 동등하다고 볼 수 없습니다. 화자 식별은 사용자가 라이브 이벤트의 대화 구조를 따라가는 데 필수적입니다.
  • 텍스트 대체 수단에서 비음성 오디오 정보를 생략하는 경우: 박수, 기술적 중단, 배경 음악, 경보, 웃음 등 관련 소리는 정보적 콘텐츠를 담고 있으며, “[박수]”, “[기술적 문제 — 오디오 중단]”과 같이 텍스트 피드에 설명되어야 합니다.
  • 텍스트 대체 수단을 동일 페이지에 임베드하지 않고 별도의 제3자 URL로만 제공하는 경우: 사용자가 자막을 보기 위해 오디오가 재생되는 원래 페이지와는 별도의 브라우저 탭이나 창을 열도록 요구하는 것은, 특히 스크린 리더 사용자와 키보드 전용 사용자에게 큰 사용성 장벽을 만듭니다. 이들은 컨텍스트를 전환해야 하기 때문입니다.
  • 자동 생성 자막이 항상 동등성 기준을 충족한다고 가정하는 경우: AI 기반 자막은 억양이 강한 발화, 전문 용어, 고유명사, 빠른 말하기 속도에서 높은 오류율을 보일 수 있습니다. 의료 브리핑이나 재무 공시처럼 중요도가 높은 라이브 이벤트에 수정되지 않은 자동 생성 자막을 사용하는 것은, 자막 피드가 기술적으로 존재하더라도 동등성 기준을 충족하지 못할 수 있습니다.
  • 실제 라이브 방송 중 실시간 텍스트 영역을 스크린 리더로 테스트하지 않는 경우: 많은 팀이 플레이어와 자막 컨테이너를 정적 플레이스홀더 텍스트로만 개별 테스트하고, 실제 라이브 스트림 중의 동적 동작은 테스트하지 않습니다. 자막 업데이트를 주입하는 JavaScript의 버그 — 예를 들어 조용히 실패하는 DOM 변경 감시자 — 는 라이브 테스트에서만 드러납니다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보 제32933호에 게재되었으며, 터키에서 활동하는 광범위한 조직에 대해 구속력 있는 웹 접근성 의무를 설정합니다. 이 대통령령은 WCAG 2.2 AA 수준 준수를 기본 표준으로 의무화합니다. 적용 대상에는 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교 등이 포함됩니다.

WCAG 1.2.9는 AAA 수준 기준으로, 대통령령이 AA 수준에서 의무화한 준수 요구 사항에는 포함되지 않습니다. 대통령령 2025/10의 적용을 받는 조직은, 별도로 WCAG 2.2 AAA 전체 준수를 약속하지 않는 한, 실시간 오디오 전용 텍스트 대체 수단을 법적으로 구현할 의무는 없습니다.

그러나 엄격한 법적 최소 요건을 넘어, 1.2.9는 터키 조직에 매우 중요한 실무적 고려 사항을 제기합니다. 통신사, 금융 기관, 공영 방송사는 농인 및 난청 사용자가 의존하는 실시간 오디오 콘텐츠 — 투자자 콜, 공공 공지, 실시간 고객 서비스 방송 등 — 을 자주 제공합니다. AAA 수준 준수를 입증하는 것은 최고 수준의 접근성 의지를 보여주는 신호이며, 장애인법 제5378호 및 그 시행령을 포함한 터키의 광범위한 장애인 권리 체계 하에서 차별 민원 위험을 크게 줄여 줍니다.

접근성 수준을 차별화하거나, 더 엄격한 요구 사항을 가진 국제 시장에 서비스를 제공하거나, AAA를 요구하는 조달 기준에 맞추기 위해 자발적으로 WCAG 2.2 AAA 준수를 추구하는 조직의 경우, 1.2.9를 올바르게 구현하는 것은 필수적입니다. Accsible은 규제 산업에 속한 터키 조직이, 특히 정보 공평성이 구체적인 이해관계자 기대인 대국민 라이브 이벤트에 대해, 실시간 오디오 콘텐츠를 선제적으로 평가하고 CART 서비스나 고정확도 실시간 자막 통합 가능성을 검토할 것을 권장합니다.