WCAG 1.3.5: 입력 목적 식별

WCAG 1.3.5는 개인 정보를 수집하는 각 입력 필드의 목적을 프로그래밍 방식으로 결정할 수 있어야 하며, 이를 통해 브라우저와 보조 기술이 필드를 자동으로 자동 채우기, 레이블 지정 또는 적응할 수 있도록 요구합니다. 이는 수동 입력이 줄어드는 데서 혜택을 받는 인지 장애 및 운동 장애가 있는 사용자에게 필수적입니다.

이 규칙의 의미

WCAG 1.3.5 — 입력 목적 식별(Identify Input Purpose)는 WCAG 2.1에서 도입되어 WCAG 2.2로 이어지는 레벨 AA 기준이다. 이 기준은 사용자에 대한 정보를 수집하는 모든 <input>, <select>, <textarea> 요소가 그 목적을 프로그램적으로 전달하도록 요구한다. 이를 통해 브라우저와 보조 기술이 그 목적을 자동으로 식별하고 이에 따라 동작할 수 있어야 한다.

이 기준을 충족하는 메커니즘은 autocomplete 속성과, HTML 명세에서 정의된 공식 목록에 있는 올바른 토큰 값의 조합이다. 필드가 사용자의 이름, 이메일 주소, 전화번호, 우편 주소, 신용카드 번호 또는 이와 유사한 개인정보를 수집하는 경우, autocomplete 속성에는 해당 필드의 목적을 정확히 설명하는 값이 포함되어야 한다. 예를 들어, 이름(First Name) 필드에는 autocomplete="given-name", 이메일 필드에는 autocomplete="email"과 같이 설정해야 한다.

이 기준은 특히 사용자 본인에 대한 정보를 수집하는 입력에 적용된다. 사용자가 다른 사람에 대한 데이터를 입력하는 필드(예: 사용자가 다른 사람을 대신해 예약할 때 승객 이름을 묻는 여행 예약 양식)에는 적용되지 않으며, 자동 완성이 보안 위험을 초래할 수 있는 필드(일회용 비밀번호나 CAPTCHA 스타일의 챌린지 등)에도 적용되지 않는다. 이러한 경우에는 autocomplete="off" 또는 autocomplete="one-time-code"를 정당하게 사용할 수 있다.

통과하려면 (1) 범위에 포함되는 모든 입력 필드에 autocomplete 속성이 있어야 하고, (2) 그 속성의 값이 HTML 자동 채우기 명세에 정의된 유효하고 인식 가능한 토큰이어야 한다. 임의의 문자열, 의미 있는 값이 필요한데 비어 있는 값, 철자가 틀린 토큰은 허용되지 않는다. 실패는 범위에 포함되는 입력에 autocomplete 속성이 전혀 없거나, 정당한 이유 없이 autocomplete="off"를 사용했거나, autocomplete="firstname" (올바른 토큰은 given-name) 또는 autocomplete="phone" (올바른 토큰은 tel)과 같은 잘못된 토큰을 사용했을 때 발생한다.

유효한 autocomplete 토큰의 전체 목록은 WHATWG HTML Living Standard에서 관리하며, 이름(given-name, family-name, additional-name), 주소(street-address, address-line1, postal-code, country-name), 연락처 정보(email, tel, tel-national), 자격 증명(username, current-password, new-password), 결제 정보(cc-name, cc-number, cc-exp, cc-csc) 등과 관련된 값을 포함한다. 토큰은 또한 섹션 식별자(예: section-billing)와 배송(shipping) 또는 청구(billing) 키워드를 접두사로 붙여, 하나의 페이지에서 여러 주소 그룹을 처리할 수 있다.

왜 중요한가

이 기준은 주로 인지 장애가 있는 사용자, 즉 난독증, 기억력 손상, 주의력 결핍, 학습 장애가 있는 사람들을 위해 존재한다. 이러한 사용자에게는 이름, 성, 거리 주소, 도시, 우편번호, 전화번호, 결제 정보 등 여러 개의 필드로 구성된 복잡한 결제 양식을 올바르게 작성하는 것이 상당한 인지적 부담이 될 수 있다. autocomplete 토큰이 올바르게 설정되어 있으면, 브라우저가 한 번의 상호작용으로 사용자 프로필에 저장된 정보로 필드를 미리 채울 수 있어 마찰과 오류 위험을 크게 줄일 수 있다.

