WCAG 3.3.8: 접근 가능한 인증 (최소)

WCAG 3.3.8은 인증 과정이 비밀번호를 암기하거나, 퍼즐을 풀거나, 문자를 옮겨 적는 것과 같은 인지 기능 테스트에 의존하지 않도록 요구하며, 예외적으로 대체 방법이나 지원이 제공되는 경우에만 이를 허용합니다. 이는 인지 장애가 있는 사용자가 디지털 서비스에서 배제되는 것을 방지합니다.

이 규칙의 의미

WCAG 3.3.8 Accessible Authentication (Minimum)은 WCAG 2.2에서 도입된 레벨 AA 기준이다. 이 기준은 인지 기능 테스트(사용자가 정보를 기억하거나, 조작하거나, 옮겨 적어야 하는 과제로 정의됨)가 다음 조건 중 최소 하나를 충족하지 않는 한, 인증 단계 완료를 위한 유일한 수단이 되어서는 안 된다고 규정한다.

대체 방법: 인지 기능 테스트에 의존하지 않는 다른 인증 경로가 제공된다(예: 이메일로 전송되는 매직 링크, 생체 인식 로그인, 패스키 등).
지원 메커니즘: 사용자 에이전트나 제3자 도구가 사용자를 대신해 해당 단계를 완료할 수 있도록 허용된다(예: 비밀번호 관리자가 자격 증명을 자동 입력하거나, 일회용 코드를 복사·붙여넣기 하는 경우).
객체 인식 예외: 인지 기능 테스트가 이미지 속 객체를 식별하는 과제인 경우(예: 신호등이 포함된 모든 이미지를 선택하기) — 이러한 유형의 테스트는 Minimum(AA) 수준에서 허용된다.
개인 콘텐츠 예외: 사용자가 직접 제공한 콘텐츠에 의존하는 테스트인 경우(예: 격자에서 이전에 업로드한 사진을 선택하기).

실무적으로, 사용자 이름과 비밀번호만 요구하는 로그인 폼은, 브라우저 자동 완성과 비밀번호 관리자가 동작할 수 있도록 허용하는 한(즉, 필드가 표준 <input type='password'>를 사용하고 붙여넣기를 차단하지 않는 경우), 이 기준을 충족한다. 왜곡된 텍스트를 옮겨 적게 하면서 다른 인증 경로를 전혀 제공하지 않는 CAPTCHA는 명백한 실패이다. 특정 범주에 해당하는 이미지를 선택하게 하는 CAPTCHA(객체 인식)는 AA 수준에서는 허용되지만, AAA(3.3.9)에서는 더 엄격하게 다뤄진다.

이 기준은 인증 프로세스의 모든 단계에 적용된다. 초기 로그인, 단계적 인증(step-up authentication), 다중 요소 인증, 계정 복구, 세션 재인증 등이 모두 포함된다. 또한 기본 로그인 화면뿐 아니라 기능 접근을 보호하는 모든 프로세스에 적용된다.

핵심 기술적 함의는, 개발자는 인증 필드에 autocomplete='off'를 사용해서는 안 되며, JavaScript 이벤트 핸들러로 붙여넣기를 비활성화해서도 안 되고, 보조 기술과 브라우저 자동 완성이 올바르게 동작하도록 하는 표준 입력 의미론을 깨뜨려서도 안 된다는 점이다.

왜 중요한가

인증은 사람들이 일상적으로 의존하는 거의 모든 디지털 서비스—은행, 의료 포털, 정부 서비스, 전자상거래, 커뮤니케이션 플랫폼—로 들어가는 관문이다. 이 관문이 인지적 장벽을 부과할 때, 인구의 상당 부분을 체계적으로 배제하게 된다.

인지 장애는 매우 넓은 스펙트럼을 포괄한다. 난독증, 계산장애, 주의력 결핍 장애, 후천적 뇌 손상, 치매, 지적 장애, 불안 장애 등이 포함된다. 세계보건기구(WHO)는 전 세계적으로 약 6명 중 1명이 어떤 형태로든 중대한 장애를 경험한다고 추정하며, 인지 및 신경학적 상태는 가장 큰 범주 중 하나를 차지한다. 이러한 사용자에게 왜곡된 문자열을 정확히 옮겨 적거나, 시간 압박 속에서 시각 퍼즐을 풀거나, 인증 앱과 로그인 폼 사이를 오가는 작업은 실제로 불가능하거나 극도로 소모적일 수 있다.

