WCAG 2.5.4: 동작 작동

WCAG 2.5.4는 기기나 사용자의 움직임(예: 흔들기나 기울이기)에 의해 트리거되는 모든 기능이 일반적인 사용자 인터페이스 구성 요소를 통해서도 작동 가능해야 하며, 사용자가 실수로 기능이 활성화되는 것을 방지하기 위해 모션 작동을 비활성화할 수 있어야 한다고 요구한다.

이 규칙의 의미

WCAG 2.5.4 — Motion Actuation은 현대 웹 애플리케이션에서 점점 더 흔해지고 있는 특정 시나리오를 다룹니다. 예를 들어 스마트폰을 흔들거나, 기기를 기울이거나, 카메라 앞에서 제스처를 취하는 등의 물리적 기기 움직임으로 기능이 트리거되는 경우입니다. 이 기준은 적합성을 위해 반드시 모두 충족해야 하는 두 가지 병렬 요구 사항을 설정합니다.

첫째, 기기 움직임이나 사용자 움직임으로 조작할 수 있는 모든 기능은 사용자 인터페이스 구성 요소를 통해서도 조작할 수 있어야 합니다. 즉, 움직임에 의존하지 않는 버튼, 링크, 폼 컨트롤 또는 유사한 인터랙티브 요소를 의미합니다. 이는 물리적 움직임 제스처를 수행할 수 없거나 안정적으로 수행할 수 없는 사람들이 해당 기능에 완전히 접근하지 못하는 일이 없도록 보장합니다.

둘째, 사용자는 우발적이거나 비자발적인 움직임이 의도하지 않은 동작을 트리거하지 않도록 움직임 반응을 비활성화할 수 있어야 합니다. 이는 떨림(tremor)이나 기타 비자발적인 기기 움직임을 유발하는 운동 장애가 있는 사용자가 예기치 않은 애플리케이션 동작으로 인해 지속적으로 방해받지 않도록 보호합니다.

이 기준은 두 가지 구별되는 유형의 움직임에 적용됩니다. 스마트폰과 태블릿에 내장된 가속도계와 자이로스코프(예: DeviceMotionEvent와 DeviceOrientationEvent 같은 API를 통해 접근)를 통해 감지되는 기기 움직임(device motion)과, 기기 자체가 아니라 신체 움직임이나 제스처를 추적하는 카메라나 기타 입력 센서를 통해 감지되는 사용자 움직임(user motion)입니다.

통과하는 구현은 모든 움직임 기반 기능을 표준 UI 컨트롤(버튼, 링크 또는 동등한 요소)을 통해 제공하고, 사용자가 원할 경우 움직임 감지를 끌 수 있도록 합니다. 실패하는 구현은 기능에 대해 움직임만으로 접근할 수 있게 하고 대체 UI 컨트롤을 제공하지 않거나, 대체 수단은 제공하지만 비자발적인 움직임으로 인해 문제가 발생하지 않도록 움직임 트리거를 비활성화할 방법을 제공하지 않는 경우입니다.

WCAG 2.5.4는 두 가지 중요한 예외를 정의합니다. 움직임이 기능에 본질적(essential)이며 이를 비활성화하면 활동 자체가 근본적으로 달라지는 경우에는 Motion Actuation이 면제됩니다. 예를 들어, 움직임 추적이 핵심 목적이 되는 걸음 수 측정 피트니스 애플리케이션이나, 기울이기 메커니즘을 중심으로 설계된 게임이 이에 해당합니다. 두 번째 예외는 움직임이 지원되는 접근성 인터페이스(supported accessibility interface)를 통해 기능을 조작하는 데 사용되는 경우에 적용되며, 이때는 플랫폼 자체의 접근성 기능이 사용자가 독립적으로 제어하는 방식으로 움직임 상호작용을 처리합니다.

왜 중요한가

Motion actuation 장벽은 운동 및 이동 장애가 있는 사람들에게 특히 큰 영향을 미치지만, 그 영향 범위는 많은 개발자가 처음에 예상하는 것보다 훨씬 넓습니다. 누가, 어떻게 영향을 받는지 이해하는 것은 팀이 이 기준의 우선순위를 적절히 설정하는 데 도움이 됩니다.

떨림(tremor) 상태 — 본태성 떨림(essential tremor), 파킨슨병, 다발성 경화증 등을 포함 — 가 있는 사람들은 손과 팔에 지속적이거나 간헐적인 비자발적 움직임을 경험할 수 있습니다. 이들이 스마트폰을 들고 있을 때 자연스러운 떨림만으로도 흔들어서 실행하는 실행 취소 대화상자, 새로고침 동작 또는 기타 움직임 기반 기능이 반복적이고 예기치 않게 트리거될 수 있습니다. 세계보건기구(WHO)는 전 세계적으로 약 13억 명이 어떤 형태로든 상당한 장애를 가지고 살아가고 있다고 추정하며, 미세 운동 조절에 영향을 미치는 상태는 모든 연령대에서 가장 흔한 장애 유형 중 하나입니다.

