WCAG 3.3.6: 오류 방지 (전체)

WCAG 3.3.6은 사용자 입력이 필요한 모든 웹 페이지에서 제출이 되돌릴 수 있거나, 오류가 교정 안내와 함께 점검되거나, 최종 제출 전에 확인 가능해야 한다고 요구합니다. 이 AAA 기준은 3.3.4를 법적 또는 금융 양식에만 국한하지 않고 모든 양식으로 확장하여, 모든 상호작용 전반에서 사용자가 되돌릴 수 없는 실수로부터 보호되도록 합니다.

이 규칙의 의미

WCAG 3.3.6 — 오류 방지(전체)는 이해 가능(Understandable) 원칙 아래의 AAA 수준 성공 기준입니다. 이 기준은 3.3.4(오류 방지: 법적, 금융, 데이터)의 요구 사항을 확장하여, 제출이 법적 약속, 금융 거래, 또는 개인 식별 가능 데이터와 관련이 있는지 여부와 상관없이 사용자가 정보를 제출해야 하는 모든 페이지를 포괄합니다.

핵심적으로, 이 기준은 사용자가 정보를 제출하는 모든 웹 페이지에 대해 다음 세 가지 조건 중 최소 하나가 충족되어야 함을 요구합니다.

되돌릴 수 있음(Reversible): 제출 후에도 되돌릴 수 있어야 합니다. 사용자는 합리적인 시간 안에 작업을 실행 취소, 취소, 또는 철회할 수 있어야 합니다. 예를 들어, 보낸 메시지를 회수할 수 있거나, 제출된 양식을 확인 대기열에서 취소할 수 있어야 합니다.
검사됨(Checked): 최종 제출 전에 사용자가 입력한 데이터에 입력 오류가 있는지 검사하고, 사용자가 그 오류를 수정할 수 있는 기회를 제공해야 합니다. 여기에는 인라인 검증, 제출 전 요약, 단계별 검토 흐름 등이 포함됩니다.
확인됨(Confirmed): 제출이 최종 확정되기 전에 정보를 검토, 확인, 수정할 수 있는 메커니즘을 제공해야 합니다. 이는 검토 화면, 확인 대화 상자, 또는 마지막에 검토 단계가 있는 다단계 마법사일 수 있습니다.

3.3.4와 3.3.6의 핵심 차이는 범위입니다. 기준 3.3.4는 법적 합의, 금융 거래, 시험 답안, 그리고 사용자가 제어하는 데이터의 삭제에만 적용됩니다. 기준 3.3.6은 이를 확장하여, 연락처 양식, 뉴스레터 가입, 댓글 섹션, 설문 응답, 프로필 업데이트, 검색 설정, 그리고 그 밖의 모든 사용자 제어 데이터 입력을 포함한, 어떤 형태로든 사용자 입력 제출이 필요한 모든 페이지에 적용합니다.

통과로 인정되는 경우: 양식이 위의 세 가지 메커니즘 중 최소 하나를 일관되게 구현하고 있으면 통과합니다. 최종 제출 전에 나오는 확인 페이지, "편집" 옵션이 있는 요약 화면, 오류 수정 기회를 제공하는 클라이언트/서버 측 검증, 또는 명확하게 안내된 실행 취소 가능 시간 창 등은 모두 이 기준을 충족합니다.

실패로 인정되는 경우: 버튼 클릭과 동시에 즉시 데이터를 제출하고, 검증도, 검토 화면도, 실행 취소 메커니즘도 없는 단일 단계 양식은 이 기준에 실패합니다. 마찬가지로, 검증은 하지만 재제출 전에 오류를 수정할 기회를 제공하지 않는 양식도 실패합니다.

WCAG 명세는 세 가지 메커니즘을 모두 동시에 요구하지 않습니다. 그 중 하나만 충족해도 충분합니다. 그러나 두 가지 또는 세 가지 메커니즘을 결합하면 방어 심층화(defense-in-depth)를 제공하고 더 넓은 범위의 사용자와 상황을 지원할 수 있습니다.

왜 중요한가

오류 방지는 단순한 사용성 향상이 아니라, 장애나 상황적 손상으로 인해 입력 오류 위험이 높은 사용자에게 근본적인 접근성 요구 사항입니다.

인지 및 학습 장애: 난독증, ADHD, 기억 장애가 있는 사용자는 자주 오타를 내거나 숫자를 바꿔 입력하거나, 복잡한 다중 필드 양식에서 흐름을 놓치곤 합니다. 검토 메커니즘이 없다면, 연락처 양식에서 이메일 주소를 잘못 입력하는 것은 답변을 받지 못하는 결과를 낳을 수 있고, 배송 양식에서 주소를 잘못 입력하면 소포 분실로 이어질 수 있습니다. 이는 예외적인 사례가 아닙니다. 세계보건기구(WHO)에 따르면, 전 세계 약 10억 명이 일상 기능에 영향을 미치는 어떤 형태의 인지 또는 신경학적 상태를 가지고 있습니다.

