WCAG 3.3.9: 접근 가능한 인증 (강화됨)

WCAG 3.3.9는 인증 과정에 인지 기능 테스트를 전혀 포함해서는 안 된다고 요구합니다. 퍼즐, 암기, 필사(옮겨 적기) 등은, 인지 기능을 요구하지 않는 대안이나 보조 메커니즘, 또는 객체 기반 방식이 제공되지 않는 한 사용할 수 없습니다. 이 향상된(AAA) 기준은 인지, 운동, 기억 관련 장애가 있는 사용자의 인증에 남아 있는 마지막 장벽을 제거합니다.

이 규칙의 의미

WCAG 3.3.9 — 접근 가능한 인증(강화)은 WCAG 3.3.8(접근 가능한 인증 — 최소, AA)의 AAA 수준 대응 기준이다. 이 둘은 함께, WCAG 2.2에서 도입된 한 쌍의 기준으로, 웹사이트나 애플리케이션에서 본인 인증을 하는 과정 자체가 접근성 장벽이 되지 않도록 보장하기 위해 설계되었다.

AAA 수준에서 3.3.9는 요구 사항을 상당히 강화한다. 이 기준은 다음과 같이 규정한다: 인증 과정의 어떤 단계에서도, 그 단계가 다음 중 최소 하나를 제공하지 않는 한 인지 기능 테스트를 요구해서는 안 된다: 인지 기능 테스트에 의존하지 않는 대체 인증 방법; 사용자가 인지 기능 테스트를 완료하도록 돕는 메커니즘; 또는 인지 기능 테스트가 사물을 인식하는 것일 때. 특히, AA 버전(3.3.8)과 달리, AAA 기준은 비-사물 콘텐츠를 인식하는 것을 허용하던 예외를 제거한다(예: 사용자가 이전에 선택한 비-사물 항목의 사진). 이 수준에서는, 다른 조건들이 충족되지 않는 경우에만, 고양이, 자전거, 집과 같은 일반적인 현실 세계의 사물 이미지를 인식하는 진정한 사물 인식만이 인지 기능 테스트로 허용된다.

인지 기능 테스트는 사용자가 정보를 기억하거나, 조작하거나, 옮겨 적어야 하는 모든 과제로 정의된다. 여기에는 사용자 이름이나 비밀번호를 기억하는 것, 수학 퍼즐을 푸는 것, 왜곡된 텍스트를 해독해야 하는 CAPTCHA를 완료하는 것, 개인 이력에 대한 보안 질문에 답하는 것(예: "당신의 첫 반려동물 이름은 무엇이었습니까?"), 또는 일련의 문자를 옮겨 적는 것이 포함된다. 이들은 모두 많은 사용자가 안정적으로 수행할 수 없는 기억 또는 필사 과제에 해당한다.

통과로 인정되는 경우: 인증 단계가 어떤 인지 기능 테스트도 요구하지 않거나, 다음 조건 중 하나를 충족하면 3.3.9를 통과한다: (1) 완전히 별도의 비-인지 인증 경로가 제공되는 경우(예: 이메일로 전송되는 매직 링크, WebAuthn/패스키, 생체 인식 로그인); (2) 테스트 완료를 돕는 메커니즘이 있는 경우(예: 브라우저의 비밀번호 관리자가 차단되지 않거나, 복사-붙여넣기가 허용되는 경우); 또는 (3) 관련된 유일한 인지 테스트가 이미지 집합에서 일반적인 현실 세계의 사물을 인식하는 것인 경우.

실패로 인정되는 경우: 우회나 대체 수단 없이 사용자가 비밀번호를 기억해서 입력하도록 강요하거나, 붙여넣기 할 수 없는 코드를 옮겨 적게 하거나, 대체 수단 없이 시각 또는 음성 CAPTCHA를 풀게 하거나, 지식 기반 보안 질문에 답하게 하거나, 대체 인증 경로 없이 추상 도형이나 개인 사진과 같은 비-사물 콘텐츠의 이전에 선택한 이미지를 식별하도록 요구하는 모든 흐름은 실패에 해당한다.

