WCAG 3.3.3: 오류 제안

WCAG 3.3.3은 입력 오류가 자동으로 감지될 때, 그렇게 하는 것이 보안이나 목적을 위협하지 않는 한, 시스템이 사용자가 실수를 어떻게 수정할 수 있는지 제안하는 텍스트 설명을 제공해야 한다고 요구합니다. 이 기준은 인지 장애가 있는 사용자, 스크린 리더 사용자, 그리고 모호하거나 누락된 오류 안내를 이해하는 데 어려움을 겪는 모든 사람에게 필수적입니다.

이 규칙의 의미

WCAG 3.3.3 Error Suggestion(오류 제안)은 이해 가능(Understandable) 원칙 아래의 레벨 AA 기준이다. 이 기준은 오류를 텍스트로 식별해야 한다고 요구하는 3.3.1(오류 식별)을 직접적으로 확장한 것이다. Error Suggestion은 한 단계 더 나아가, 입력 오류가 자동으로 감지되었을 때, 그 제안이 콘텐츠의 보안이나 목적을 훼손하지 않는 한, 인터페이스가 사용자가 이를 어떻게 수정할 수 있는지 제안해야 한다고 요구한다.

여기서 핵심적인 구분은 오류 식별과 오류 제안의 차이다. 사용자에게 "Your date of birth is invalid"(생년월일이 유효하지 않습니다)라고 말하는 것은 식별이다. 사용자에게 "Your date of birth is invalid — please enter a date in DD/MM/YYYY format"(생년월일이 유효하지 않습니다 — DD/MM/YYYY 형식으로 입력해 주세요)라고 말하는 것은 제안이다. 둘 다 각자의 기준에서 요구되지만, Error Suggestion은 가능한 곳에서는 오류 메시지에 실행 가능한 수정 안내가 동반되도록 요구한다.

이 기준은 입력 오류가 자동으로 감지되는 모든 경우에 적용된다. 즉, 클라이언트 측 또는 서버 측 검증 로직이 제출되거나 입력된 값이 기대되는 기준을 충족하지 못한다고 판단하는 경우이다. 이는 텍스트 입력, 셀렉트, 체크박스, 라디오 버튼, 날짜 선택기, 파일 업로드 필드, 그리고 사용자 데이터를 수집하는 모든 인터랙티브 컴포넌트 등 모든 폼 컨트롤에 적용된다.

충족으로 인정되는 경우: 오류 메시지가 텍스트(색상이나 아이콘만이 아니라)로 제시되고, 오류가 있는 필드를 명확히 식별하며, 이를 어떻게 수정해야 하는지에 대한 구체적인 안내를 제공하는 경우이다. 예를 들어, 단순히 "Invalid password"(잘못된 비밀번호)라고 하는 대신 "Password must be at least 8 characters and include one uppercase letter"(비밀번호는 최소 8자이며 하나 이상의 대문자를 포함해야 합니다)라고 하는 것이다. 제안은 해당 필드와 가까운 위치에 나타나야 하고, aria-describedby 또는 유사한 방법을 통해 프로그래밍적으로 필드와 연결되어야 하며, 보조 기술로 인지 가능해야 한다.

실패로 인정되는 경우: 무엇이 잘못되었는지 또는 어떻게 수정해야 하는지 설명하지 않고 단지 오류가 발생했다고만 말하는 모든 오류 메시지이다. "Error"(오류), "Invalid input"(잘못된 입력), "Required field"(필수 입력값)과 같은 일반적인 메시지가 추가적인 맥락 없이 사용되는 경우 모두 이 기준을 충족하지 못한다. 빨간 테두리나 경고 아이콘만으로 오류를 전달하고 설명 텍스트가 없는 경우도 실패에 해당한다.

