진입과 도착
상단 버튼의 이름과 열림 상태를 확인합니다. 문의 링크가 실제 목적지로 가는지와 현재 페이지의 앵커 이동인지 구분합니다. 가정한 예로 연락 버튼이 메뉴 아래에 숨으면 방문자는 기본 메뉴를 열어도 다음 행동을 찾지 못할 수 있습니다.
가정한 경로 시험
아래는 실제 모바일 검수에 사용할 수 있는 시나리오 예시입니다. 모든 브라우저의 적합성을 보장하는 체크리스트는 아닙니다.
entry: narrow viewport at page top and after scrolling
open_menu: visible state and accessible button state agree
choose_inquiry: one navigation to intended destination
after_navigation: overlay closed, body scroll restored
cancel_path: close button and supported keyboard behavior work
focus_path: returns or moves to a logical position
repeat: opening again does not retain stale lock or selection
배경과 스크롤
메뉴 뒤 콘텐츠가 조작 가능한지 정책과 실제 구현을 맞춥니다. 메뉴를 닫았는데 body 잠금이 남거나 원래 스크롤 위치를 잃는지 봅니다. 화면 회전과 크기 변경에서 모바일 메뉴가 데스크톱 메뉴와 동시에 겹치지 않는지도 확인합니다.
검수 순서
- 서로 다른 좁은 폭에서 열고 닫습니다.
- 터치와 키보드로 문의 링크를 선택합니다.
- 이동 후 스크롤·초점·오버레이를 확인합니다.
- 뒤로 가기·회전·재열기를 시험합니다.
메뉴 애니메이션 중 빠르게 누를 때 이벤트가 중복되거나 닫기 동작이 무시되는지 봅니다. 링크를 장식 요소의 클릭 핸들러만으로 구현하지 않고 의미와 기본 탐색을 고려합니다. 측정 이벤트 성공은 실제 이동의 성공과 별도입니다.
완료 기준
방문자가 메뉴를 통해 문의와 핵심 자료에 도달하고 취소 후에도 페이지를 사용할 수 있어야 합니다. 확인한 폭·기기·경로와 미확인 범위를 기록합니다. 자동 화면 검사와 실제 조작 검수를 조합하고 예전 메뉴의 오류가 다른 프로젝트 수정으로 해결돼야 한다고 범위를 확대하지 않습니다.
자주 묻는 질문
- 메뉴가 보이면 모바일 내비게이션은 정상인가요?
- 링크 이동과 닫기, 배경 조작과 도착 뒤 상태까지 확인해야 합니다. 열린 화면의 캡처만으로 실제 문의 경로를 검수할 수 없습니다.
- 모바일 메뉴는 항상 모달로 만들어야 하나요?
- 실제 상호작용 구조에 맞게 설계합니다. 모달이라고 표시한다면 배경 차단과 초점 등 그 동작이 실제로 맞아야 하며 단순 펼침 메뉴와 구분합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.