WCAG 성공 기준 · Level A

WCAG 1.4.2: 오디오 제어

WCAG 1.4.2는 자동으로 3초를 초과하여 재생되는 모든 오디오에 대해, 사용자가 시스템 볼륨과는 별도로 해당 오디오의 재생을 일시 중지하거나 중단하거나 볼륨을 조절할 수 있는 수단을 제공할 것을 요구합니다. 이는 오디오가 스크린 리더 출력에 방해가 되는 것을 막고, 사용자들을 예기치 못한 혼란스러운 소리로부터 보호하기 위한 것입니다.

이 규칙의 의미

WCAG 1.4.2 — Audio Control은 Perceivable 원칙 아래의 레벨 A 성공 기준이다. 이 기준은 다음과 같이 규정한다: 웹 페이지에서 어떤 오디오든 사용자의 명시적인 조작 없이 자동으로 3초를 초과하여 재생되는 경우, 오디오를 일시 정지하거나 중지할 수 있는 메커니즘이 제공되거나, 전체 시스템 볼륨 수준과는 독립적으로 오디오 볼륨을 제어할 수 있는 메커니즘이 제공되어야 한다.

이 기준은 사용자의 명시적인 행동 없이 재생이 시작되고 3초를 초과해 계속되는 모든 오디오 콘텐츠에 의해 촉발된다. 여기에는 페이지에 삽입된 배경 음악, 소리가 나는 사운드트랙이 있는 자동 재생 비디오, 오디오 광고, 반복되는 효과음, 페이지 로드 시 실행되는 음성 소개 등이 포함된다. 핵심 문구는 자동으로(automatically)라는 점이다 — 사용자가 의도적으로 시작한 오디오(재생 버튼 클릭, 링크 활성화 등)는 이 규칙의 적용을 받지 않는다.

이 기준을 충족하려면 다음 중 적어도 하나는 참이어야 한다:

  • 사용자에게 오디오를 완전히 중지하거나 사용자가 다시 재생할 때까지 일시 정지하는 일시 정지 또는 중지 컨트롤이 제공된다.
  • 사용자에게 운영 체제의 마스터 볼륨과는 독립적인 볼륨 컨트롤이 제공되어, 다른 애플리케이션이나 시스템 사운드에 영향을 주지 않고 해당 오디오만 줄이거나 음소거할 수 있다.

페이지 상단에만 나타나고 키보드로 접근 가능한 메커니즘도 허용되지만, 오디오가 방해가 되기 전에 도달 가능하고 조작 가능해야 한다. 모범 사례로는 키보드 및 스크린 리더 사용자가 즉시 이 컨트롤을 만나도록 포커스 순서에서 가장 첫 번째 인터랙티브 요소로 배치하는 것을 강력히 권장한다.

WCAG에서 정의한 유일한 공식 예외는 3초 이하의 오디오이다. 스스로 멈추는 짧은 알림음이나 짧은 종소리 등은 예외에 해당한다. 볼륨이 낮은 오디오, 반복 재생되는 오디오, 서드파티 위젯에 포함된 오디오에 대한 예외는 없다 — 이들 모두 자동 재생되고 3초를 초과하면 이 규칙의 적용을 받는다.

왜 중요한가

제어할 수 없는 자동 재생 오디오는 여러 장애 그룹에 상당한 장벽을 만들며, 조용한 환경이나 공유 공간에 있는 비장애 사용자에게도 불편을 초래한다.

스크린 리더 사용자가 가장 심각한 영향을 받는다. JAWS, NVDA, VoiceOver와 같은 스크린 리더는 페이지 콘텐츠를 전달하기 위해 합성 음성 출력을 사용한다. 웹 페이지가 동시에 배경 오디오나 비디오 사운드트랙을 재생하면 두 오디오 스트림이 겹친다. 스크린 리더의 음성이 이해하기 어렵거나 사실상 불가능해져, 사용자가 중지 컨트롤을 찾고 활성화할 수 있을 때까지 페이지에 접근할 수 없게 된다 — 그러나 소음 때문에 스크린 리더가 페이지를 제대로 읽어 줄 수 없어 그 컨트롤을 찾는 것조차 쉽지 않다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 그 중 상당수가 스크린 리더를 주요 브라우징 도구로 사용한다.