정의된 예외: 이 기준에는 제안이 요구되지 않는 두 가지 명시적 예외가 포함된다. 첫째, 제안을 제공하는 것이 보안을 위태롭게 하는 경우이다. 예를 들어, 로그인 폼에서 비밀번호가 실패한 이유(잘못된 비밀번호인지, 잘못된 사용자 이름인지)를 자세히 설명하면 무차별 대입 공격에 도움이 될 수 있다. 둘째, 제안을 제공하는 것이 콘텐츠의 목적을 위태롭게 하는 경우이다. 예를 들어, 정답을 알려주면 평가 목적이 무의미해지는 교육용 퀴즈가 이에 해당한다. 이러한 예외는 범위가 매우 좁으며, 일반적인 폼 환경에서 요구 사항을 회피하기 위해 사용되어서는 안 된다.

왜 중요한가

Error Suggestion이 존재하는 이유는, 폼 작성이 사용자가 웹에서 수행하는 활동 중 인지적으로 가장 부담이 크고, 동시에 가장 결과가 중대한 활동 중 하나이기 때문이다. 결제 폼, 정부 복지 신청서, 의료 문진 폼, 은행 포털 등에서 발생하는 오류는, 무엇이 잘못되었는지 또는 어떻게 복구해야 하는지 이해할 수 없는 사용자에게 현실 세계에서 심각한 결과를 초래할 수 있다.

인지 장애: 난독증, ADHD, 학습 장애, 제한된 문해력을 가진 사용자는 모호한 오류 메시지를 해독하고 이를 특정 필드나 요구 형식과 연결하는 데 어려움을 겪을 수 있다. 명확한 수정 제안이 없으면, 이들은 폼을 아예 포기하거나 잘못된 정보를 제출할 수 있다. 세계보건기구(WHO)에 따르면 전 세계 인구 6명 중 약 1명, 즉 13억 명 이상이 어떤 형태로든 장애를 가지고 있으며, 인지 장애는 가장 흔하면서도 가장 적게 배려되는 범주 중 하나이다.

시각장애 및 저시력 사용자: 스크린 리더 사용자는 검증 오류를 이해하기 위해 전적으로 텍스트 설명에 의존한다. 오류 메시지가 "Invalid"(유효하지 않음)라고만 하고 제안을 제공하지 않으면, 사용자는 해당 필드에서 "유효하지 않다"는 것이 무엇을 의미하는지 알 수 있는 수단이 없다. 이들은 기대되는 형식을 추론하기 위해 인접한 레이블, 플레이스홀더 텍스트, 시각적 서식 단서를 훑어볼 수 없다. aria-describedby를 통해 입력과 프로그래밍적으로 연결된 명확한 제안이 유일하게 신뢰할 수 있는 정보 채널이다.

운동 장애 사용자: 스위치 액세스, 음성 제어, 대체 입력 장치에 의존하는 사용자는 폼을 작성할 때 상당한 신체적 노력을 들여야 한다. 무엇을 변경해야 하는지 이해하지 못한 채 실패한 제출 후 다시 폼으로 돌아가야 하는 것은 과도한 부담을 준다. 명확한 제안은 재입력 부담과 실패한 제출 사이클의 횟수를 줄여준다.

비원어민 사용자와 고령 사용자: 폼의 언어에 능숙하지 않거나, 웹 관행에 익숙하지 않은 사용자도 명시적인 수정 제안으로부터 큰 도움을 받는다. "Enter your phone number without spaces or dashes, e.g. 05321234567"(공백이나 대시 없이 전화번호를 입력하세요. 예: 05321234567)와 같은 메시지는, 그렇지 않으면 폼을 끝까지 성공적으로 완료하지 못할 수도 있는 사용자에게서 모호성을 제거해 준다.

실제 시나리오: 한 터키 시민이 전자정부(e-government) 포털을 통해 사회 복지 혜택을 신청한다고 가정해 보자. 신청서에는 특정한 11자리 형식의 TR Identity Number(TC Kimlik Numarası)가 필요하다. 사용자가 10자리만 입력하고 "TC Kimlik Numarası hatalı"(TC Identity Number is incorrect)라는 메시지만 받는다면, 인지 장애가 있는 사용자, 고령 사용자, 스크린 리더 사용자는 숫자가 너무 짧은 것인지, 잘못된 문자가 포함된 것인지, 형식에 문제가 있는 것인지 알지 못할 수 있다. "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901"(TC Identity Number must be 11 digits, e.g., 12345678901)라는 메시지를 추가하면 즉시 모호성이 해소되고 사용자가 스스로 수정할 수 있게 된다.