구체적인 상황을 생각해 보자. 난독증이 있는 한 사람이 검사 결과를 확인하기 위해 건강보험 포털에 로그인하려 한다. 사이트는 오디오 대체 수단도 우회 방법도 없는 텍스트 CAPTCHA를 제시한다. 이 사용자에게 왜곡된 글자 형태는 구분이 되지 않고, 입력 필드는 붙여넣기를 차단한다. 여러 번 실패한 끝에 계정이 잠긴다. 사용자는 시급한 의료 정보를 확인할 수 없다. 이는 가상의 예외적 사례가 아니라, 수백만 명이 일상적으로 겪는 경험이다.

스위치 액세스나 시선 추적 장치에 의존하는 운동 장애 사용자도 영향을 받는다. 별도의 기기에서 복잡한 일회용 코드를 다시 입력하거나, 이미지 타일을 특정 순서로 드래그하는 작업은 이러한 입력 방식으로는 물리적으로 불가능할 수 있다. 복사·붙여넣기나 패스키 기반 인증을 허용하면 이러한 장벽은 완전히 해소된다.

고령층도 또 하나의 중요한 집단이다. 연령 관련 인지 저하는 기억력과 처리 속도에 영향을 미쳐, 복잡한 CAPTCHA와 다단계 암기 과제를 불균형적으로 어렵게 만든다. 터키와 전 세계적으로 인구 고령화가 진행됨에 따라, 접근 가능한 인증에 대한 비즈니스·규제적 필요성은 해마다 더 커지고 있다.

사용성 및 전환 관점에서 보면, 인증 흐름의 마찰은 이탈률을 직접적으로 높인다. 텍스트 CAPTCHA를 리스크 기반 인증이나 패스키로 대체한 전자상거래 플랫폼은 일관되게 더 높은 로그인 완료율과 잠긴 계정 관련 지원 비용 감소를 보고하고 있다.

테스트 방법

자동 스캔(axe DevTools / Lighthouse): 각 인증 페이지(로그인, 회원가입, 계정 복구, MFA)에 대해 axe DevTools를 실행한다. 사용자 이름 및 비밀번호 필드에서 autocomplete-valid 위반이 있는지 확인한다. Lighthouse에서는 접근성 감사에서 폼 관련 이슈를 검토한다. 어떤 자동 규칙도 3.3.8 실패를 확정적으로 표시하지는 못한다는 점에 유의해야 한다. 자동 결과는 출발점일 뿐이다.
모든 인지 기능 테스트 식별: 인증 흐름의 모든 단계를 수동으로 목록화한다. 현재 화면에 제공되지 않은 정보를 기억해야 하거나, 문자를 옮겨 적거나, 퍼즐을 풀거나, 계산을 수행해야 하는 단계를 모두 기록한다. 각 단계가 준수하는 대체 수단(객체 인식, 개인 콘텐츠, 대체 로그인 방법, 지원 메커니즘)을 갖추고 있는지 확인한다.
붙여넣기 기능 테스트: 모든 인증 입력(사용자 이름, 비밀번호, OTP, 복구 코드)에 대해 키보드 단축키(Windows/Linux: Ctrl+V, macOS: Cmd+V)를 사용해 텍스트를 붙여넣어 본다. 붙여넣은 내용이 필드에 나타나는지 확인한다. 우클릭 컨텍스트 메뉴를 사용해 다시 시도한다. 붙여넣기가 차단된다면, 인지 기능 테스트가 없는 대체 수단이 존재하지 않는 한 이는 실패이다.
비밀번호 관리자 자동 입력 테스트: 비밀번호 관리자가 탑재된 브라우저(네이티브 또는 확장 기반)를 사용해, 회원가입 시 자격 증명을 저장한 뒤 로그인 페이지로 돌아온다. 비밀번호 관리자가 필드를 인식하고 자동 입력할 수 있는지 확인한다. 주요 AT+브라우저 조합을 포괄하기 위해 Firefox+NVDA, Safari+VoiceOver(macOS/iOS), Chrome+JAWS에서 테스트한다. 필드가 비표준 마크업을 사용하거나 자동 입력된 값을 JavaScript로 지우는 경우, 이는 실패이다.
NVDA + Firefox — 스크린 리더 점검: 키보드와 NVDA만 사용해 로그인 폼을 탐색한다. 모든 필드에 접근 가능한지, 필드 레이블이 올바르게 읽히는지, CAPTCHA 위젯이 있다면 접근 가능한 대체 수단이 있는지 확인한다. CAPTCHA가 순수 시각적 요소이고 오디오 옵션도, 대체 로그인 경로도 없다면 실패로 기록한다.
VoiceOver + Safari(iOS): 모바일 기기에서, 사이트가 생체 인식 로그인을 제공하는 경우 Face ID 또는 Touch ID로 로그인을 시도한다. 스와이프 탐색으로 생체 인식 옵션에 접근할 수 있는지, VoiceOver가 이를 올바르게 안내하는지 확인한다. 이는 인지 기능 테스트가 없는 대체 수단이 형식적으로만 존재하는 것이 아니라 실제로 접근 가능하게 동작하는지 검증하는 것이다.
인지 단계의 시간 제한 확인: CAPTCHA나 OTP 입력에 시간 제한이 있는 경우, 사용자가 이를 연장하거나 비활성화할 수 있는지(2.2.1 관련)를 확인하고, 별도로 해당 시간 제한 단계가 대체 수단 없는 인지 기능 테스트에 해당하는지 기록한다.