마비나 사지 차이가 있는 사람들은 휠체어나 거치대에 기기를 장착해 사용하거나, 머리 포인터, 시선 추적, 스위치 컨트롤 등을 사용해 기기와 상호작용할 수 있습니다. 이러한 사용자는 기기를 전혀 흔들거나 기울일 수 없는 경우가 많아, 움직임만으로 제공되는 기능은 완전히 접근 불가능해집니다. 예를 들어 모바일 웹 애플리케이션에서 텍스트 입력을 실행 취소하는 유일한 방법이 기기를 흔드는 것뿐이라면, 휴대폰을 거치한 휠체어 사용자는 그 기능에 전혀 접근할 수 없습니다.

고령자 역시 크게 영향을 받는 집단입니다. 악력 감소, 관절염, 본태성 떨림 등 연령 관련 상태는 나이가 들수록 점점 더 흔해지며, 이는 점점 더 활발한 디지털 사용자이기도 한 인구 집단의 상당 부분이 정밀하거나 의도적인 움직임 제스처에 어려움을 겪을 수 있음을 의미합니다.

구체적인 실제 시나리오를 생각해 봅시다. 한 터키 전자상거래 사이트가 사용자가 휴대폰을 흔들면 임의의 상품 추천을 보여주는 “흔들어서 셔플(shake to shuffle)” 기능을 추가해, 탐색을 더 흥미롭게 만들었다고 가정합니다. 이 기능은 재미있고 새롭지만, 셔플을 트리거할 수 있는 버튼이 없고, 흔들기 감지를 끌 수 있는 방법도 없습니다. 파킨슨병이 있는 사용자가 그 사이트를 방문하면 자연스러운 떨림이 제스처를 트리거해 셔플이 계속 통제 불가능하게 활성화됩니다. 페이지가 계속 임의의 상품으로 이동하기 때문에 이 사용자는 차분하게 둘러볼 수 없습니다. 이 사용자는 사실상 정상적인 쇼핑 경험에서 배제된 것이며, 터키의 접근성 규제 하에서는 이것이 단순한 UX 문제가 아니라 법적 준수 실패에 해당합니다.

장애 접근성 외에도, 움직임 기능을 비활성화하거나 대체 수단을 제공하는 것은 기기 움직임이 신뢰하기 어려운 환경 — 대중교통, 사무실, 또는 사용자가 기기를 자유롭게 움직일 수 없는 모든 환경 — 에 있는 사용자 경험을 개선합니다.

테스트 방법

출발점으로서의 자동 스캔: 페이지에서 axe DevTools, Lighthouse 또는 Accsible 접근성 검사기를 실행합니다. 이 도구들은 2.5.4 위반을 자동으로 표시하지는 않지만, 관련 문제를 드러낼 수 있습니다. 표시된 항목을 기록한 뒤 수동 단계로 진행합니다. 자동 경고가 없다고 해서 페이지가 2.5.4를 통과했다는 의미는 아닙니다.
움직임 기반 기능 식별: Chrome DevTools를 열고 Elements 패널로 이동합니다. Sources 탭과 전역 검색(Ctrl+Shift+F)을 사용해 페이지의 JavaScript 소스 파일에서 devicemotion, deviceorientation, accelerat, gyro, shake 문자열을 검색합니다. 발견된 모든 인스턴스와 관련 기능을 문서화합니다.
UI 대체 수단 존재 여부 확인: 이전 단계에서 발견한 각 움직임 기반 기능에 대해, 기기 움직임 없이 키보드 탐색과 마우스 클릭만으로 동일한 동작을 수행해 보십시오. Tab, Enter, Space, 방향키를 사용해 인터페이스를 탐색합니다. 동일한 결과를 내는 조작 가능한 UI 컨트롤을 찾을 수 없다면 이 기준은 실패입니다.
움직임 비활성화 가능 여부 확인: 설정 메뉴, 환경설정 패널, 접근성 설정 또는 움직임 기능 전용 토글을 찾습니다. 움직임 조작을 비활성화해 보십시오. 그러한 컨트롤이 없거나, 움직임을 비활성화하면 UI 대체 수단도 함께 비활성화되는 경우 이 기준은 실패입니다.
실제 기기 테스트: 실제 스마트폰이나 태블릿에서 페이지를 로드합니다. 기기를 일부러 부드럽게 움직여(작고 지속적인 움직임으로 비자발적 떨림을 시뮬레이션) 기능이 의도치 않게 트리거되는지 관찰합니다. 그런 다음 사용 가능한 설정을 통해 움직임을 비활성화한 후 동일한 테스트를 시도합니다.
스크린 리더 및 키보드 테스트: Firefox와 NVDA, iOS의 Safari와 VoiceOver, 또는 Chrome과 JAWS를 사용해 키보드와 스크린 리더 명령만으로 페이지를 탐색합니다. 움직임을 통해 접근 가능한 모든 기능이 스크린 리더 탐색을 통해서도 접근 가능한지, 그리고 움직임 비활성화 컨트롤(있는 경우) 자체가 키보드로 접근 가능하고 적절히 레이블링되어 있는지 확인합니다.
브라우저 DevTools 기기 시뮬레이션: Chrome DevTools에서 Sensors 패널(More Tools > Sensors)을 열고 기기 방향 및 가속도계 시뮬레이션 컨트롤을 사용해 움직임 이벤트를 프로그래밍 방식으로 트리거합니다. 이를 통해 실제 기기 없이도 데스크톱에서 움직임 기반 동작을 테스트할 수 있습니다.

