모바일 메뉴를 과업 순서와 펼침 상태로 다시 설계하는 법

모바일 메뉴의 첫 질문은 어떻게 접을지가 아니라 무엇을 먼저 찾게 할지입니다

데스크톱 헤더의 로고, 여섯 개 메뉴, 검색, 언어 선택, 문의 버튼을 같은 순서로 세로 목록에 넣으면 구현은 빠르지만 모바일에서 링크가 길어지고 역할이 섞일 수 있습니다. 화면 폭이 줄어든 만큼 방문자가 자주 수행하는 과업과 콘텐츠 탐색, 운영 문서를 다시 구분해야 합니다. 이 글은 어떤 순서가 클릭을 늘린다고 주장하지 않고, 메뉴 항목의 목적·그룹·현재 위치·열림 상태·조작 경로가 분명한지 확인합니다.참고: U.S. Web Design System · Header

USWDS 헤더 지침은 짧고 명확한 링크 이름을 쓰고 조직 구조보다 사용자가 자주 찾는 과업과 정보에 맞춰 내비게이션을 구성하며 우선순위를 반영하라고 안내합니다. W3C의 Consistent Navigation 기준은 여러 페이지에 반복되는 내비게이션이 같은 상대 순서로 제공되어 예측 가능해야 한다고 설명합니다. 이 두 기준을 모바일 메뉴의 링크 목록을 만드는 출발점으로 삼되, 실제 우선순위는 사이트의 콘텐츠와 사용자 조사로 별도 확인해야 합니다.참고: U.S. Web Design System · Header · W3C Web Accessibility Initiative · Understanding Success Criterion 3.2.3: Consistent Navigation

모든 링크를 과업·콘텐츠·운영 정보로 분류하고 중복을 제거합니다

자체 예제는 실제 서비스와 무관한 ‘Public Notes 자료실’입니다. 데스크톱 헤더에는 홈, 최신 글, 세 개 주제, 소개, 작성 원칙, 광고 고지, 개인정보, 문의, 검색이 있다고 가정합니다. 모바일에서는 ‘최신 글 보기’와 ‘검색’을 주요 과업으로, 세 주제를 콘텐츠 탐색으로, 소개·원칙·고지·개인정보를 운영 문서로 묶습니다. 문의는 별도 행동으로 두되 같은 링크를 상단과 하단에 이유 없이 두 번 넣지 않습니다.

분류표를 만들 때 링크 이름이 같은데 도착지가 다르거나, 이름은 다른데 같은 페이지로 가는 항목을 찾습니다. ‘정보’, ‘서비스’, ‘더보기’처럼 범위가 넓은 이름은 실제 도착 H1과 비교해 구체화합니다. 링크를 삭제하기 전에 푸터, 사이트맵, 검색 같은 다른 탐색 수단이 남는지도 확인합니다. 메뉴가 짧아졌다는 이유만으로 접근 경로 자체를 없애지 않습니다.참고: U.S. Web Design System · Header

일반 사이트 내비게이션은 복잡한 앱 메뉴보다 disclosure 버튼과 링크 목록으로 시작합니다

W3C ARIA Authoring Practices의 disclosure 패턴은 버튼이 콘텐츠를 펼치고 접으며 `aria-expanded`로 상태를 전달하고, 필요하면 `aria-controls`로 제어 대상을 가리키는 방식을 설명합니다. 별도의 disclosure navigation 예제는 일반적인 사이트 링크 모음에 복잡한 `menu` 역할을 사용하지 않습니다. `menu`와 `menubar`는 데스크톱 애플리케이션과 유사한 키보드 상호작용을 기대하게 하므로, 단순한 페이지 링크 목록에는 native `nav`, 목록, 링크, 버튼을 우선하는 편이 구현과 검수 범위를 분명하게 합니다.참고: W3C Web Accessibility Initiative · Disclosure (Show/Hide) Pattern · W3C Web Accessibility Initiative · Example Disclosure Navigation Menu