운동 장애가 있는 사용자, 즉 스위치 액세스, 시선 추적 소프트웨어, sip-and-puff 장치 등을 사용하는 손 기능이 제한된 사람들에게도 동일하게 중요하다. 이들에게 타이핑은 느리고 힘들며 때로는 고통스럽다. 신뢰할 수 있게 동작하는 자동 채우기는 10분이 걸리는 고역을 거의 즉각적인 작업으로 바꿀 수 있다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 13억 명이 상당한 장애를 가지고 살고 있으며, 미세한 손 조작에 영향을 미치는 운동 장애는 가장 흔한 장애 유형 중 하나이다.

자동 채우기 외에도, 올바른 autocomplete 토큰은 브라우저와 보조 기술이 사용자 정의 아이콘, 레이블 또는 보강된 입력 인터페이스를 제공할 수 있게 한다. 예를 들어, 모바일 기기에서 tel 필드에 자동으로 전화 키패드를 표시하거나, cc-number 필드에 신용카드 그래픽을 표시하는 식이다. 기억력 손상이 있는 사용자에게 중요한 접근성 도구인 비밀번호 관리자 역시 이러한 토큰에 의존해 자격 증명 필드를 올바르게 식별하고 채운다.

현실적인 시나리오를 생각해 보자. 뇌성마비가 있는 사용자가 정부 복지 신청서를 작성하고 있다. 양식에는 이름, 주소, 주민/국가 ID, 연락처 정보를 포함해 12개의 필드가 있다. 올바른 autocomplete 값이 없다면 모든 필드를 수동으로 입력해야 한다. 단 하나의 잘못된 토큰, 예를 들어 autocomplete="family-name" 대신 autocomplete="surname"을 사용한 경우만으로도 브라우저가 해당 필드를 인식하지 못하게 되어, 사용자는 성을 한 글자씩 직접 입력해야 한다. 반대로 토큰이 올바르면 전체 양식을 몇 초 만에 자동으로 채울 수 있어, 노력과 오류율 모두를 줄일 수 있다.

또한 조직 입장에서는 사용성 및 전환율 측면의 이점도 있다. 연구에 따르면 자동 채우기와 호환되는 양식은 이탈률이 낮고 완료율이 높다는 결과가 일관되게 나타난다. 즉, autocomplete 토큰을 수정하는 것은 접근성 개선일 뿐 아니라 직접적인 비즈니스 개선이기도 하다.

테스트 방법

axe DevTools 또는 Lighthouse로 자동 스캔을 실행한다. Chrome 또는 Firefox에서 양식이 포함된 페이지를 연다. axe DevTools에서 "Analyze"를 클릭하고 규칙 ID autocomplete-valid로 결과를 필터링한다. Lighthouse에서는 접근성 감사(a11y audit)를 실행하고 autocomplete 관련 위반 사항을 찾는다. 플래그된 모든 요소를 기록하고 보고된 잘못된 토큰 값을 메모한다. 각 플래그된 요소를 수정한 뒤 다시 스캔하여 수정이 적용되었는지 확인한다.
범위에 포함되는 모든 입력 필드를 수동으로 식별한다. 양식을 검토하고 현재 사용자에 대한 정보를 수집하는 모든 필드(이름, 주소, 이메일, 전화번호, 결제 정보, 자격 증명)를 목록으로 만든다. 각 필드에 autocomplete 속성이 존재하는지, 그리고 그 토큰이 HTML 자동 채우기 토큰 목록에 따라 필드의 실제 목적과 일치하는지 확인한다. 다른 사람에 대한 정보를 수집하는 필드는 범위 밖이므로 제외할 수 있다.
브라우저 자동 채우기 동작을 테스트한다. Chrome 또는 Firefox에서 브라우저에 저장된 프로필이 있는지 확인한다(설정 > 자동 채우기). 양식 페이지로 이동해 첫 번째 개인정보 필드를 클릭한다. 브라우저가 자동 채우기 제안을 표시하는지, 그리고 이를 선택했을 때 올바른 필드에 올바른 값이 채워지는지 확인한다. 주소 필드, 결제 필드, 자격 증명 필드에 대해서도 반복한다. 자동 채우기가 값을 제안하지 않거나 잘못된 필드를 채운다면 autocomplete 토큰이 잘못되었을 가능성이 크다.
스크린 리더와 브라우저 조합으로 테스트한다. NVDA와 Firefox를 사용해 Tab 키로 각 양식 필드를 이동한다. NVDA는 필드의 레이블과 목적을 알려야 하며, 일부 스크린 리더와 브라우저 조합은 autocomplete 목적도 함께 알려준다. macOS의 VoiceOver(Safari)에서는 Tab으로 필드를 이동하며 VoiceOver가 자동 채우기 가능 여부를 알리는지 확인한다. JAWS와 Chrome에서는 동일하게 Tab으로 필드를 이동하며 JAWS가 예상되는 필드 맥락을 알리는지 확인한다. 스크린 리더가 항상 autocomplete 토큰을 명시적으로 알리지는 않지만, 키보드 탐색과 함께 자동 채우기가 올바르게 동작하는지 확인하는 것은 프로그램적 목적이 노출되고 있음을 검증하는 방법이다.
브라우저 DevTools에서 autocomplete 속성을 검사한다. 각 양식 필드를 마우스 오른쪽 버튼으로 클릭하고 "Inspect"를 선택한다. Elements 패널에서 autocomplete 속성이 존재하는지, 그리고 그 값이 유효한 토큰과 정확히 일치하는지 확인한다. 특히 autocomplete="shipping street-address"와 같은 다중 토큰 값에 주의를 기울이고, 토큰 순서가 명세(섹션 이름, 그 다음 "shipping" 또는 "billing", 그 다음 필드 이름)를 따르는지 확인한다.