해결 방법

대체 수단 없는 텍스트 CAPTCHA — 잘못된 예

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

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

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

대체 수단 없는 텍스트 CAPTCHA — 올바른 예

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</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'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

붙여넣기를 차단하는 OTP 필드 — 잘못된 예

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

붙여넣기를 차단하는 OTP 필드 — 올바른 예

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

대체 수단 없는 이미지 선택 CAPTCHA(AAA에서는 문제, AA에서는 통과) — AA 수준에서 올바른 예

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

자주 발생하는 실수

비밀번호 필드에 autocomplete='off' 설정: 이는 비밀번호 관리자 자동 입력을 비활성화해, 표준 비밀번호 인증을 준수하게 만드는 지원 메커니즘을 제거한다. 대신 autocomplete='current-password'를 사용하고, 브라우저가 자격 증명 저장을 관리하도록 해야 한다.
onpaste='return false;' 또는 addEventListener('paste', e => e.preventDefault())로 붙여넣기 차단: 이는 사용자가 자격 증명을 직접 입력하도록 강제해, 접근 불가능한 옮겨 적기 과제를 만든다. 인증 입력에서 모든 붙여넣기 방지 핸들러를 제거해야 한다.
키보드로 접근할 수 없는 패스키 옵션 제공: 생체 인식 대체 수단은 키보드와 보조 기술로 접근·조작할 수 있어야만 3.3.8을 충족한다. 호버 메뉴 뒤에 숨겨져 있거나 포커스를 받을 수 없는 <div>로 렌더링된 패스키 버튼은 준수하는 대체 수단으로 간주되지 않는다.
봇 완화 전략으로 텍스트 CAPTCHA만 사용: 디바이스 지문, 타이핑 패턴, IP 평판 등을 분석하는 리스크 기반 서버 측 봇 탐지로 전환하면, 보안을 희생하지 않고도 인지 기능 테스트를 완전히 제거할 수 있다. 클라이언트 측 CAPTCHA에만 의존하는 것은 접근성 실패이자 보안 관점에서도 좋지 않은 관행이다.
OTP를 여러 개의 한 글자 입력으로 나누고 필드 간 붙여넣기 차단: 일부 구현은 OTP 입력을 위해 여섯 개의 <input maxlength='1'> 필드를 사용하고, JavaScript로 포커스를 자동 이동시킨다. 이 패턴은 비밀번호 관리자에서 붙여넣기를 자주 깨뜨리며, 첫 번째 필드에 전체 코드를 붙여넣었을 때 문자를 올바르게 분배하는 구현이 없는 한 3.3.8을 위반한다.
계정 복구 흐름에만 이미지 기반 CAPTCHA 요구: 팀은 종종 기본 로그인 페이지에는 접근 가능한 로그인 대체 수단을 추가하면서, 단계적 인증, 비밀번호 재설정, 계정 잠금 해제 흐름은 잊어버린다. 이들 각각은 별도의 인증 단계이며, 개별적으로 3.3.8을 준수해야 한다.
오디오 CAPTCHA를 텍스트 CAPTCHA의 완전한 대체로 간주: 오디오 대체 수단은 시각장애인에게는 도움이 되지만, 인지 장애가 있는 사용자나 소음이 심한 환경에 있는 사용자에게는 도움이 되지 않는다. 오디오 CAPTCHA 역시 옮겨 적기 요구를 제시한다. 올바른 해결책은 CAPTCHA를 제거하거나, 인지 기능 테스트가 전혀 없는 경로를 제공하는 것이다.
비밀번호 관리자 감지를 깨뜨리는 동적 입력 필드 ID 생성: 사용자 이름과 비밀번호 필드의 id 속성을 페이지 로드마다 무작위로 변경하는(잘못된 봇 방지 기법) 경우, 비밀번호 관리자는 필드를 안정적으로 식별할 수 없다. 이는 사실상 자동 입력을 비활성화하고, 준수하는 지원 메커니즘을 제거하는 것이다.
서드파티 CAPTCHA 위젯이 자동으로 준수한다고 가정: 인기 있는 CAPTCHA 서비스는 접근 가능한 변형을 제공할 수 있지만, 기본적으로 활성화되어 있지는 않다. 개발자는 접근 가능한 버전을 명시적으로 구성해야 하며, 단순히 새로운 유형의 접근 불가능한 테스트를 추가하는 것이 아니라, 해당 버전이 기준 요구 사항을 충족하는지 직접 검증해야 한다.
포커스 시 JavaScript로 자동 입력 값을 지우기: 일부 폼은 플레이스홀더 텍스트를 보여주거나 재입력을 유도하기 위해, 필드에 포커스가 가면 입력 내용을 지운다. 이 동작이 비밀번호 관리자가 자동 입력한 값을 지우는 경우, 수동 재입력을 강제하게 되어 3.3.8을 위반한다.

