WCAG 3.3.7: 중복 입력

WCAG 3.3.7은 다단계 프로세스에서 사용자가 이미 제공한 정보가 자동으로 채워지거나 선택할 수 있는 형태로 제공되어, 사용자가 동일한 데이터를 두 번 다시 입력할 필요가 없도록 할 것을 요구합니다. 이는 인지, 운동 또는 기타 장애가 있는 사용자의 좌절감과 오류를 방지합니다.

이 규칙의 의미

WCAG 3.3.7 Redundant Entry(중복 입력)는 WCAG 2.2에서 새로 도입된 레벨 A 성공 기준이다. 이 기준은 다음과 같이 규정한다. "동일한 프로세스에서 다시 입력해야 하는, 사용자에 의해 이전에 입력되었거나 사용자에게 제공되었던 정보는 자동으로 채워지거나 사용자가 선택할 수 있는 형태로 제공되어야 한다." 쉽게 말해, 사용자가 한 세션 동안 이미 이메일 주소, 배송지 주소, 생년월일 또는 그 밖의 어떤 정보를 한 번 입력했다면, 동일한 프로세스나 흐름 안에서 인터페이스가 그 정보를 다시 입력하도록 요구해서는 안 된다는 뜻이다.

이 기준은 여러 단계로 이루어진 폼, 결제(체크아웃) 프로세스, 회원가입 마법사, 예약(약속) 신청 흐름 등, 한 단계에서 수집한 데이터가 이후 단계에서 다시 필요할 수 있는 모든 시퀀스에 폭넓게 적용된다. 영향을 받는 동작에는 텍스트 입력, 드롭다운, 체크박스, 라디오 버튼 및 사용자 제공 데이터를 수집하는 기타 모든 폼 컨트롤이 포함된다. 동일한 정보가 다시 필요할 때에는, 이전에 제공된 값을 사용해 자동으로 미리 채워져 있어야 하거나, 사용자가 다시 입력하는 대신 확인만 하면 되도록 선택 가능한 옵션으로 제공되어야 한다.

이 기준을 준수하는 사례는 다음과 같다. 이전 화면에서 사용자가 입력한 배송지 주소로 청구지 주소 폼이 미리 채워져 있거나, 확인 단계에서 사용자가 이전에 입력한 이메일 주소를 읽기 전용 필드로 보여주는 경우다. 또 다른 준수 패턴은 "청구지 주소가 배송지 주소와 같습니다"라는 라벨의 체크박스를 제공하고, 체크 시 값을 자동으로 복사하는 방식이다. 미준수 사례는 다음과 같다. 1단계에서 이메일 주소를 입력하게 하고 3단계에서 다시 이메일 주소를 요구하면서 두 번째 필드를 미리 채우지 않는 다단계 회원가입 흐름, 또는 여러 개의 별도 화면에서 청구인의 이름과 증권 번호를 반복해서 입력하게 하면서 자동 채우기 기능이 전혀 없는 보험 청구 폼 등이다.

WCAG 3.3.7은 두 가지 공식 예외를 정의한다. 첫 번째 예외는 정보를 다시 입력하는 것이 프로세스에 필수적인 경우에 적용된다. 예를 들어, "새 비밀번호 확인" 필드는 오타 방지를 위한 안전장치로 동일한 비밀번호를 두 번 입력하도록 의도적으로 요구하며, 이는 필수적인 보안 점검으로 간주된다. 두 번째 예외는 이전에 입력한 정보가 더 이상 유효하지 않은 경우에 적용된다. 예를 들어 세션이 만료되었거나 상품이 품절되어 사용자가 새로운 데이터로 프로세스를 다시 시작해야 하는 상황이 이에 해당한다. 이러한 예외에 해당하지 않는 한, 중복 입력은 비준수(불일치)로 간주된다.

왜 중요한가