인지 및 주의력 관련 장애가 있는 사용자는 ADHD, 자폐 스펙트럼, 불안 장애 등을 포함하며, 예상치 못한 오디오를 매우 혼란스럽거나 고통스럽게 느낄 수 있다. 갑작스러운 음악이나 음성의 시작은 집중을 깨뜨리고, 감각 과부하를 유발하거나, 소리가 페이지 콘텐츠의 일부인지 외부 알림인지에 대한 혼란을 초래할 수 있다.

청각 처리 장애가 있거나 보청기를 사용하는 사용자는 오디오가 예상치 못한 볼륨으로 보청기 등을 통해 재생될 때 피드백 루프나 증폭된 왜곡을 경험할 수 있다. 독립적인 볼륨 컨트롤은 이들이 시스템 전체 설정을 바꾸지 않고(다른 애플리케이션에 영향을 주지 않고) 자신의 청취 환경을 관리할 수 있게 해준다.

운동 장애가 있는 사용자는 키보드나 스위치 접근 방식으로 탐색하므로, 정지/일시 정지 컨트롤이 키보드로 도달 가능하고 페이지 구조 초반에 논리적으로 배치되어야 한다. 컨트롤이 마우스로만 클릭 가능하거나 탭 순서 후반에 묻혀 있다면, 그 위치까지 이동하는 동안 아무런 실질적인 도움을 주지 못한다.

구체적인 상황을 생각해 보자. 한 시각장애 구직자가 한 회사의 채용 페이지를 방문했는데, 그 페이지가 경쾌한 음악이 깔린 홍보 영상을 자동 재생한다. 사용자가 스크린 리더를 실행하면, 스크린 리더는 즉시 페이지 제목과 내비게이션을 읽기 시작한다. 그러나 음악이 합성 음성을 완전히 묻어 버린다. 정지 버튼은 키보드 포커스를 받을 수 없는 스타일링된 <div>로, 페이지 중간의 비디오 플레이어 안에 시각적으로만 배치되어 있다. 사용자는 키보드로 그 위치에 도달할 수 없고, 스크린 리더의 음성을 충분히 들을 수 없어 효율적으로 탐색할 수도 없으며, 결국 페이지를 떠난다. 회사는 유능한 지원자를 잃고 잠재적인 법적 리스크에 직면한다.

사용성과 SEO 관점에서, 자동 재생 오디오가 있는 페이지는 이탈률이 높아지는 경우가 많다. 많은 사용자(장애 여부와 관계없이)가 예상치 못한 소리가 나기 시작하면 즉시 탭을 닫기 때문이다. 검색 엔진은 높은 이탈률을 부정적인 품질 신호로 해석하여, 간접적으로 검색 노출에 악영향을 줄 수 있다.

관련 Axe-core 규칙

