WCAG 3.3.4: 오류 방지 (법적, 금융, 데이터)

WCAG 3.3.4는 법적 약속, 금융 거래 또는 민감한 데이터가 포함된 웹 제출이 최종 확정되기 전에 확인, 수정 또는 되돌릴 수 있어야 한다고 요구합니다. 이는 모든 사용자, 특히 인지 및 운동 장애가 있는 사용자를 되돌릴 수 없는 중대한 실수로부터 보호합니다.

이 규칙의 의미

오류 방지(법적, 금융, 데이터)라는 제목의 WCAG 성공 기준 3.3.4는 원칙 3(이해 가능)과 지침 3.3(입력 지원) 아래의 레벨 AA 요구 사항입니다. 이 기준은 사용자가 법적 약속이나 금융 거래를 발생시키거나, 데이터 저장 시스템에서 사용자가 제어할 수 있는 데이터를 수정하거나 삭제할 수 있는 웹 페이지에 구체적으로 적용됩니다.

이 기준은 그러한 모든 제출에 대해 다음 세 가지 안전장치 중 최소 하나를 제공할 것을 요구합니다.

되돌릴 수 있음(Reversible): 제출이 전송된 후에도 취소할 수 있습니다. 예를 들어, 주문을 정해진 시간 내에 취소할 수 있거나, 삭제된 레코드를 복원할 수 있는 경우입니다.
검사됨(Checked): 사용자가 입력한 데이터에 입력 오류가 있는지 검사하고, 제출이 최종 확정되기 전에 사용자가 그 오류를 수정할 수 있는 기회를 제공합니다.
확인됨(Confirmed): 최종 제출 전에 정보를 검토하고, 확인하고, 수정할 수 있는 메커니즘을 제공합니다. 이는 일반적으로 제출 버튼이 거래를 완료하기 전에 요약 또는 검토 단계의 형태를 취합니다.

이 세 가지 조건 중 하나만 충족해도 통과된다는 점이 중요합니다. 검토 및 확인 단계만 제공해도 충분하며, 제출 후 취소 가능 기간만 제공해도, 수정 기회를 포함한 견고한 실시간 검증만 제공해도 기준을 충족합니다. 그러나 모범 사례는 여러 안전장치를 결합하는 것입니다.

기준의 범위: 이 규칙은 세 가지 범주의 거래에 적용됩니다. 첫째, 구독 신청, 계약 동의, 구속력 있는 법적 서류 제출과 같은 법적 약속을 포함합니다. 둘째, 구매, 자금 이체, 대출 신청, 청구서 납부 등 금융 거래를 포함합니다. 셋째, 데이터 저장 시스템에서 사용자가 제어하는 데이터를 수정하거나 삭제하는 모든 행위를 포함합니다. 예를 들어, 프로필 정보 업데이트, 클라우드 서비스에서 파일 삭제, 관리 패널에서 레코드 편집 등이 이에 해당합니다.

통과 사례: 전자상거래 결제 과정의 마지막 단계에서 주문 요약을 보여주고, 그 옆에 "수정" 링크와 "주문하기" 버튼을 제공하는 경우입니다. 실패 사례: 단일 페이지 구매 폼에서 "지금 구매"를 클릭하는 즉시 검토 화면도, 취소 옵션도, 검증 단계도 없이 카드가 바로 결제되는 경우입니다.

이 기준에는 명시적인 예외가 있습니다. 잘못된 정보를 제출해도 결과가 중대하지 않고, 제출을 쉽게 다시 할 수 있는 폼에는 적용되지 않습니다. 단순한 문의 폼이나 뉴스레터 신청 폼은 일반적으로 범위 밖이지만, 이러한 폼에서도 검증을 제공하는 것이 바람직한 관행입니다.

왜 중요한가

