문의 양식의 빨간 테두리만으로는 부족합니다, 고칠 항목과 방법을 알려 줍니다

문의 양식을 제출했는데 '입력값을 확인하세요'라는 문장만 뜨면 이용자는 모든 칸을 다시 읽어야 합니다. 빨간 테두리만 바뀌어도 어떤 문제인지 충분히 알기 어렵습니다. 오류 안내에는 문제가 있는 항목과 수정 방법을 적고, 그 항목까지 이동할 수 있는 경로를 제공해야 합니다. 문구를 친절하게 만드는 것과 실제로 오류를 해결할 수 있게 만드는 것을 함께 검토합니다.

오류 이름에 실제 항목명을 사용합니다

양식에 '회신 이메일'이라고 적혀 있다면 오류 메시지에서도 같은 이름을 씁니다. 내부 개발용 필드명이나 번호만 표시하면 사용자가 대응하는 칸을 찾기 어렵습니다. W3C WAI는 오류 알림을 명료하게 작성하고 해결 방법을 안내하며, 해당 입력 요소와 메시지를 연결하는 방법을 설명합니다. W3C 양식 알림 안내

가정으로 이메일 주소 형식이 맞지 않는 경우 '잘못된 정보입니다'보다 '회신 이메일의 주소 형식을 확인해 주세요'가 수정 대상을 분명하게 합니다. 단, 시스템이 실제로 확인한 것이 형식뿐이라면 주소가 존재하지 않는다고 단정하지 않습니다. 오류 문구의 주장 범위가 검증 결과보다 넓어지지 않아야 합니다.

여러 오류는 전체 위치와 개별 설명을 함께 제공합니다

예를 들어 5개 입력칸 중 2개에서 오류가 발생했다면 상단에는 문제가 있는 항목들을 정리하고 각 칸 가까이에는 구체적인 설명을 둘 수 있습니다. 상단 목록에서 해당 입력칸으로 이동할 수 있는지도 확인합니다. 두 위치의 문구가 서로 다르면 이용자가 어느 안내를 따라야 할지 혼동할 수 있습니다.

이 숫자는 운영 예시이며 특정 양식의 실제 오류 통계가 아닙니다. 오류 개수 자체보다 빠진 항목이 없는지, 색을 구분하지 못해도 문제를 알 수 있는지, 보조기술에서도 메시지를 발견할 수 있는지가 중요합니다. 동적으로 나타나는 메시지는 화면에 추가되는 것과 읽히는 방식 모두 점검해야 합니다.

입력 오류와 전송 실패를 같은 말로 처리하지 않습니다

필수 항목을 비운 경우에는 그 항목을 채우도록 안내할 수 있습니다. 반면 통신 오류나 서버 처리 실패라면 사용자가 올바르게 입력한 값을 다시 고쳐도 해결되지 않을 수 있습니다. 이때도 '입력값을 확인하세요'라고 표시하면 잘못된 행동을 반복하게 됩니다.

전송 결과가 불명확한 경우에는 실제로 접수가 저장됐는지를 확인할 수 있는 처리 방식이 필요합니다. 화면에서 무조건 재제출하라고 안내하기 전에 중복 접수 가능성과 재시도 동작을 개발 담당자와 검토합니다. 확인되지 않은 성공을 알리거나 실패를 확정하지 말고 현재 알 수 있는 상태와 가능한 다음 행동을 전달합니다.

입력한 내용을 오류 때마다 모두 지우는지도 살핍니다. 일반적인 수정 오류에서는 이용자가 고칠 부분에 집중할 수 있어야 합니다. 다만 민감한 값의 보존 방식은 별도 검토가 필요하며, 편의를 이유로 입력 내용을 외부 분석 로그에 남기는 방식으로 해결하지 않습니다.

오류를 고친 뒤 사라지는 안내까지 시험합니다

검수는 정상 제출, 필수 항목 누락, 형식 오류, 전송 실패의 4가지 경로로 나눠 볼 수 있습니다. 각 경로에서 메시지 내용, 이동 위치, 입력값 유지, 재시도 결과를 기록합니다. 전송 실패 시험은 운영 접수에 영향을 주지 않는 점검 환경에서 진행합니다.

문제가 해결됐는데도 이전 오류가 남으면 이용자는 아직 제출할 수 없다고 생각할 수 있습니다. 반대로 하나를 수정한 뒤 다른 오류까지 모두 사라지는지도 확인합니다. 입력 중 너무 이른 시점에 오류를 반복해 알리는 경우에는 아직 작성 중인 사람을 방해하지 않는지 검토합니다.

출처 확인일: 2026-10-26. 본문의 메시지와 시험 경로는 운영 제안입니다. 화면 안내 개선만으로 접수 저장과 중복 처리가 정상이라는 판단을 대신하지 않습니다.