WCAG 1.4.2는 수동 테스트를 요구한다. 이 기준에 직접적으로 매핑되는 axe-core 자동 규칙은 없다. 자동화 도구가 이 위반을 잡아낼 수 없는 이유는 브라우저와 JavaScript의 동작 방식에 근본적으로 기인한다:

  • 동적 오디오 시작: 오디오는 JavaScript 타이머, 이벤트 리스너, 초기 DOM 파싱 이후 실행되는 서드파티 스크립트에 의해 트리거될 수 있다. 정적인 DOM만 검사하는 자동 스캐너는 오디오가 자동 재생될지, 얼마나 오래 재생될지, 특정 오디오 소스와 기능적으로 연결된 컨트롤이 있는지를 신뢰성 있게 판단할 수 없다.
  • 컨트롤의 존재와 동작 가능성: 볼륨 슬라이더나 일시 정지 버튼이 DOM에 존재하더라도, 실제로는 동작하지 않거나 화면 밖에 숨겨져 있거나 키보드 사용자에게 접근 불가능할 수 있다. 자동화 도구는 요소의 존재는 감지할 수 있지만, 상호작용을 실제로 실행하고 결과를 청취하지 않는 이상 그 요소를 활성화했을 때 오디오가 실제로 멈추는지 검증할 수 없다 — 이는 인간의 청각적 판단이 필요한 작업이다.
  • 시간 임계값: 오디오가 3초를 초과해 재생되는지 판단하려면 페이지 로드 동안의 시간 기반 평가가 필요하며, 이는 정적 DOM 분석이나 심지어 런타임 DOM 분석 도구의 범위를 벗어난다.
  • 서드파티 임베드: iframe, 서드파티 SDK, 광고 네트워크를 통해 삽입된 오디오는 테스트 도구의 JavaScript 샌드박스에서 검사할 수 없을 수 있어, 프로그램적으로 감지하는 것이 불가능하다.

이러한 한계 때문에, 감사자는 반드시 페이지를 직접 방문해 자동 재생 오디오가 있는지 듣고, 일시 정지/정지/볼륨 컨트롤이 존재하는지, 키보드로 접근 가능한지, 제대로 동작하는지를 수동으로 검증해야 한다.

테스트 방법

  1. 자동 사전 스캔: 페이지에서 axe DevTools 또는 Google Lighthouse를 실행한다. 두 도구 모두 1.4.2 위반을 직접적으로 표시하지는 않지만, 컨트롤의 키보드 포커스 누락, 접근 불가능한 미디어 플레이어 요소, 커스텀 오디오 위젯의 ARIA 레이블 누락 등 관련 문제를 드러낼 것이다. 수동 테스트를 시작하기 전에 이러한 문제를 해결해 별개의 이슈가 혼재되지 않도록 한다.
  2. 수동 오디오 감지: 스피커나 헤드폰을 켠 상태에서 페이지를 로드한다. 사용자 상호작용 없이 처음 몇 초 안에 어떤 오디오가 재생되기 시작하는지 확인한다. 그렇다면 타이머를 사용해 3초를 초과해 재생되는지 확인한다. 홈페이지, 랜딩 페이지, 상품 페이지, 미디어 임베드나 광고 슬롯이 있는 것으로 알려진 모든 주요 페이지 유형을 확인한다.
  3. 정지/일시 정지/볼륨 컨트롤 찾기: 마우스를 사용하지 않고, 페이지가 로드되자마자 Tab 키를 누른다. 오디오 컨트롤에 도달하기까지 몇 번의 탭 정지가 발생하는지 센다. 컨트롤이 눈에 보이는 포커스 표시를 받는지 확인한다. Enter 또는 Space를 눌러 활성화하고, 오디오가 멈추거나 볼륨을 독립적으로 조정할 수 있는지 확인한다.
  4. NVDA와 Firefox로 스크린 리더 테스트: NVDA를 실행하고 Firefox를 열어 페이지로 이동한다. 오디오가 시작되도록 둔다. NVDA의 읽기 명령(화살표 키, 가상 커서)을 사용해 오디오 컨트롤을 찾고 활성화해 본다. NVDA가 컨트롤의 역할과 레이블을 올바르게 안내하는지(예: "Pause audio, button") 그리고 이를 활성화했을 때 경쟁하는 오디오가 실제로 사라지는지 확인한다.
  5. VoiceOver와 Safari(macOS/iOS)로 스크린 리더 테스트: Command + F5로 VoiceOver를 활성화한다. 페이지로 이동한 뒤, 스와이프나 화살표 키를 사용해 오디오 컨트롤을 찾는다. VoiceOver가 의미 있는 레이블을 읽어 주는지, 컨트롤이 기대대로 동작하는지 확인한다. iOS에서는 모바일 브라우저가 오디오 권한을 다르게 처리하므로 자동 재생 동작도 함께 테스트한다.
  6. JAWS와 Chrome으로 스크린 리더 테스트: JAWS를 실행한 상태에서 Chrome에서 페이지를 연다. 탭 키와 JAWS의 폼 컨트롤 목록(Insert + F5)을 사용해 인터랙티브 요소를 찾는다. 오디오 컨트롤이 목록에 나타나는지, 조작 가능한지 확인한다.
  7. 서드파티 콘텐츠 확인: 페이지에 소셜 미디어 비디오, 광고 유닛, iframe 콘텐츠가 포함되어 있다면, 가능하다면 이를 별도로 로드해 역시 기준을 준수하는지, 또는 호스트 페이지가 이를 무시할 수 있는 오버라이드 컨트롤을 제공하는지 확인한다.
  8. 볼륨 독립성 확인: 페이지가 일시 정지/정지 컨트롤 대신 볼륨 컨트롤을 제공하는 경우, 페이지의 볼륨 컨트롤을 조정해도 운영 체제의 마스터 볼륨이 변경되지 않는지 확인한다. 다른 애플리케이션(예: 로컬 미디어 플레이어)을 열어, 페이지의 컨트롤을 조작한 후에도 그 애플리케이션의 볼륨이 영향을 받지 않는지 확인한다.

