작성 후에도 목적이 남는지
가정한 예로 여러 연락처를 입력한 뒤 어느 칸이 회사명인지 이름인지 구분하기 어려울 수 있습니다. 빈 화면만 보지 말고 모든 칸에 값이 들어간 상태를 검수합니다. 강조 색과 위치만으로 목적을 설명하지 않습니다.
설계 예시
다음은 라벨·형식 안내를 구분하는 단순 HTML 예시입니다. 실제 폼 처리와 보안 검증은 별도로 구현해야 합니다.
<label for="demo-contact-email">회신 받을 이메일</label>
<p id="demo-email-help">답변을 받을 수 있는 주소를 입력해 주세요.</p>
<input id="demo-contact-email" name="reply_email" type="email"
autocomplete="email" aria-describedby="demo-email-help"
placeholder="name@example.invalid" required>
관계의 검수
라벨을 눌렀을 때 맞는 입력창에 초점이 가는지 확인합니다. 같은 컴포넌트가 두 개 렌더링되면 id가 중복될 수 있습니다. 보조기술에서 읽는 이름과 화면 문구가 다르면 음성 조작과 오류 찾기가 어려울 수 있어 같은 목적을 설명하는지 봅니다.
확인 순서
- 빈값·입력 후·오류 상태의 라벨을 읽습니다.
- 라벨 클릭과 키보드 초점을 확인합니다.
- 실제 접근성 이름과 도움말 연결을 대조합니다.
- 모바일 확대와 긴 입력값에서도 배치를 봅니다.
장식 아이콘만 있는 버튼과 선택 항목도 이름이 필요한지 확인합니다. 필수 표시를 별표만으로 한다면 폼 앞의 안내와 실제 필수 검증이 같은지 봅니다. 단순히 속성이 있다는 자동 검사 결과만으로 내용의 명확성까지 통과했다고 보지 않습니다.
완료 기준
방문자가 입력 전후에 각 칸의 목적을 이해하고 오류 항목을 찾을 수 있어야 합니다. 코드 예시를 복사한 뒤에도 실제 페이지의 중복 id와 시각적 읽기를 검수해야 합니다. 완료율 변화는 별도 관찰이고 라벨 수정만으로 문의 성과를 보장하지 않습니다. 설명이 명확해도 불필요한 입력이 많다면 폼의 수집 목적을 함께 재검토합니다.
자주 묻는 질문
- 입력창 안에 이메일이라고 보이면 충분한가요?
- 입력 후 사라지는 안내만으로 목적을 기억해야 하면 검토가 어려울 수 있습니다. 지속적으로 보이는 이름과 실제 컨트롤 연결을 확인하는 것이 좋습니다.
- aria-label을 넣으면 화면 라벨은 없어도 되나요?
- 보조기술의 이름과 시각적 안내는 다른 측면입니다. 문맥과 용도를 확인하고 일반 문의폼에서는 방문자가 직접 읽을 라벨을 제공하는 방식을 우선 검토합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.