WCAG 2.2.4: 방해 요소

WCAG 2.2.4는 사용자에게 긴급 상황이 포함된 경우를 제외하고, 알림, 통지, 자동 콘텐츠 업데이트와 같은 모든 방해 요소를 연기하거나 차단할 수 있도록 할 것을 요구합니다. 이 기준은 작업 중 예기치 않은 방해로 인해 심각한 방해를 받을 수 있는 주의력, 인지, 또는 신경학적 장애가 있는 사용자에게 필수적입니다.

이 규칙의 의미

WCAG 2.2.4: Interruptions(방해 요소)는 지침 2.2(충분한 시간) 아래의 AAA 수준 성공 기준이다. 이 기준은 다음과 같이 규정한다. “긴급 상황이 수반되는 방해를 제외하고, 사용자는 방해를 연기하거나 차단할 수 있어야 한다.” 실질적으로 이는, 사용자가 직접 시작하지 않았는데도 나타나는 모든 콘텐츠, 알림, 통지, 대화 상자, 업데이트는 — 화재 경보, 생명을 위협하는 의료 경보, 치명적인 시스템 장애와 같은 실제 긴급 상황을 전달하는 경우가 아니라면 — 사용자가 이를 연기하거나 비활성화할 수 있는 메커니즘을 제공해야 함을 의미한다.

WCAG에서 말하는 방해(interruption)란, 사용자의 현재 행동과 독립적으로 발생하여 사용자가 하고 있는 일에서 주의를 돌리게 만드는 모든 사건을 의미한다. 여기에는 다음이 포함되지만 이에 한정되지는 않는다: 토스트 알림, 푸시 알림, 자동으로 열리는 채팅 위젯, 새로고침되거나 변경되는 상태 배너, 자동 재생 미디어, JavaScript로 삽입되는 라이브 리전 공지, 타이머에 의해 트리거되는 모달 대화 상자, 세션 중간에 나타나는 쿠키 동의 배너. 이 기준은 이러한 패턴을 전면 금지하는 것이 아니라, 사용자에게 이를 제어할 수 있는 권한을 부여할 것을 요구한다.

페이지가 2.2.4를 준수하려면, 긴급 상황이 아닌 모든 방해 요소에 대해 다음 중 최소 하나가 제공되어야 한다. 방해가 발생하기 전에 이를 비활성화할 수 있는 사용자 접근 가능한 설정, 방해 요소 자체 안에 포함된 닫기 또는 연기 메커니즘, 혹은 이러한 방해를 전면적으로 차단하는 사이트 전역 수준의 환경설정. 페이지가 미준수가 되는 경우는, 방해 요소가 자동으로 나타나고, 닫기나 연기 메커니즘을 제공하지 않으며, 긴급 상황과 관련이 없을 때이다. 예를 들어, 10초 후 자동으로 확장되지만 닫기 버튼이 없는 라이브 채팅 버블, 또는 마케팅 메시지를 순환 재생하면서 사용자가 중단시킬 수 없는 알림 배너는 모두 미준수 사례에 해당한다.

명시적으로 정의된 유일한 예외는 긴급 상황이다. 건강, 안전, 생명에 대한 위험을 전달하기 위해 반드시 사용자를 방해해야 하는 콘텐츠 — 예를 들어, 병원 포털에서 전송되는 치명적인 약물 관련 경보 — 는 사용자의 환경설정을 무시하고 나타날 수 있다. 이 예외는 의도적으로 매우 좁게 정의되어 있다. 일상적인 마케팅 메시지, 충분한 시간이 남아 있는 세션 만료 경고, 우선순위가 낮은 상태 업데이트 등은 긴급 상황에 해당하지 않는다.