고위험 거래 중 발생하는 오류는 심각하고 때로는 되돌릴 수 없는 결과를 초래할 수 있습니다. 예를 들어, 잘못된 계좌로 송금되거나, 허위 전제하에 법적 합의에 서명하거나, 잘못된 정보로 의료 기록이 업데이트되거나, 잘못된 요금제로 구독을 구매하는 경우입니다. 장애가 없는 사용자에게는 이러한 실수를 발견하고 수정하는 일이 대체로 수월합니다. 그러나 많은 장애인 집단에게는 이 기준이 요구하는 안전장치가 없다면 실수를 발견하거나 수정하는 것이 매우 어렵거나 사실상 불가능할 수 있습니다.

인지 장애가 있는 사용자 — 난독증, ADHD, 기억 장애, 지적 장애 등을 포함 — 는 데이터 입력 오류를 더 자주 일으키고, 제출 버튼을 누르기 전에 이를 알아차릴 가능성이 더 낮습니다. 검토 화면은 이들이 실수를 발견하는 데 필요한 시간과 명료성을 제공합니다. 세계보건기구(WHO)에 따르면 전 세계 약 10억 명이 일상 기능에 영향을 미치는 인지, 신경학적 또는 정신 건강 상태를 가지고 있습니다.

운동 장애가 있는 사용자는 스위치 액세스, 시선 추적 장치, 대체 키보드 등에 의존하기 때문에 의도치 않은 활성화나 오타가 발생하기 쉽습니다. 확인 단계는 중요한 완충 장치 역할을 합니다. "제출"이 실수로 활성화되더라도, 거래가 완료되기 전에 사용자가 다시 취소할 수 있는 기회를 제공합니다. 이러한 안전장치가 없다면, 단 한 번의 실수 탭으로 사용자가 되돌릴 수 없는 금융 거래가 발생할 수 있습니다.

스크린 리더 사용자는 긴 폼을 선형으로 탐색하기 때문에 자신이 입력한 내용을 전체적으로 파악하기 어렵습니다. 확인 단계에서 입력값을 다시 읽어주는 음성 요약은 시각적으로 훑어볼 수 없었던 오류를 발견할 수 있게 해줍니다.

불안이나 주의력 문제를 가진 사용자는 안전망이 있다는 사실에서 큰 도움을 받습니다. 연구에 따르면 사용자가 프로세스를 오류 허용적인 것으로 인식할 때 더 자신 있게 참여하고, 거래를 중도 포기하는 비율이 낮아지는 것으로 일관되게 나타납니다. 이는 전환율과 사용자 만족도에 직접적인 이점을 제공하므로, 3.3.4 준수는 윤리적 의무일 뿐 아니라 비즈니스 측면에서도 이점이 됩니다.

실제 시나리오: 이스탄불에 사는 시각장애 여성이 스크린 리더를 사용해 국내선 항공편을 예약하고 있습니다. 그녀는 날짜를 선택하지만, 승객 수 필드를 지나쳐버려 기본값인 2명을 그대로 두고 1명으로 변경하지 못합니다. 예약 사이트가 그녀가 "확인"을 활성화하는 순간 카드를 결제해버리면, 그녀는 2장의 티켓을 구매하게 되고 환불 불가 운임에 따른 불이익을 감수해야 할 수 있습니다. "승객 1명: Ayşe Yılmaz, Ankara에서 Istanbul, 3월 14일, 이코노미 — 총액: ₺850"과 같이 읽어주는 검토 화면이 있었다면, 그녀는 즉시 오류를 발견할 수 있었을 것입니다.

테스트 방법

