웹 접근성 첫 점검: 키보드·폼·오류 메시지
로그인 폼 예제로 이름표, 포커스, 오류 안내를 점검하고 수동 검사 범위를 정합니다.
웹 접근성 점검은 자동 검사에서 오류가 없다는 결과로 끝나지 않습니다. 로그인처럼 짧은 흐름을 골라 마우스 없이 완료할 수 있는지, 오류의 위치와 이유를 알 수 있는지 확인하는 것이 작은 사이트의 출발점이 될 수 있습니다.
키보드로 로그인 흐름 따라가기
페이지를 새로 열고 Tab으로 이동합니다. 이동 순서가 화면의 읽기 순서와 맞는지, 현재 포커스가 보이는지, Enter로 제출할 수 있는지 기록합니다. 모달을 열었다면 닫기 버튼에 접근할 수 있어야 하고 닫은 뒤 원래 작업으로 돌아갈 수 있어야 합니다.
단순히 div에 클릭 이벤트를 붙여 버튼처럼 보이게 하는 대신 실제 button을 쓰는 것이 기본 동작을 확보하기 쉽습니다. outline: none만 지정해 포커스 표시를 없애지 않습니다.
입력칸의 이름과 오류 연결하기
다음은 오류가 발생한 상태의 HTML 예제입니다. 정상 상태에서는 aria-invalid를 제거하거나 false로 두고, 오류 문구도 실제 검증 결과에 따라 표시해야 합니다.
<label for="email">이메일</label>
<input id="email" name="email" type="email"
autocomplete="email" aria-invalid="true"
aria-describedby="email-error">
<p id="email-error">이메일 주소의 @ 앞뒤 내용을 확인해 주세요.</p>
<button type="submit">로그인</button>
placeholder는 입력하면 사라지므로 label의 대체물이 아닙니다. 빨간 테두리만 표시하면 색을 구분하기 어려운 사람은 원인을 알 수 없습니다. 텍스트 설명과 필드 연결을 함께 제공합니다. 여러 오류가 있으면 요약 영역과 각 입력칸의 연결도 검토합니다.
이미지와 확대 화면 확인하기
정보를 전달하는 이미지에는 목적에 맞는 대체 텍스트를 작성합니다. 같은 내용을 이미 인접 문장으로 충분히 전달하는 장식 이미지는 빈 대체 텍스트가 더 적절할 수 있습니다. ‘이미지입니다’처럼 유형만 말하는 설명은 보통 도움이 적습니다.
브라우저 확대와 좁은 화면에서도 버튼이나 입력칸이 겹치지 않는지 봅니다. 문단이 화면 밖으로 잘리고 가로 스크롤을 강요하는지, 고정 헤더가 포커스된 항목을 가리는지도 확인합니다.
결과를 수정 가능한 문제로 남기기
‘접근성 나쁨’ 대신 ‘로그인 실패 후 오류 문구가 필드와 연결되지 않아 어떤 입력을 수정할지 알 수 없음’으로 적습니다. 재현 단계, 예상 동작, 실제 동작을 함께 남기면 수정 후 같은 경로로 검증할 수 있습니다.
이 점검은 전체 표준 준수 인증을 대신하지 않습니다. 자동 검사, 키보드 검사, 보조기술 사용을 함께 진행하고 실제 사용자의 어려움을 확인할수록 놓친 문제를 발견할 수 있습니다.