APG 예제는 그대로 복사해 생산 환경에 넣는 코드가 아니라 브라우저와 보조기술 조합에서 직접 시험해야 하는 예시임을 경고합니다. 따라서 이 글의 구조도 구현 전 체크리스트일 뿐입니다. 버튼 이름은 닫힌 상태에서 ‘메뉴 열기’, 열린 상태에서 ‘메뉴 닫기’처럼 행동을 설명하고, 상태와 보이는 패널이 항상 일치하는지 DOM과 화면을 함께 검사합니다.참고: W3C Web Accessibility Initiative · Example Disclosure Navigation Menu

열기·탐색·닫기·복귀 네 동작을 키보드와 터치에서 각각 확인합니다

메뉴는 열린 화면 한 장만 보고 검수할 수 없습니다. 닫힌 상태에서 숨은 링크가 Tab 순서에 없는지, 열기 버튼을 Enter와 Space로 작동할 수 있는지, 열린 뒤 링크 순서가 시각적 목록과 맞는지, Escape 또는 닫기 버튼으로 종료할 수 있는지, 종료 후 초점이 열기 버튼으로 돌아오는지를 확인합니다. W3C disclosure navigation 예제는 Tab 이동, Enter·Space 활성화, Escape로 닫기와 초점 복귀 같은 동작을 설명합니다.참고: W3C Web Accessibility Initiative · Disclosure (Show/Hide) Pattern · W3C Web Accessibility Initiative · Example Disclosure Navigation Menu

1. 페이지를 새로 열고 키보드 Tab으로 열기 버튼에 도달하며 초점 표시를 확인합니다.
2. Enter로 메뉴를 열어 `aria-expanded=true`, 패널 표시, 배경 상태가 동시에 바뀌는지 봅니다.
3. Tab과 Shift+Tab으로 링크를 왕복하며 숨은 요소나 예상 밖의 초점 이동을 기록합니다.
4. 현재 페이지 링크의 레이블과 aria-current 상태가 실제 URL·H1과 맞는지 확인합니다.
5. Escape와 닫기 버튼을 각각 시험해 메뉴가 닫히고 초점이 열기 버튼으로 돌아오는지 봅니다.
6. 터치로 바깥 영역을 눌러 닫는 기능이 있다면 명시적 닫기 버튼 없이도 의존하지 않는지 확인합니다.

초점을 메뉴 안에 가둘지는 메뉴가 전체 화면 dialog처럼 구현되는지에 따라 달라집니다. 단순 disclosure라면 자연스러운 문서 Tab 순서를 유지할 수 있고, 모달처럼 배경을 비활성화한다면 적절한 dialog 패턴과 초점 관리가 추가로 필요합니다. 두 방식을 섞어 시각적으로만 전체 화면인데 배경 링크가 계속 눌리는 상태를 만들지 않습니다. 이 글은 한 방식을 보편 정답으로 정하지 않고 선택한 패턴의 상태와 동작이 일관되는지를 봅니다.참고: W3C Web Accessibility Initiative · Example Disclosure Navigation Menu

링크 높이와 간격, 내부 스크롤, 고정 버튼의 가림을 함께 점검합니다

WCAG 2.2 Target Size (Minimum) 해설은 포인터 입력 대상이 원칙적으로 최소 24×24 CSS 픽셀이거나 정해진 예외를 충족하도록 설명합니다. 모바일 메뉴의 주요 링크와 닫기 버튼은 작은 인라인 링크 예외에 기대기보다 실제 조작 영역 안에 24×24 사각형이 들어가는지 먼저 측정합니다. 아이콘 그림의 크기가 아니라 클릭 가능한 요소의 bounding box를 보고, 서로 가까운 작은 대상은 간격 조건도 확인합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.5.8: Target Size (Minimum)

메뉴를 열 때 본문 스크롤을 막는다면 닫을 때 원래 스크롤 위치가 유지되는지 확인합니다. 주소창 높이 변화와 화면 회전으로 viewport 높이가 줄어도 닫기 버튼과 마지막 링크를 사용할 수 있어야 합니다. 메뉴 안에 자체 스크롤을 두는 경우 스크롤 가능한 영역이 시각적으로 구분되고 키보드·터치 모두 접근 가능한지 봅니다. 링크 수를 줄이지 못한 채 글자 크기만 줄여 한 화면에 맞추지 않습니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.5.8: Target Size (Minimum) · U.S. Web Design System · Header