고위험 폼 목록 작성: 테스트를 시작하기 전에, 금융 거래(결제, 지불, 청구), 법적 약속(계약 서명, 구독 등록, 동의서), 데이터 수정/삭제(프로필 편집, 파일 삭제, 계정 삭제)가 포함된 사이트의 모든 폼 또는 인터랙티브 워크플로를 목록으로 만듭니다. 3.3.4의 범위에 포함되는 것은 이 흐름들뿐입니다.
관련 문제에 대한 자동 스캔 실행: axe DevTools 또는 Lighthouse를 사용해 범위 내 각 페이지에서 폼 수준의 접근성 실패를 식별합니다. 이 도구들은 3.3.4를 직접 표시하지는 않지만, 레이블 누락, autocomplete 속성 누락, 오류 알림 누락과 같은 문제를 해결하면 오류 방지 안전장치를 평가하기 전에 폼 품질의 기준선을 마련할 수 있습니다.
"검사됨(Checked)" 안전장치 테스트: 의도적인 오류를 포함해 범위 내 각 폼을 제출해 봅니다. 예를 들어 카드 번호 자리수 바꾸기, 잘못된 날짜, 이메일 확인 필드 불일치 등을 입력합니다. 시스템이 제출을 중단하는지, 특정 오류를 식별하는지, 이를 어떻게 수정해야 하는지(3.3.3에 따라) 설명하는지, 사용자를 수정할 수 있도록 폼에 그대로 남겨두는지 관찰합니다. 폼이 조용히 제출되거나, 어떤 필드가 실패했는지 밝히지 않은 채 일반적인 오류만 보여준다면 이 안전장치는 충족되지 않습니다.
"확인됨(Confirmed)" 안전장치 테스트: 유효한 데이터를 입력해 범위 내 각 폼을 완료하고 전체 흐름을 진행합니다. 최종 제출 전에 검토 단계가 제공되는지 확인합니다. 검토 단계가 모든 입력 데이터를 읽기 쉬운 형식으로 표시하는지, 뒤로 가서 수정할 수 있는 메커니즘을 포함하는지, 제출을 완료하기 위해 의도적인 최종 동작을 요구하는지 확인합니다. NVDA+Firefox와 JAWS+Chrome을 사용해 스크린 리더로 이 검토 단계를 탐색하면서 모든 값이 읽히는지, 수정 및 확인 컨트롤이 키보드로 접근 가능한지 확인합니다.
"되돌릴 수 있음(Reversible)" 안전장치 테스트: 제출을 완료한 후 이를 되돌리려고 시도합니다. 전자상거래의 경우 확인 이메일이나 주문 내역 페이지에서 취소 링크를 찾습니다. 데이터 삭제의 경우 복원 또는 휴지통 메커니즘을 찾습니다. 되돌릴 수 있는 기간이 제출 후가 아니라 제출 전에 사용자에게 명확히 전달되는지 평가합니다.
스크린 리더 워크스루(VoiceOver + macOS/iOS의 Safari): 키보드와 VoiceOver만 사용해 전체 결제 또는 제출 흐름을 탐색합니다. 검토 화면이 입력값을 논리적인 순서로 모두 읽어주는지, 수정 링크가 충분한 맥락과 함께 안내되는지(예: 단순히 "수정"이 아니라 "배송지 주소 수정"), 최종 확인 버튼의 목적이 모호하지 않은지 확인합니다.
인지 부하 점검: 검토 단계가 쉬운 언어로 제시되는지 평가합니다. 데이터베이스 필드 이름을 그대로 나열하거나 설명 없이 법률 용어를 사용하는 요약은 형식상 검토 화면일 수는 있지만, 실제로는 인지 장애가 있는 사용자에게 도움이 되지 않을 수 있습니다.

해결 방법

검토 단계가 없는 단일 단계 결제 — 잘못된 예

<!-- 문제: "Complete Purchase"를 클릭하면 즉시 카드가 결제됨 -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

검토 단계가 추가된 단일 단계 결제 — 올바른 예

<!-- 1단계: 폼이 데이터를 수집하고 검토 페이지로 제출(최종 아님) -->
<form action='/checkout/review' method='post'>
  <!-- 결제 및 배송 필드 -->
  <button type='submit'>Review Order</button>
</form>

<!-- 2단계: 검토 페이지가 모든 입력 데이터를 요약하고 수정 링크 제공 -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- 최종 버튼은 구속력 있는 동작임을 명확히 표시 -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

확인 없이 되돌릴 수 없는 데이터 삭제 — 잘못된 예

