같은 링크라도 헤더에서 맡는 일은 다릅니다
자료를 찾는 사람이 많은 사이트와 제작 문의를 받는 사이트는 헤더에서 먼저 보여줄 행동이 다릅니다. 두 경우의 링크 수를 똑같이 맞추기보다 방문 목적을 적고 첫 줄의 자리를 배정합니다.
| 조건 | 첫 줄에 남길 것 | 다른 곳으로 옮길 것 |
|---|---|---|
| 글을 찾는 방문이 중심 | 사이트 이름 · 주제 · 검색 | 제작 문의는 구분되는 보조 링크 |
| 제작 조건을 확인한 뒤 문의 | 사이트 이름 · 작업 범위 · 문의 | 세부 자료 목록은 본문과 별도 탐색 |
| 작은 화면 | 사이트 이름 · 검색 · 메뉴 열기 | 주제와 문의를 이름 있는 패널 안에 배치 |
이 표는 배치 선택을 위한 설명용 설계안입니다. 메뉴의 열기·닫기와 초점 복귀 구현은 모바일 메뉴 예제에서 따로 다룹니다.
헤더를 꾸미기 전에 사용자가 해야 할 네 가지 일을 분리합니다
헤더가 복잡해지는 원인은 메뉴 수만이 아닙니다. 사이트 이름, 카테고리, 검색, 로그인, 장바구니, 문의가 모두 ‘가장 중요한 요소’처럼 같은 색과 크기를 요구할 때 경쟁이 시작됩니다. 이 글의 자체 예제는 미디어형 사이트를 가정하고 역할을 사이트 식별, 주제 탐색, 글 검색, 제작·정정 문의 네 가지로 제한합니다. 각 역할마다 대표 조작을 하나만 정하고, 사용하지 않는 회원 기능이나 판매 기능은 빈 자리를 채우기 위해 추가하지 않습니다. 실제 사이트에서는 사용자 과업과 운영 기능을 다시 조사해 역할표를 새로 만들어야 합니다.
USWDS는 헤더가 사용자가 현재 위치를 식별하고 사이트의 주요 영역으로 빠르게 이동하도록 돕는다고 설명합니다. 또한 중요한 섹션을 내비게이션 링크로 제공하고 링크 레이블은 짧고 명확하며 낯선 전문용어를 피하라고 안내합니다. 이 기준은 문의 버튼을 무조건 강조하거나 모든 페이지를 가로 메뉴에 넣으라는 뜻이 아닙니다. 어떤 역할이 헤더에 남아야 하는지, 어떤 링크가 하위 페이지나 푸터로 이동해야 하는지를 판정하는 출발점으로 사용합니다.참고: U.S. Web Design System · Header
같은 줄에 있어도 요소마다 시각적 무게와 실패 조건은 달라야 합니다
자체 예제에서는 로고를 홈으로 돌아가는 식별 링크, 세 개의 주제 링크를 주요 내비게이션, 검색 아이콘을 검색 패널을 여는 버튼, 문의를 별도 페이지로 이동하는 링크로 정의합니다. 여기서 검색은 현재 페이지 안의 내용을 즉시 찾는 기능이 아니라 사이트 글 목록을 조회하는 기능이고, 문의는 양식을 제출하는 동작이 아니라 문의 페이지로 이동하는 링크입니다. 기능 정의가 다르면 HTML 요소와 키보드 동작도 달라집니다. 링크를 버튼처럼 꾸밀 수는 있지만 목적지가 다른 페이지라면 링크의 의미를 유지합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.4: Link Purpose (In Context)
| 요소 | 주요 역할 | 예제 표현 | 실패 조건 |
|---|---|---|---|
| 사이트 식별 | 현재 사이트 확인과 홈 이동 | 텍스트 로고 + 홈 링크 | 페이지마다 다른 이름 또는 잘못된 홈 주소 |
| 주요 메뉴 | 핵심 주제 이동 | 상세페이지·웹디자인·마케팅 | 내부 용어, 지나치게 긴 레이블, 중복 목적 |
| 검색 | 검색 인터페이스 열기 | 검색 열기 버튼 | 레이블 없음, 초점 이동 불명확, 닫기 불가 |
| 문의 | 문의 안내 페이지 이동 | 제작·정정 문의 링크 | 클릭 뒤 목적이 다른 홈이나 빈 양식 |
| 모바일 메뉴 | 접힌 내비게이션 열기 | 메뉴 열기·닫기 버튼 | 상태 전달 없음 또는 배경 링크 조작 가능 |
시각적 무게는 역할표 이후에 정합니다. 현재 페이지의 카테고리 링크는 aria-current와 색 또는 밑줄로 구분하고, 문의 링크는 주요 메뉴보다 눈에 띄더라도 로고와 메뉴 전체를 가리지 않는 크기로 둡니다. 검색은 아이콘만 쓸 경우 접근 가능한 이름을 제공하고, 같은 화면에서 검색과 메뉴 아이콘이 형태만으로 혼동되지 않는지 확인합니다. ‘모두 중요하다’는 결론이 나오면 요소를 더 강조하는 대신 헤더 밖으로 옮길 기능을 찾습니다. 이 과정은 취향 투표가 아니라 역할 중복을 줄이는 편집 작업입니다.참고: U.S. Web Design System · Header
메뉴 이름은 조직의 분류표가 아니라 도착할 내용의 목적을 설명해야 합니다
메뉴 레이블을 정할 때 팀명, 상품 코드, 캠페인 이름처럼 내부에서만 익숙한 단어를 그대로 쓰지 않습니다. 링크만 따로 읽어도 목적을 예상할 수 있는지, 도착 페이지의 H1과 의미가 일치하는지 확인합니다. W3C의 링크 목적 해설은 링크의 목적이 링크 텍스트 자체 또는 허용된 문맥에서 파악될 수 있어야 한다는 기준을 설명합니다. 모든 링크를 길게 만들라는 뜻은 아니며, 짧은 단어가 실제 도착 내용을 충분히 가리키는지가 핵심입니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.4: Link Purpose (In Context)
내비게이션 랜드마크가 페이지에 여러 개라면 레이블도 점검합니다. W3C 예시는 서로 다른 링크 집합을 가진 navigation 영역에는 구분 가능한 레이블을 제공하고, 동일한 링크 집합이면 같은 레이블을 사용하라고 설명합니다. 예를 들어 헤더 주제 메뉴와 글 안의 목차는 다른 목적이므로 ‘주요 메뉴’와 ‘이 글의 목차’처럼 구분합니다. 데스크톱 메뉴와 모바일 메뉴가 같은 링크 집합의 대체 표현이라면 두 버전이 동시에 접근성 트리에 노출되지 않게 상태를 확인하고, 이름도 불필요하게 다르게 만들지 않습니다.참고: W3C Web Accessibility Initiative · Navigation Landmark Example
- 링크 텍스트만 읽었을 때 도착 주제를 예상할 수 있는가
- 도착 페이지 H1과 메뉴 레이블이 서로 다른 약속을 하지 않는가
- 현재 페이지 상태가 색 하나에만 의존하지 않는가
- 헤더 메뉴와 본문 목차의 접근 가능한 이름을 구분했는가
- 숨겨진 데스크톱 또는 모바일 메뉴가 중복해서 읽히지 않는가
- 로고를 페이지마다 반복되는 H1으로 사용하지 않았는가
헤더의 탐색 우선순위에 사용한 원문
원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.
- HeaderU.S. Web Design System · 확인 2026-08-20
헤더의 역할, 주요 섹션 링크, 짧고 명확한 레이블, 반응형 구성과 프로젝트별 접근성 재검수 지침을 참고했습니다.
- Understanding Success Criterion 2.4.4: Link Purpose (In Context)W3C Web Accessibility Initiative · 확인 2026-08-20
메뉴 링크의 목적을 텍스트 또는 허용된 문맥에서 파악할 수 있어야 한다는 기준을 레이블·도착 페이지 대조에 사용했습니다.