중복 입력은 타이핑이 느리거나, 고통스럽거나, 오류가 잦거나, 인지적으로 부담스러운 사용자에게 불균형적으로 큰 부담을 준다. 누가 영향을 받는지 이해하는 것은 개발자와 디자이너가 이 기준을 단순한 편의 기능이 아니라 많은 사람에게 실질적인 장벽이라는 점을 인식하는 데 도움이 된다.

운동 장애가 있는 사용자는 떨림, 척수 손상, ALS나 다발성 경화증과 같은 질환으로 인해 스위치 액세스, 마우스 스틱, 시선 추적 소프트웨어, 음성 제어 등에 의존해 텍스트를 입력할 수 있다. 이들에게는 짧은 주소를 입력하는 것조차 몇 분이 걸리고 상당한 신체적 노력이 필요할 수 있다. 동일한 입력을 반복하도록 요구하는 것은 단순히 짜증나는 수준을 넘어, 신체적 통증을 유발하거나 한 세션 안에 작업을 사실상 불가능하게 만들 수 있다.

인지 장애가 있는 사용자는 난독증, 주의력 결핍 장애, 외상성 뇌 손상, 치매 관련 질환 등을 포함하며, 세 단계 전에서 무엇을 입력했는지 기억하는 데 어려움을 겪을 수 있다. 기억이나 종이 문서에서 동일한 정보를 여러 번 정확히 옮겨 적는 것은 오류율과 이탈률을 크게 높인다. 세계보건기구(WHO)에 따르면 전 세계 10억 명이 넘는 사람이 어떤 형태로든 장애를 가지고 있으며, 인지 장애는 접근성 계획에서 가장 크고 가장 서비스가 부족한 집단 중 하나를 차지한다.

상지(팔) 차이가 있는 사용자는 선천적이거나 후천적으로 팔에 차이가 있는 사람들을 포함하며, 타이핑 속도가 훨씬 느리고 대체 입력 장치를 사용할 수 있다. 요구되는 키 입력이 하나 늘어날 때마다 이들에게 가해지는 부담은 배가된다.

현실적인 시나리오를 생각해 보자. 류머티즘 관절염이 있는 사용자가 병원의 온라인 포털을 통해 진료 예약을 하고 있다. 화면 1에서 이 사용자는 주민등록번호, 이름, 생년월일, 연락처 전화번호를 입력한다. 화면 3에서 포털은 환자 기록을 확인한다는 이유로 다시 이름과 생년월일을 요구한다. 이 사용자는 두 화면 전에 제공했던 정보를 힘겹게 다시 입력해야 하고, 기록이 일치하지 않을 수 있는 오타 위험을 감수해야 하며, 불필요한 신체적 부담을 겪게 된다. 단순히 해당 필드를 미리 채우거나 자동으로 채워 주기만 해도 이러한 장벽은 완전히 제거될 수 있다.

접근성을 넘어, 중복 입력을 제거하면 전환율이 향상되고, 폼 이탈이 줄어들며, 데이터 입력 오류로 인한 지원 티켓이 감소한다. 이는 포용적 디자인과 더불어 측정 가능한 비즈니스 가치를 제공한다.

테스트 방법