페이지마다 메뉴 순서와 이름이 달라지지 않도록 공통 원본에서 생성합니다

홈에서는 ‘자료’, 글에서는 ‘아카이브’, 정책 페이지에서는 ‘콘텐츠’처럼 같은 링크의 이름이 달라지면 반복 탐색이 어려워집니다. W3C Consistent Navigation 기준은 반복 내비게이션이 같은 상대 순서로 나타나도록 요구합니다. 현재 위치 표시나 사용자가 직접 바꾼 정렬처럼 합리적인 상태 차이는 있을 수 있지만, 템플릿을 복사하다 생긴 순서 차이는 제거해야 합니다. 공통 데이터나 템플릿에서 메뉴를 생성하고 페이지별로 링크를 손으로 복사하지 않는 방식이 유지보수에 유리합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 3.2.3: Consistent Navigation

• 홈·카테고리·글·소개·문의·정책·검색·404에서 메뉴 항목과 순서가 같은가
• 현재 페이지 링크만 상태가 달라지고 이름과 도착지는 유지되는가
• 로그인 여부처럼 실제 조건이 없다면 임의의 페이지별 메뉴를 만들지 않았는가
• 모바일과 데스크톱에서 시각 순서는 달라도 핵심 과업과 경로가 누락되지 않는가
• 메뉴 링크와 HTML 사이트맵, 푸터의 주요 경로가 서로 모순되지 않는가
• 새 페이지를 추가할 때 공통 원본과 공개 QA 목록이 함께 갱신되는가

일관성은 모든 링크를 같은 위치에 강제로 넣는 것이 아닙니다. 데스크톱에서는 가로 목록, 모바일에서는 그룹형 disclosure를 쓸 수 있지만 같은 링크가 무엇을 뜻하고 어디로 가는지는 유지되어야 합니다. 모바일에서 덜 중요한 정책 링크를 접힌 그룹으로 옮기더라도 키보드와 검색, 사이트맵으로 접근할 수 있어야 합니다. 실제 사용자의 우선순위는 분석이나 사용자 조사로 확인하기 전까지 가설로 남깁니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 3.2.3: Consistent Navigation · U.S. Web Design System · Header

스크립트 지연과 실패 상태에서도 홈과 핵심 경로가 완전히 사라지지 않게 합니다

모바일 메뉴가 JavaScript로만 만들어지고 스크립트가 늦게 오거나 실패하면 모든 내비게이션이 사라질 수 있습니다. 서버 HTML에 기본 링크 목록을 두고 스크립트가 로드된 뒤 접는 점진적 향상 방식을 고려하거나, 최소한 로고 홈 링크와 본문·푸터 탐색을 남깁니다. 로딩 전 메뉴가 잠깐 펼쳐지는 현상을 숨기려고 HTML 전체를 보이지 않게 만들지 않습니다. 실패 상태는 네트워크 차단, JavaScript 오류, 느린 로드에서 별도로 확인합니다.참고: U.S. Web Design System · Header

스크립트 실패 시험에서 메뉴 애니메이션이 없다는 사실은 오류가 아닙니다. 사용자가 사이트 정체를 확인하고 홈이나 핵심 콘텐츠로 이동할 수 있는지가 우선입니다. 페이지에 따라 빌드 파일 경로가 달라 하위 경로에서만 메뉴가 작동하지 않는 문제도 확인합니다. 절대·상대 URL 규칙을 통일하고, 배포된 각 표면의 실제 href와 상태 코드를 검사해야 합니다.

공개 전에는 링크 구조와 상호작용을 분리한 검수 행렬을 완성합니다

최종 검수 행렬은 링크 내용, 상태, 키보드, 포인터, 화면 폭, 실패 상태를 별도 열로 둡니다. ‘모바일 메뉴 정상’ 한 줄로 끝내지 않고 320×568 세로, 844×390 가로, 390×844 세로, 200퍼센트 확대에서 열기·닫기·마지막 링크 접근을 기록합니다. 각 페이지 유형에서 항목 순서와 도착 H1을 확인하고, 실제 사용자 과업 연구를 하지 않았다면 우선순위가 검증되었다고 표시하지 않습니다.참고: W3C Web Accessibility Initiative · Disclosure (Show/Hide) Pattern · W3C Web Accessibility Initiative · Understanding Success Criterion 2.5.8: Target Size (Minimum) · W3C Web Accessibility Initiative · Understanding Success Criterion 3.2.3: Consistent Navigation

