WCAG 2.5.1: 포인터 제스처

WCAG 2.5.1은 멀티포인트나 경로 기반 제스처(예: 핀치 투 줌 또는 스와이프)를 사용하는 모든 기능이, 제스처가 필수적인 경우를 제외하고는 경로 기반 제스처 없이도 단일 포인터로 조작 가능해야 한다고 요구합니다. 이는 복잡한 터치 제스처를 안정적으로 수행하기 어려운 운동 장애가 있는 사용자를 보호합니다.

이 규칙의 의미

WCAG 2.5.1 Pointer Gestures는 웹 페이지에서 멀티포인트 제스처(두 손가락으로 확대/축소하는 핀치 제스처, 세 손가락 스와이프처럼 두 개 이상의 터치 포인트를 동시에 사용하는 제스처)나 경로 기반 제스처(스와이프, 특정 경로를 따라 드래그, 도형 그리기처럼 포인터가 이동한 경로가 중요한 제스처)에 의존하는 모든 기능은, 경로 기반 제스처를 요구하지 않는 단일 포인터만으로도 조작 가능해야 한다고 요구한다. 단일 포인터란 하나의 지점에서 동작하는 모든 입력을 의미하며, 여기에 한 손가락 터치, 마우스 클릭, 스타일러스 탭 등 유사한 입력이 포함된다.

실질적으로, 캐러셀이 사용자가 가로로 스와이프할 때 슬라이드를 넘기도록 되어 있다면, 한 번의 탭이나 클릭으로 활성화할 수 있는 다음/이전 버튼도 제공해야 한다. 커스텀 지도 위젯이 두 손가락 핀치 제스처로만 확대/축소에 반응한다면, 한 번의 탭만으로 동작하는 확대/축소 컨트롤도 제공해야 한다. 이 기준은 멀티포인트나 경로 기반 제스처를 금지하는 것이 아니라, 항상 동등한 단일 포인터 대안이 존재해야 한다는 점만 요구한다.

공식 WCAG 예외는 다음과 같이 규정한다. 멀티포인트 또는 경로 기반 제스처가 본질적(essential)인 경우에는 이 요구 사항이 적용되지 않는다. 본질적인 제스처란, 이를 제거하면 정보나 기능이 근본적으로 달라지고, 텍스트나 다른 대안으로는 동일한 목적을 달성할 수 없는 경우를 말한다. 자유형 서명 위젯이나, 그려진 경로 자체가 출력이 되는 드로잉 애플리케이션은 본질적인 제스처에 해당한다. 그러나 대부분의 내비게이션, 캐러셀, 지도, 슬라이더 상호작용은 간단한 탭/클릭 대안으로 정보 손실 없이 재현할 수 있기 때문에 이 예외에 해당하지 않는다.

이 기준은 모든 포인터 입력에 적용된다. 터치스크린, 마우스, 스타일러스, 시선 추적 포인터, 그 밖의 모든 포인팅 장치가 포함된다. 이는 WCAG 2.2에서 레벨 A 요구 사항으로, 최소 준수를 위해 반드시 충족해야 하는 기본적인 접근성 요구 사항으로 간주된다.

통과하는 구현은 제스처에 의존하는 모든 기능을 단일 포인터, 비경로 기반 활성화(일반적으로 눈에 보이는 버튼, 링크, 기타 포커스 가능한 컨트롤)를 통해 수행할 수 있는 메커니즘을 최소 하나 이상 제공한다. 실패하는 구현은 스와이프, 핀치, 벌리기(spread), 회전, 경로 그리기 제스처에만 전적으로 의존해 기능을 수행하고, 이에 상응하는 단일 포인터 대안을 제공하지 않는 경우이다.

왜 중요한가

운동 장애는 전 세계 인구의 상당 부분에 영향을 미친다. 파킨슨병, 본태성 떨림, 뇌성마비, 뇌졸중 관련 편마비, 사지 차이, 반복성 긴장성 손상과 같은 상태는 사용자가 정교한 멀티포인트 또는 경로 기반 제스처를 안정적으로 수행하는 것을 어렵거나 불가능하게 만들 수 있다. 세계보건기구(WHO)에 따르면, 전 세계 약 13억 명이 어떤 형태로든 중대한 장애를 가지고 있으며, 이 중 운동 및 이동 장애는 가장 흔한 범주에 속한다. 웹 인터페이스가 복잡한 제스처에만 의존할 때, 이러한 사용자들은 시력이 있고 장애가 없는 사용자가 당연하게 여기는 기능에서 완전히 배제된다.