운동 장애: 손 떨림, 미세 운동 능력 제한이 있거나 스위치 접근 장치나 음성 입력 소프트웨어에 의존하는 사용자는 양식을 실수로 제출하거나 의도하지 않은 문자를 입력하는 일이 자주 발생합니다. 파킨슨병이 있는 사용자가 스위치 인터페이스로 복잡한 양식을 탐색하는 동안, 의도치 않게 불완전하거나 잘못된 양식을 제출할 수 있습니다. 되돌리기나 확인 단계가 없다면 이러한 오류는 영구적인 것이 됩니다.

스크린 리더 사용자: JAWS, NVDA, VoiceOver로 탐색하는 시각장애 사용자는 제출 전에 완성된 양식을 시각적으로 한눈에 볼 수 있는 비장애 사용자와 같은 개요를 가지지 못할 수 있습니다. 스크린 리더가 읽어 주는 확인 화면이나 요약은, 데이터가 되돌릴 수 없이 제출되기 전에 이를 검증할 마지막 기회를 제공합니다.

디지털 문해력이 낮은 사용자와 고령층: 고령자와 디지털 인터페이스에 익숙하지 않은 사용자는 특히 실수로 제출하는 상황에 취약합니다. 쉬운 언어로 된 요약을 제공하는 확인 단계는 안전망 역할을 하여 지원 비용과 사용자 좌절을 크게 줄여 줍니다.

실제 시나리오: 한 시민이 사업자 등록을 위해 긴 관료적 양식을 작성하는 터키의 전자정부 포털을 생각해 보십시오. 시민이 필수 필드를 실수로 누락하거나 세금 식별 번호를 잘못 입력했는데, 검토 단계 없이 양식이 즉시 제출된다면, 며칠 뒤 공식적인 반려 통지를 받기 전까지 오류를 인지하지 못할 수 있습니다. 최종 제출 전에 입력된 모든 데이터를 보여 주는 간단한 확인 화면만 있었어도 이런 문제는 완전히 예방될 수 있었습니다.

SEO 및 사용성 이점: 견고한 오류 방지를 구현한 페이지는 일반적으로 양식 이탈률이 낮고, 전환율이 높으며, 사용자 만족도 점수가 더 좋습니다. 검색 엔진은 점점 더 사용자 경험 신호를 순위에 반영하고 있으며, 양식 오류로 인한 높은 이탈률을 가진 페이지는 유기적 가시성에서 간접적으로 손해를 보게 됩니다.

테스트 방법

