폼 검증과 접근 가능한 오류 패턴 — 인라인·서버·스크린리더

UX/UI

접근성검증

이 글은 누구를 위한 것인가

가입·주문·예약 폼을 만드는 디자이너와 개발자, 그리고 “오류 문구가 너무 공격적이에요”라는 CS 피드백을 받은 분을 위한 글입니다. 접근성은 장애인만의 이야기가 아니라, 키보드·작은 화면·자동완성 사용자 모두에게 이익입니다.

오류의 세 층

클라이언트 즉시 검증, 제출 시 검증, 서버 비즈니스 규칙 위반을 메시지 톤까지 구분해 표시합니다. 같은 “이메일이 잘못됐습니다”라도, 즉시/제출 후/서버 거절은 사용자 기대가 다릅니다.

스크린리더

aria-describedby로 필드와 오류를 연결하고, 중요 알림은 적절한 aria-live 정책을 씁니다. 시각적으로는 빨간 테두리만 바뀌어도, 스크린리더 사용자에게는 무슨 필드가 왜 틀렸는지가 들려야 합니다.

포커스 관리

첫 오류 필드로 포커스를 옮길지, 요약 상자로 옮길지 팀에서 정합니다. 모달 안 폼은 트랩과 충돌하지 않게 설계합니다.

맺으며

디자인 시스템에 오류 상태 컴포넌트가 없으면 매 화면마다 다른 빨간 글씨가 생깁니다.