구체적인 실제 상황을 생각해 보자. 본태성 떨림이 있는 한 사용자가 태블릿으로 터키의 전자상거래 사이트를 둘러보고 있다. 상품 이미지 갤러리는 사진을 넘기기 위해 스와이프 제스처만 사용한다. 사용자는 깔끔한 수평 스와이프를 안정적으로 수행할 수 없고, 떨림 때문에 실수로 탭을 하거나, 대각선으로 움직이거나, 의도치 않은 다중 손가락 터치를 하게 된다. 이전/다음 버튼이 없다면, 이 사용자는 추가 상품 사진을 볼 수 없고 결국 구매를 포기할 수도 있다. 단 두 개의 간단한 화살표 버튼을 추가하는 데 개발팀이 드는 시간은 몇 분에 불과하지만, 이 사용자에게는 완전한 장벽을 제거하는 효과가 있다.

운동 장애를 넘어, 이 기준은 단일 포인터를 에뮬레이션하는 상지(팔) 보조기나 단일 스위치 접근 장치를 사용하는 사용자, 회전이나 멀티터치가 기계적으로 어려운 휠체어 장착 기기에서 장치를 조작하는 사용자, 복잡한 터치 제스처가 직관적이지 않거나 배우기 어려운 고령 사용자에게도 도움이 된다. 마우스나 비터치 스타일러스로 장치를 조작하는 사용자 역시 직접적인 영향을 받는데, 이러한 입력 방식은 본질적으로 단일 포인터이며 멀티포인트 제스처를 전혀 수행할 수 없다.

사용성 및 비즈니스 관점에서, 명시적인 단일 포인터 컨트롤(버튼, 링크)을 제공하는 것은 모든 사용자의 발견 가능성을 높이고, 인지적 부담을 줄이며, 작업 완료율과 전환 지표에 긍정적으로 기여할 수 있다. 검색 엔진은 제스처 기반 상호작용보다 버튼 기반 내비게이션을 더 안정적으로 파싱하고 따라갈 수 있어, 크롤링 가능한 내비게이션 패턴에 대해 부가적인 SEO 이점도 제공한다.

테스트 방법

기본선으로 자동 스캔 실행: axe DevTools, Lighthouse 또는 Accsible 위젯의 내장 감사 기능을 사용해 페이지를 스캔한다. 2.5.1에 직접 매핑되는 규칙은 없지만, 스캔 결과는 수동 검토에 참고가 되는 관련 문제(포커스 가능한 컨트롤 누락 등)를 표시할 수 있다. 키보드 또는 포인터 지원 누락으로 표시된 모든 인터랙티브 요소를 기록한다.
제스처 의존 기능 식별: 터치 기기에서 페이지를 수동으로 탐색한다(또는 Chrome DevTools의 브라우저 기기 에뮬레이션 사용 — 디바이스 툴바를 토글하고 시뮬레이션된 터치로 상호작용). 캐러셀, 슬라이더, 지도, 아코디언, 이미지 갤러리, 스크롤 가능한 패널, 드래그 앤 드롭 인터페이스, 드로잉 도구 등 터치 제스처에 반응하는 모든 컴포넌트를 찾는다. 스와이프, 핀치, 회전, 기타 경로 기반 또는 멀티포인트 제스처로 트리거되는 모든 기능을 문서화한다.
단일 포인터 대안 시도: 식별된 각 제스처 의존 기능에 대해, 단일 탭(또는 데스크톱의 마우스 클릭)만 사용해 동일한 기능을 수행할 수 있는지 시도한다. 동일한 결과를 트리거하는 버튼, 화살표, 링크 등의 눈에 보이는 컨트롤이 있는지 확인한다. 마우스, 키보드(Tab으로 포커스 이동, Enter/Space로 활성화), 스크린 리더를 사용해 해당 컨트롤을 조작해 본다.
스크린 리더 검증(NVDA + Firefox): NVDA와 Firefox를 실행한다. Tab과 화살표 키를 사용해 인터랙티브 컴포넌트를 탐색한다. 제스처 기반 기능을 위한 단일 포인터 컨트롤(버튼, 링크)이 스크린 리더에 의해 안내되는지, 키보드로 도달 가능한지, 활성화 시 예상 결과를 내는지 확인한다.
스크린 리더 검증(VoiceOver + iOS의 Safari): iPhone 또는 iPad에서 VoiceOver를 활성화한다. 한 손가락으로 오른쪽으로 스와이프해 요소를 탐색한다. 제스처에 대한 단일 포인터 대안을 제공하는 모든 컨트롤이 VoiceOver의 탭 제스처로 도달 및 활성화 가능하며, 올바른 결과를 내는지 확인한다.
스크린 리더 검증(JAWS + Chrome): Windows에서 JAWS와 Chrome을 사용한다. 인터랙티브 컴포넌트를 Tab으로 이동하며, 제스처 대체 컨트롤이 포커스 가능하고, 적절히 레이블링되어 있으며, 기능하는지 확인한다.
본질적 예외 평가: 단일 포인터 대안이 없는 제스처 의존 기능에 대해, 해당 제스처가 콘텐츠나 기능에 진정으로 본질적인지 판단한다. 예외를 정당화할 수 없다면 실패로 기록한다. 스크린샷과 재현 단계와 함께 결과를 문서화한다.