수정 방법

컨트롤이 없는 자동 재생 배경 오디오 — 잘못된 예

<!-- Audio starts automatically with no visible or keyboard-accessible control -->
<audio src='background-music.mp3' autoplay loop></audio>

접근 가능한 일시 정지 컨트롤이 있는 자동 재생 배경 오디오 — 올바른 예

<!-- Control is the first focusable element, announced properly by screen readers -->
<button id='audio-toggle' aria-label='Pause background music' aria-pressed='true' onclick='toggleAudio()'>
  Pause Music
</button>

<audio id='bg-audio' src='background-music.mp3' autoplay loop></audio>

<script>
  function toggleAudio() {
    var audio = document.getElementById('bg-audio');
    var btn = document.getElementById('audio-toggle');
    if (audio.paused) {
      audio.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.setAttribute('aria-label', 'Pause background music');
      btn.textContent = 'Pause Music';
    } else {
      audio.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.setAttribute('aria-label', 'Play background music');
      btn.textContent = 'Play Music';
    }
  }
</script>

<!-- The native <button> element is keyboard-accessible by default.
     aria-pressed communicates toggle state to screen readers.
     aria-label updates dynamically to reflect current action. -->

키보드 접근 가능한 정지 컨트롤이 없는 사운드트랙 자동 재생 비디오 — 잘못된 예

<!-- The video autoplays with sound; the only stop control is a mouse-only overlay -->
<div class='hero-video-wrapper'>
  <video src='promo.mp4' autoplay loop></video>
  <div class='stop-btn' onclick='stopVideo()'>Stop</div>
</div>
<!-- Problem: <div> is not keyboard-focusable and has no role or label -->

접근 가능한 정지 컨트롤이 있는 자동 재생 비디오 — 올바른 예

<div class='hero-video-wrapper'>
  <!-- Stop control appears first in DOM and focus order -->
  <button
    id='video-stop-btn'
    aria-label='Stop promotional video'
    onclick='stopVideo()'
  >
    Stop Video
  </button>

  <video id='promo-video' src='promo.mp4' autoplay loop muted='false'></video>
</div>

<script>
  function stopVideo() {
    var video = document.getElementById('promo-video');
    var btn = document.getElementById('video-stop-btn');
    video.pause();
    video.currentTime = 0;
    btn.disabled = true;
    btn.textContent = 'Video Stopped';
  }
</script>

<!-- Using a native <button> ensures keyboard access without additional ARIA.
     Placing the button before the video in DOM order puts it early in tab sequence. -->

독립적인 볼륨 컨트롤이 있는 임베디드 서드파티 오디오 위젯 — 올바른 예

