WCAG 3.2.2: 입력 시

이 규칙의 의미

WCAG 3.2.2 On Input은 이해 가능(Understandable) 원칙의 일부이며, 지침 3.2 예측 가능(Predictable)에 속한다. 이 기준은, 어떤 사용자 인터페이스 구성 요소의 설정을 변경하는 것이, 그러한 동작이 발생할 것임을 사용자가 사전에 안내받지 않은 이상, 자동으로 맥락(context)의 변화를 일으켜서는 안 된다고 규정한다.

맥락의 변화(change of context)란, 한 번에 페이지 전체를 볼 수 없는 사용자들을 혼란스럽게 만들 수 있는, 웹 페이지 콘텐츠의 큰 변화를 의미한다. WCAG 명세에 따르면, 맥락의 변화에는 사용자 에이전트(브라우저)의 변경, 뷰포트의 변경, 포커스의 변경, 그리고 페이지의 의미를 크게 바꾸는 콘텐츠의 변경이 포함된다. 폼 제출, 새 창 열기, 다른 페이지로의 이동은 모두 맥락의 변화에 해당한다. 단순히 추가 콘텐츠를 드러내는 것(예: 아코디언 확장)은 이에 해당하지 않는다.

이 기준은 특히 UI 구성 요소의 설정 변경에 적용된다. 예를 들어, 라디오 버튼 선택, 체크박스 체크, <select> 드롭다운에서 옵션 선택 등은 이에 해당하며, 버튼 클릭과 같은 컨트롤의 “활성화”와는 구분된다. 어떤 동작이 명시적인 활성화 단계(Enter 키 누르기, Submit 버튼 클릭)를 요구한다면, 일반적으로 이 기준의 적용 대상이 아니다. 문제가 되는 패턴은, 값만 선택해도 아무런 경고 없이 즉시 내비게이션이나 큰 페이지 리로드가 발생하는 경우이다.

충족으로 인정되는 경우: 드롭다운이나 체크박스를 포함하더라도, 사용자 선택을 처리하기 위해 제출 버튼을 사용하는 폼은 이 기준을 충족한다. 페이지를 다시 로드하거나 포커스를 크게 이동시키지 않고 같은 페이지 내에서 결과를 필터링하는 드롭다운도 충족한다. “언어를 선택하면 페이지가 다시 로드됩니다”와 같이, 특정 입력이 맥락 변화를 일으킬 것임을 페이지가 미리 사용자에게 알려주는 경우도 충족한다.

실패로 인정되는 경우: 국가 또는 언어 선택기가, 사용자가 옵션을 선택하는 즉시 자동으로 새 URL로 리다이렉트하는 경우는 실패이다. 제출 버튼 없이, 라디오 버튼을 선택하는 순간 폼이 자동으로 제출되고 다른 페이지로 이동하는 경우도 실패이다. 선택 시 아무런 경고 없이 키보드 포커스를 페이지의 새로운 영역으로 이동시키는 자동완성 위젯 역시 실패이다.

공식 예외: WCAG 명세는, 사용자가 구성 요소를 사용하기 전에 해당 동작에 대해 안내를 받았다면, 자동 맥락 변화가 허용될 수 있다고 명시한다. 이 안내는 상호작용이 일어나기 “이전”에 제공되어야 하며, 이후가 되어서는 안 된다.

왜 중요한가

예상치 못한 맥락의 변화는 웹에서 가장 혼란스러운 경험 중 하나이며, 그 영향은 장애가 있는 사용자에게서 훨씬 더 크게 증폭된다. 페이지가 예고 없이 갑자기 이동하거나, 다시 로드되거나, 포커스를 옮기면, 페이지의 전체 시각적 레이아웃을 볼 수 없는 사용자는 완전히 방향 감각을 잃게 된다.

스크린 리더 사용자는 특히 취약하다. NVDA나 JAWS를 사용하는 시각장애 사용자가 드롭다운에서 옵션을 선택했을 때, 페이지가 즉시 다시 로드되거나 다른 곳으로 이동하면, 스크린 리더는 새로운 페이지 맥락을 처음부터 다시 읽기 시작한다. 사용자는 자신이 어디에 있었는지, 무엇을 하고 있었는지의 맥락을 잃고, 다시 페이지 전체를 탐색해 위치를 찾아야 한다. 이는 단순한 불편을 넘어, 과제를 독립적으로 완료하는 것을 사실상 불가능하게 만들 수 있다.

