WCAG 3.2.5: 요청 시 변경

WCAG 3.2.5는 페이지 이동, 양식 제출, 콘텐츠 업데이트와 같은 컨텍스트 변경이 자동으로 트리거되지 않고, 명시적인 사용자 동작에 의해서만 시작되도록 요구합니다. 이는 스크린 리더, 키보드 내비게이션, 인지 지원 도구에 의존하는 사용자를 예기치 않은 방해로부터 보호하여, 그들의 탐색 경험이 방해받지 않도록 합니다.

이 규칙의 의미

WCAG 3.2.5 Change on Request는 Understandable(이해 가능) 원칙 아래의 AAA 수준 기준이다. 이 기준은 맥락의 변경은 반드시 사용자에 의해서만 시작되어야 하며, 시스템에 의해 자동으로 트리거되어서는 안 된다고 규정한다. WCAG에서 말하는 “맥락의 변경(change of context)”이란, 사용자가 한 번에 페이지 전체를 볼 수 없는 경우, 사용자의 인지 없이 발생하면 사용자를 혼란스럽게 만들 수 있는 웹 페이지 콘텐츠의 큰 변화를 의미한다. 여기에는 사용자 에이전트(브라우저), 뷰포트, 포커스, 또는 페이지의 의미를 크게 바꾸는 콘텐츠의 변경이 포함된다.

구체적으로, 이 기준은 명시적인 사용자 요청 없이 맥락의 변경을 일으키는 모든 메커니즘을 금지한다. 이는 자동 맥락 변경이 발생할 수 있는 나머지 모든 상황을 다룸으로써 3.2.1(On Focus)과 3.2.2(On Input)의 요구 사항을 확장한다. 여기에 포함되지만 이에 한정되지는 않는 예로는 자동 새로고침 페이지, 자동으로 슬라이드를 넘기며 다른 위치로 이동시키는 캐러셀, 짧은 지연 시간을 가진 메타 리다이렉트 태그, 폼 필드 입력 완료 시 JavaScript로 트리거되는 내비게이션, 사용자 개입 없이 새 창이나 새 탭을 여는 동작 등이 있다.

이 기준을 충족하려면 두 가지 조건 중 하나를 만족해야 한다. 첫째, 맥락의 변경이 명시적이고 의도적인 사용자 행동(예: 버튼이나 링크 활성화)에 의해서만 트리거되거나, 둘째, 자동 맥락 변경이 발생하기 전에 사용자가 이를 끌 수 있는 메커니즘을 제공해야 한다. 예를 들어, 페이지가 30초마다 자동 새로고침되며 새로운 콘텐츠로 이동한다면, 이는 실패에 해당한다. 단, 첫 번째 새로고침이 일어나기 전에 그 동작을 비활성화할 수 있는 명확한 레이블의 컨트롤이 제공되는 경우는 예외다. 사후에 경고만 제공하는 것은 충분하지 않다.

이 기준은 모든 인터랙티브 및 동적 웹 콘텐츠에 폭넓게 적용된다. 일반적으로 영향을 받는 요소와 동작에는 다음이 포함된다: <meta http-equiv='refresh'> 리다이렉트, 타이머에 의해 트리거되는 JavaScript의 window.location 또는 history.pushState 호출, 새로운 URL로 이동하는 <select> 요소의 onchange 이벤트 핸들러, 자동 제출되는 폼, 포커스에 의해 트리거되는 내비게이션, 그리고 사용자 입력 없이 자동으로 스크롤되거나 슬라이드를 넘기거나 보이는 콘텐츠 집합을 변경하는 모든 위젯.

중요한 공식 예외가 하나 있다. 맥락의 변경이 사용자가 명시적이고 인지적으로 설정한 환경설정에 대한 응답인 경우 — 예를 들어, 사용자 환경설정 패널에서 “1분마다 자동 새로고침”을 선택한 경우 — 이 자동 동작은 사용자가 요청한 것이므로 허용된다. 핵심적인 구분은 사용자가 자동 동작을 활성화하기 위해 정보에 기반한 의도적인 선택을 했는지, 아니면 예기치 않게 이를 마주했는지 여부이다.

왜 중요한가

예기치 않은 맥락의 변경은 웹에서 가장 혼란스러운 경험 중 하나이며, 그 영향은 장애 유형에 따라 크게 달라진다.