1. 전체 공개 링크를 과업·콘텐츠·운영 문서로 분류하고 중복 이름과 중복 도착지를 제거합니다.
2. native button, 이름 있는 nav, 목록과 링크로 구조를 만들고 펼침 상태와 제어 대상을 연결합니다.
3. Enter·Space·Tab·Shift+Tab·Escape와 터치로 열기·탐색·닫기·초점 복귀를 검사합니다.
4. 주요 대상의 실제 크기와 간격, 짧은 화면의 내부 스크롤, 고정 요소의 가림을 측정합니다.
5. 홈·글·정책·문의·검색·404에서 메뉴 항목·순서·현재 위치·도착 제목을 비교합니다.
6. JavaScript 차단과 오류 상태에서도 홈·본문·대체 탐색이 남는지 확인하고 미실행 항목은 예정으로 표시합니다.

모바일 메뉴의 과업 순서을 확인한 순서

1. 닫힌 메뉴에서 숨은 링크가 Tab 초점을 받지 않는지 봅니다.
2. 메뉴를 열어 세 주제 링크를 왕복합니다. 목록과 초점 순서·aria-expanded=true가 같은 상태를 나타내야 합니다.
3. Escape로 닫아 열기 버튼에 초점이 돌아오는지 확인합니다. 짧은 화면에서도 닫기와 마지막 항목을 사용할 수 있어야 합니다.

모바일 메뉴의 과업 순서 판단에서 제외한 범위

• Public Notes는 내비게이션 구조를 설명하기 위한 가상 자료실이며 실제 방문자, 분석 데이터 또는 메뉴 성과와 관련이 없습니다.
• ARIA Authoring Practices 예제는 생산 환경의 완전한 호환성을 보장하지 않으므로 실제 브라우저와 보조기술 검사가 필요합니다.
• 24×24 CSS 픽셀은 최소 기준과 예외를 포함하며 모든 사용자의 편안한 조작을 보장하는 목표 크기는 아닙니다.
• 정한 화면 폭과 키보드 시험은 모든 기기, 브라우저, 터치 보조기술과 사용자 설정을 대표하지 않습니다.
• 메뉴 링크의 우선순위는 사이트별 사용자 조사나 분석 없이 확정할 수 없으며 이 글의 분류는 자체 예제입니다.

모바일 메뉴의 과업 순서에 사용한 원문

원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.

1. Disclosure (Show/Hide) PatternW3C Web Accessibility Initiative · 확인 2026-08-20

   버튼, aria-expanded와 선택적 aria-controls를 이용한 펼침·접힘 상태 구조를 참고했습니다.

2. Example Disclosure Navigation MenuW3C Web Accessibility Initiative · 확인 2026-08-20

   일반 사이트 내비게이션에서 복잡한 menu 역할 대신 disclosure와 링크 목록을 사용하는 예, 키보드·Escape 동작 및 실제 환경 테스트 주의를 참고했습니다.

3. HeaderU.S. Web Design System · 확인 2026-08-20

   짧은 링크 이름, 사용자 과업 중심 우선순위, 현재 구역, 키보드와 터치 내비게이션 검수 지침을 사용했습니다.

4. Understanding Success Criterion 2.5.8: Target Size (Minimum)W3C Web Accessibility Initiative · 확인 2026-08-20

   포인터 대상의 24×24 CSS 픽셀 최소 크기와 간격 예외를 메뉴 조작 영역 검수에 적용했습니다.

5. Understanding Success Criterion 3.2.3: Consistent NavigationW3C Web Accessibility Initiative · 확인 2026-08-20

   여러 페이지에 반복되는 내비게이션을 같은 상대 순서로 제공하는 기준을 페이지 간 비교에 사용했습니다.