사용성 및 전환율 이점: 접근성을 넘어, 폼 이탈은 중요한 비즈니스 지표이다. 연구에 따르면 불명확한 오류 메시지는 사용자가 전자상거래 결제나 가입 흐름을 이탈하는 주요 원인 중 하나이다. 구체적이고 실행 가능한 오류 제안은 폼 이탈률을 낮추고 모든 사용자의 완료율을 높여 준다. 따라서 이 기준은 접근성 요구사항일 뿐 아니라 강력한 비즈니스 근거이기도 하다.

테스트 방법

자동 스캔 기준선: 폼이 포함된 페이지에 대해 axe DevTools 또는 Lighthouse를 실행한다. 폼 레이블, ARIA 역할, 오류 식별(3.3.1)과 관련된 기존 위반 사항을 기록한다. 이는 효과적인 오류 제안을 위한 전제 조건이므로 먼저 해결해야 한다. 자동 스캔은 누락된 제안을 표시하지 않고, 구조적 기준선만 설정한다.
모든 검증 조건 트리거: 각 폼 필드에 대해 가능한 모든 오류 상태를 의도적으로 트리거한다. 필수 필드를 비운 채 제출하고, 잘못된 형식의 데이터를 입력한다(잘못된 날짜 형식, 유효하지 않은 이메일, 너무 짧은 비밀번호, 숫자 필드에 비숫자 값 입력 등). 그리고 나타나는 각 오류 메시지를 문서화한다.
제안 품질 평가: 각 오류 메시지에 대해 다음을 자문한다. (a) 특정 필드를 식별하는가? (b) 무엇이 잘못되었는지 설명하는가? (c) 입력을 어떻게 수정해야 하는지에 대한 실행 가능한 안내를 제공하는가? 세 가지 모두에 답하는 메시지는 3.3.3을 충족한다. (a)에만 답하는 메시지는 3.3.1은 충족하지만 3.3.3은 충족하지 못한다.
NVDA + Firefox로 스크린 리더 테스트: Tab 키로 폼으로 이동한다. 잘못된 값을 입력한다. 제출하거나 포커스를 이동한다. NVDA가 무엇을 읽는지 듣는다. 오류 제안 텍스트가 aria-live 영역이나 오류로의 포커스 이동을 통해, 사용자가 이를 수동으로 찾아야 하지 않고 자동으로 읽히는지 확인한다.
VoiceOver + Safari(macOS/iOS)로 스크린 리더 테스트: 동일한 단계를 수행한다. VO+오른쪽 화살표를 사용해 필드와 그에 연결된 설명을 읽는다. 제안 텍스트가 단순히 건너뛸 수 있는 인접 텍스트가 아니라, 필드의 접근 가능한 설명의 일부로 읽히는지 확인한다.
JAWS + Chrome으로 스크린 리더 테스트: 오류가 있는 폼을 제출한 후, JAWS가 포커스 관리(포커스를 오류 요약으로 이동) 또는 aria-live 영역 업데이트를 통해 오류 제안을 읽는지 확인한다. JAWS 가상 커서를 사용해 필드로 이동하고, 제안이 필드 설명의 일부로 포함되어 있는지 확인한다.
키보드 전용 탐색: 스크린 리더 없이 Tab, Shift+Tab, Enter만 사용해 폼을 탐색한다. 실패한 제출 후 필드에 포커스가 돌아왔을 때, 오류 제안이 뷰포트 내에 표시되고 화면 밖에 숨겨져 있거나 다른 요소에 가려져 있지 않은지 확인한다.
보안 예외 확인: 로그인 및 인증 폼의 경우, 구체적인 제안 생략이 의도적이고 문서화되어 있는지, 그리고 보안 예외가 최소한으로 필요한 필드에만 제한되어 있는지 확인한다.

수정 방법

일반적인 오류 메시지 — 잘못된 예

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

일반적인 오류 메시지 — 올바른 예

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