스크린 리더에 의존하는 시각장애 사용자에게 갑작스러운 페이지 내비게이션이나 콘텐츠 새로고침은 읽기 커서를 페이지의 완전히 다른 위치로 — 또는 맨 위로 — 아무런 안내 없이 이동시킬 수 있다. 사용자가 긴 글을 읽는 도중에 페이지가 자동으로 새로운 URL로 리다이렉트되면, 사용자는 자신의 위치를 완전히 잃고 무슨 일이 일어났는지, 어떻게 복구해야 하는지 이해하지 못할 수 있다. NVDA, JAWS, VoiceOver 같은 스크린 리더는 페이지 수준 내비게이션 이벤트를 항상 일관되거나 적시에 알리지 않기 때문에, 사용자는 자신이 어디에 있고 무엇이 바뀌었는지 혼란스러워할 수 있다.

키보드, 헤드 포인터, 스위치 장치, 시선 추적 기술로 탐색하는 운동장애 사용자에게 예기치 않은 포커스 변경은 치명적일 수 있다. 예를 들어, 폼이 이전 필드를 완료하자마자 자동으로 다음 필드로 넘어가면서 사용자 행동 없이 포커스가 프로그래밍적으로 이동하면, 사용자는 자신의 위치를 잃고 시스템이 자신을 어디로 데려갔는지 찾기 위해 힘들게 다시 탐색해야 할 수 있다. 입력 장치의 특성상 키 입력 하나하나에 상당한 신체적 노력이 필요한 사용자에게 이러한 재탐색은 실제적인 접근성 장벽이 된다.

주의력 결핍, 기억력 손상, 불안 장애 등을 포함한 인지장애 사용자는 예기치 않은 변경에 특히 취약하다. 자동 페이지 변경은 인터페이스에 대한 그들의 정신적 모델을 깨뜨린다. 안내문을 읽기 위해 잠시 멈췄다가 페이지가 다시 로드된 것을 발견한 사용자는 혼란스럽거나 불안감을 느끼기 쉽다. 이러한 방해는 거래를 완료하거나 정보를 독립적으로 소비하는 것을 불가능하게 만들 수 있다.

전정기관 장애가 있는 사용자에게 자동으로 넘어가는 캐러셀처럼 빠르고 예기치 않은 시각적 변화 — 특히 내비게이션까지 트리거하는 경우 — 는 어지러움, 메스꺼움 등 신체적 증상을 유발할 수 있다. 진단된 장애가 없는 시각 사용자에게도 예측 가능한 인터페이스는 이롭다. 연구에 따르면 예기치 않은 내비게이션은 모든 사용자 그룹에서 오류율과 작업 포기율을 일관되게 증가시키는 것으로 나타난다.

구체적인 실제 사례를 보자. 한 터키 전자상거래 사이트가 사용자가 드롭다운에서 값을 선택하는 즉시 상품 필터 폼을 자동 제출하여 새로운 검색 결과 URL로 이동시킨다. 여러 조건을 선택하기 위해 필터를 탭으로 이동하던 키보드 전용 사용자는 첫 번째 옵션을 선택하자마자 페이지가 다시 로드되고 필터 패널이 접히는 상황을 겪는다. 이 사용자는 패널을 다시 열고, 시작 위치로 다시 이동한 뒤 다시 시도해야 하며, 이는 기능을 사실상 사용할 수 없게 만드는 반복 루프가 될 수 있다. 세계보건기구(WHO)에 따르면 전 세계 약 13억 명이 어떤 형태로든 장애를 가지고 있으며, 이러한 패턴은 이들을 디지털 서비스에서 불균형적으로 배제한다.

사용성 및 SEO 관점에서도 자동 리다이렉트나 자동 새로고침이 있는 페이지는 이탈률이 더 높은 경향이 있다. 예기치 않은 동작을 경험한 사용자는 종종 페이지를 떠나기 때문이다. 또한 검색 엔진은 크롤러 세션과 사용자 세션 간에 다른 예기치 않은 리다이렉트를 페널티 대상으로 삼을 수 있으므로, 3.2.5를 준수하는 것은 기술적 SEO 위생 측면에서도 바람직하다.

테스트 방법