<!-- 문제: 삭제 버튼이 확인 대화 상자 없이 바로 전송됨 -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

확인 대화 상자가 있는 되돌릴 수 없는 데이터 삭제 — 올바른 예

<!-- 트리거 버튼은 파괴적 동작이 아니라 확인 대화 상자를 엶 -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

인라인 검증이 없는 금융 폼 — 잘못된 예

<!-- 문제: 검증 없음, 잘못된 IBAN도 조용히 허용됨 -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

검증 및 검토가 있는 금융 폼 — 올바른 예

<!-- 오류 연결을 위한 aria-describedby를 사용하는 인라인 검증 -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- 검토 페이지로 제출되며, 직접 실행되지 않음 -->
  <button type='submit'>Review Transfer</button>
</form>

자주 발생하는 실수

툴팁을 "검토" 메커니즘으로 사용하는 경우: 제출 버튼 전에 입력값을 호버 툴팁으로 표시하는 것은 검토 단계로 인정되지 않습니다. 툴팁은 키보드 전용 사용자나 스크린 리더 사용자가 접근할 수 없고, 사용자가 조치하기 전에 사라지기 때문입니다.
최종 버튼에 동작을 설명하지 않고 "계속"이라고만 라벨링하는 경우: 검토 페이지에서 "Continue"라고만 적힌 버튼은 클릭 시 금융 거래가 완료된다는 사실을 명확히 전달하지 못합니다. 버튼은 "Place Order and Pay ₺850" 또는 "Sign Contract"처럼 구속력 있는 동작을 명확하게 설명해야 합니다.
취소 정책을 이용 약관에만 제공하는 경우: 대부분의 사용자가 읽지 않을 링크된 법률 문서에 되돌리기 메커니즘을 숨겨두는 것은 되돌릴 수 있음 요구 사항을 충족하지 못합니다. 취소 가능 여부와 그 기간은 거래 흐름 자체에서 전달되어야 합니다.
window.confirm()을 유일한 확인 메커니즘으로 사용하는 경우: 브라우저 기본 confirm 대화 상자는 일부 보조 기술에서 지원이 미흡하고, 가독성을 위해 스타일을 변경할 수 없으며, 특정 브라우저 설정에서는 차단되기도 합니다. 고위험 제출에 대한 유일한 안전장치로 사용해서는 안 됩니다.
검증 실패 시 유효한 필드 값까지 보존하지 않고 폼을 초기화하는 경우: 폼이 검증에 실패했을 때 모든 필드를 비우면, 특히 운동 장애가 있는 사용자에게 모든 데이터를 다시 입력하도록 강요하게 됩니다. 유효하지 않은 필드만 비우거나 강조해야 하며, 유효한 입력값은 모두 보존해야 합니다.
검토 페이지의 "Edit" 링크에 프로그래밍적 연관을 제공하지 않는 경우: 각 데이터 그룹 옆의 "Edit" 링크는 aria-label='Edit billing address'처럼 설명적인 접근 가능한 이름을 가져야 합니다. 동일한 "Edit" 링크가 여러 번 반복되면, 링크 단위로 탐색하는 스크린 리더 사용자에게는 모호합니다.
검토 단계를 스크린 리더에 알리지 않는 경우: 검토 페이지가 로드될 때 포커스를 제목이나 요약 영역으로 이동시키지 않으면, 스크린 리더 사용자는 자신이 검토 페이지에 있다는 사실을 인식하지 못한 채 요약을 읽지 않고 제출 버튼을 활성화할 수 있습니다.
이 기준이 결제 페이지에만 적용된다고 생각하는 경우: 이 기준의 범위에는 모든 법적 약속(구독 신청, 동의서, 계약 수락)과 모든 사용자 데이터 수정(파일 삭제, 의료 기록 업데이트, 계정 설정 변경)이 포함됩니다. 개발자는 종종 관리 패널과 설정 페이지를 간과합니다.
전화나 이메일로만 되돌리기를 제공하는 경우: 취소를 위해 고객센터에 전화해야 한다면, 말하기 또는 듣기 장애가 있는 사용자는 되돌리기 메커니즘을 이용하지 못할 수 있습니다. 되돌리기 경로 자체도 접근 가능해야 하며, 가능하면 앱 내 취소 흐름을 제공해야 합니다.
모바일 웹뷰에서 이 기준을 생략하는 경우: 일부 팀은 데스크톱에서는 검토 단계를 구현하지만, 화면 공간을 줄이기 위해 모바일에서는 축약된 단일 단계 흐름을 사용합니다. 이 기준은 모든 뷰포트 크기에 동일하게 적용되며, 반응형 또는 모바일 웹 구현에서 생략되어서는 안 됩니다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.2를 기술 표준으로 참조하는 포괄적인 국가 접근성 프레임워크를 수립합니다. 이 대통령령은 디지털 서비스가 최소한 WCAG 2.2 레벨 AA에 부합할 것을 요구하며, 여기에는 WCAG 3.3.4 오류 방지(법적, 금융, 데이터)가 포함됩니다.