공식 예외: WCAG 명세는 사물 인식(현실 세계 사물의 사진)을 AAA 수준에서 허용되는 유일한 이미지 인식 과제로 명시한다. AA 기준(3.3.8)은 사용자가 개인적으로 선택한 "비-사물" 이미지를 인식하는 것도 허용했지만, 3.3.9는 이 예외를 완전히 제거한다. "널리 사용되는" 인증 패턴에 대한 예외는 없다 — 어떤 패턴이 대체 수단 없이 인지 테스트를 요구한다면, 3.3.9를 위반한다.

왜 중요한가

인증은 사용자가 디지털 서비스와 맺는 첫 번째 의미 있는 상호작용인 경우가 많다. 이 상호작용 자체가 접근 불가능하다면, 사이트의 나머지 접근성은 무의미해진다 — 사용자는 아예 "문 안으로 들어갈" 수 없다. WCAG 3.3.9는 이 장벽을 직접적으로 다루며, 그 영향은 매우 넓은 장애 집단에 걸쳐 있다.

인지 장애가 있는 사용자 — 난독증, ADHD, 외상성 뇌손상, 치매, 학습 장애 등을 포함 — 는 복잡한 비밀번호를 암기하거나, 시간 제한이 있는 일회용 코드를 수동으로 옮겨 적거나, 왜곡된 CAPTCHA 텍스트를 해독하는 것이 매우 어렵거나 불가능할 수 있다. 세계보건기구(WHO)는 전 세계 인구의 약 6명 중 1명이 어떤 형태로든 상당한 장애를 경험한다고 추정하며, 인지 장애는 웹 접근성에서 가장 크고 가장 소외된 범주 중 하나를 차지한다.

운동 장애가 있는 사용자 — 파킨슨병, 본태성 떨림, 척수 손상, 스위치 접근이나 시선 추적 기술을 필요로 하는 상태 등을 가진 사람들 — 는 비밀번호를 정확히 입력하거나 코드를 한 글자씩 옮겨 적는 데 어려움을 겪을 수 있다. 클립보드 붙여넣기를 차단하는 것(자주 쓰이지만 실제로는 해로운 사기 방지 조치)은 이러한 사용자들이 보조기기를 통해 각 문자를 힘겹게 입력해야 함을 의미하며, 오류율과 피로도를 극적으로 증가시킨다.

시각장애인 또는 저시력 사용자는 전적으로 스크린 리더나 화면 확대 도구에 의존할 수 있다. 시각 CAPTCHA는 음성 대안이 없으면 완전히 접근 불가능하며, 심지어 음성 CAPTCHA도 청각 장애나 청각 처리 장애가 있는 사용자에게는 악명 높게 어렵다. "모든 신호등을 선택하라"와 같은 이미지 기반 과제는 이미지 설명이 없거나 오해를 부를 경우 역시 문제가 될 수 있다.

청각장애인 또는 난청 사용자는 일회용 코드를 전달하기 위해 오직 전화 통화에만 의존하는 인증 방식에서 장벽을 겪을 수 있으며, 특히 SMS 대안 없이 음성 통화만 제공되는 경우에 그렇다.

구체적인 실제 시나리오: 경도 인지 저하가 있는 72세 사용자가 온라인 뱅킹 포털에 접속하려 한다고 가정해 보자. 은행은 사용자 이름(이메일 주소가 아닌, 기억해야 하는 별도의 값), 복잡한 비밀번호(클립보드 붙여넣기 차단), 그리고 왜곡된 텍스트가 포함된 CAPTCHA를 요구한다. 사용자는 CAPTCHA를 두 번 실패하고 계정이 잠기며, 은행 고객센터에 전화를 걸어야 한다 — 40분이 걸리는 과정이다. 만약 은행이 패스키나 매직 링크를 구현했다면, 이 사용자는 몇 초 만에 인증을 마쳤을 것이다. 이 시나리오는 전 세계 웹에서 매일 수백만 번 반복되고 있으며, 전적으로 예방 가능하다.

