마우스 없이 문의할 수 있나요, 병원 홈페이지의 키보드 이동을 점검합니다
2026-10-26 · 플라톤마케팅 · 약 4분 읽기

마우스로는 문의 버튼을 누를 수 있어도 키보드로는 버튼에 도달하지 못할 수 있습니다. 또는 이동은 되지만 현재 어느 요소가 선택됐는지 보이지 않을 수 있습니다. 키보드 점검에서는 도달, 초점 표시, 실제 조작, 다음 경로로의 이동을 따로 확인해야 합니다. 버튼 하나를 실행해 본 결과로 양식 전체를 판단하지 않습니다.
시작 조건을 정하고 이동 순서를 기록합니다
점검할 페이지 주소, 운영체제, 브라우저를 기록합니다. 마우스 사용 없이 페이지의 처음부터 Tab 키로 이동하고 Shift+Tab으로 되돌아가 봅니다. 브라우저나 운영체제 설정에 따라 이동 가능한 요소가 달라질 수 있으므로 결과와 환경을 함께 남깁니다.
W3C WAI의 기초 점검은 키보드 접근과 보이는 초점을 확인하도록 안내하며, 이런 간단한 검사만으로 전체 접근성을 평가할 수는 없다고 명시합니다. W3C 접근성 기초 점검 여기서의 목적도 인증 판단이 아니라 이용을 막는 구체적인 지점을 찾아 수정 요청을 만드는 것입니다.

도달한 요소가 무엇인지 눈으로 확인합니다
이동할 때 테두리나 다른 표시로 현재 초점을 알아볼 수 있는지 살핍니다. 초점이 있는 버튼이 고정 메뉴나 하단 배너 뒤에 가려지면 조작할 대상을 찾기 어려울 수 있습니다. 화면 위쪽에서 아래쪽으로 갑자기 뛰거나 문맥상 예상하기 어려운 순서로 이동하는지도 기록합니다.
가정으로 문의 흐름이 안내 링크, 입력칸, 선택 항목, 제출 버튼의 4구간으로 이루어졌다고 하겠습니다. 각 구간에서 도달과 위치 식별이라는 2개 항목을 각각 확인하면 기본 기록은 8칸입니다. 이는 누락을 줄이기 위한 검수표 예시이며 통과 비율을 접근성 점수로 사용하지 않습니다. 하나의 필수 버튼에 도달하지 못해도 문의 자체가 막힐 수 있습니다.
선택과 제출을 실제로 실행해 봅니다
초점이 보이는 것과 기능을 실행할 수 있는 것은 다릅니다. 체크박스나 선택 메뉴 등 사용 중인 요소의 일반적인 키 조작으로 선택이 바뀌는지 확인합니다. 모든 요소가 Enter 하나로 같은 동작을 해야 한다고 가정하지 않습니다. 사용자 정의 요소라면 기대되는 키보드 동작을 개발 담당자와 확인합니다.
제출 시험은 운영 문의와 구분되는 점검 환경에서 수행합니다. 필수 항목 오류가 발생한 뒤 오류 설명을 발견하고 해당 칸으로 돌아갈 수 있는지 봅니다. 오류 메시지와 수정 안내까지 연결해서 확인해야 실패 후 재시도 경로를 평가할 수 있습니다.

팝업에 들어간 뒤 나오는 경로도 확인합니다
문의 양식이 팝업으로 열리면 처음 초점이 어디로 가는지, 닫기 조작을 할 수 있는지, 닫은 뒤 어느 위치로 돌아오는지 기록합니다. 팝업이 떠 있는데 배경의 다른 요소를 조작하게 되거나, 닫을 방법 없이 갇히는지 살핍니다. 기대 동작은 사용한 팝업 구조에 맞춰 검토해야 합니다.
문제를 전달할 때 '키보드가 안 됩니다'라고만 적기보다 '문의 버튼에서 실행 후 Tab을 누르면 닫기 버튼을 지나 배경 링크로 이동함'처럼 관찰 순서를 적습니다. 실제 발생한 현상을 기록하고 원인은 개발자가 확인하도록 구분합니다. 시험하지 않은 브라우저에서도 같은 문제라고 확대하지 않습니다.
수정 뒤에는 실패 지점과 그 앞뒤 경로를 다시 실행합니다. 한 버튼의 초점 표시를 고치면서 다른 버튼의 표시가 없어지지 않았는지도 봅니다. 실제 사용자와 보조기술을 포함한 추가 평가는 별도로 계획할 수 있습니다. 출처 확인일: 2026-10-26. 본문의 구간 수와 검수표는 가정이며 전체 접근성 준수 여부를 입증하지 않습니다.

이 글과 이어지는 주제