수정 방법

대체 수단 없는 흔들어서 새로고침 — 잘못된 예

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

대체 수단 있는 흔들어서 새로고침 — 올바른 예

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

비활성화 옵션 없는 기울여서 스크롤하는 캐러셀 — 잘못된 예

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

비활성화 옵션 있는 기울여서 스크롤하는 캐러셀 — 올바른 예

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

대체 수단 없는 카메라 제스처 기능 — 잘못된 예

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

대체 수단 있는 카메라 제스처 기능 — 올바른 예

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

자주 발생하는 실수

UI 대체 버튼은 제공하지만 움직임 비활성화 토글을 빠뜨리는 경우: 많은 개발자가 버튼 대체 수단은 추가하지만, 움직임 리스너를 끌 수 있는 방법을 구현하지 않습니다. 이 경우 기능은 기술적으로 다른 수단으로 조작 가능하더라도, 떨림이 있는 사용자는 여전히 원치 않는 활성화를 겪게 됩니다.
움직임 비활성화 옵션을 햄버거 메뉴나 깊숙한 설정 페이지에 숨기는 경우: 움직임을 비활성화하는 컨트롤 자체가 쉽게 도달 가능해야 합니다. 떨림이 있는 사용자가 비활성화 옵션에 도달하기 전에 다섯 단계의 메뉴를 탐색하는 동안 계속 흔들어서 새로고침이 트리거된다면, 그 비활성화 옵션은 실질적으로 접근 가능하지 않은 것입니다.
OS 수준의 “reduce motion” 환경설정이 2.5.4를 충족한다고 가정하는 경우: prefers-reduced-motion 미디어 쿼리와 OS 접근성 설정은 애니메이션과 전정기관(vestibular) 관련 문제를 다루지만, 웹 애플리케이션의 기기 움직임 이벤트 리스너를 자동으로 비활성화하지는 않습니다. 이는 코드에서 직접 처리해야 합니다.
움직임 임계값을 너무 낮게 설정하는 경우: DeviceMotionEvent 가속도 값에 매우 민감한 임계값을 사용하면, 작은 비자발적 떨림도 임계값을 넘을 수 있습니다. 임계값은 의도적이고 큰 움직임이 필요하도록 설정해야 하며, 그 경우에도 비활성화 옵션은 여전히 필요합니다.
window에 전역으로 움직임 리스너를 등록하고 제거하지 않는 경우: 리스너를 연결해 놓고 removeEventListener로 제거하는 코드 경로를 제공하지 않으면, 비활성화 토글은 동작을 조건부로만 억제할 수 있습니다. 토글이 실패하거나 페이지 새로고침 시 초기화되면 움직임은 계속 활성 상태로 남습니다.
움직임 비활성화 체크박스를 접근 불가능하게 만드는 경우: 비활성화 토글을 적절한 <input type='checkbox'>나 ARIA로 강화된 컨트롤 대신 스타일링된 <div>나 <span>에 click 리스너를 붙여 구현하면, 키보드 및 스크린 리더 사용자는 그들을 돕기 위해 마련된 바로 그 컨트롤에 도달하거나 조작할 수 없습니다.
사용자의 움직임 선호도를 세션 간에 유지하지 않는 경우: 사용자가 움직임 조작을 비활성화했는데 그 선호도가(localStorage나 사용자 계정 설정 등으로) 저장되지 않으면, 방문할 때마다 다시 비활성화해야 하며, 이는 가장 큰 영향을 받는 사용자에게 반복적인 부담을 줍니다.
본질적 기능 예외를 지나치게 넓게 적용하는 경우: “본질적(essential)” 예외는 범위가 좁습니다. 흔들어서 셔플하는 상품 갤러리는 본질적이지 않습니다. 셔플 기능은 쇼핑 사이트의 핵심 기능이 아니기 때문입니다. 팀이 구현 작업을 피하기 위해 이 예외를 잘못 적용하는 경우가 있습니다.
실제 물리 기기와 실제 움직임으로 테스트하지 않는 경우: 데스크톱 시뮬레이션 도구나 자동 스캔에만 의존하면, 사용자의 자연스러운 떨림이 있을 때 기능이 어떻게 동작하는지 등 실제 환경의 움직임 민감도 문제는 사용자 신고가 있기 전까지 발견되지 않습니다.
서드파티 SDK나 분석 라이브러리가 추가한 움직임 기능도 준수 대상이라는 점을 잊는 경우: 서드파티 채팅 위젯, 게이미피케이션 SDK, A/B 테스트 도구에 포함된 움직임 리스너도 여전히 페이지의 적합성 책임 범위에 속합니다. 서드파티 스크립트가 대체 수단 없이 devicemotion 리스너를 등록하면, 해당 페이지는 2.5.4를 위반하게 됩니다.