자동 스캔(기본선): 페이지에 대해 axe DevTools 또는 Lighthouse를 실행하여 리다이렉트나 포커스 관리와 관련된 플래그된 이슈를 확인한다. Chrome DevTools에서 Lighthouse 패널을 열고 Accessibility 감사(audit)를 실행한다. axe DevTools 확장에서는 “Analyze”를 클릭하고 결과를 검토한다. 자동 검사에서 문제가 없다고 나오더라도 3.2.5 준수를 보장하지는 않으므로, 수동 테스트가 필수적이다.
메타 새로고침 검사: 브라우저에서 페이지를 연 뒤, 마우스 오른쪽 버튼을 클릭해 “페이지 소스 보기”를 선택하고, http-equiv 또는 refresh를 검색(Ctrl+F / Cmd+F)한다. URL이 포함되어 있거나 72시간을 초과하는 지연 시간을 가지면서 이를 비활성화할 수 있는 메커니즘이 없는 <meta http-equiv='refresh'> 태그는 실패에 해당한다.
시간 경과에 따른 페이지 동작 관찰: 페이지를 로드한 후 2–5분 동안 아무 상호작용 없이 기다린다. 자동 콘텐츠 변경, 페이지 재로딩, 내비게이션 이벤트, 새 창 열림 등이 있는지 관찰한다. 브라우저 주소 표시줄과 탭 제목이 변경되는지도 확인한다. 사용자 입력 없이 이러한 일이 발생하면, 이 기준은 실패했을 가능성이 크다.
폼 컨트롤과 드롭다운 테스트: 키보드만 사용(Tab, 방향키, Enter, Space)하여 각 <select>, 라디오 버튼 그룹, 체크박스로 이동한다. 값을 변경하고, 제출 버튼을 활성화하기 전에 선택 즉시 내비게이션이나 큰 콘텐츠 변경이 발생하는지 관찰한다. 그런 경우, 해당 동작을 비활성화할 수 있는 컨트롤이 그 요소에 도달하기 전에 제공되지 않았다면 실패에 해당한다.
NVDA + Firefox로 테스트: NVDA를 활성화한 후(브라우즈 모드: Insert+Space), 방향키와 Tab으로 페이지를 탐색한다. 폼 상호작용을 완료하면서 포커스나 읽기 위치가 예기치 않게 이동하는지 확인한다. 페이지 변경에 대한 안내를 듣는다. 스크린 리더가 사용자의 명시적 행동 없이 새 페이지를 알리거나 가상 커서를 리셋한다면, 이는 맥락의 변경을 의미한다.
VoiceOver + Safari(macOS/iOS)로 테스트: Mac에서 VoiceOver를 활성화(Cmd+F5)하고 VO+방향키로 탐색한다. 컨트롤과 상호작용하면서 예기치 않은 페이지 안내나 커서 리셋이 있는지 듣는다. iOS에서는 요소를 스와이프하며, 사용자가 시작하지 않은 접근성 트리 구조의 갑작스러운 변화를 관찰한다.
JAWS + Chrome으로 테스트: JAWS를 활성화하고 Tab과 방향키로 탐색한다. 폼을 제출하고 동적 위젯과 상호작용한다. 포커스와 가상 커서 위치가 항상 예측 가능하며 사용자의 통제 아래에 있는지 확인한다.
JavaScript 소스 검토: Chrome DevTools의 Sources 패널을 사용하거나 검색(Ctrl+Shift+F) 기능으로 window.location, location.href, history.pushState, 내비게이션 호출과 결합된 setTimeout, onchange 속성 등의 패턴을 찾는다. 이들이 명시적인 사용자 행동이 아닌 타이머나 시스템 이벤트에 의해 트리거되는지 평가한다.
자동으로 넘어가는 캐러셀과 슬라이더 확인: 페이지에 있는 캐러셀, 슬라이드쇼, 회전 배너를 식별한다. 자동으로 슬라이드가 넘어가는지 확인한다. 자동으로 넘어가는 경우, 자동 전환 시 내비게이션(예: 새 페이지로 링크)을 함께 트리거하는지도 확인한다. 보이는 콘텐츠만 변경하는 자동 캐러셀은 2.2.2의 대상일 수 있지만, 내비게이션까지 발생시키는 경우 3.2.5에 해당한다.

해결 방법

메타 새로고침 리다이렉트 — 잘못된 예

<!-- 이 meta 태그는 5초 후 사용자에게 자동으로 리다이렉트합니다.
     사용자는 이 내비게이션을 제어할 수 없습니다. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>잠시 후 다른 페이지로 이동합니다...</p>
</body>

메타 새로고침 리다이렉트 — 올바른 예

<!-- 자동 리다이렉트를 완전히 제거합니다.
     사용자가 원하는 시점에 직접 활성화할 수 있는 명시적인 링크를 제공합니다.
     이를 통해 사용자는 내비게이션 시점을 완전히 제어할 수 있습니다. -->
