폼 오류 메시지는 전환율과 접근성을 함께 좌우한다

회원가입, 견적 문의, 결제 화면에서 입력 오류를 처리할 때 빨간 테두리만 표시하면 사용자는 무엇을 고쳐야 하는지 바로 알기 어렵습니다. 화면을 보지 못하는 사용자는 오류가 생겼다는 사실을 놓칠 수 있고, 키보드만 사용하는 사용자는 어느 필드에 문제가 있는지 찾기 어렵습니다. 모바일에서 확대해 쓰는 환경에서도 색상만으로 상태를 구분하게 하면 입력 완료까지 시간이 길어집니다.

접근 가능한 폼은 별도의 복잡한 화면을 의미하지 않습니다. 입력 항목의 이름을 명확히 연결하고, 도움말과 오류 메시지를 프로그램적으로 연결하며, 제출 후에는 오류 위치로 이동할 수 있게 만드는 것이 핵심입니다. 이 문서에서는 브라우저의 기본 HTML 기능을 우선 사용하고 필요한 경우에만 ARIA를 추가하는 방식으로 구현합니다.

1. label과 입력 요소를 연결한다

placeholder는 입력 예시를 보여 주는 보조 수단일 뿐 label을 대신하지 못합니다. 값을 입력하면 placeholder가 사라지고, 보조기기는 필드 목적을 안정적으로 읽지 못할 수 있습니다. label의 for 값과 input의 id를 일치시키면 라벨을 클릭해도 입력칸으로 이동하고 스크린 리더도 필드 이름을 읽습니다. id는 페이지에서 유일해야 하며, 반복되는 폼이라면 데이터의 고유 키를 포함해 생성합니다.

<label for="companyEmail">담당자 이메일</label>
<input id="companyEmail" name="companyEmail"
  type="email" autocomplete="email" required
  aria-describedby="companyEmailHint companyEmailError" />
<p id="companyEmailHint">견적 회신을 받을 이메일을 입력하세요.</p>
<p id="companyEmailError" class="field-error" aria-live="polite"></p>

name은 서버가 값을 구분하는 데 쓰이므로 화면 문구와 별개로 의미 있는 이름을 붙입니다. autocomplete 속성도 브라우저 자동 완성, 비밀번호 관리자, 모바일 입력 환경에 직접 영향을 줍니다. 이메일, 전화번호, 조직명처럼 표준화된 값은 적절한 autocomplete 토큰을 명시하는 편이 안전합니다.

2. 도움말과 오류 문구를 연결한다

aria-describedby에는 공백으로 구분한 여러 id를 지정할 수 있습니다. 평상시에는 도움말을 읽고 오류가 생기면 같은 연결 안의 오류 문구도 읽게 할 수 있습니다. 오류 문구가 비어 있어도 요소와 id 자체는 유지하는 편이 좋습니다. 자바스크립트가 오류 요소를 새로 만들었다가 제거하면 포커스와 읽기 순서가 불안정해질 수 있기 때문입니다.

오류 상태가 된 input에는 aria-invalid="true"를 추가합니다. 이 속성은 단순히 빨간 테두리를 그리는 용도가 아니라 보조기기에 해당 필드가 유효하지 않다는 의미를 전달합니다. 오류를 수정한 뒤에는 false로 바꾸거나 속성을 제거해 화면 상태와 접근성 상태를 동기화해야 합니다.

3. 제출 시 첫 오류로 포커스를 이동한다

입력할 때마다 강한 오류 알림을 내보내면 화면 읽기 사용자의 작업을 방해할 수 있습니다. 필수 항목 누락처럼 즉시 확인이 유용한 경우에는 blur 시점에 안내하고, 전체 검증은 submit 시점에 처리하는 구성이 안정적입니다. 제출에 실패했다면 첫 번째 오류 필드로 포커스를 옮겨 사용자가 바로 수정할 수 있게 합니다.

const form = document.querySelector('#inquiryForm');
const email = document.querySelector('#companyEmail');
const error = document.querySelector('#companyEmailError');

function setError(message) {
  error.textContent = message;
  email.setAttribute('aria-invalid', message ? 'true' : 'false');
}

form.addEventListener('submit', (event) => {
  setError('');
  if (!email.validity.valid) {
    event.preventDefault();
    setError(email.validity.valueMissing
      ? '담당자 이메일을 입력해 주세요.'
      : '이메일 주소 형식으로 입력해 주세요.');
    email.focus();
  }
});

HTML의 required와 type="email"은 브라우저 기본 검증을 제공합니다. 디자인 시스템에서 자체 메시지를 보여 주고 싶다면 form에 novalidate를 추가하고 validity 객체를 이용해 같은 규칙을 해석할 수 있습니다. 다만 클라이언트 검증은 편의 기능일 뿐이므로 서버에서도 동일한 필수값, 형식, 길이, 권한 검증을 다시 수행해야 합니다.

4. 색상 외의 수단으로 오류를 표현한다

오류 입력칸에는 테두리 색상, 오류 아이콘, 텍스트 메시지를 함께 제공합니다. 정상 상태와 오류 상태의 대비가 충분한지 확인하고 포커스 윤곽선을 제거하지 않습니다. outline: none을 적용해야 한다면 같은 수준 이상으로 눈에 띄는 focus-visible 스타일을 별도로 제공해야 합니다. 마우스 사용자는 테두리를 보고, 키보드 사용자는 포커스 링을 보고, 보조기기 사용자는 aria-invalid와 연결된 메시지를 통해 같은 정보를 얻어야 합니다.

.field-error {
  min-height: 1.5em;
  margin-top: 0.25rem;
  color: #b42318;
}
input[aria-invalid="true"] { border: 2px solid #b42318; }
input:focus-visible {
  outline: 3px solid #175cd3;
  outline-offset: 2px;
}

5. 서버 오류와 요약 영역을 함께 처리한다

이미 사용 중인 이메일이나 허용되지 않는 첨부파일처럼 클라이언트에서 알 수 없는 오류는 서버가 반환합니다. 이때 상단에 오류 요약을 표시하고 항목별 메시지도 각 입력칸에 연결합니다. 요약 영역은 role="alert" 또는 aria-live="assertive"를 신중하게 사용해 제출 직후 한 번만 알립니다. 여러 문장을 반복해 갱신하면 읽기 순서가 뒤섞일 수 있으므로 오류 목록을 완성한 뒤 DOM에 한 번 반영합니다.

배포 전 점검 체크리스트

  • 모든 입력칸에 연결된 label과 고유 id가 있는지 확인합니다.
  • placeholder만으로 필드 목적을 설명하지 않았는지 확인합니다.
  • 도움말과 오류 문구가 aria-describedby로 연결되는지 확인합니다.
  • 오류 시 aria-invalid 상태와 화면 스타일이 함께 바뀌는지 확인합니다.
  • 제출 실패 후 첫 오류 필드로 키보드 포커스가 이동하는지 확인합니다.
  • 색상 외에 텍스트와 테두리 형태로 오류를 구분하는지 확인합니다.
  • 클라이언트 검증과 별개로 서버 검증을 수행하는지 확인합니다.

폼 접근성은 특정 사용자만을 위한 부가 기능이 아닙니다. 문의, 가입, 결제처럼 전환에 직접 연결되는 화면에서 입력 실패를 줄이는 기본 품질입니다. 실제 기기에서 Tab 키만으로 전 과정을 이동해 보고 오류가 난 뒤 무엇을 고쳐야 하는지 화면을 보지 않고도 이해할 수 있는지 검증하면 가장 중요한 문제를 빠르게 찾을 수 있습니다.