장애를 넘어, 접근 가능한 인증은 모든 사용자에게 이득이 된다. 수억 명이 사용하는 비밀번호 관리자는 자격 증명을 붙여넣을 수 있는 능력에 의존한다. 붙여넣기를 차단하거나, 수동 필사를 요구하거나, 접근 불가능한 CAPTCHA를 삽입하는 것은 일반 사용자에게도 좌절감을 준다. 보안 측면의 논거도 있다: 복잡한 비밀번호를 수동으로 입력하도록 강요하면, 사용자가 더 단순하고 약한 비밀번호를 선택하거나 여러 사이트에서 재사용할 가능성이 높아진다. 패스키와 매직 링크는 권장되는 대안으로, 전통적인 비밀번호+CAPTCHA 흐름보다 더 접근 가능할 뿐만 아니라 더 안전하기도 하다.

테스트 방법

모든 인증 진입 지점 식별: 테스트 전에, 애플리케이션에서 사용자가 인증하거나 신원을 검증해야 하는 모든 위치를 매핑한다. 여기에는 초기 로그인, 계정 생성, 비밀번호 재설정, 2단계 인증 프롬프트, 세션 타임아웃 후 재인증, 결제 확인 화면, 연령 확인 게이트 등이 포함된다. 각 흐름은 독립적으로 평가해야 한다.
자동화된 기본 스캔 실행: 각 인증 페이지에서 axe DevTools(브라우저 확장) 또는 Chrome DevTools의 Lighthouse를 사용한다. 이 도구들은 3.3.9 위반을 직접 표시하지는 않지만, 폼 필드의 레이블 누락, 접근 불가능한 iframe 콘텐츠, 포커스 관리 누락 등 인증 장벽을 악화시키는 관련 문제를 드러낸다. 수동 평가를 위한 맥락으로 표시된 문제를 기록한다. axe DevTools에서는 수동 판단이 필요한 항목을 위해 "Needs Review" 탭을 확인한다.
인지 기능 테스트 여부 점검: 각 인증 단계에 대해 다음을 자문한다: 이 단계는 사용자가 (a) 무언가를 기억하거나, (b) 무언가를 옮겨 적거나, (c) 퍼즐을 풀도록 요구하는가? 그렇다면, 다음 중 최소 하나가 존재하고 동등하게 눈에 띄는지 확인한다: 비-인지 대체 경로; 붙여넣기 허용이나 자동완성 호환 필드와 같은 완료를 돕는 메커니즘; 또는 유일한 인지 과제가 일반적인 현실 세계 사물을 인식하는 것인지 여부.
클립보드 붙여넣기 동작 테스트: 각 비밀번호 및 코드 입력 필드에서, 텍스트 문자열을 클립보드에 복사한 뒤 Windows/Linux에서는 Ctrl+V, macOS에서는 Cmd+V로 붙여넣기를 시도한다. 붙여넣기가 차단되면 이는 실패다. 또한 브라우저 비밀번호 관리자 자동완성이 억제되는지(autocomplete='off' 또는 포커스 시 자동완성 값을 지우는 JavaScript가 있는지) 확인한다.
NVDA + Firefox로 테스트: 키보드와 NVDA 스크린 리더만 사용해 전체 인증 흐름을 탐색한다. 모든 폼 필드가 의미 있는 레이블과 함께 안내되는지, 모든 인터랙티브 컨트롤(버튼, 링크, CAPTCHA 과제)에 접근 및 조작이 가능한지, 모든 오류 메시지가 관련 필드와 프로그램적으로 연결되어 있고 추가 탐색 없이 즉시 안내되는지 확인한다.
VoiceOver + Safari(macOS/iOS)로 테스트: 전체 인증 흐름을 반복한다. iOS에서는, 네이티브 인증이 사용되는 경우 생체 인증(Face ID / Touch ID)이 대체 수단으로 제공되는지, 그리고 생체 인증이 불가능할 때 웹 기반 흐름이 Switch Control만으로 완전히 조작 가능한지 확인한다.
JAWS + Chrome으로 테스트: 흐름을 반복하면서, 특히 서드파티 위젯(OAuth 소셜 로그인, CAPTCHA iframe 등)이 어떻게 안내되는지에 주의를 기울인다. JAWS는 특정 ARIA 패턴을 NVDA와 다르게 처리하므로, 두 스크린 리더 모두로 테스트해야 한다.
대체 경로의 진정한 동등성 평가: 대체 인증 방법(예: "매직 링크로 로그인")이 존재한다면, 그 대체 수단만 사용해 전체 흐름을 완료한다. 어떤 인지 테스트도 요구하지 않고 동일한 인증 상태에 도달하는지 확인한다. 대체 경로 자체에 CAPTCHA나 기억 테스트가 포함되어 있다면, 이는 3.3.9에서 유효한 대체 수단이 아니다.
증거와 함께 결과 문서화: 각 실패에 대해, 정확히 어떤 단계가 왜 실패하는지 보여주는 화면 녹화나 주석이 포함된 스크린샷을 캡처한다. 이 문서는 개발팀에 대한 개선 작업 인계와 감사 추적을 위해 필수적이다.