수정 방법

스와이프 전용 내비게이션을 사용하는 이미지 캐러셀 — 잘못된 예

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

스와이프 전용 내비게이션을 사용하는 이미지 캐러셀 — 올바른 예

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

핀치 투 줌만 지원하는 지도 — 잘못된 예

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

핀치 투 줌만 지원하는 지도 — 올바른 예

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

드래그 경로 제스처만 지원하는 범위 슬라이더 — 잘못된 예

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

드래그 경로 제스처만 지원하는 범위 슬라이더 — 올바른 예

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

자주 발생하는 실수

이전/다음 버튼 컨트롤 없이 스와이프 전용 캐러셀만 제공: 많은 캐러셀 라이브러리는 제스처 지원만 기본 제공하며, 단일 포인터 대안을 제공하려면 개발자가 내비게이션 버튼을 명시적으로 설정하고 렌더링해야 한다.
CSS 미디어 쿼리로 터치 기기에서 내비게이션 버튼을 숨김: 일반적인 패턴으로, 터치 기기라고 가정되는 화면에서 화살표 버튼을 숨긴다(예: @media (pointer: coarse)). 이로 인해 터치스크린에서도 해당 버튼에 의존하는 운동 장애 사용자의 단일 포인터 대안이 사라진다.
지도 확대/축소를 위한 두 손가락 핀치 제스처에만 의존하고 확대/축소 버튼을 제공하지 않음: 서드파티 지도 임베드(커스텀 구현 포함)는 확대/축소 컨트롤을 생략하는 경우가 많아, 핀치가 유일한 확대/축소 메커니즘이 된다.
대체 액션 버튼 없이 스와이프 삭제 또는 스와이프 노출 패턴만 사용: 웹 앱의 리스트 항목이 수평 스와이프를 통해서만 삭제 또는 액션 옵션을 노출하는 경우, 스와이프를 안정적으로 수행할 수 없는 사용자를 위한 탭 기반 동등 메커니즘이 없다.
키보드 또는 클릭 기반 재정렬 대안이 없는 커스텀 드래그 앤 드롭 인터페이스: 드래그 상호작용은 본질적으로 경로 기반이다. 위/아래 버튼이나 잘라내기-붙여넣기 모델 같은 대체 메커니즘을 제공하지 않으면 이 기준을 위반하게 된다.
그려진 경로 자체가 출력이 아닌 드로잉 또는 서명 위젯: 개발자는 실제로는 단순 UI 컨트롤(예: 콘텐츠를 노출하기 위한 제스처 잠금 패턴)에 불과한 위젯에 대해, 진정한 자유형 입력 도구가 아님에도 “본질적” 예외를 잘못 적용하는 경우가 있다.
단일 포인터 대체 컨트롤을 기본적으로 보이는 뷰포트 밖이나 접힌 상태에 배치: 동등한 버튼이 DOM에 존재하더라도 시각적으로 숨겨져 있거나 추가 상호작용을 통해서만 노출된다면, 인지 가능하고 조작 가능한 단일 포인터 대안 요구 사항을 완전히 충족하지 못한다.
포인터 이벤트를 가로채고 기본 동작을 막는 제스처 라이브러리 구현: 터치 이벤트에서 event.preventDefault()를 호출하는 라이브러리는 브라우저의 자체 단일 포인터 상호작용과 스크롤을 의도치 않게 차단해, 제스처 기준을 넘어서는 추가적인 실패를 초래할 수 있다.
제스처 전용 영역에 aria-label만 추가하면 충분하다고 가정: 스와이프 영역에 레이블을 추가하는 것은 단일 포인터 대안을 제공하는 것이 아니라, 여전히 제스처 없이는 조작할 수 없는 영역을 스크린 리더 사용자에게 설명만 해 줄 뿐이다.
실제 기기나 터치 시뮬레이션으로 테스트하지 않음: 마우스가 있는 데스크톱에서만 테스트하는 개발자는, 데스크톱에서는 마우스 클릭 폴백이 우연히 동작하지만 터치 전용 코드 경로에는 클릭 대안이 없는 탓에, 어떤 기능이 모바일에서 제스처 전용으로 동작한다는 사실을 전혀 발견하지 못할 수 있다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 웹 및 모바일 접근성 의무를 규정한다. 이 대통령령은 WCAG 2.2를 규범적 기술 표준으로 채택하고 있으며, 모든 레벨 A 성공 기준 — WCAG 2.5.1 Pointer Gestures를 포함 — 을 법적으로 의무적인 기본 요구 사항으로 만든다.

