직접 살펴보는 예제
사이트 식별·주제·검색·문의를 나눈 미디어 헤더
메뉴를 열고 Tab으로 이동한 다음 Escape로 닫아 초점의 위치를 확인하세요.
아래 내용은 구조를 설명하기 위해 만든 예제입니다. 실제 상품·고객 성과 자료가 아닙니다.
닫힘 · aria-expanded=false
헤더의 탐색 우선순위 예제에서 나눈 판단
예제 헤더의 메뉴 버튼은 링크 목록을 열고 닫습니다. 세 링크는 같은 예제 안의 해당 주제 설명으로 이동하고, Escape를 누르면 메뉴가 닫히며 버튼으로 초점이 돌아옵니다. 실제 사이트의 인기 메뉴나 클릭 성과를 측정한 예제는 아닙니다.
헤더를 꾸미기 전에 사용자가 해야 할 네 가지 일을 분리합니다
헤더가 복잡해지는 원인은 메뉴 수만이 아닙니다. 사이트 이름, 카테고리, 검색, 로그인, 장바구니, 문의가 모두 ‘가장 중요한 요소’처럼 같은 색과 크기를 요구할 때 경쟁이 시작됩니다. 이 글의 자체 예제는 미디어형 사이트를 가정하고 역할을 사이트 식별, 주제 탐색, 글 검색, 제작·정정 문의 네 가지로 제한합니다. 각 역할마다 대표 조작을 하나만 정하고, 사용하지 않는 회원 기능이나 판매 기능은 빈 자리를 채우기 위해 추가하지 않습니다. 실제 사이트에서는 사용자 과업과 운영 기능을 다시 조사해 역할표를 새로 만들어야 합니다.
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으로 사용하지 않았는가
모바일 메뉴는 데스크톱 링크를 접는 일이 아니라 우선순위를 다시 표현하는 일입니다
1440픽셀에서 한 줄로 보이는 로고, 세 개 메뉴, 검색, 문의를 390픽셀에 그대로 축소하면 레이블이 잘리거나 터치 대상이 겹칠 수 있습니다. 자체 예제에서는 로고, 검색, 메뉴 열기만 첫 줄에 남기고 세 개 주제와 문의 링크는 메뉴 패널 안에 배치합니다. 문의가 패널 안으로 이동해도 레이블과 목적지는 바꾸지 않습니다. 검색 패널과 내비게이션 패널이 동시에 열리지 않도록 상태 전환을 정의하고, 닫을 때 초점을 패널을 연 버튼으로 되돌립니다. 이 동작은 실제 구현에서 키보드와 스크린리더로 확인해야 합니다.참고: U.S. Web Design System · Header
- 1440픽셀에서 로고부터 문의 링크까지 시각 순서와 DOM 순서를 기록합니다.
- 390픽셀에서 첫 줄에 남을 요소와 메뉴 패널로 이동할 요소를 역할표에 따라 정합니다.
- 메뉴 열기 버튼의 접근 가능한 이름, aria-expanded, aria-controls를 확인합니다.
- 메뉴를 연 뒤 Tab 순서가 패널 안에서 예측 가능하게 이어지고 닫기 조작을 찾을 수 있는지 봅니다.
- 메뉴를 닫은 뒤 초점이 열기 버튼으로 돌아오는지, 숨긴 링크가 계속 초점을 받지 않는지 확인합니다.
- 320픽셀에서 긴 한국어 레이블, 텍스트 확대, 브라우저 기본 글꼴로 다시 점검합니다.
| 상태 | 보이는 요소 | 초점 시작 | 종료 동작 | 기록할 오류 |
|---|---|---|---|---|
| 데스크톱 | 로고·주제·검색·문의 | 건너뛰기 링크 또는 로고 | 본문으로 이동 | 겹침, 과도한 줄바꿈, 현재 위치 누락 |
| 모바일 닫힘 | 로고·검색·메뉴 열기 | 로고 | 메뉴 버튼 | 숨긴 링크 초점, 이름 없는 아이콘 |
| 모바일 열림 | 주제·문의·닫기 | 첫 메뉴 또는 닫기 | 닫기 후 열기 버튼 | 초점 유실, 배경 조작, 스크롤 잠김 |
| 검색 열림 | 검색 입력·제출·닫기 | 검색 입력 | 닫기 후 검색 버튼 | 레이블 없음, 자동 제출, 메뉴와 동시 노출 |
마우스 없이 이동했을 때 현재 위치와 열림 상태를 잃지 않아야 합니다
헤더 검수는 화면 캡처만으로 끝내지 않습니다. 페이지를 새로 연 뒤 마우스를 사용하지 않고 Tab, Shift+Tab, Enter, Space, Escape를 순서대로 사용합니다. 링크는 Enter로 이동하고, 실제 button 요소는 Enter와 Space에서 동작하는지 확인합니다. 검색이나 메뉴가 열릴 때 초점이 어디로 이동하는지, 닫을 때 어디로 돌아오는지 기록합니다. hover 색만 있고 focus 표시가 없으면 마우스 사용자에게만 상태가 전달되므로 통과로 보지 않습니다. 자동으로 메뉴가 열리거나 초점만 받았는데 페이지가 이동하는 동작도 피합니다.참고: U.S. Web Design System · Header
USWDS 헤더 예시는 접근성 검사를 프로젝트 안에서 다시 수행하라고 명시합니다. 구성요소가 공식 예시를 닮았다는 사실은 현재 사이트의 CSS, 자바스크립트, 플러그인 충돌까지 검증했다는 뜻이 아닙니다. 따라서 검수 기록에는 브라우저, viewport, 확대율, 조작 키, 예상 상태, 실제 상태를 함께 남깁니다. 스크린리더 확인을 하지 않았다면 ‘키보드 검사 완료’라고만 쓰고 보조기술 전체 검사를 마친 것처럼 표현하지 않습니다.참고: U.S. Web Design System · Header · W3C Web Accessibility Initiative · Navigation Landmark Example
| 조작 | 예상 결과 | 실패 예 | 수정 확인 |
|---|---|---|---|
| Tab | 보이는 순서대로 초점 이동 | 숨은 메뉴로 초점 이동 | display·hidden·inert 상태 대조 |
| Enter | 링크 이동 또는 버튼 실행 | 아이콘에 반응 없음 | 시맨틱 요소와 이벤트 확인 |
| Space | 버튼 실행, 페이지 불필요 스크롤 없음 | 가짜 div 버튼 | button 요소와 type 확인 |
| Escape | 열린 패널 닫기 | 초점이 body로 사라짐 | 열기 버튼으로 반환 |
| Shift+Tab | 역순 이동 가능 | 패널 안에 초점 갇힘 | 처음·마지막 경계 확인 |
현재 위치, 링크 도착점, 메뉴 상태를 별도의 검수 열로 기록합니다
헤더의 ‘정상 작동’을 한 칸으로 기록하면 현재 위치 표시와 링크 이동, 패널 제어가 섞입니다. 자체 검수표에서는 메뉴별 href와 도착 H1, 현재 페이지 aria-current, 데스크톱 노출, 모바일 패널 노출, 키보드 초점, 404 여부를 각각 기록합니다. 예를 들어 ‘웹디자인’ 링크가 올바른 페이지로 이동해도 마케팅 페이지에서 aria-current가 잘못 남아 있으면 링크 검사는 통과하고 상태 검사는 실패입니다. 검색 버튼이 패널을 열어도 닫기 후 초점이 사라지면 동작 검사는 부분 실패로 남깁니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.4: Link Purpose (In Context) · W3C Web Accessibility Initiative · Navigation Landmark Example
| 검수 열 | 수집값 | 통과 기준 | 판정하지 않는 것 |
|---|---|---|---|
| 도착점 | href·최종 URL·H1 | 레이블과 목적 일치 | 방문자가 좋아할지 여부 |
| 현재 위치 | aria-current·시각 표시 | 현재 항목 하나만 표시 | 브랜드 신뢰 상승 |
| 반응형 | 노출 요소·줄바꿈·가로 폭 | 정보 손실 없이 재배치 | 모든 기기 대표 |
| 키보드 | 초점 순서·열림·닫힘 | 조작 가능하고 상태 인지 | 모든 보조기술 적합 |
| 성능 | 레이아웃 이동 관찰 | 헤더가 본문을 반복해서 밀지 않음 | 검색 순위 효과 |
검수 결과는 ‘깔끔해졌다’보다 관찰 가능한 문장으로 씁니다. ‘390×844에서 로고 112픽셀, 검색 버튼과 메뉴 버튼이 한 줄에 있고 가로 스크롤 없음’, ‘메뉴 닫힘 상태에서 숨은 링크는 Tab 순서에 없음’, ‘문의 링크의 최종 URL과 도착 H1이 일치’처럼 조건과 결과를 남깁니다. 실제 사용자가 더 빨리 찾았는지, 문의가 늘었는지, 이탈이 줄었는지는 별도 연구가 없으므로 기록하지 않습니다. 수정 전후 캡처도 성과 증거가 아니라 배치와 상태를 재현하기 위한 자료로만 사용합니다.
헤더 공개 전에는 역할, 목적, 반응형, 조작 가능성을 차례로 닫습니다
공개 판정은 네 문장으로 요약할 수 있습니다. 각 요소의 역할이 하나로 정의되어 있는가, 메뉴 레이블과 도착 내용이 일치하는가, 화면 폭이 줄어도 핵심 기능이 사라지지 않는가, 키보드로 열고 이동하고 닫을 수 있는가입니다. 이 네 가지를 모두 확인한 뒤에도 실제 사용자 과업 성공이나 사업 성과는 미확인으로 남습니다. 반대로 하나라도 실패하면 색과 그림자 조정으로 덮지 않고 기능 정의나 DOM 구조부터 수정합니다.참고: U.S. Web Design System · Header · W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.4: Link Purpose (In Context) · W3C Web Accessibility Initiative · Navigation Landmark Example
- 사이트 식별, 주제 탐색, 검색, 문의, 모바일 메뉴의 역할과 HTML 요소를 적습니다.
- 모든 메뉴 레이블을 도착 URL과 H1에 대조하고 모호한 내부 용어를 줄입니다.
- 1440·390·320픽셀에서 시각 순서, DOM 순서, 줄바꿈, 가로 넘침을 기록합니다.
- 메뉴와 검색의 닫힘·열림 조합을 만들고 동시에 열리는 충돌을 확인합니다.
- Tab·Shift+Tab·Enter·Space·Escape로 전체 경로를 재현합니다.
- 확인하지 않은 클릭률, 전환, 사용자 만족을 결과에 추가하지 않습니다.
헤더의 탐색 우선순위을 확인한 순서
- 사이트 표시와 세 주제 링크를 구분하고 각 예제 설명으로 이동하는지 확인합니다.
- 열기·닫기에서 목록과 aria-expanded를 대조하고 Escape 후 초점 복귀를 봅니다.
- 검색·문의는 본문의 확장 설계안입니다. 위 메뉴 예제에서 검색 서비스나 문의 전송을 실행했다고 기록하지 않습니다.
헤더의 탐색 우선순위 판단에서 제외한 범위
- 자체 헤더 예제는 실제 고객, 운영 데이터, 클릭률, 문의 전환 또는 사용자 테스트 결과를 포함하지 않습니다.
- USWDS 구성은 미국 연방정부 사이트 맥락의 예시이므로 모든 브랜드와 서비스에 같은 메뉴 수나 배치를 요구하지 않습니다.
- 키보드 검수는 중요한 확인 단계이지만 여러 스크린리더·브라우저 조합의 전체 접근성 시험을 대신하지 않습니다.
- 320·390·1440픽셀 검사는 선택한 viewport 조건만 다루며 모든 기기, 글꼴 확대, 번역 길이를 대표하지 않습니다.
- 정보 위계와 링크 목적이 분명해도 실제 사용자의 탐색 성공이나 사업 성과는 별도 연구 없이는 판단할 수 없습니다.
헤더의 탐색 우선순위에 사용한 원문
원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.
- 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
메뉴 링크의 목적을 텍스트 또는 허용된 문맥에서 파악할 수 있어야 한다는 기준을 레이블·도착 페이지 대조에 사용했습니다.
이 페이지에서 실제 작동하는 범위
위의 작동 예제는 메뉴 열기·닫기, 세 주제의 예제 내부 이동과 Escape 초점 복귀를 다룹니다. 본문의 검색 패널·문의 페이지·현재 카테고리 표시는 확장 설계안의 역할과 검수 방법이며, 작동 예제에 검색 서비스나 문의 전송이 구현됐다는 뜻이 아닙니다. 설계표에 적은 상태는 실제 구현 뒤 별도 확인해야 하고 여기서 시험하지 않은 상태를 통과로 기록하지 않습니다.