해결 방법

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

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

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

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA를 패스키와 매직 링크로 대체 — 올바른 예

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

OTP 필드에서 클립보드 붙여넣기 차단 — 잘못된 예

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

붙여넣기 허용 및 자동완성 힌트가 있는 OTP 필드 — 올바른 예

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

지식 기반 보안 질문 — 잘못된 예

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

비-인지 대체 수단을 활용한 신원 확인 — 올바른 예

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

자주 발생하는 실수

비밀번호 필드에 autocomplete='off'를 추가하여 브라우저 자동완성을 막는 것. 이는 사용자가 비밀번호를 기억하지 않고도 로그인할 수 있게 해 주는 주요 메커니즘을 비활성화하며, 3.3.9를 직접 위반한다. autocomplete='off'를 제거하고 대신 autocomplete='current-password' 또는 autocomplete='new-password'를 사용해야 한다.
인증 입력 필드에 JavaScript paste 이벤트 리스너를 붙여 event.preventDefault()를 호출하는 것이 보안을 향상시킨다고 믿는 경우. 실제로는 비밀번호 관리자와 보조기술을 차단하며, 3.3.9에서 필사 요구 사항에 해당한다.
시각 CAPTCHA에 대한 우회 수단으로 음성 CAPTCHA를 충분하다고 보는 것. 음성 CAPTCHA 역시 왜곡된 음성 문자를 옮겨 적게 하는 인지 기능 테스트이며, 3.3.9를 충족하지 못한다. 진정한 비-인지 대체 경로가 필요하다.
패스키나 소셜 로그인 옵션을 제공하지만, 이를 CAPTCHA 도전 과제 뒤에 숨기는 것. 사용자가 접근 가능한 대체 수단에 접근하기 위해 먼저 인지 테스트를 통과해야 한다면, 그 대체 수단은 실제로 동등하지 않으며 흐름은 3.3.9를 위반한다.
OTP 입력을 위해 6개의 단일 문자 <input> 필드를 사용하는 것(흔한 UI 패턴)이면서, 필드 전체에 걸친 붙여넣기-자동 채우기를 지원하지 않는 경우. 많은 구현이 첫 번째 필드에만 붙여넣기를 허용하고 나머지 다섯 개는 수동으로 한 글자씩 입력하도록 요구하는데, 이는 필사 장벽이다.
반복 인증이 어려운 사용자를 위한 유일한 편의로 "Remember me"나 지속 세션 쿠키에 의존하는 것. 인증 빈도를 줄이는 것은 도움이 되지만, 접근 불가능한 인증 과정을 해결하지는 못한다 — 사용자는 여전히 최소 한 번은 인지 테스트를 통과해야 하며, 세션은 만료되거나 삭제될 수 있다.
사전 경고 없이 타임아웃 시 필드를 지우는 시간 제한 OTP 필드를 구현하는 것으로, 사용자가 새 코드를 요청하고 다시 필사를 시도하도록 강요한다. 이는 운동 또는 인지 처리 속도가 느린 사용자에게 인지 부담을 가중시킨다.
비-사물 콘텐츠 인식을 요구하는 이미지 기반 CAPTCHA 과제를 사용하는 것 — 추상 패턴, 색상, 개인적으로 선택한 사진의 순서 등 — 이 3.3.9를 충족한다고 믿는 경우. AAA 기준은 자동차, 자전거, 신호등과 같은 현실 세계 사물 인식만을 허용하며, 비-사물 이미지 인식은 이 수준에서 예외가 아니다.
로그인 필드에 autocomplete='new-password'를 사용해 브라우저 자격 증명 관리자 접근을 차단하는 것(회원가입 필드가 아닌데도). new-password 값은 브라우저에 새 비밀번호 생성용 필드임을 알리며, 로그인 시 저장된 자격 증명 자동완성을 막는다.
실제 보조기술로 인증 흐름을 테스트하지 않고, 자동 스캔 결과에만 의존하는 것. 3.3.9는 수동 테스트만 가능한 기준이기 때문에, 수동 스크린 리더 및 키보드 테스트를 생략하는 팀은 매 릴리스마다 이 기준의 실패를 체계적으로 놓치게 된다.