WCAG 2.2.4는 AAA 수준이므로, 기본 적합성 주장에 필수는 아니지만, 완전한 포용을 지향하는 조직에게는 의미 있는 기준이다. 이 기준은 모든 웹 콘텐츠에 적용된다. 데스크톱 및 모바일 웹 애플리케이션, JavaScript 기반 알림을 사용하는 단일 페이지 애플리케이션(SPA), Web Notifications API를 활용하는 프로그레시브 웹 앱(PWA) 등이 모두 포함된다.

왜 중요한가

웹페이지에서의 예기치 않은 방해 요소는 단순히 성가신 수준을 넘어 — 많은 사용자에게는 작업 완료를 가로막는 심각한 장벽이며, 경우에 따라 직접적인 건강 위험이 되기도 한다.

인지 및 주의력 관련 장애가 있는 사용자 — ADHD, 외상성 뇌손상, 자폐 스펙트럼 상태, 치매 등을 포함 — 는 집중을 유지하기 위해 안정적이고 예측 가능한 환경에 크게 의존한다. 갑작스러운 알림이나 애니메이션 경보는 이들의 집중을 완전히 깨뜨려, 복수 단계로 이루어진 절차(복지 신청서 작성, 의료 기록 검토, 세금 신고서 작성 등)의 흐름을 잃게 만들 수 있다. 방해 이후 다시 방향을 잡는 데 걸리는 시간은 신경학적으로 전형적인 사용자보다 훨씬 길 수 있으며, 어떤 경우에는 아예 원래 위치를 찾지 못할 수도 있다.

스크린 리더 사용자는 동적인 방해 요소의 영향을 특히 크게 받는다. 라이브 리전이나 ARIA alert가 DOM에 삽입되면, NVDA, JAWS, VoiceOver와 같은 스크린 리더는 이를 즉시 공지하도록 설계되어 있어, 보조 기술이 현재 읽고 있던 내용을 중단시킨다. 사용자가 중요한 안내 문단을 듣고 있는 도중에 마케팅 토스트가 문장 중간에 발생하면, 스크린 리더는 문단 읽기를 포기하고 알림을 공지한다. 사용자는 다시 돌아가서 자신의 위치를 찾고, 내용을 다시 읽어야 하는데 — 키보드와 음성만으로 탐색하는 사람에게 이 과정은 생각보다 훨씬 더 큰 부담이다.

불안 장애와 PTSD가 있는 사용자는 갑작스럽고 예기치 않은 시각적·청각적 변화로 인해 심박수 증가, 집중력 상실, 공황 등 신체적 스트레스 반응을 경험할 수 있다. 통제되지 않은 방해 요소 환경의 예측 불가능성은 이러한 사용자 집단에게 일부 웹사이트를 사실상 사용 불가능하게 만들 수 있다.

뇌전증이나 전정 기관 장애가 있는 사용자는 특정 유형의 방해 요소, 특히 깜빡이거나 빠르게 움직이는 요소로 인해 피해를 입을 수 있다. 지침 2.3은 발작 위험을 별도로 다루지만, 애니메이션 알림 배너나 예기치 않게 나타나는 자동 재생 비디오 알림은 두 기준 모두와 교차하는 문제다.

구체적인 상황을 생각해 보자. ADHD가 있는 사용자가 온라인 뱅킹 포털에서 계좌 간 이체를 하고 있다. 이체 금액과 입금 계좌 번호를 신중히 검토하는 중이다. 이때 화면 오른쪽 하단에서 프로모션 알림이 슬라이드 인되며, 스크린 리더 공지와 함께 애니메이션으로 등장한다. 사용자는 자신의 위치를 잃고, 애니메이션 때문에 포커스가 분산되어 닫기 버튼을 찾지 못한 채, 잘못된 금액을 제출해 버린다. 이는 가상의 극단 사례가 아니라, 이 기준을 무시할 때 충분히 예측 가능한 결과다.

장애 여부와 관계없이, 통제되지 않은 방해 요소는 모든 사용자의 사용성을 저해하고, 이탈률을 높이며(사용자를 괴롭히는 사이트는 곧 떠나게 된다), 방해 요소가 촉진하려던 행동의 전환율을 오히려 떨어뜨릴 수 있다. SEO 관점에서 높은 이탈률과 짧은 세션 시간은 검색 순위 신호를 악화시키는 경향이 있으므로, 접근성과 비즈니스 성과는 이 지점에서 일치한다.