기본선으로 자동 스캔 실행: axe DevTools, Lighthouse, 또는 Accsible 위젯의 내장 감사 모드를 사용하여 양식을 포함한 모든 페이지를 스캔합니다. 이 도구들은 3.3.6 위반을 직접 표시하지는 않지만, 누락된 레이블, 없는 오류 메시지, 잘못 연결된 검증 피드백 등을 식별하여 기반을 마련합니다. 수동 테스트로 넘어가기 전에 자동화 결과를 모두 해결하십시오.
사이트의 모든 제출 양식 식별: 사용자 입력을 받아 제출하는 모든 페이지—연락처 양식, 회원가입 양식, 로그인 양식, 검색 환경설정 양식, 프로필 업데이트 페이지, 댓글 섹션, 뉴스레터 가입, 다단계 마법사 등—의 전체 목록을 작성합니다. 각각을 독립적으로 테스트해야 합니다.
의도적인 오류를 포함한 정상 경로 테스트: 각 양식에서 의도적으로 잘못되거나 불완전하거나 형식이 잘못된 데이터(예: 잘못된 이메일 주소, 문자 포함 전화번호, 필수 필드 비우기)를 입력합니다. 양식을 제출하고 다음을 관찰합니다. 페이지가 제출을 막고 오류 메시지를 제공하는가? 오류 메시지가 올바른 필드와 연결되어 있는가? 사용자가 명확하게 오류를 수정하고 재제출할 수 있는 기회를 제공하는가?
확인 또는 검토 메커니즘 테스트: 검증을 통과하는 양식에 대해서는 유효한 데이터로 양식을 완성하고 제출합니다. 데이터가 되돌릴 수 없이 제출되기 전에 확인 화면, 요약 대화 상자, 검토 단계가 나타나는지 관찰합니다. 검토 단계에서 사용자가 뒤로 돌아가 입력값을 수정할 수 있는지 확인합니다.
제출 후 되돌리기 가능성 테스트: 성공적으로 제출한 후, 취소, 실행 취소, 또는 철회 메커니즘이 존재하는지 확인합니다. 이는 확인 이메일의 "제출 취소" 링크, 관리자 영역의 대기열 관리 화면, 실행 취소 동작이 있는 인앱 알림일 수 있습니다. 이 메커니즘이 실제로 작동하는지, 사용자에게 명확하게 전달되는지 검증합니다.
NVDA + Firefox로 스크린 리더 테스트: NVDA와 Firefox를 사용해 각 양식으로 이동합니다. 모든 필드를 Tab 키로 탐색하고 데이터를 입력한 뒤 양식을 제출합니다. 오류 메시지가 나타날 때 이를 읽어 주는지, 검토 화면(있는 경우)이 문서 순서대로 완전히 읽히는지, 확인 화면의 모든 인터랙티브 컨트롤(편집 버튼, 확인 버튼, 취소 버튼)이 키보드로 접근 가능하고 적절히 레이블링되어 있는지 확인합니다.
VoiceOver + Safari(macOS/iOS)로 스크린 리더 테스트: 위 과정을 Safari의 VoiceOver로 반복합니다. 특히 동적 콘텐츠 업데이트에 주의를 기울입니다. 검증 오류가 JavaScript를 통해 페이지 새로고침 없이 동적으로 나타나는 경우, aria-live 라이브 영역을 통해 VoiceOver가 페이지를 다시 탐색하지 않고도 이를 읽어 주는지 확인합니다.
키보드만으로 테스트: 마우스 없이 Tab, Shift+Tab, Enter, Space 키만 사용하여 전체 양식 제출 흐름을 탐색합니다. 검토 화면의 편집, 뒤로, 확인, 취소 버튼을 포함한 모든 인터랙티브 요소가 포인팅 장치 없이도 도달 가능하고 조작 가능한지 확인합니다.

수정 방법

검증 및 검토가 없는 연락처 양식 — 잘못된 예

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

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

검증 및 확인 단계가 있는 연락처 양식 — 올바른 예

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

요약 단계가 없는 다단계 마법사 — 잘못된 예

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

최종 검토 단계가 있는 다단계 마법사 — 올바른 예

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

즉시 제출되고 실행 취소가 없는 양식 — 잘못된 예

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

확인 대화 상자가 있는 파괴적 작업 — 올바른 예

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

일반적인 실수