터키 접근성 규정과의 관계

터키의 2025/10호 대통령령은 2025년 6월 21일 관보 제32933호에 게재되었으며, 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 포괄적인 웹 및 모바일 접근성 의무를 설정한다. 이 대통령령은 WCAG 2.2 준수를 의무화하며, WCAG 2.2 버전을 명시적으로 언급한 터키 최초의 법적 문서이다.

대통령령의 적용 대상에는 모든 수준의 정부 공공 기관 및 단체, 전자상거래 플랫폼과 온라인 마켓플레이스, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 여행사, 민간 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받은 사립 학교가 포함된다. 이들 조직의 디지털 서비스 — 로그인 포털, 환자 포털, 뱅킹 대시보드, 티켓팅 시스템, 학생 정보 시스템 등을 포함 — 는 대통령령이 정의한 접근성 요구 사항을 충족해야 한다.

WCAG 3.3.9는 AAA 수준 기준으로서, 대통령령 하에서 최소 법적 의무는 아니다. 법적으로 요구되는 기준선은 WCAG 2.2 A 및 AA 수준 준수에 해당한다. 그러나 대통령령의 취지와 범위를 고려할 때, 3.3.9는 실제로 여러 측면에서 매우 관련성이 높다.

첫째, WCAG 3.3.8(접근 가능한 인증 — 최소)은 AA 수준 요구 사항이며, 따라서 모든 적용 대상 기관에 법적으로 구속력이 있다. 3.3.8 준수를 위해 노력하는 조직은, 3.3.9 준수로 나아가는 길이 종종 작은 추가 단계에 불과하다는 것을 알게 될 것이다 — 주로 3.3.8이 허용하는 이미지 인식 예외를 제거하고, 모든 인지 테스트에 보조 메커니즘뿐 아니라 비-인지 대체 수단이 있도록 보장하는 것이다.

둘째, 인지 또는 운동 장애 비율이 높은 인구에게 서비스를 제공하는 기관 — 특히 병원, 공공 의료 포털, 정부 서비스 포털 — 에게 인증 기준에서 AAA 수준을 달성하는 것은, 터키의 광범위한 헌법상 평등 원칙과, 터키가 비준한 장애인권리협약(CRPD) 하의 의무에 부합하는 실질적인 평등 접근 보장 의지를 보여준다.

셋째, 터키의 은행과 핀테크 제공자는 인증과 관련해 특히 엄격한 감시를 받는다. 은행규제감독청(BDDK)과 금융범죄조사위원회(MASAK)는 강력한 신원 확인 요구 사항을 부과하며, 조직들은 이를 충족하기 위해 복잡하고 다단계인 인증 흐름을 구현하는 경우가 많다. 패스키, WebAuthn, 매직 링크 흐름을 사용하는 3.3.9 준수 인증을 구현하는 것은 더 접근 가능할 뿐 아니라, 국제 금융 규제 기관이 지지하는 현대적 안전 인증 모범 사례와도 일치하므로, 여러 측면의 규정 준수를 동시에 지원하는 설계 목표가 된다.

자신들의 접근성 수준을 차별화하고, 향후 규제 강화에 대비하며, 사용자를 접근 가능하고 포용적인 방식으로 지원하고자 하는 조직은 WCAG 3.3.9를 단순한 선택적 향상이 아닌 설계 표준으로 취급할 것을 강력히 권장한다. 완전히 비-인지적인 인증 경로를 구현하는 것은 현대 브라우저 API(WebAuthn/패스키)와 인증 SDK 덕분에 점점 더 용이해지고 있으며, 준수 비용은 그 어느 때보다 낮아지는 반면, 어떤 디지털 제품에서든 가장 중대한 접근성 장벽 중 하나를 제거하는 이점은 매우 크다.