수정 방법

이름 필드 — 잘못된 예

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

이름 필드 — 올바른 예

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

청구 및 배송 섹션이 있는 주소 양식 — 잘못된 예

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

청구 및 배송 섹션이 있는 주소 양식 — 올바른 예

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

전화번호 필드 — 잘못된 예

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

전화번호 필드 — 올바른 예

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

로그인 자격 증명 — 잘못된 예

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

로그인 자격 증명 — 올바른 예

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

자주 발생하는 실수

올바른 토큰 given-name" 대신 autocomplete="firstname" 또는 autocomplete="first-name"을 사용하는 경우. 이런 비표준 값은 논리적으로 보이더라도 브라우저나 보조 기술에서 인식되지 않는다. 항상 HTML 자동 채우기 명세에 있는 정확한 토큰을 사용해야 한다.
autocomplete="tel" 대신 autocomplete="phone"을 사용하는 경우. "phone"이라는 단어는 유효한 토큰이 아니다. 명세에서는 전체 전화번호에 대해 tel을 사용하며, 전화번호의 하위 부분에 대해서는 tel-national, tel-area-code, tel-local을 사용한다.
보안을 이유로 자격 증명 필드에 autocomplete="off"를 설정하는 경우. 최신 브라우저와 WCAG 명세는 로그인 양식에서 자동 채우기를 막는 것이 장애가 있는 사용자에게 실제 장벽을 만들 뿐, 보안을 의미 있게 향상시키지 못한다는 점을 인정하고 있다. 대신 autocomplete="username"과 autocomplete="current-password"를 사용해야 한다.
브라우저가 필드 이름이나 레이블에서 목적을 추론할 것이라고 가정하고 개인정보 필드에 autocomplete 속성을 아예 생략하는 경우. 브라우저는 필드 목적을 추측하기 위해 휴리스틱을 사용하지만, 이는 신뢰할 수 없고 브라우저마다 일관성이 없다. 보장된 접근 가능한 경험을 위해서는 명시적인 토큰이 필요하다.
구체적인 주소 하위 토큰 대신 autocomplete="address"를 사용하는 경우. 명세에는 address 토큰이 없다. street-address, address-line1, address-line2, address-level1(주/도), address-level2(도시), postal-code를 개별적으로 사용해야 한다.
다중 토큰 값에서 shipping 또는 billing 키워드를 잘못된 순서로 배치하는 경우. 올바른 순서는 선택적 섹션 접두사(예: section-billing), 그 다음 선택적 shipping/billing 키워드, 그 다음 필드 이름 토큰이다. autocomplete="street-address billing"는 잘못된 형식이며, 올바른 형식은 autocomplete="billing street-address"이다.
보이는 필드에만 autocomplete를 적용하고 숨겨진 필드나 동적으로 표시되는 필드는 무시하는 경우. 처음에는 숨겨져 있다가 사용자 상호작용을 통해 표시되는 필드(추가 주소 줄이나 선택적 필드 등)도 활성화될 때 올바른 autocomplete 토큰을 가져야 한다.
페이지 로드 후 JavaScript로 autocomplete 속성을 동적으로 제거하거나 덮어쓰는 경우. 일부 폼 라이브러리나 UI 프레임워크는 컴포넌트가 마운트되거나 다시 렌더링될 때 입력 속성을 재설정하면서 autocomplete 토큰을 의도치 않게 제거한다. 모든 JavaScript가 실행된 후에도 라이브 DOM에서 속성이 유지되는지 항상 확인해야 한다.
type="email" 또는 type="tel"만으로 autocomplete 없이도 목적이 전달된다고 가정하는 경우. type은 일부 정보를 제공하지만, autocomplete 속성은 WCAG 1.3.5에서 별도로 요구하는 명시적 신호이며 브라우저와 보조 기술에서 다른 방식으로 사용된다.
서로 다른 데이터를 수집하는 두 개의 필드에 동일한 autocomplete 토큰을 사용하는 경우. 예를 들어, 업무용 이메일 필드와 개인 이메일 필드 모두에 autocomplete="email"을 사용하면 브라우저가 혼란을 겪고 잘못된 자동 채우기가 발생할 수 있다. 이를 구분하기 위해 section-work email과 section-personal email처럼 섹션 접두사를 사용해야 한다.