출발점으로서의 자동 스캔: 다단계 프로세스의 각 단계를 대상으로 axe DevTools, Lighthouse 또는 Accsible auditor를 실행한다. 이 도구들은 3.3.7 위반을 직접 표시하지는 않지만, 종종 함께 발생하는 autocomplete 속성 누락, 라벨이 없는 폼 필드, 기타 3.3.x 기준 실패와 같은 관련 문제를 드러낸다. 각 단계에서 발견한 모든 폼 필드를 문서화한다.
단계별 데이터 요구사항 매핑: 수동 테스트 전에, 프로세스의 각 단계와 그 단계에서 수집하는 모든 데이터 필드를 나열한 간단한 표나 스프레드시트를 만든다. 그런 다음 둘 이상의 단계에 나타나는 필드 라벨이나 데이터 유형을 식별한다. 이 매핑 작업만으로도 브라우저를 열기 전에 잠재적인 위반 후보를 드러낼 수 있다.
수동 워크스루 — 데스크톱: 표준 마우스와 키보드를 사용해 전체 다단계 프로세스(예: 체크아웃, 회원가입, 청구 제출)를 완료한다. 모든 필드에 현실적인 값을 입력한다. 매핑에서 중복 필드로 표시된 단계에 도달하면, 해당 필드가 이전에 입력한 값으로 미리 채워져 있는지, 또는 이전에 입력한 값을 제시하는 선택 가능한 옵션이 있는지 확인한다. 둘 다 아니라면 실패로 기록한다. 그런 다음 스크린 리더(NVDA+Firefox, JAWS+Chrome, VoiceOver+Safari)를 사용해 테스트를 반복하여, 미리 채워진 값이 제대로 안내되는지, 이전에 입력한 값을 선택하는 컨트롤이 키보드로 접근 가능한지 확인한다.
수동 워크스루 — 모바일: iOS(VoiceOver + Safari)와 Android(TalkBack + Chrome)에서 동일한 흐름을 완료한다. 애플리케이션이 의도치 않게 네이티브 자동완성 또는 자동 채우기 기능을 억제하여, 개발자가 자동완성을 돕기 위해 의도했더라도 결과적으로 중복 입력 장벽을 만들고 있지 않은지 주의 깊게 살펴본다.
예외 테스트: 의도적으로 중복 입력을 요구하는 필드(예: 비밀번호 확인, 이메일 재입력)를 식별한다. 이 필드들이 WCAG 예외에서 규정한 필수적인 보안 또는 검증 점검에 해당하는지, 아니면 제거하거나 미리 채워야 할 단순 중복 필드인지 확인한다.
자동완성 비활성화 상태에서 테스트: 일부 사용자는 개인정보 보호를 위해 브라우저 자동완성을 비활성화한다. 브라우저 자동완성을 꺼도 애플리케이션 자체의 미리 채우기 메커니즘(서버 측 또는 JavaScript 기반)이 제대로 작동하는지 테스트하여, 이 기준이 브라우저 동작과 무관하게 충족되는지 확인한다.

해결 방법

다단계 체크아웃 — 두 화면에서 동일한 주소 요구 — 잘못된 예

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

다단계 체크아웃 — 두 화면에서 동일한 주소 요구 — 올바른 예

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

회원가입 마법사에서 정당한 이유 없이 이메일을 두 번 요구 — 잘못된 예

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

회원가입 마법사 — 세션 데이터에서 이메일을 미리 채움 — 올바른 예

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

예약(약속) 신청 — 요약 단계에서 환자 정보를 다시 요구 — 잘못된 예

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

예약(약속) 신청 — 생년월일을 읽기 전용 확인용으로 표시 — 올바른 예

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

자주 발생하는 실수