형식 안내가 없는 비밀번호 검증 — 잘못된 예

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

형식 안내가 없는 비밀번호 검증 — 올바른 예

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

형식이 모호한 날짜 필드 오류 — 잘못된 예

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

형식이 모호한 날짜 필드 오류 — 올바른 예

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

서버 측 오류 요약이 있는 다중 필드 폼 — 잘못된 예

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

서버 측 오류 요약이 있는 다중 필드 폼 — 올바른 예

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

자주 발생하는 실수

오류 제안의 대체로 placeholder를 사용하는 경우: 플레이스홀더 텍스트는 사용자가 입력을 시작하는 즉시 사라지며, 오류로서 스크린 리더에 안정적으로 읽히지 않는다. 오류가 발생한 후 요구되는 형식을 전달하는 수단으로 플레이스홀더 텍스트만을 절대 의존해서는 안 된다.
몇 초 후 사라지는 토스트 알림에만 오류 메시지를 표시하는 경우: 일시적인 알림은 모든 사용자가 인지할 수 있는 것이 아니다. 스크린 리더 사용자는 알림을 놓칠 수 있고, 속도가 느린 독자는 메시지를 처리하기도 전에 메시지가 사라질 수 있다. 오류 제안은 오류가 수정될 때까지 지속되어야 한다.
제안 텍스트를 가리키는 aria-describedby 없이 aria-invalid='true'만 사용하는 경우: aria-invalid를 설정하면 필드에 오류가 있음을 알리지만, 제안 요소에 연결하는 aria-describedby가 없으면 필드에 포커스가 갔을 때 스크린 리더가 제안 텍스트를 읽지 않는다.
제안을 DOM이 아닌 시각적 디자인(예: 호버 시 툴팁)에만 제공하는 경우: 호버 전용 툴팁은 키보드 사용자와 스크린 리더 사용자에게 접근할 수 없다. 제안 텍스트는 DOM에 존재해야 하며 필드와 프로그래밍적으로 연결되어야 한다.
어떤 필드에 오류가 있는지 표시하는 데 색상이나 아이콘만 사용하는 경우: 빨간 테두리나 경고 아이콘은 오류 제안이 아니다. 제안은 수정 조치를 설명하는 텍스트 설명이어야 하며, 단순한 시각적 표시로는 충분하지 않다.
문제는 식별하지만 해결책은 제시하지 않는 제안을 작성하는 경우: "Your password is too short"(비밀번호가 너무 짧습니다)는 오류를 식별하지만 해결책을 제안하지 않는다. "Your password must be at least 8 characters"(비밀번호는 최소 8자여야 합니다)는 필요한 수정 안내를 제공한다. 3.3.3을 준수하려면 두 부분이 모두 필요하다.
보안 예외를 지나치게 넓게 적용하는 경우: 보안 예외는 제안을 제공하는 것이 실제로 보안을 위태롭게 하는 상황, 일반적으로 인증 필드에만 좁게 적용된다. 이름, 주소, 전화번호와 같은 일반적인 폼 필드에서 일반적인 오류 메시지를 정당화하는 데 사용되어서는 안 된다.
오류 제안을 제출 버튼 뒤나 필드에서 멀리 떨어진 곳에 배치하는 경우: 오류 제안은 시각적으로도, 프로그래밍적으로도 설명하는 필드와 가까워야 한다. 긴 폼의 맨 아래에만 모든 오류를 모아 두고 각 필드에 인라인 제안을 제공하지 않으면, 사용자는 어떤 제안이 어떤 필드에 해당하는지 계속해서 맥락을 전환하고 기억해야 한다.
서버 측 제출 실패 후 포커스를 오류 요약으로 이동하지 않는 경우: 제출 실패 후 페이지가 다시 로드되면, 포커스는 일반적으로 페이지 상단으로 돌아간다. 오류 요약이나 첫 번째 오류 필드로의 프로그래밍적 포커스 관리가 없으면, 스크린 리더 사용자는 무엇이 잘못되었는지 알아내기 위해 페이지 전체를 탐색해야 한다.
"Please check your input"(입력을 확인해 주세요)나 "Something went wrong"(문제가 발생했습니다)와 같은 모호한 문구를 사용하는 경우: 이러한 메시지는 무엇이 잘못되었는지 또는 어떻게 수정해야 하는지에 대한 정보를 제공하지 않는다. 모든 오류 제안은 필드와 위반된 특정 검증 규칙에 구체적이어야 한다.