테스트 방법

기본선으로 자동 스캔을 실행한다. Chrome 또는 Firefox에서 페이지를 열고 axe DevTools 또는 Lighthouse를 실행한다. 두 도구 모두 2.2.4 전용 규칙은 없지만, 자동 스캔을 통해 관련 문제 — 동적 콘텐츠에 대한 누락된 role, 잘못 구성된 라이브 리전, 대화 상자에서의 포커스 관리 문제 — 를 표시할 수 있다. 표시된 aria-live 리전이나 role='alert' 요소를 기록해 두었다가 수동으로 후속 검토한다.
페이지를 최소 2~3분간 수동으로 관찰한다. 아무것도 클릭하지 않은 채, 변경되거나 새로 나타나거나 스스로 공지하는 콘텐츠가 있는지 시각·청각적으로 관찰한다. 백그라운드에서 스크린 리더(NVDA+Firefox, 또는 macOS의 VoiceOver+Safari)를 실행하고, 자신의 행동으로 트리거되지 않은 공지가 있는지 듣는다. 각 방해 요소의 발생 시점과 내용을 기록한다.
알림을 자주 트리거하는 상호작용 흐름을 테스트한다. 해당되는 경우 애플리케이션에 로그인하고, 폼이나 다단계 프로세스로 이동하여 천천히 작성해 본다. 이때 발생하는 방해 요소 — 세션 만료 경고, 채팅 초대, 프로모션 배너, 진행 상황 업데이트, 구독 요청 등 — 를 기록한다. 각 방해 요소에 대해 키보드만 사용(Tab, Escape, Enter, Space)하여 닫거나 연기해 보며, 해제 후 포커스가 논리적인 위치로 돌아오는지 확인한다.
NVDA와 Firefox로 테스트한다. NVDA를 활성화하고 Firefox에서 페이지를 탐색한다. 현재 읽기 중인 내용을 방해하는 음성 출력이 있는지 주의 깊게 듣는다. 자동 알림이 발생하면 키보드 제어로 이를 닫아 보고, NVDA가 해제 확인을 공지하거나 포커스가 적절히 돌아오는지 확인한다.
JAWS와 Chrome으로 테스트한다. JAWS와 Chrome을 사용해 수동 관찰 및 상호작용 흐름 테스트를 반복한다. JAWS와 NVDA는 라이브 리전을 다루는 방식이 다르므로, 두 스크린 리더 모두에서 방해 요소가 일관되게 공지되고, 닫기 메커니즘이 정상 작동하는지 확인하는 것이 중요하다.
iOS의 VoiceOver와 Safari로 테스트한다. 모바일 기기 또는 시뮬레이터에서 VoiceOver와 Safari를 사용해 페이지를 탐색한다. 콘텐츠를 스와이프하며 방해 요소가 발생하는지 관찰한다. 터치 제스처(더블 탭으로 활성화)를 사용해 닫기 메커니즘을 테스트하고, 포커스가 의미 있는 위치로 돌아오는지 확인한다.
알림 환경설정 설정을 확인한다. 애플리케이션 내에서 사용자 프로필, 설정 패널, 접근성 환경설정 섹션 등을 찾아본다. 알림을 전역적으로 차단하거나 구성할 수 있는 제어가 존재하는지 확인하고, 이 설정을 활성화했을 때 이후 세션에서 실제로 방해 요소가 발생하지 않는지 테스트한다.
JavaScript 소스 또는 네트워크 활동을 검토한다. 브라우저 DevTools에서 세션 동안 Network 및 Console 탭을 관찰한다. DOM에 콘텐츠를 삽입하는 WebSocket 연결, 폴링 주기, setTimeout/setInterval 호출이 있는지 확인한다. 이들은 모두 잠재적인 방해 요소의 원인이며, 사용자 제어가 구현되어 있는지 추적해야 한다.

