성공 기준(SC)
입력 오류가 자동으로 감지되는 경우, 오류가 발생한 항목을 보여주고, 오류의 내용을 사용자에게 텍스트로 설명해야 한다.
3.3.1 오류 식별
(Level A)
- 목표
- 사용자가 오류가 발생했음을 알고, 무엇이 잘못되었는지 이해할 수 있도록 한다.
- 할 일
- 오류에 대해 설명하는 알림을 제공한다.
- 중요성
- 오류를 명확히 표시하면 저시력 사용자 및 인지적 어려움이 있는 사람의 문제 해결에 도움이 된다.
이 성공 기준의 목적은 사용자가 오류가 발생했음을 인지하고, 무엇이 잘못되었는지 확인할 수 있도록 하는 것이다. 양식 제출에 실패한 경우, 실패의 어떠한 안내도 없이 단순히 양식을 다시 표시하는 것만으로는 충분하지 않다. 오류는 텍스트로 명확히 표시되어야 한다.
이 성공기준은 사용자에게 오류의 성격에 대한 정보, 어느 항목에 오류가 있는지에 대한 정보를 제공 해야한다.
오류가 있는 항목을 어떻게 수정해야 하는지는 3.3.3 오류 수정 제안에서 다룬다.
오류 설명은 종종 성공기준 3.3.1과 성공기준 3.3.3을 동시에 충족하도록 작성할 수 있다.
예를 들어, “이메일 형식이 올바르지 않습니다.”라는 문구는 성공기준 3.3.1을 충족하고 “name@domain.com 형식의 올바른 이메일 주소를 입력해 주세요.”라는 문구는 오류를 어떻게 수정해야 하는지까지 함께 안내하기에, 두 성공기준을 충족한다.
“입력 오류” 에는 다음이 포함된다.
- 웹 페이지에서 필수로 요구하는 정보가 사용자에 의해 입력되지 않은 경우, 또는
- 사용자가 정보를 입력했지만, 해당 정보가 요구되는 데이터 형식이나 허용된 값의 범위를 벗어나는 경우
예를 들면,
- 사용자가 주, 도 또는 지역 입력란에 올바른 약어를 입력하지 않은 경우.
- 사용자가 해당 국가에서 유효하게 인정되지 않는 주(state)의 약어 값을 입력한 경우.
- 사용자가 존재하지 않는 우편번호를 입력한 경우.
- 사용자가 현재 시점보다 2년 이후의 생년월일을 입력한 경우.
- 사용자가 숫자만 허용되는 전화번호 입력란에 영문자나 괄호를 입력한 경우.
- 사용자가 이전 입찰가 보다 낮거나, 최소 입찰 증가 단위보다 낮은 금액을 입력한 경우.
참고
사용자가 너무 높거나 너무 낮은 값을 입력했을 때, 페이지의 코드가 그 값을 자동으로 허용 범위 안의 값으로 변경 하더라도, 해당 오류는 이 성공기준에서 요구하는 바에 따라 사용자에게 설명되어야 한다. 이렇게 변경된 값을 사용자에게 알려 주는 오류 설명이 이 성공기준(오류 식별)과 3.3.3 오류 수정 제안을 모두 충족하게 된다.
오류의 식별과 설명은 프로그래밍 방식의 정보와 함께 제공할 수 있다. 사용자 에이전트나 보조기술이 오류를 인식해서 사용자에게 정보를 제공할 수 있다. 예를 들어, 특정 기술은 사용자의 입력 값이 지정된 범위를 벗어나지 않아야 함을 명시하거나, 특정 양식 필드가 필수 항목임을 지정할 수 있다. 이러한 유형의 프로그래밍 방식 정보는 이 성공기준에서 요구되는 사항은 아니지만, 4.1.2 이름, 역할, 값과 같은 다른 기준에서 다루어질 수 있다.
또한 오류를 텍스트 설명과 함께 이미지, 색상, 또는 기타 시각적 표시와 같은 방식으로 추가적으로 나타내는 것도 허용된다.
참고
이 기준은 오류를 어떤 방식으로 표시해야 하는지에 대해 특정 방법을 요구하지 않는다. 상황에 따라서는 모든 오류를 양식의 시작 부분이나 앞쪽에 한 번에 나열하는 방식이 더 적절할 수 있다. 다른 경우에는 오류가 있는 각 필드 옆에 오류 메시지를 바로 표시하는 방식이 더 적합할 수 있다. 오류를 알림이나 대화상자로 표시할 수도 있다. 이 기준은 이러한 방법 중 어떤 방식을 사용해야 하는지 까지는 다루지 않는다 - 유일한 요구 사항은 오류를 텍스트 또는 텍스트 대체 수단으로 사용자에게 제시하는 것이다.
3.3.3 오류 수정 제안 또한 참고하라.
사용자 에이전트 기본 제공 HTML 양식 검증
Section titled “사용자 에이전트 기본 제공 HTML 양식 검증”기본 제공 HTML 클라이언트 측 양식 검증을 사용하는 경우, 사용자 에이전트는 불완전하거나 유효하지 않은 양식의 제출을 자동으로 차단하고, 사용자에게 일반적인 오류 메시지를 표시한다. 사용자 에이전트는 보통 오류가 있는 첫 번째 양식 필드로 초점을 이동시키며, 그 결과 해당 필드와 생성된 오류 메시지가 뷰포트에 보이도록 페이지를 스크롤한다.
대부분의 일반적인 사용자 에이전트와 스크린리더 조합에서는, 스크린리더가 오류 메시지와 초점을 받은 필드의 프로그래밍 방식 이름을 함께 읽어 준다. 이 방식은 이 성공기준의 요구 사항을 충족하지만, 다음과 같은 몇 가지 단점이 있다는 점에 유의해야 한다.
- 사용자 에이전트에 따라 오류 메시지가 항상 화면에 유지되지 않거나, 페이지를 스크롤해도 함께 이동하지 않을 수 있다.
- 사용자 에이전트에 따라, 사용자가 콘텐츠를 확대했더라도 오류 메시지는 함께 확대되지 않을 수 있다. 검증 메시지의 텍스트는 사용자 에이전트 인터페이스와 동일한 크기로 표시되기 때문에, 사용자에게는 메시지가 너무 작아 읽기 어려울 수 있다.
- 기본 제공 HTML 검증 오류 메시지는 대체로 매우 일반적인 내용에 그쳐, 3.3.3 오류 수정 제안을 충족할 만큼 충분히 구체적이거나, 도움이 되는 안내를 제공하지 못할 수 있다.
- 만약, 여러 오류가 있는 경우에는 첫 번째 오류 메시지만 표시된다. 사용자가 해당 필드 유형에 맞게 입력을 수정하고 양식을 다시 제출하면, 그 다음 오류가 있는 경우에만 다음 오류 메시지가 표시된다. 이로 인해 사용자는 양식을 여러 차례 다시 제출하고 수정해야 할 수 있다.
이러한 문제는 사용자 에이전트의 동작과 관련이 있어, 개발자는 기본 브라우저 검증이 접근성 지원을 충족하는지 신중하게 검토해야 한다.
- 입력 오류에 대한 정보를 텍스트로 제공하면, 시각에 어려움이 있는 사용자, 저시력 사용자, 또는 색각 이상이 있는 사용자가 오류가 발생했다는 사실을 인지할 수 있다.
- 이 성공기준은 또한, 양식 제출이 실패한 구체적인 이유를 이해하는 데 어려움이 있는 인지적, 언어적, 학습에 어려움이 있는 사람에게 도움이 될 수 있다. (양식의 특성상, 실패 원인이 사전에 미리 명확하게 드러나 있지 않은 경우.)
- 양식 제출 시 오류 식별
항공사 웹사이트에서 할인 항공권에 대한 특별 프로모션을 제공한다. 사용자는 이름, 주소, 전화번호, 선호 좌석, 이메일 주소 등, 개인정보를 입력하는 간단한 양식을 작성해야 한다. 양식의 항목 중 일부가 입력되지 않았거나, 잘못 입력된 경우, 어떤 필드가 누락되었거나 올바르지 않다고 사용자에게 알리는 알림이 표시된다.
참고
이 성공기준은 오류를 표시할 때 색상이나 텍스트 스타일을 사용할 수 없다는 의미가 아니다. 다만, 오류는 텍스트로도 식별되어야 한다는 것을 요구할 뿐이다.
- 여러가지 단서 제공
사용자가 양식의 두 개 항목를 입력하지 않았다. 오류를 설명하고 해당 필드를 쉽게 찾을 수 있도록 고유한 문자 표시를 제공하는 것과 같이, 시각적으로도 쉽게 찾을 수 있도록 해당 필드를 노란색으로 강조 표시한다.
이 섹션에서 번호가 매겨진 각 항목은 접근성 지침 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 간주하는 기법 또는 기법의 조합을 나타낸다. 그러나 이러한 특정 기법을 사용할 필요는 없다. 다른 기법 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 기법 이해, 특히 “기타 기법” 섹션을 참고하라.
아래에서 귀하의 콘텐츠와 일치하는 상황을 선택하라. 각 상황에는 해당 상황에 충분하다고 알려져 있고 문서화된 기법 또는 기법의 조합이 포함된다.
상황 A: If a form contains fields for which information from the user is mandatory.
Section titled “상황 A: If a form contains fields for which information from the user is mandatory.”- G83: Providing text descriptions to identify required fields that were not completed
- ARIA2: Identifying a required field with the aria-required property
- ARIA21: Using aria-invalid to Indicate An Error Field
- SCR18: Providing client-side validation and alert
- PDF5: Indicating required form controls in PDF forms
상황 B: If information provided by the user is required to be in a specific data format or of certain values.
Section titled “상황 B: If information provided by the user is required to be in a specific data format or of certain values.”- ARIA18: Using aria-alertdialog to Identify Errors
- ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
- ARIA21: Using aria-invalid to Indicate An Error Field
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- SCR18: Providing client-side validation and alert
- SCR32: Providing client-side validation and adding error text via the DOM
- PDF22: Indicating when user input falls outside the required format or values in PDF forms
준수를 위해 필수는 아니지만 콘텐츠에 더 쉽게 접근할 수 있도록 다음과 같은 추가 기법을 고려해야 한다. 모든 기법을 사용할 수 없거나 모든 상황에서 효과적인 것은 아니다.
- G139: Creating a mechanism that allows users to jump to errors
- G199: Providing success feedback when data is submitted successfully
- ARIA2: Identifying a required field with the aria-required property
다음은 이 성공 기준의 특정 측면에 대한 점검 규칙이다. WCAG 준수 여부를 확인하기 위해 이러한 특정 점검 규칙을 사용할 필요는 없지만 이것은 정의되고 승인된 검사 방법이다. 점검 규칙 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 점검 규칙 이해를 참고하라.