<head>
  <!-- meta refresh 태그 없음 -->
</head>
<body>
  <p>이 페이지는 다른 위치로 이동했습니다. 새 위치를 방문해 주세요:</p>
  <a href='https://example.com/new-page'>업데이트된 페이지로 이동</a>
</body>

변경 시 자동 내비게이션하는 select 요소 — 잘못된 예

<!-- onchange 핸들러가 사용자가 값을 선택하는 즉시 내비게이션을 수행합니다.
     키보드 사용자는 내비게이션 전에 자신의 선택을 검토할 기회를 갖지 못합니다. -->
<label for='category'>카테고리를 선택하세요:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>선택...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

변경 시 자동 내비게이션하는 select 요소 — 올바른 예

<!-- select 요소는 더 이상 변경 시 내비게이션을 트리거하지 않습니다.
     명확한 레이블의 버튼이 사용자가 언제 진행할지 명시적으로 제어할 수 있게 합니다.
     이 패턴은 키보드 및 스크린 리더 사용자를 포함한 모든 사용자에게 적합합니다. -->
<label for='category'>카테고리를 선택하세요:</label>
<select id='category'>
  <option value=''>선택...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>카테고리로 이동</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

내비게이션을 트리거하는 자동 캐러셀 — 잘못된 예

<!-- 이 캐러셀은 3초마다 자동으로 슬라이드를 넘기며 각 슬라이드는 새 페이지로 링크됩니다.
     슬라이드가 자동으로 바뀌면, 어디를 클릭하든 예기치 않게 내비게이션이 발생합니다. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

내비게이션을 트리거하는 자동 캐러셀 — 올바른 예

<!-- 캐러셀은 더 이상 자동으로 슬라이드를 넘기지 않습니다.
     슬라이드 간 이동과 대상 페이지로의 내비게이션은 전적으로 사용자에 의해 제어됩니다.
     일시정지 및 이전/다음 컨트롤은 2.2.2와 3.2.5 모두를 충족합니다. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — 지금 쇼핑하기'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='이전 슬라이드' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='다음 슬라이드' onclick='nextSlide()'>›</button>
</div>

자주 발생하는 실수

<select> 요소에서 onchange를 사용해 즉시 window.location.href 내비게이션을 트리거하는 것으로, 별도의 제출 버튼을 제공하지 않아 키보드 사용자가 선택을 확인하기도 전에 즉각적인 페이지 변경을 강요하는 경우.
세션 타임아웃 처리를 위해 <meta http-equiv='refresh' content='30; url=...'>를 구현하는 것으로, 자동 리다이렉트가 실행되기 전에 사용자가 세션을 연장하거나 자동 리다이렉트를 비활성화할 수 있는 메커니즘을 제공하지 않는 경우.
setTimeout 또는 setInterval을 사용해 location.replace()나 history.pushState()를 호출하는 것으로, URL 업데이트를 동반한 자동 저장 같은 “편의” 기능을 위해 사용하지만, 사용자를 예기치 않게 새로운 브라우저 히스토리 상태로 이동시키는 경우.
타이머나 자동 프로세스에 의해 트리거되는 window.open()을 사용해 새 브라우저 창이나 탭을 여는 것으로, 클릭이나 키 입력 같은 사용자 제스처가 아닌 방식이다. 이는 많은 브라우저에서 팝업으로 차단될 수 있으며, 항상 원치 않는 맥락의 변경에 해당한다.
oninput이 트리거하는 debounce 함수 내부에서 form.submit()을 사용해 검색 또는 필터 폼을 자동 제출하는 것으로, 지연이 있더라도 텍스트 필드에 대해 눈에 보이는 제출 버튼이라는 대체 컨트롤 메커니즘을 제공하지 않는 경우.
첫 번째 자동 내비게이션이 이미 발생한 후에야 나타나는 “자동 전환 끄기” 컨트롤을 제공하는 것. 옵트아웃 메커니즘은 첫 번째 맥락 변경이 일어나기 전에 사용자에게 제공되어야 한다.
콘텐츠 업데이트와 맥락의 변경을 혼동하는 것. 텍스트를 제자리에서 업데이트하는 라이브 리전(예: 주가 티커)은 맥락의 변경이 아니므로 허용되지만, 전체 보이는 페이지를 자동으로 교체하거나 새 URL로 내비게이션하는 것은 맥락의 변경이며 이 기준의 적용 대상이다.
자동 내비게이션 전에 경고 대화 상자를 제공하면 기준을 충족한다고 가정하는 것. 이때 대화 상자 자체가 자동으로 트리거되고 키보드 포커스를 가두는 경우가 있다. 사용자는 단지 경고를 받는 것이 아니라, 해당 동작을 비활성화할 수 있어야 한다.
onblur 또는 onfocusout 이벤트 핸들러를 사용해 폼 검증과 자동 리다이렉트를 트리거하는 것으로, 사용자가 명시적으로 다음 단계로 진행하겠다고 요청하지 않았는데도 오류 페이지나 다단계 폼의 다른 단계로 이동시키는 경우.
스크롤 깊이 또는 특정 섹션에서 보낸 시간에 따라 history.pushState를 업데이트하는 단일 페이지 애플리케이션(SPA) 라우팅을 배포하는 것. 이는 분석 목적으로 사용되기도 하지만, 사용자의 요청 없이 맥락의 변경을 일으키며, URL 상태에 묶여 있는 스크린 리더의 가상 버퍼를 혼란스럽게 만들 수 있다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보(Official Gazette) 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 주체에 대해 WCAG 2.2와 정렬된 의무적 웹 접근성 요구 사항을 수립한다. 이 대통령령은 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교를 포괄한다.