대통령령에 따른 준수 일정은 단계적으로 구성되어 있다. 공공 기관과 공공 단체는 대통령령 발효 후 1년 이내에 준수해야 하며, 규제 대상 민간 부문은 완전한 준수에 도달하기 위해 2년의 기간이 주어진다. 준수하지 않을 경우, 해당 기관은 관련 감독 당국의 규제 조사와 집행 조치에 노출될 수 있다.

대통령령의 적용 대상에는 터키 디지털 서비스 제공자의 광범위한 범주가 포함된다. 모든 수준의 정부 공공 기관과 그 산하기관이 포함된다. 민간 부문에서는, 전자상거래 플랫폼과 마켓플레이스, 은행 및 금융 기관, 민간 병원과 의료 서비스 제공자, 가입자 200,000명 이상인 통신 회사, 여행사, 민간 여객 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받아 운영하는 민간 학교가 대통령령의 적용을 받는다.

이러한 조직에게 WCAG 2.5.1은 직접적이고 실질적인 영향을 미친다. 터키 전자상거래 사이트는 제스처 기반 상품 이미지 갤러리, 스와이프 기반 카테고리 내비게이션, 핀치 투 줌 상품 뷰어를 자주 사용하며, 이제 이들 모두에 단일 포인터 대안이 필요하다. 제스처 기반 인증 패턴이나 드래그 기반 거래 인터페이스를 사용하는 은행 및 금융 애플리케이션은 감사와 개선이 필요하다. 핀치 줌을 사용하는 지도 기반 클리닉 찾기 기능이 있는 의료 포털은 확대/축소 버튼을 제공해야 한다. 스와이프 기반 요금제 선택기를 사용하는 통신사 셀프 서비스 포털은 탭 기반 컨트롤을 추가해야 한다.

터키에서 운영하는 조직은 WCAG 2.5.1을 즉시 접근성 감사 체크리스트에 포함할 것을 강력히 권고받는다. 이 기준의 영향을 받는 제스처 상호작용 패턴은 현대의 반응형 웹 디자인과 모바일 우선 개발에서 매우 널리 사용되지만, 대다수 사용자에게는 정상적으로 동작하는 것처럼 보이기 때문에 종종 간과된다. 이 기준을 WCAG 2.2 레벨 A 준수 프로그램의 일부로 선제적으로 해결하는 것은 대통령령 2025/10에 따른 법적 의무이자, 운동 장애가 있는 터키 사용자들의 디지털 포용을 실질적으로 개선하는 조치이다.