<!-- When a third-party widget auto-plays, provide a host-level mute control -->
<button
  id='mute-widget-audio'
  aria-label='Mute podcast player'
  aria-pressed='false'
  onclick='muteWidget()'
>
  Mute Podcast
</button>

<iframe
  id='podcast-frame'
  src='https://embed.example.com/podcast/ep42?autoplay=1'
  title='Episode 42: Web Accessibility Deep Dive'
  allow='autoplay'
></iframe>

<script>
  function muteWidget() {
    <!-- postMessage API used to communicate with cross-origin iframe player -->
    var frame = document.getElementById('podcast-frame');
    var btn = document.getElementById('mute-widget-audio');
    var isMuted = btn.getAttribute('aria-pressed') === 'true';
    frame.contentWindow.postMessage({ action: isMuted ? 'unmute' : 'mute' }, 'https://embed.example.com');
    btn.setAttribute('aria-pressed', String(!isMuted));
    btn.setAttribute('aria-label', isMuted ? 'Mute podcast player' : 'Unmute podcast player');
  }
</script>

<!-- Note: host-level volume/mute control satisfies 1.4.2 when
     the iframe player's own controls may be inaccessible. -->

자주 발생하는 실수

  • 오디오 정지 버튼으로 <div><span>을 사용하면서 tabindex='0', role='button', 키보드 이벤트 핸들러를 추가하지 않는 경우. 이러한 요소는 키보드 내비게이션과 스크린 리더에 보이지 않아, 가장 필요한 사용자에게 컨트롤이 무용지물이 된다.
  • 오디오 컨트롤을 DOM에서 메인 콘텐츠 뒤에 배치하는 경우. 이 경우 키보드 사용자는 그 컨트롤에 도달하기 전에 수십 개의 링크와 폼 필드를 탭으로 지나가야 하며, 그때쯤이면 오디오는 이미 1분 이상 재생되었을 수 있다. 컨트롤은 페이지에서 첫 번째 또는 두 번째 포커스 가능한 요소여야 한다.
  • HTML muted 속성으로 기본적으로 오디오를 음소거해 두고 이를 준수로 간주하는 경우. 음소거된 자동 재생 오디오 요소는 사용자 조작이 가능한 컨트롤이 아니다. 사용자는 오디오가 존재하는지 알 수 없고, 자신의 볼륨 선호를 선택할 수 없다.
  • window.AudioContext.destination.gain을 호출해 시스템 오디오 수준을 변경하는 볼륨 슬라이더를 제공하는 경우. 이는 특정 미디어 요소의 .volume 속성만 조정해야 하는 독립성 요구 사항을 충족하지 못한다.
  • 모바일 브라우저가 자동 재생을 차단한다고 가정하고 컨트롤을 제공하지 않는 경우. 많은 모바일 브라우저는 오디오가 비디오 요소에 포함되어 있거나 사용자가 이전에 해당 도메인과 상호작용한 경우 자동 재생을 허용한다. 브라우저 동작을 가정하지 말고 항상 컨트롤을 구현해야 한다.
  • 버튼 상태가 변경될 때 접근 가능한 레이블을 업데이트하지 않는 경우. 오디오를 다시 재생하는 버튼이 되었음에도 여전히 "Pause"로 레이블링된 버튼은 aria-label을 "Play"로 업데이트해야 한다 — 그렇지 않으면 스크린 리더 사용자는 잘못된 안내를 듣고 잘못된 동작을 실행할 수 있다.
  • 브라우저의 기본 미디어 컨트롤(controls 속성)에만 의존하면서, 자동 재생 오디오가 방해가 되기 전에 이 컨트롤이 나타나는지 확인하지 않는 경우. 기본 컨트롤은 미디어 요소 아래에 렌더링되며, 이는 화면 아래쪽(폴드 아래)에 있을 수 있어, 상당한 방해가 발생하기 전에 키보드로 도달할 수 없게 만든다.
  • 광고 네트워크를 통해 제공되는 오디오 재생 광고를 테스트하지 않는 경우. 페이지 로드 후 동적으로 삽입되는 광고 슬롯도 페이지 경험의 일부이며 1.4.2의 적용을 받는다. 광고 네트워크가 준수를 보장할 수 없다면, 페이지 전체에 대한 글로벌 음소거 컨트롤을 제공해야 한다.
  • 3초 예외를 악용해 연속 오디오 트랙을 3초 미만의 세그먼트로 나누는 경우. WCAG의 의도는 명확하다. 기술적으로 어떻게 분할되었는지와 관계없이, 연속적으로 재생되거나 반복되는 오디오는 이 기준의 적용을 받는다.
  • 오디오 컨트롤에 눈에 보이는 포커스 표시를 제공하지 않는 경우. 컨트롤이 키보드로 도달 가능하더라도, 시력이 있는 키보드 사용자는 포커스 링이 없으면 이를 찾을 수 없다. 이는 이 기준의 사용성 의도와 WCAG 2.4.7(포커스 표시) 모두를 위반한다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보 제32933호에 게재되었으며, 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 WCAG 2.2와 정렬된 의무적인 웹 접근성 요구 사항을 수립한다. WCAG 1.4.2 — Audio Control은 레벨 A 기준으로, 가장 기초적인 요구 사항 계층에 속한다. 레벨 A 기준을 준수하지 않는 것은 이 대통령령 하에서 기본적인 실패에 해당한다.