터키 접근성 규정과의 관계

터키의 접근성 환경은 2025년 6월 21일 관보(Official Gazette) 제32933호에 게재된 대통령령 2025/10을 통해 크게 진전되었다. 이 대통령령은 WCAG 2.2와 정렬된 웹 및 모바일 접근성 의무 요건을 수립하며, 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 Erişilebilirlik Logosu(접근성 로고)를 취득하려는 기관에 레벨 AA 준수를 요구한다.

레벨 AA 기준인 WCAG 3.3.3 Error Suggestion은 이러한 의무 요건의 범위에 포함된다. 등록, 결제, 서비스 신청, 계정 관리 등을 위해 폼을 운영하는 모든 해당 기관은, 오류를 단순히 식별하는 것에 그치지 않고 이 기준에서 설명하는 대로 실행 가능한 수정 제안을 제공하도록 오류 메시지를 구성해야 한다.

대통령령 2025/10의 적용 대상 기관은 매우 다양한 부문에 걸쳐 있다. 공공 기관 및 정부 기관은 준수가 의무이며, 이는 모든 전자정부 포털(예: e-Devlet 서비스, 지방자치단체 포털, 복지 신청 시스템)이 기준에 맞는 오류 제안 구현을 제공해야 함을 의미한다. 많은 정부 서비스가 시민에게 복잡한 개인 데이터(신분 번호, 주소 코드, 세금 번호 등)를 제출하도록 요구한다는 점을 고려하면, 명확한 오류 제안은 특히 이 맥락에서 중요하다.

은행 및 금융 기관도 적용 대상이며, 온라인 뱅킹 플랫폼, 투자 계좌 개설 폼, 대출 신청 포털 등이 포함된다. 이러한 폼은 민감하고 정확한 형식의 데이터를 상시 수집하며, 수정 제안의 부재는 장애가 있는 고객에게 실질적인 장벽을 만들고 법적 리스크를 초래할 수 있다.

병원 및 의료 서비스 제공자 역시 준수해야 하며, 환자 등록 시스템, 예약 폼, 보험 청구 포털 등이 포함된다. 의료 관련 폼은 진단 코드, 보험 증권 번호, 정확한 날짜 형식 등 복잡한 필드 요구사항을 포함하는 경우가 많아, 고령자와 인지 장애 환자에게 명확한 오류 제안이 특히 중요하다.

20만 명 이상의 가입자를 보유한 통신사도 적용 대상이며, 주요 사업자의 고객 포털, SIM 등록 폼, 계정 관리 인터페이스가 포함된다. 전자상거래 플랫폼 — 결제 흐름과 계정 등록을 포함 — 역시 준수해야 하며, Error Suggestion은 이들의 핵심 비즈니스 운영에 해당하는 상품 및 장바구니 관리 폼과 직접적으로 관련된다.

여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교도 범위에 포함된다. 이들이 운영하는 예약 폼, 등록 신청서, 결제 인터페이스는 모두 3.3.3을 포함한 레벨 AA 기준을 충족해야 한다.

실질적인 준수 관점에서, Erişilebilirlik Logosu를 추구하는 조직은 WCAG 3.3.3을 모든 접근성 평가에서 핵심 감사 항목으로 다루어야 한다. 클라이언트 측과 서버 측 오류 상태를 모두 포함한 모든 폼 검증 흐름에 대한 수동 테스트가 필요하며, 수정 제안을 의도적으로 생략한 필드에 대해서는 보안 예외에 대한 근거를 문서화해야 한다. Error Suggestion을 포함한 레벨 AA 요구사항을 충족하지 못하면 로고 수여가 불가능하며, 대통령령에 따른 행정적 제재에 노출될 수 있다.