키보드만 사용하는 사용자는, 마우스를 사용할 수 없는 운동 장애가 있는 사람들을 포함해, 비슷한 문제에 직면한다. 이들은 Tab과 방향키로 폼을 탐색하다가 의도치 않게 맥락 변화를 유발할 수 있다. 미세한 운동 조절이 어려운 경우, 원치 않는 페이지 이동에서 회복하는 데 상당한 노력이 필요할 수 있다.

인지 장애는 문제를 더욱 복합적으로 만든다. 주의력 결핍, 학습 장애, 기억 장애가 있는 사용자는, 무슨 일이 일어나고 있는지 이해하기 위해 예측 가능하고 안정적인 인터페이스에 의존한다. 갑작스러운 맥락 변화는 세션 동안 형성해 온 정신적 모델을 깨뜨려, 종종 처음부터 다시 시작하거나 과제를 포기하게 만든다.

전정 기관(vestibular) 장애가 있는 사용자는, 특히 변화에 애니메이션이나 스크롤 위치 이동이 수반될 경우, 페이지가 예상치 못하게 바뀌면 신체적 불편이나 어지러움을 겪을 수 있다.

구체적인 실제 시나리오를 들어보자. 터키의 한 전자상거래 결제 페이지에서 사용자가 드롭다운에서 자신의 주(province)를 선택한다고 가정하자. 이 선택이 배송 옵션을 업데이트하기 위해 즉시 페이지를 다시 로드한다면, 스크린 리더 사용자는 갑자기 페이지 상단으로 이동한 것처럼 느끼면서, 무슨 일이 일어났는지에 대한 안내 없이 남게 될 수 있다. 이전에 입력한 값이 유지되었는지 알 수 없는 상태에서, 다시 모든 폼 필드를 지나 자신이 있던 위치를 찾아야 한다. 이러한 마찰은 사용자가 구매를 완전히 포기하게 만들 수 있다.

사용성 및 SEO 관점에서, 예측 가능하게 동작하는 페이지는 이탈률이 낮다. 사용자가 좌절감으로 떠날 가능성이 줄어들고, 검색 엔진 크롤러도 예기치 않은 리다이렉트로 크롤 경로가 방해받지 않아 콘텐츠를 더 안정적으로 인덱싱할 수 있다.

관련 Axe-core 규칙

WCAG 3.2.2 On Input은 수동 테스트가 필요하다. axe-core와 같은 자동화 도구는, 문제가 되는 동작이 맥락적이며 특정 HTML 속성이나 구조의 유무가 아니라 상호작용 뒤에 있는 의도에 따라 달라지기 때문에, 이 기준의 위반을 신뢰성 있게 감지할 수 없다. 도구는 <select> 요소에 onchange 이벤트 핸들러가 있다는 사실은 식별할 수 있지만, 그 핸들러가 맥락 변화를 일으키는지, 사용자에게 이에 대해 경고가 되었는지, 실제로 그 결과가 혼란을 유발하는지 여부는 판단할 수 없다.

• 수동 테스트 필요 — onchange 내비게이션 패턴: 자동 스캐너는 JavaScript 이벤트 핸들러(특히 onchange)가 연결된 <select>, <input type='radio'>, <input type='checkbox'> 요소를 표시할 수 있지만, 해당 핸들러가 맥락 변화를 일으키는지는 판단할 수 없다. 사람 테스트 담당자가 각 컨트롤과 상호작용해, 페이지가 사용자에 의한 명시적 활성화 없이 내비게이션, 리로드, 포커스의 극적인 이동, 새 창 열기 등을 수행하는지 관찰해야 한다.
• 수동 테스트 필요 — 사전 경고의 존재 및 적절성: 맥락 변화가 감지되더라도, 자동 도구는 사용자가 컨트롤과 상호작용하기 전에 이에 대해 충분히 경고받았는지 판단할 수 없다. 사람은 사전 안내가 구성 요소를 만나기 전에 보이는지, 문구가 명확한지, 실제로 발생할 동작을 설명하는지 확인해야 한다.
• 수동 테스트 필요 — 입력 후 포커스 관리: 일부 위반은, 내비게이션 자체보다는 입력 변경 시 포커스가 예상치 못한 위치로 이동하는 형태로 나타난다. 자동 도구는 onchange 이벤트에 의해 트리거된 포커스 목적지를 신뢰성 있게 추적하고, 그 결과 포커스 위치가 혼란을 유발하는 맥락 변화를 구성하는지 확인할 수 없다.

테스트 방법

