오류 종류를 구분합니다
필수 누락·형식 오류·서버 거절·네트워크 실패는 다른 수정 행동이 필요합니다. ‘오류가 발생했습니다’로 모두 끝내면 사용자가 무엇을 해야 할지 모릅니다. 실제로 알 수 없는 결과는 미확인으로 안내하고 이미 접수됐을 가능성을 무시한 반복 제출을 유도하지 않습니다.
설계용 연결 예시
다음은 필드 오류의 관계를 보여주는 간단한 예시입니다. 실제 검증과 오류 발생 시점, 알림 방식은 앱 구조에 맞춰 구현합니다.
<label for="demo-reply">회신 이메일</label>
<input id="demo-reply" type="email" name="reply"
aria-invalid="true" aria-describedby="demo-reply-error">
<p id="demo-reply-error">이메일 형식을 확인해 주세요.</p>
수정 중 경험
가정한 예로 오류 뒤 전체 폼이 초기화되면 사용자가 긴 문의를 다시 써야 합니다. 안전하게 유지할 입력과 초기화할 민감 정보의 정책을 정합니다. 한 항목을 고쳤다고 다른 오류 안내까지 사라져 제출할 수 없는 상태도 점검합니다.
검수 순서
- 필수 누락과 복수 오류를 각각 만듭니다.
- 오류 요약·필드 연결·초점을 확인합니다.
- 모바일 키보드와 고정 UI의 가림을 봅니다.
- 수정 후 재제출과 입력 보존을 시험합니다.
오류 문장에 사용자 입력값을 불필요하게 반복하거나 분석 이벤트로 보내지 않습니다. 서버가 반환한 내부 오류를 그대로 노출하지 않고 사용자에게 필요한 안내와 기술 조사를 분리합니다. 잘못된 형식을 예시로 보여줄 때는 실제 개인정보를 쓰지 않습니다.
완료 기준
방문자가 오류 원인을 이해하고 수정할 수 있어야 합니다. 자동 접근성 검사만으로 안내 문장의 명확성과 실제 수정 성공을 보장하지 않습니다. 입력 오류가 줄어든 것을 측정하려면 이벤트 정의와 개인정보 최소화를 함께 확인하고, 검증을 끈 결과로 오류 수가 줄어든 것을 개선이라고 보고하지 않습니다.
자주 묻는 질문
- 입력창 테두리를 빨갛게 하면 충분한가요?
- 색만으로 오류 종류와 수정 방법을 알기 어렵습니다. 텍스트 안내와 필드 연결을 제공하고 실제 보조기술과 키보드 흐름도 검수해야 합니다.
- 첫 오류로 무조건 초점을 이동하면 되나요?
- 폼 구조와 오류 요약, 사용 중인 검증 방식에 맞는 흐름을 정해야 합니다. 초점이 예상치 않게 반복 이동하거나 안내를 읽기 전에 가려지지 않는지 시험합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.