대통령령이 명시적으로 적용되는 주체는 광범위한 부문에 걸쳐 있습니다. 공공 기관 및 공공 단체는 온라인 신청, 전자정부 포털, 디지털 신원 서비스 등 시민 대상 모든 디지털 서비스를 접근 가능하게 해야 하며, 이들 서비스는 법적 약속과 데이터 수정이 자주 수반됩니다. BDDK(은행 규제 및 감독 기관)의 규제를 받는 은행 및 금융 기관은 이를 준수해야 하며, 이로 인해 3.3.4는 이들이 제공하는 모든 온라인 뱅킹 거래, 자금 이체, 대출 신청과 직접적으로 관련됩니다. 디지털 환자 포털, 예약 시스템, 전자 건강 기록을 운영하는 병원 및 의료 기관은 해당 시스템에서 이루어지는 모든 데이터 입력 및 수정이 오류 방지 기준을 충족하도록 해야 합니다. 20만 명 이상의 가입자를 보유한 통신 사업자 — Turkcell, Vodafone TR, Türk Telekom 등을 포함 — 는 구독 관리, 요금제 변경, 결제 흐름이 모두 기준을 충족하도록 해야 합니다. 전자상거래 플랫폼, 여행사, 민간 운송 회사, 국가교육부(MoNE)의 인가를 받은 사립학교도 범위에 포함되어, 터키 시장에서 거래량이 많은 웹 서비스의 상당 부분을 포괄합니다.

이 프레임워크에서 3.3.4 준수는 단순한 기술적 체크리스트 항목이 아닙니다. 가족사회서비스부가 발급하는 Erişilebilirlik Logosu(접근성 로고)를 취득하려는 기관은 WCAG 2.2 AA를 완전히 준수해야 합니다. 이 로고는 공적 신뢰의 신호로 작용하며, 소비자와 조달 기관이 점점 더 기대하는 요소가 되고 있습니다. 금융 또는 법적 워크플로에서 오류 방지 안전장치를 구현하지 않으면 로고 발급이 거부될 수 있을 뿐 아니라, 대통령령의 집행 규정에 따른 행정 조치 대상이 될 수 있습니다.

특히 전자상거래 및 핀테크 부문의 터키 조직에게 3.3.4는 터키 법 아래 기존 소비자 보호 요구 사항과 밀접하게 일치합니다. 소비자 보호법(제6502호) 및 관련 전자상거래 규정은 이미 거리 계약에 대해 명확한 계약 전 정보 제공과 취소 권리를 요구하고 있습니다. WCAG 3.3.4를 준수하는 검토 및 확인 단계를 구현하면, 접근성 요구 사항과 구매자에게 주문 요약을 제시해야 한다는 소비자법 의무를 동시에 충족할 수 있습니다. 이러한 이중 준수는 터키 디지털 서비스 제공자에게 오류 방지 UX에 투자하는 것이 높은 가치와 낮은 중복 비용을 가진 노력임을 의미합니다.