1. 자동 스캔 기준선: 페이지에 대해 axe DevTools 또는 Lighthouse를 실행해 WCAG 3.2 관련으로 표시된 문제를 확인한다. 3.2.2 자체는 수동 테스트가 필요하지만, axe는 시작점이 될 수 있는 관련 문제(예: 레이블 누락, 포커스 관리 문제)를 표면화할 수 있다. 모든 폼 컨트롤, 특히 <select> 드롭다운, 라디오 그룹, 체크박스를 수동 후속 조치 대상으로 기록한다.
2. 변경 핸들러가 있는 모든 입력 컨트롤 식별: 브라우저 DevTools에서 페이지의 JavaScript를 검사하거나 Event Listeners 패널을 사용해, <select>, <input type='radio'>, <input type='checkbox'> 또는 onchange, oninput 또는 동등한 이벤트 리스너가 연결된 커스텀 위젯을 식별한다.
3. 수동 키보드 상호작용 테스트: 키보드만 사용해(Tab으로 이동, 방향키로 라디오/선택 옵션 변경) 식별된 각 컨트롤과 상호작용한다. 옵션 선택이 페이지 내비게이션, 리로드, 새 창 열기, 페이지의 상당히 다른 부분으로의 포커스 이동을 유발하는지 관찰한다. 그렇다면, 해당 컨트롤을 만나기 전에 눈에 보이는 경고가 있었는지 확인한다.
4. NVDA + Firefox 테스트: NVDA를 활성화한 상태에서 Firefox를 실행한다. NVDA의 가상 커서(방향키)를 사용해 각 폼 컨트롤로 이동한 뒤, 폼 모드(Enter 또는 Space)로 상호작용한다. 드롭다운과 라디오 그룹에서 옵션을 선택하고, 페이지 로드, 내비게이션, 큰 맥락 변화가 있음을 나타내는 예기치 않은 안내가 있는지 듣는다. NVDA가 새로운 페이지 제목이나 크게 다른 영역을 읽는지 기록한다.
5. VoiceOver + Safari 테스트(macOS/iOS): VoiceOver를 활성화하고 VO+오른쪽 화살표로 각 컨트롤로 이동한다. 드롭다운과 체크박스와 상호작용한다. 맥락 변화가 발생하면, VoiceOver는 일반적으로 새 페이지나 포커스 이동을 안내한다. 사용자가 사전에 경고를 받았는지 판단한다.
6. JAWS + Chrome 테스트: JAWS를 가상 커서 모드로 사용해 페이지를 탐색한다. 폼 컨트롤과 상호작용하고, 제출 버튼이 활성화되지 않은 상태에서 입력 직후 JAWS가 맥락 변화(페이지 제목 변경, 새 URL, 읽기 위치 이동)를 안내하는지 모니터링한다.
7. 시각적 관찰 테스트: 보조 기술을 사용하지 않는 시력이 있는 사용자의 관점에서, 각 드롭다운과 라디오 그룹에서 옵션을 선택하고 페이지가 예상치 못하게 이동하거나 다시 로드되는지 관찰한다. 그렇다면, 이 동작에 대해 컨트롤 이전에 보이는 안내 문구가 있었는지 확인한다.

수정 방법

자동 제출 select 드롭다운 — 잘못된 예

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

자동 제출 select 드롭다운 — 올바른 예

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

라디오 버튼 자동 제출 패턴 — 잘못된 예

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

라디오 버튼 자동 제출 패턴 — 올바른 예

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

사전 경고가 있는 언어 전환기 — 올바른 예

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

자주 발생하는 실수