터키 접근성 규정과의 관계

터키의 대통령 통지 2025/10은 2025년 6월 21일 관보(Official Gazette) 제 32933호에 게재되었으며, 터키에서 운영되는 광범위한 조직에 대해 구속력 있는 접근성 요구사항을 수립한다. 이 통지는 디지털 서비스의 기준으로 WCAG 2.2 레벨 AA 준수를 의무화하며, 여기에는 WCAG 1.3.5 — 입력 목적 식별(Identify Input Purpose)이 직접적으로 포함된다.

통지의 적용 대상은 매우 광범위하다. 공공기관과 정부 기관은 모든 시민 대상 디지털 서비스에 대해 이 기준을 충족해야 한다. 포함되는 민간 부문 조직으로는 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 허가받은 여행사, 민간 여객 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 민간 교육 기관 등이 있다. 실질적으로 이는 터키의 거의 모든 주요 소비자 대상 디지털 제품(은행 앱, 온라인 소매 결제, 의료 예약 포털 등)이 모든 개인정보 입력 필드에 올바르게 구현된 autocomplete 토큰을 가져야 함을 의미한다.

특히 WCAG 1.3.5와 관련해서는, 터키의 전자상거래 결제 양식, 은행 계좌 개설 양식, 병원 환자 등록 양식, 통신 가입 양식 등에서 이름, 주소, 전화번호, 결제 정보와 같은 사용자 정보를 수집하는 경우, 모든 관련 입력 필드에 유효한 autocomplete 속성 값이 포함되어야 한다. 이를 준수하지 않으면 레벨 AA 비준수에 해당하며, 조직이 접근성 기준을 충족했음을 인증하는 공식 마크인 접근성 로고(Erişilebilirlik Logosu)를 취득하거나 유지하는 데 장애가 될 수 있다. 이 로고는 가족·사회서비스부(Ministry of Family and Social Services)에서 발급한다.

접근성 로고는 평판과 규제 측면에서 중요한 의미를 가지며, 전자상거래나 은행과 같이 경쟁이 치열한 소비자 시장에 있는 조직은 이를 획득하고 유지할 강한 동기를 가진다. WCAG 1.3.5는 구현이 간단하다(올바른 autocomplete 속성 값을 추가하거나 수정하는 데 아키텍처 변경이 필요하지 않음)면서도 인지 및 운동 장애가 있는 사용자에게 상당한 이점을 제공하므로, 2025/10 통지에 따른 레벨 AA 완전 준수를 추구하는 조직이 수행할 수 있는 가장 비용 대비 효과가 높은 접근성 개선 중 하나이다.

조직은 모바일 웹 인터페이스와 반응형 레이아웃을 포함해 모든 디지털 자산의 양식을 감사하고, 어떤 양식 구현이든 올바른 autocomplete 토큰을 필수 요소로 요구하는 개발 정책을 수립해야 한다. 이는 axe-core와 같은 도구를 사용한 CI/CD 파이프라인 내 자동 테스트를 통해 강제하여, 회귀가 프로덕션에 반영되기 전에 발견되도록 해야 한다.