수정 방법

자동으로 열리는 채팅 위젯 — 잘못된 예

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

자동으로 열리는 채팅 위젯 — 올바른 예

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

통제 불가능한 마케팅 토스트 알림 — 잘못된 예

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

통제 불가능한 마케팅 토스트 알림 — 올바른 예

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

사용자 제어가 없는 세션 타임아웃 모달 — 잘못된 예

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

사용자 제어가 없는 세션 타임아웃 모달 — 올바른 예

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

일반적인 실수

프로모션 또는 우선순위가 낮은 메시지에 role='alert'를 사용하는 경우. alert role은 스크린 리더에 긴급성을 알리고, 현재 읽기를 즉시 중단시킨다. 마케팅 메시지, 팁, 기능 안내 등은 role='status' 또는 aria-live='polite'를 사용해야 하며, 이는 스크린 리더가 현재 출력을 마친 후에만 콘텐츠를 공지한다.
호버 또는 포커스 상태에서만 보이는 닫기 버튼을 제공하여 사실상 접근 불가능하게 만드는 경우. 닫기 메커니즘이 마우스 호버 시에만 나타난다면, 키보드만 사용하는 사용자와 스크린 리더 사용자는 이를 볼 수도, 접근할 수도 없다. 닫기 버튼은 항상 보이거나, 최소한 키보드 Tab 순서로 항상 도달 가능해야 한다.
알림을 닫은 후 포커스를 document.body로 되돌리는 경우. 알림이나 대화 상자를 닫은 후에는, 포커스가 의미 있고 맥락상 적절한 요소 — 일반적으로 방해 요소가 나타나기 전에 사용자가 상호작용하던 요소 — 로 돌아가야 한다. 포커스를 body에 떨어뜨리면, 스크린 리더 사용자는 페이지 전체를 다시 탐색해야 한다.
여러 개의 aria-live 리전을 동시에 트리거하는 경우. 여러 라이브 리전이 동시에 업데이트되면, 스크린 리더는 공지를 예측 불가능한 방식으로 큐에 넣거나 누락시킨다. 각 방해 요소는 신중하게 관리하여 한 번에 하나의 라이브 리전만 트리거되도록 하고, 가능한 경우 업데이트를 묶어서 처리해야 한다.
브라우저의 기본 알림 권한 프롬프트를 충분한 사용자 제어로 간주하는 경우. Web Notifications API에 대한 브라우저 권한 대화 상자는 OS 수준에서 동작하며, 애플리케이션 수준이 아니다. WCAG 2.2.4는 사용자가 브라우저 수준에서 사이트를 차단하는 것만이 아니라, 웹 애플리케이션 내부에서 알림을 관리할 수 있어야 함을 요구한다.
페이지를 새로 열 때마다 해제된 알림을 다시 표시하는 경우. 사용자가 알림을 닫았는데, 같은 페이지나 사이트의 다른 페이지로 이동할 때마다 다시 나타난다면, 닫기 동작은 무의미한 것이 된다. 환경설정은 최소한 세션 동안은 sessionStorage를 사용해, 영구적으로는 localStorage나 서버 측 환경설정을 사용해 유지되어야 한다.
일시 정지 제어 없이 회전 배너나 팁을 순환시키기 위해 setInterval을 사용하는 경우. 타이머 기반으로 새로고침되는 회전 콘텐츠는 방해 요소다. 스크린 리더 사용자가 읽는 도중 콘텐츠가 변경되면, 공지가 다시 시작된다. 이러한 캐러셀과 회전 배너는 재생/일시 정지 제어가 필요하며, 사용자 동의 없이 무한 반복되어서는 안 된다.
예기치 않은 스크롤 점프를 유발하는 위치에 알림을 DOM에 삽입하는 경우. 알림 배너를 페이지 상단에 삽입하여 페이지가 아래로 밀리면, 사용자는 시각적 읽기 위치를 잃게 된다. 알림은 사용자가 현재 보고 있는 콘텐츠의 레이아웃에 영향을 주지 않는 방식으로 삽입해야 하며, 일반적으로 fixed 또는 absolute 포지셔닝을 사용한다.
짧은 자동 해제 타이머만으로 기준을 충족한다고 가정하는 경우. 5초 후 사라지는 토스트는 사용자에게 의미 있는 제어를 제공하지 않는다 — 많은 사용자는 그 정도 시간 안에 콘텐츠를 읽고, 이해하고, 반응할 수 없으며, 특히 인지 장애가 있거나 스크린 리더를 사용하는 경우 더욱 그렇다. 사용자 제어 닫기 버튼 없이 자동 해제 타이머만 제공하는 것은 비준수다.
사용자의 운영체제나 브라우저에 감소된 모션 또는 알림 환경설정이 설정된 경우의 방해 요소 동작을 테스트하지 않는 경우. 일부 사용자는 OS 수준에서 모션 감소나 알림 억제를 설정한다. 애플리케이션은 이러한 신호를 존중해야 하며, 개발자는 prefers-reduced-motion: reduce 미디어 쿼리가 활성화된 상태에서 테스트하여 애니메이션 방해 요소가 적절히 억제되는지 확인해야 한다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보(번호 32933)에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 조직을 대상으로 구속력 있는 웹 접근성 프레임워크를 수립한다. 이 대통령령은 WCAG 2.2를 기술적 참조 표준으로 채택하고, 해당 주체에 대해 준수를 의무화한다. 대통령령에서 명시적으로 포함한 주체 유형에는 공공 기관 및 공공 단체, 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 보건 서비스 기관, 가입자 200,000명 이상 통신사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받아 운영되는 사립 학교가 포함된다.