다단계 폼을 공유 세션 상태 없이 독립된 페이지로 구축하여 이전 단계에서 입력한 값을 전달할 메커니즘이 전혀 없는 경우 — 3.3.7 실패를 초래하는 가장 근본적인 아키텍처적 실수다.
"배송지와 동일" 체크박스를 제공하지만, 체크되었을 때 실제로 청구지 필드를 채우지 않아 사용자가 일치한다고 표시한 후에도 주소를 수동으로 입력해야 하는 경우.
페이지 로드 시 필드를 미리 채워 두었다가 검증 오류가 발생하면 필드를 비워 버려 이후 단계에서 실수를 한 사용자가 수정하러 돌아왔을 때 이전에 제공한 모든 데이터를 다시 입력해야 하는 경우.
세션 데이터를 안전하지 않게 저장한 뒤 보안 문제를 해결하는 대신 세션 저장을 비활성화하여 기술적으로 3.3.7 실패에 해당하는 깨진 미리 채우기 경험을 초래하는 경우.
비밀번호 확인 예외를 근거로 사용자가 이메일 주소를 다시 입력하도록 요구하면서 이메일 확인이 필수적인 보안 점검이 아님에도 WCAG 예외에 해당한다고 주장하는 경우.
서버 렌더링 폼에서 숨겨진 입력(hidden input)을 통해 전달된 값을 유지하지 않아 사용자가 브라우저 뒤로/앞으로 가기 버튼으로 단계를 이동할 때 미리 채워진 값이 사라지는 경우.
애플리케이션 수준의 미리 채우기를 구현하지 않고 브라우저 자동 채우기에만 의존하여 개인정보 보호를 위해 자동 채우기를 비활성화한 사용자가 프로세스를 준수 방식으로 완료할 수 없게 되는 경우.
필드를 미리 채워 두고 readonly 대신 disabled로 설정하여 대부분의 브라우저에서 해당 값이 폼 제출에 포함되지 않게 만들어 프로세스를 깨뜨리고, 결국 재입력을 강요하는 경우.
Dragon NaturallySpeaking과 같은 음성 입력 소프트웨어를 사용하는 사용자와 함께 전체 엔드 투 엔드 흐름을 테스트하지 않아 중복 필드가 동일한 음성 명령을 여러 번 반복하게 만드는 부담을 간과하는 경우. 이는 개발자 테스트에서 쉽게 놓치기 쉽다.
이 기준을 주소 필드에만 적용되는 것으로 간주하여 이름, 전화번호, 주민등록번호, 증권 번호, 날짜 및 동일한 프로세스에서 두 번 이상 요청되는 기타 모든 사용자 제공 정보에도 동일하게 적용된다는 점을 간과하는 경우.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 웹 접근성 준수를 의무화한다. WCAG 3.3.7 Redundant Entry는 WCAG 2.2의 레벨 A 기준이며, 이 대통령령에서 요구하는 최소 의무 수준은 레벨 A 준수다. 이는 해당 범위에 속하는 어떤 기관이든 웹사이트, 웹 애플리케이션 또는 디지털 서비스를 운영하는 경우, 동일한 프로세스 내에서 사용자가 이미 제공한 정보를 다시 입력하도록 요구해서는 안 되며 — 예외 없이 — 그렇지 않을 경우 비준수 위험을 감수해야 한다는 의미다.

대통령령은 단계적 이행 일정을 규정한다. 공공 기관은 대통령령 공포 후 1년 이내에 준수를 달성해야 하며, 해당 범주에 속하는 민간 부문 기관은 2년의 이행 기간을 가진다.

대통령령이 적용되는 기관 유형은 매우 광범위하며, 전자상거래 플랫폼과 마켓플레이스, 모든 공공 기관 및 정부 부처, 은행 및 금융 서비스 제공자, 병원 및 의료 포털(공공·민간 모두), 가입자 200,000명 이상인 통신사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교를 포함한다. 이들 모든 기관에 대해, 전자상거래 사이트의 체크아웃 흐름, 병원 포털의 환자 등록, 은행 플랫폼의 계좌 개설, 학교 웹사이트의 등록 폼 등 다단계 디지털 프로세스는 중복 입력 사례를 제거하기 위해 감사 및 수정되어야 한다.

실무적으로 이 규정은 터키 디지털 경제 전반의 조달, 제품, 법무 팀이 WCAG 3.3.7 준수를 반드시 고려해야 함을 의미한다. 예를 들어, 다단계 체크아웃을 운영하는 터키의 한 전자상거래 플랫폼이 한 화면에서 배송지 주소를, 다음 화면에서 청구지 주소를 요구하면서 미리 채우기나 복사 옵션을 제공하지 않는다면, 이는 WCAG 2.2 레벨 A와 대통령령 모두를 직접적으로 위반하는 것이다. 마찬가지로, 여러 화면에 걸쳐 환자에게 주민등록번호나 생년월일을 반복해서 입력하도록 요구하는 국립 병원의 진료 예약 포털 역시 비준수 상태다. 대통령령의 적용을 받는 조직은 준수 로드맵의 일환으로 모든 다단계 프로세스에 대한 엔드 투 엔드 감사를 우선순위에 두고, 중복 입력 제거를 선택 사항이 아닌 필수 엔지니어링 과제로 취급해야 한다.