터키 접근성 규정과의 관계

터키의 2025/10번 대통령령은 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.2와 정렬된 웹 및 모바일 접근성 의무를 수립한다. 이 대통령령은 해당 기관이 디지털 제품과 서비스 전반에서 레벨 AA 준수에 도달할 것을 요구한다. WCAG 2.2에서 레벨 AA 기준인 WCAG 3.3.8은, 따라서 이 대통령령이 도입한 의무적 준수 요구 사항의 직접적인 범위에 포함된다.

이 대통령령은 광범위한 민간 및 공공 부문 기관을 포괄한다. 공공 기관과 정부 부처는 완전한 AA 준수를 달성해야 한다. 민간 부문에서는, 이 대통령령이 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 민간 의료 제공자, 가입자 200,000명 이상인 통신 사업자, 여행사, 민간 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받은 민간 학교에 적용된다. 이러한 조직에서, 지원되지 않는 CAPTCHA가 있는 로그인 페이지나 붙여넣기를 차단하는 OTP 필드와 같은 접근 불가능한 인증 흐름은 직접적인 규제 리스크를 초래한다.

접근성 로고(Erişilebilirlik Logosu)는 가족·사회서비스부가 발급하는, 터키의 디지털 접근성 준수에 대한 공식 인증 마크이다. 이 로고를 획득하려면 3.3.8을 포함한 레벨 AA 준수를 입증해야 한다. 전자상거래 사업자, 은행, 기타 트래픽이 많은 디지털 서비스 제공자에게 이 로고는 공적 신뢰 신호 역할을 하며, 조달 및 입찰 요건에서 언급될 수 있다. 접근 불가능한 인지 테스트에 의존하는 인증 흐름은 인증을 가로막고, 조직을 민원 및 집행 조치에 노출시킬 수 있다.

실질적인 준수 관점에서, 터키의 조직은 접근성 로고 심사를 신청하기 전에 로그인, 회원가입, MFA, 비밀번호 재설정, 계정 잠금 해제 등 모든 인증 접점을 3.3.8에 비추어 점검해야 한다. 텍스트 CAPTCHA를 리스크 기반 서버 측 제어로 대체하고, 모든 자격 증명 필드에서 autocomplete를 활성화하며, 패스키나 매직 링크 대체 수단을 제공하는 것이 가장 영향력이 큰 개선 조치이다. 이러한 변경은 규제 요구 사항을 충족하는 동시에, 디지털 서비스를 이용하는 터키 내 약 850만 명의 장애인의 인증 경험을 개선한다.