검증을 구현했지만 스크린 리더에 노출하지 않는 경우: aria-describedby를 사용해 입력과 연결하거나 aria-live 영역에 오류 메시지를 삽입하지 않고, CSS 색상 변경이나 아이콘으로만 시각적으로 오류 메시지를 표시하면, 시각장애 사용자는 오류를 들을 수 없습니다. 양식은 실제로는 미완성 상태임에도, 성공적으로 제출된 것처럼 보이게 됩니다.
3.3.4 준수를 AAA 수준에 충분한 것으로 간주하는 경우: 팀이 금융 또는 법적 양식에 대해서만 오류 방지를 구현(3.3.4 충족)하고, 모든 양식이 커버되었다고 가정하는 경우가 많습니다. 기준 3.3.6은 사이트의 모든 양식—뉴스레터 가입, 댓글, 프로필 업데이트를 포함—에 대해 동일한 보호를 요구합니다.
편집 경로가 없는 읽기 전용 확인 화면 제공: 제출된 데이터를 표시하지만 "확인" 버튼만 있고, 뒤로 돌아가 오류를 수정할 방법이 없는 검토 페이지는 이 기준의 취지를 완전히 충족하지 못하며, 사용자가 검토 중에 실수를 발견해도 대처할 수 없게 만듭니다.
window.confirm()을 유일한 확인 메커니즘으로 사용하는 경우: 브라우저 기본 confirm 대화 상자는 모든 사용자에게 접근 가능하지 않으며, 명확성을 위해 스타일링하거나 구조화할 수 없습니다. 또한 보조 기술 간에 동작이 일관되지 않습니다. 대신 적절한 ARIA 속성이 있는 <dialog> 요소를 사용하십시오.
검증 실패 시 전체 양식을 초기화하고 유효한 입력을 보존하지 않는 경우: 사용자가 10개 필드 중 하나만 오류가 있는 양식을 제출했는데, 양식이 모든 필드를 지워 버리면 사용자는 모든 데이터를 다시 입력해야 합니다. 이는 운동 장애가 있거나 인지 피로가 있는 사용자에게 특히 부담이 됩니다. 항상 유효한 데이터는 보존하고, 주의를 오류가 있는 필드에만 집중시키십시오.
오류 요약 메시지를 뷰포트 밖이나 키보드 포커스 순서 밖에 배치하는 경우: 제출 실패 후 페이지 상단에 삽입된 오류 요약 배너는, 포커스가 양식 중간에 있는 사용자에게 아무런 도움이 되지 않습니다. 요약 컨테이너에 aria-live='assertive'를 사용하고, 제출 실패 시 포커스를 프로그램적으로 그곳으로 이동시키십시오.
"OK"나 "Yes" 같은 모호한 레이블의 확인 버튼 사용: 검토 화면에서 버튼은 어떤 일이 일어날지 명확하게 전달해야 합니다. "Confirm and Send Message"는 명확하지만, "OK"는 그렇지 않습니다. 특히 주변 시각적 문맥을 볼 수 없는 스크린 리더 사용자에게는 더욱 그렇습니다.
서버 측 검증만으로 기준을 충족한다고 가정하는 경우: 클라이언트 측 검증이 없으면, 사용자는 오류를 알기 위해 매번 서버로의 전체 왕복을 거쳐야 합니다. 느린 연결을 사용하거나 제출 중 네트워크가 끊긴 사용자는 명확한 오류 피드백 없이 불확실한 상태에 놓일 수 있습니다.
현실적인 조건에서 되돌리기 메커니즘을 테스트하지 않는 경우: 팀이 확인 이메일에 "취소" 옵션을 구현했지만, 취소 링크가 접근 가능한지, 유효 기간이 지난 후에도 어떻게 동작하는지, 스크린 리더로 사용 가능한지 등을 테스트하지 않는 경우가 있습니다. 접근할 수 없는 실행 취소 메커니즘은 이 기준을 충족하지 못합니다.
검토 화면에서 자동 완성(edge case)을 처리하지 않는 경우: 브라우저나 비밀번호 관리자의 자동 완성이 양식 필드를 채우는 경우, 자동 완성이 완료되기 전에 JavaScript가 DOM에서 값을 가져와 검토 화면을 구성하면, 검토 화면에 표시되는 값이 실제 제출된 값과 일치하지 않을 수 있습니다. 검토 화면을 렌더링하기 직전에 값을 가져오고, 초기 페이지 로드 시점에 가져오지 마십시오.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영하는 광범위한 주체에 대해 의무적인 디지털 접근성 의무를 설정합니다. 이 대통령령은 해당 조직이 최소 기준으로 WCAG 2.2 AA 수준에 부합할 것을 요구합니다. 명시적으로 포함된 주체에는 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 가입자 200,000명 이상 통신 회사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교가 포함됩니다.

WCAG 3.3.6은 AAA 수준 기준이므로, 2025/10 대통령령 하에서 직접적인 법적 요구 사항은 아닙니다. 그러나 터키 규제 맥락에서 그 중요성을 간과해서는 안 됩니다. 특히 은행, 전자상거래 플랫폼, 의료 서비스 제공자와 같은 여러 유형의 대상 기관은 오류 방지가 단순한 모범 사례를 넘어 법적·윤리적 필수 사항인 고위험 거래 양식을 운영합니다. 확인 단계나 오류 수정 메커니즘이 없는 터키 은행의 온라인 송금 양식, 의료 포털의 진료 예약 시스템, 전자상거래 체크아웃 흐름은 법적으로 집행 가능한 의미에서 3.3.6을 위반하지 않을 수 있지만, 장애가 있는 사용자에게 상당한 피해 위험을 초래하고 조직을 평판 및 운영 리스크에 노출시킵니다.

더 나아가, 이 대통령령은 터키가 정렬해 온 유럽 접근성법(EAA) 프레임워크와 일치하게, 시간이 지남에 따라 접근성 요구 사항을 강화하려는 명확한 방향성을 보여 줍니다. 오늘 3.3.6과 같은 AAA 기준을 구현하는 조직은 향후 규제 강화에 선제적으로 대비할 수 있으며, 최소 준수를 넘어서는 포용적 설계에 대한 의지를 보여 줍니다. 고령 인구나 인지·운동 장애 사용자를 비율적으로 더 많이 상대하는 민간 병원과 금융 기관과 같은 주체에게는, 모든 양식에 3.3.6을 구현하는 것이 법적 지위와 무관하게 건전한 리스크 관리 결정입니다. Accsible의 오버레이 SDK는 오류 메시지를 노출하고, 검증 상태를 강화하며, 추가적인 확인 프롬프트를 제공함으로써, 접근성 선도에 힘쓰는 터키 조직에 강화된 보호 계층을 제공하는 데 도움을 줄 수 있습니다.