터키 접근성 규제와의 관계

터키의 2025/10호 대통령령(Presidential Circular No. 2025/10)은 2025년 6월 21일 관보(Official Gazette, No. 32933)에 게재되었으며, WCAG 2.2와 정렬된 의무 웹 접근성 요구 사항을 수립합니다. WCAG 2.5.4 Motion Actuation은 Level A 기준으로, 이 대통령령 하에서 가장 높은 우선순위의 의무 준수 계층에 속합니다.

이 대통령령은 공공 및 민간 부문의 광범위한 주체를 포괄합니다. 모든 중앙 및 지방 정부 기관, 부처, 공공 기관을 포함한 공공 기관은 대통령령 공포 후 1년 이내에 Level A 전면 적합성을 달성해야 합니다. 해당 범주에 속하는 민간 부문 주체는 2년 이내에 동일한 수준을 달성해야 합니다. 해당 민간 부문 범주에는 전자상거래 플랫폼 및 마켓플레이스, 은행 및 금융 기관, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받아 운영되는 민간 학교가 포함됩니다.

Motion actuation은 터키 디지털 서비스와 특히 관련이 깊습니다. 터키에서는 모바일 인터넷 사용률이 매우 높고, 웹 트래픽의 대부분이 스마트폰에서 발생하기 때문입니다. 따라서 모바일 우선 또는 모바일 전용 웹 애플리케이션이 모든 해당 부문에서 매우 일반적입니다. 터키의 전자상거래 사이트, 뱅킹 애플리케이션, 정부 포털이 흔들어서 새로고침, 기울이기 내비게이션, 제스처 기반 상호작용 또는 유사한 움직임 기능을 UI 대체 수단과 비활성화 컨트롤 없이 구현했다면, 이는 2025/10호 대통령령에 따른 의무 Level A 요구 사항을 직접적으로 위반하는 것입니다.

준수 로드맵을 준비하는 해당 주체는 Motion actuation을 보다 광범위한 모바일 접근성 감사의 일부로 평가해야 합니다. 자동 도구는 2.5.4 위반을 감지할 수 없으므로, 조직은 적합성 검증 과정의 일부로 자격을 갖춘 접근성 전문가에 의한 수동 테스트를 포함해야 합니다. 이 대통령령은 공포 이전에 구현된 기능에 대한 유예 기간을 포함하지 않고 — 단지 적합성 달성을 위한 일정만 제시하기 때문에 — 현재 해당 사이트에 배포된 모든 움직임 기반 기능은 적용되는 기한 내에 시정되어야 합니다.

대통령령의 요구 사항을 준수하지 않는 주체는 행정 제재를 받을 수 있으며, 각 부문별 관련 감독 기관의 집행 대상이 됩니다. 규제 리스크를 넘어, 트래픽이 많은 터키 모바일 사이트에서 2.5.4를 준수하지 않는 것은 운동 장애, 떨림이 있거나 보조 기술을 사용하는 수백만 사용자에게 실제 사용성 실패를 의미합니다. 이 인구 집단의 요구는 WCAG 2.2 Level A를 기준선으로 채택한 대통령령에 의해 명시적으로 인정되고 보호됩니다.