대통령령은 해당 주체에 대해 WCAG 2.2 AA 수준 준수를 기본 기준으로 의무화한다. WCAG 3.2.5 Change on Request는 AAA 수준 기준이므로, 대통령령이 정한 최소 법적 기준에 따라 직접적으로 요구되지는 않는다. 그러나 이것이 터키 맥락에서 이 기준이 무의미하다는 뜻은 아니다.

여러 범주의 해당 주체는 3.2.5에 대해 AAA 수준 준수를 추구할 강력한 실질적 이유를 가진다. 대규모 사용자 기반을 가진 전자상거래 플랫폼과 여행사는 동적 필터링, 자동 제안 내비게이션, 프로모션 캐러셀을 자주 구현하는데, 이는 이 기준을 위반하기 쉬운 패턴들이다. 예기치 않은 내비게이션이 오류나 보안 문제를 야기할 수 있는 민감한 거래를 처리하는 은행 및 금융 서비스 제공자는 모든 맥락의 변경이 명시적으로 사용자에 의해 제어되도록 보장함으로써 큰 이익을 얻는다. 사용자가 취약한 상태에 있을 수 있고 예측 가능하며 차분한 인터페이스가 필요한 의료 포털 역시 AA 기준을 넘어 3.2.5 같은 AAA 기준을 충족하는 것이 윤리적 책임과 실질적인 사용자 안전을 모두 보여주는 영역이다.

대통령령에 따라 감사 및 보고 의무를 지는 공공 기관은 자신의 준수 수준을 문서화해야 한다. AAA 수준이 법적으로 의무는 아니지만, 이를 달성하고 문서화하는 것은 최고 수준의 접근성에 대한 헌신을 입증하는 방어 가능한 기록이 된다. 사회보장청(SGK)이나 장애 지원 서비스처럼 장애인을 주요 또는 중요한 사용자 집단으로 두는 기관의 경우, AAA 수준 준수를 추구하는 것은 규정의 취지와 특히 잘 부합한다.

자발적으로 WCAG 3.2.5를 충족하는 조직은 유럽연합 접근성 정렬 측면에서도 유리한 위치를 차지한다. 터키의 EU 회원국과의 디지털 무역 관계에서 접근성은 조달 및 파트너십 기준으로 점점 더 중요해지고 있기 때문이다. 2025년 6월 발효된 European Accessibility Act(EAA)는 EU 시장에 제공되는 제품과 서비스 — 터키 기업이 유럽 사용자에게 제공하는 서비스 포함 — 에 적용되며, 3.2.5와 일치하는 사용자 제어 상호작용 패턴을 강하게 장려한다.

실무적으로, Accsible의 오버레이 SDK를 구현하는 터키 개발팀은 동적으로 삽입되는 위젯, 환경설정 패널, 보조 컨트롤이 스스로 비의도적인 맥락 변경을 일으키지 않도록 해야 한다. SDK의 툴바와 설정 패널은 명시적인 사용자 행동에 의해서만 열리고 닫혀야 하며, 오버레이를 통해 트리거되는 모든 내비게이션이나 콘텐츠 업데이트는 사용자에 의해 시작되어야 한다. 이를 통해 접근성 솔루션 자체가 제거하려는 바로 그 장벽을 새로 만들지 않도록 할 수 있다.