04 · Patterns · 입력 · 폼
유효성 검증Validation
언제 검사하고 어디에 보여줄지. 너무 빨라도 귀찮고, 너무 늦어도 좌절스러운 영역 — 시점을 나누어 각자의 역할을 맡깁니다.
3가지 시점
- 실시간 (onChange) — 길이·형식이 명백히 잘못된 경우에만. 사용자가 한 글자 쳤는데 빨간 메시지를 띄우지 마세요.
- 포커스 아웃 (onBlur) — 기본. 필드를 떠날 때 검사하고 에러를 보여줍니다.
- 제출 시 (onSubmit) — 서버 검증 포함. 이 시점에만 알 수 있는 중복 확인 등.
Do· 포커스 아웃 우선
이메일 형식은 onBlur에서 검사. 사용자가 작성을 마쳤다는 신호를 받은 후에 피드백을 주는 것이 덜 공격적입니다.
Don't· 타이핑 중 빨간 에러
u한 글자를 친 순간 “이메일이 올바르지 않습니다”를 띄우지 마세요. 아직 작성 중입니다.
서버 반환 오류
서버가 반환한 에러는 해당 필드에 붙여서보여주는 것이 원칙입니다. ‘이메일 중복’이면 이메일 필드 아래에, ‘제출 실패’처럼 특정 필드에 귀속되지 않는 오류만 폼 상단의 Alert으로 요약합니다.
제출 실패 시 첫 번째 에러 필드로 스크롤 + 포커스 이동이 기본 동작이어야 합니다. 사용자가 긴 폼에서 어디가 틀렸는지 찾아 헤매지 않도록 하세요.
메시지 작성
- 문제 + 해결을 함께 적습니다. “이메일이 올바르지 않습니다”보다 “이메일에 @ 기호를 포함하세요”.
- 사용자 탓으로 들리게 쓰지 않기. “잘못 입력했습니다” → “8자 이상이어야 합니다”.
- 같은 상황엔 같은 문구. “필수 항목”은 앱 전체에서 한 가지 표현으로 통일.
성공 신호
필드마다 초록 체크를 붙이는 것은 보통 과잉입니다. 중복 확인이 필요한 ID·닉네임 같은 ‘성공 여부 자체가 유용한 정보’인 필드에만 제한적으로 사용하세요. 제출 후 폼 전체의 성공은 Toast나 페이지 전환으로 알립니다.
접근성
- 에러가 뜨면 입력에
aria-invalid="true"를 부여하고aria-describedby로 에러 메시지 ID를 연결. - 폼 상단 요약 Alert은
role="alert"로 즉시 읽히게. - 에러 색만으로 구분하지 말고 아이콘이나 텍스트도 함께. 색각이상자를 위한 기본.