WCAG 2.2.4: Interruptions는 AAA 수준 기준으로, 이는 대통령령 2025/10 하에서 대부분의 해당 주체에 요구되는 기본 적합성 요건에는 포함되지 않음을 의미한다. A 수준과 AA 수준 적합성을 달성하고 이를 선언한 조직은 대통령령의 최소 요건을 법적으로 충족한 것으로 간주된다. 그러나 2.2.4와 같은 AAA 수준 기준은 터키 시장 맥락에서 실질적·평판상 의미가 크다.

해당 주체 유형 중 일부 — 특히 병원, 은행, 공공 기관 — 는 인지 및 신경학적 상태, 불안 장애, 고령 관련 주의력 저하를 가진 사용자 비율이 높은 집단을 주로 대상으로 한다. 이러한 조직에서 디지털 인터페이스의 통제되지 않은 방해 요소는 단순한 접근성 실패를 넘어, 잠재적인 환자 안전 또는 재정적 피해 위험을 의미한다. 예를 들어, 병원 환자 포털이 중요한 폼 작성 흐름 중에 통제 불가능한 약 복용 알림이나 예약 알림을 발생시키거나, 은행 애플리케이션이 거래 검토 중에 차단할 수 없는 프로모션 배너를 표시하는 경우, 이러한 사용자 집단에 실제 피해를 초래한다.

터키에서 디지털 접근성 리더십을 입증하고자 하는 조직 — 특히 자발적으로 WCAG 2.2 AAA 수준 선언을 추구하거나, 공공 조달 접근성 요건에 대응하거나, 더 높은 기준을 설정한 유럽 접근성법(EAA) 적용 시장을 목표로 하는 조직 — 에게 2.2.4 구현은 의미 있는 차별화 요소다. Accsible 오버레이 SDK는 구성 가능한 알림 관리 기능, 사용자 환경설정 지속, 접근성 인지 위젯 동작을 제공함으로써, 터키 규제 기대와 국제 모범 사례 모두에 부합하는 높은 기준을 달성하도록 조직을 지원한다.