• <select> 요소의 onchange 속성에 직접 window.location.href 할당을 연결해, 사용자가 옵션을 선택하는 즉시 페이지 내비게이션이 발생하도록 하면서 제출 버튼을 제공하지 않는 경우.
• 라디오 버튼의 onchange 핸들러 안에서 this.form.submit()을 사용하는 경우로, 사용자가 선택을 검토하기도 전에 라디오 옵션을 선택하는 순간 전체 폼이 제출되고 다른 페이지로 이동하게 된다.
• DOM에서 컨트롤 뒤에 사전 경고를 배치하는 경우로, 스크린 리더 사용자와 키보드 탐색 사용자가, 해당 컨트롤이 유발하는 동작에 대한 경고를 듣거나 읽기 전에 컨트롤을 먼저 만나게 된다.
• 사전 경고를 툴팁이나 placeholder 텍스트로만 표시하는 경우로, 이는 보조 기술에 안정적으로 노출되지 않아, 스크린 리더 사용자가 자신의 입력 뒤에 맥락 변화가 뒤따를 것이라는 어떤 안내도 받지 못하게 만든다.
• <div>와 <ul> 요소를 사용해 커스텀 드롭다운 위젯을 구축하는 경우로, JavaScript로 선택 시 내비게이션을 트리거하지만, 테스트 담당자나 접근성 오버레이가 3.2.2 기준에 따라 검토해야 할 인터랙티브 컨트롤로 인식할 수 있는 시맨틱 구조가 부족한 경우.
• 폼의 마지막 필드(예: PIN 또는 OTP 입력)에 자동 폼 제출을 트리거하는 경우로, 필요한 글자 수에 도달하는 즉시 제출이 이루어지지만, 사용자에게 이 사실을 알리지 않는 경우.
• 체크박스를 체크했을 때, 사전 안내 없이 모달 대화 상자나 새 브라우저 창을 여는 경우로, 이는 사용자의 뷰포트와 포커스를 크게 이동시키므로 맥락 변화에 해당한다.
• 예측 가능한 페이지 내 콘텐츠 업데이트를 맥락 변화와 혼동하는 경우로, 이미 허용 가능한 상호작용(예: 실시간 검색 필터) 주변에 불필요한 제출 버튼을 추가해 UI를 복잡하게 만든다. 팀은 인라인으로 이루어지는, 혼란을 유발하지 않는 업데이트에는 제출 단계가 필요 없다는 점을 이해해야 한다.
• 자동 접근성 스캔에만 의존하는 경우로, 어떤 자동 규칙도 문제를 표시하지 않았다는 이유로 3.2.2를 통과로 표시하면서, 이 기준이 요구하는 필수 수동 키보드 및 스크린 리더 테스트를 수행하지 않는 경우.
• 결과 목록에서 정렬 또는 필터링에 사용되는 <select>에 맥락 변화를 일으키는 onchange 핸들러를 적용하는 경우로, AJAX 업데이트 대신 전체 페이지 리로드를 유발하면서, 선택 시 이 리로드가 발생할 것임을 사용자에게 알리지 않는 경우.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보(Official Gazette) 제 32933호에 게재되었으며, WCAG 2.2를 기반으로 한 의무적인 웹 접근성 요구 사항을 수립한다. WCAG 3.2.2 On Input은 레벨 A 기준으로, 이는 해당 대통령령 하에서 최소 준수 기준을 의미한다. 즉, 규정 대상 기관에 대해 이 기준 준수는 선택 사항이 아니라 법적으로 요구된다.

대통령령은 2단계 이행 일정을 정의한다. 공공 기관 — 부처, 지방자치단체, 국립 대학, 정부 기관을 포함 — 은 대통령령 공포일로부터 1년 이내에 레벨 A 전 항목을 완전히 준수해야 한다. 규제 대상인 민간 부문 기관은 준수를 위해 2년의 기간을 가진다.

대통령령에 따라 명시적으로 규제 대상이 되는 기관 유형은 다음과 같으며, 따라서 이들은 디지털 서비스가 WCAG 3.2.2를 준수하도록 해야 한다. 전자상거래 플랫폼, 모든 수준의 공공 기관, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교가 이에 해당한다.

이들 기관의 경우, 예를 들어 선택 시 자동 리다이렉트되는 은행 포털의 언어 선택기나, 진료과 라디오 버튼을 선택하는 즉시 자동으로 제출되는 병원 예약 폼과 같은 WCAG 3.2.2 위반은, 곧바로 규제 미준수에 해당한다. 터키에는 상당한 수의 장애인 사용자가 존재하고, 정부 디지털 서비스가 점점 더 시민이 공공 서비스를 이용하는 주요 채널이 되고 있다는 점을 고려하면, 이 기준을 무시하는 실질적 위험은 매우 크다.

대통령령의 적용을 받는 조직은 WCAG 3.2.2 테스트를 QA 과정에서 필수 감사 단계로 취급해야 한다. 자동 도구로는 이 기준의 위반을 잡아낼 수 없기 때문에, NVDA와 JAWS를 사용한 키보드 상호작용 및 스크린 리더 동작, 그리고 모든 onchange 기반 상호작용에 대한 명시적 검토를 포함하는, 훈련된 접근성 전문가의 수동 테스트를 준수 프로세스에 반드시 포함해야 한다. 테스트 결과와, (사전 경고가 갖춰진) 허용된 예외를 문서화하는 것은 규제 기관에 대한 성실한 이행(due diligence) 입증에 도움이 된다.