대통령령은 다음과 같은 준수 기한을 규정한다. 공공 기관은 대통령령 공포일로부터 1년 이내에 레벨 A 전 항목을 완전히 준수해야 하며, 규제 대상인 민간 부문 기관2년의 준수 기간을 가진다.

다음 유형의 기관은 대통령령에 의해 명시적으로 포함되며, 따라서 WCAG 1.4.2를 준수해야 한다:

  • 모든 수준의 공공 기관 및 정부 기관 — 부처, 지방자치단체, 공공이 디지털 서비스를 이용하는 국가 산하 기관을 포함한다.
  • 터키에서 운영되는 전자상거래 플랫폼 — 마켓플레이스 운영자와 직접 소비자 대상 온라인 소매업체를 포함한다.
  • 터키 은행법의 규제를 받는 은행 및 금융 기관 — 온라인 뱅킹 포털, 모바일 웹 인터페이스, 디지털 상품 페이지를 포함한다.
  • 병원 및 의료 서비스 제공자 — 민간 병원 그룹과, 환자가 예약을 잡고, 기록에 접근하며, 건강 정보를 받는 공공 보건 포털을 포함한다.
  • 20만 명 이상의 가입자를 보유한 통신사 — 고객 대상 웹사이트, 셀프 서비스 포털, 프로모션 페이지가 모두 준수해야 한다.
  • 터키 소비자를 대상으로 하는 여행사 및 온라인 여행 플랫폼 — 예약 엔진과 여행지 콘텐츠 페이지를 포함한다.
  • 온라인으로 승차권 발권 및 승객 정보 서비스를 제공하는 민간 운송 회사.
  • 국가교육부(MoNE)의 인가를 받은 사립학교 — 입학 포털, 학습 관리 시스템, 정보 제공 웹사이트를 포함한다.

이 모든 기관에 대해, 자동으로 오디오를 재생하면서 — 은행 홈페이지의 홍보 영상, 전자상거래 상품 페이지의 배경 사운드트랙, 정부 포털에 삽입된 뉴스 클립 등 — 접근 가능하고 키보드로 도달 가능한 일시 정지 또는 볼륨 컨트롤을 제공하지 않는 페이지는 WCAG 1.4.2와 대통령령 2025/10이 부과하는 의무를 모두 직접적으로 위반하는 것이다. 규제 대상 기관은 모든 페이지 템플릿에서 자동 재생 미디어를 점검하고, 규정 준수 컨트롤을 해당 기한 훨씬 이전에 구현해 규제상의 지적을 피하고 모든 사용자를 공평하게 지원할 것을 강력히 권고한다.