헤더(Header) — 공공웹이 자주 틀리는 지점

공공 사이트에 들어가면 가장 먼저, 그리고 가장 자주 보는 영역이 어디일까요. 화려한 메인 비주얼? 아닙니다. 화면 맨 위, 로고와 메뉴와 검색이 모여 있는 그 가로 띠 — 헤더(Header)입니다. 우리는 헤더를 "당연히 거기 있는 것"으로 여기고 잘 의식하지 않습니다. 그런데 어느 공공 사이트에서 메뉴를 찾느라 마우스를 위로 한참 헤매 본 적, 한 번쯤 있으실 겁니다. 분명 메뉴가 있긴 한데 어디 있는지 모르겠고, 검색창은 또 어디 숨었는지 안 보이고, 로고를 눌렀더니 엉뚱한 페이지로 가거나 아예 아무 일도 안 일어나고. 그 짧은 짜증의 진원지가 거의 다 헤더입니다.

이 글은 "KRDS 완전해부" 시리즈 중 헤더 편이고, 다른 글과 달리 공공웹이 헤더에서 가장 많이 틀리는 지점을 중심으로 풀어 보려 합니다. 기준을 차근차근 설명하는 글은 따로 있지만, 헤더만큼은 "어디서 자주 망가지는가"를 먼저 보는 게 훨씬 도움이 됩니다. 왜냐하면 헤더는 사이트를 통째로 새로 만들지 않는 한 한 번 잘못 설계되면 모든 페이지에서 똑같이 잘못되기 때문입니다. 푸터 하나, 카드 하나는 페이지마다 다를 수 있어도, 헤더는 거의 항상 전 페이지 공통입니다. 그래서 헤더의 실수는 "한 군데 실수"가 아니라 "사이트 전체의 실수"가 됩니다.

수백 개 공공 사이트를 분석하다 보면, 헤더에서 똑같은 실수가 지겨울 만큼 반복되는 걸 봅니다. 로고에 링크가 없고, 메뉴를 키보드로 못 펼치고, "본문 바로가기"가 없어서 스크린리더 사용자가 매 페이지 메뉴를 처음부터 다 들어야 하고, 모바일 햄버거 버튼에 이름이 없어서 그냥 "버튼"으로만 읽히고. 하나하나 보면 사소해 보이는데, 모이면 사이트의 첫인상 전체를 망칩니다. 이 글을 다 읽고 나면, 앞으로 어떤 공공 사이트를 들어가든 헤더만 봐도 "아, 이 사이트는 신경 써서 만들었구나" 또는 "여긴 위험하겠다"가 바로 보이실 겁니다.

미리 하나만 짚어 두면, 헤더의 실수는 대부분 "기술이 어려워서"가 아니라 "당연하다고 생각하고 안 챙겨서" 생깁니다. 로고에 링크 거는 건 어렵지 않습니다. 그냥 아무도 안 챙길 뿐이죠. 그래서 더 안타깝습니다. 조금만 신경 쓰면 안 생길 문제들이거든요.

헤더가 대체 뭘 담는 영역인가 — 정의부터

본격적으로 실수를 보기 전에, 헤더가 무엇을 담는 영역인지부터 맞추겠습니다. "맨 위 띠"라고만 알고 있으면 무엇이 빠졌는지 알아챌 수 없으니까요.

KRDS(대한민국 정부 디자인 시스템)에서 헤더는 단순한 장식 띠가 아니라, 사이트의 정체성과 주요 탐색을 책임지는 핵심 컴포넌트입니다. 헤더가 통상 담는 요소를 나열하면 이렇습니다.

• 로고 / 기관명: 이 사이트가 어디인지 알리는 정체성. 거의 항상 메인 페이지로 가는 링크 역할을 겸합니다.
• 주 메뉴(Global Navigation, GNB): 사이트의 큰 분류로 이동하는 메뉴. 대분류에 마우스를 올리거나 누르면 하위 메뉴가 펼쳐지는 경우가 많습니다.
• 검색: 검색창 또는 검색 아이콘 버튼.
• 유틸리티 영역: 로그인/회원가입, 언어 선택, 글자 크기 조절, 사이트맵 같은 보조 기능.
• 건너뛰기 링크(Skip Navigation): "본문 바로가기"처럼, 반복되는 헤더를 건너뛰고 본문으로 바로 이동하게 해 주는 링크. 화면엔 평소 안 보이다가 키보드 초점이 오면 나타납니다.

이 다섯 가지가 헤더의 기본 구성입니다. 그리고 공공웹이 틀리는 지점은 이 다섯 곳 거의 전부에 골고루 퍼져 있습니다. 하나씩 보겠습니다.

KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 열어 보면, 헤더가 "알아서 만들라"가 아니라 표준 마크업과 동작이 구현된 코드로 제공됩니다. 로고-메뉴-유틸리티의 배치, 메뉴 펼침 동작, 모바일 전환, 건너뛰기 링크까지요. 즉 헤더의 위반은 "참고할 정답이 없어서" 생기는 게 아닙니다. 정답은 이미 공개돼 있는데 가져다 쓰지 않아서 생깁니다.

여기서 헤더의 특수성을 다시 강조하고 싶습니다. 헤더는 반복 요소입니다. 사용자가 사이트 안에서 10개 페이지를 돌아다니면, 같은 헤더를 10번 마주칩니다. 마우스 사용자에게는 이게 별 문제가 안 됩니다. 위쪽에 시선만 한 번 던지면 되니까요. 그런데 스크린리더나 키보드만 쓰는 사용자에게는 다릅니다. 페이지를 옮길 때마다 헤더의 모든 메뉴를 처음부터 다시 거쳐야 합니다. 본문으로 가려면 매번 GNB 수십 개 항목을 다 듣고 지나가야 하죠. "건너뛰기 링크"가 왜 그토록 중요한지, 이 한 가지 사실에서 이미 답이 나옵니다.

공공웹이 헤더에서 가장 많이 틀리는 지점 8가지

이제 본론입니다. 현업에서 실제로 반복되는 헤더 위반을 심각한 것부터 정리하겠습니다. 모두 익명화한 일반적 사례이며, 특정 기관을 지목하지 않습니다.

위반 1) 건너뛰기 링크(본문 바로가기)가 아예 없다

가장 흔하고, 가장 영향이 큰 위반입니다. "본문 바로가기" 또는 "주요 콘텐츠로 건너뛰기" 링크는 화면 맨 처음(헤더보다도 앞)에 놓여, 키보드 사용자가 Tab을 처음 눌렀을 때 가장 먼저 닿는 링크여야 합니다. 이걸 누르면 반복되는 헤더·메뉴를 건너뛰고 곧장 본문으로 점프합니다.

이게 없으면 어떻게 될까요. 스크린리더 사용자가 어느 공공 사이트의 공지사항 10개를 차례로 읽는다고 합시다. 공지 하나를 보고 다음 페이지로 넘어가면, 또 헤더부터 시작입니다. GNB 대분류 5개, 그 아래 펼쳐지는 중분류 수십 개, 검색, 로그인… 이 모든 걸 다 듣고 나서야 비로소 본문에 도착합니다. 페이지를 넘길 때마다 이 고역을 반복하죠. 건너뛰기 링크 하나면 이 모든 게 단번에 해결되는데, 그 한 줄이 없어서 사용자는 매번 메뉴의 늪을 건너야 합니다.

• 나쁜 예: 건너뛰기 링크가 아예 없음. 또는 있긴 한데 화면 한가운데에 항상 떠 있어서 디자인을 해친다며 display: none으로 숨겨 둠 — 숨기면 키보드 초점도 못 받으니 없는 것과 같습니다.
• 올바른 예: 화면 맨 앞에 "본문 바로가기" 링크를 두되, 평소엔 화면 밖으로 시각적으로만 숨기고(visually hidden) 키보드 초점이 오면 나타나게 함. 누르면 본문의 시작 지점(<main> 또는 본문 컨테이너의 id)으로 초점이 이동.

이 한 가지만 제대로 넣어도 키보드·스크린리더 사용자의 체감 만족도가 가장 크게 올라갑니다. 비용은 가장 적게 들고요. 그런데도 가장 많이 빠집니다. 왜냐하면 마우스로 테스트하면 절대 그 부재를 못 느끼거든요. "우리는 잘 작동한다"는 착각이 여기서 생깁니다.

위반 2) 로고에 링크가 없다 (또는 엉뚱한 곳으로 간다)

웹의 오래된 암묵적 약속 하나 — 로고를 누르면 메인(홈)으로 간다. 사용자는 길을 잃으면 거의 반사적으로 로고를 누릅니다. 그런데 의외로 많은 공공 사이트가 로고를 그냥 이미지로만 박아 두고 링크를 안 겁니다. 누르면 아무 일도 안 일어나죠. 또는 로고를 눌렀더니 메인이 아니라 "기관 소개"나 엉뚱한 하위 페이지로 가는 경우도 있습니다.

• 나쁜 예: 로고가 <img> 또는 배경 이미지로만 있고 링크 없음. 사용자가 눌러도 반응 없음.
• 올바른 예: 로고를 메인 페이지로 가는 링크로 감싸고, 그 링크에 "○○ 홈" 같은 접근 가능한 이름을 부여. 로고 이미지의 대체 텍스트(alt)에도 기관명을 넣어 스크린리더가 "○○ 홈, 링크"로 읽게 함.

여기서 하나 더. 로고 이미지에 alt가 없으면 스크린리더는 파일명(logo.png 같은)을 그대로 읽거나 그냥 "이미지"로 처리합니다. 사이트의 정체성을 알리는 가장 중요한 요소가, 음성 사용자에겐 정체불명의 그림으로 전락하는 거죠.

위반 3) 메뉴(GNB)를 키보드로 펼칠 수 없다

대분류에 마우스를 올리면 하위 메뉴가 좌라락 펼쳐지는 헤더, 많이 보셨을 겁니다. 문제는 이게 마우스 호버(hover)에만 반응하도록 만들어진 경우입니다. 키보드 사용자는 Tab으로 대분류에 초점을 옮길 수는 있는데, 거기서 하위 메뉴를 펼칠 방법이 없습니다. 호버를 흉내 낼 수 없으니까요.

• 나쁜 예: :hover로만 하위 메뉴를 펼침. 키보드 초점(:focus)으로는 안 펼쳐짐. 모바일 터치에서도 호버가 애매하게 작동해 한 번 누르면 펼쳐지지도, 이동하지도 않는 어정쩡한 상태가 됨.
• 올바른 예: 대분류 버튼에 키보드로 초점이 오면(또는 Enter/Space를 누르면) 하위 메뉴가 펼쳐지고, 방향키로 하위 항목 간 이동, Esc로 닫기가 되도록 구현. aria-expanded로 펼침/접힘 상태를 코드로 알려 스크린리더가 "하위 메뉴 펼침"을 인지하게 함.

이 위반은 KRDS 킷의 헤더 코드를 쓰면 거의 자동으로 해결됩니다. 직접 호버 메뉴를 만들다 키보드 처리를 빠뜨리는 게 문제의 핵심이라, 검증된 코드를 가져다 쓰는 것만으로 대부분 사라집니다.

위반 4) 아이콘 전용 버튼에 이름이 없다 (햄버거·검색·설정)

모바일에서 메뉴를 접어 넣는 햄버거(줄 세 개) 버튼, 검색 돋보기 버튼, 톱니바퀴 설정 버튼. 헤더에는 텍스트 없이 아이콘만 있는 버튼이 많습니다. 마우스 쓰는 사람은 모양으로 짐작하지만, 스크린리더 사용자에게 이름이 없으면 그냥 "버튼"으로만 읽힙니다. 무엇을 하는 버튼인지 알 수 없죠.

• 나쁜 예: <button> 안에 아이콘 SVG/이미지만 있고 텍스트도 aria-label도 없음. 스크린리더는 "버튼"이라고만 읽음. 햄버거가 메뉴인지 검색인지 알 길 없음.
• 올바른 예: 아이콘 전용 버튼에 aria-label="전체 메뉴 열기", aria-label="검색" 같은 이름을 부여하거나, 화면엔 안 보이는 텍스트(visually hidden)로 이름을 넣음. 펼침 상태가 바뀌는 햄버거 버튼은 aria-expanded로 열림/닫힘도 함께 알림.

헤더는 아이콘 버튼이 밀집한 영역이라, 이 위반이 한 헤더에 여러 개 겹치는 경우가 흔합니다. 햄버거·검색·언어·설정이 전부 이름 없는 아이콘 버튼이면, 음성 사용자에겐 헤더 전체가 "버튼, 버튼, 버튼, 버튼"으로만 읽히는 셈입니다.

위반 5) 헤더가 의미 있는 구조(landmark)로 표시되지 않는다

스크린리더 사용자는 페이지를 위에서 아래로 다 듣는 대신, "랜드마크"라는 구획 단위로 빠르게 점프할 수 있습니다. "배너(헤더)로 가기", "내비게이션으로 가기", "본문으로 가기"처럼요. 이게 가능하려면 헤더가 <header>(또는 role="banner"), 메뉴가 <nav>(또는 role="navigation")처럼 의미 있는 태그로 선언돼 있어야 합니다.

• 나쁜 예: 헤더 전체를 <div class="header">로만 만들고, 메뉴도 <div class="gnb">. 스크린리더에겐 그냥 평범한 박스 더미라 구획 점프가 안 됨. 사용자는 헤더를 일일이 통과해야 함.
• 올바른 예: 헤더는 <header>, 주 메뉴는 <nav>로 감싸고, 메뉴가 여러 개면 각 <nav>에 이름(aria-label="주 메뉴", aria-label="유틸리티 메뉴")을 부여해 구분. 이러면 스크린리더 사용자가 원하는 구획으로 바로 점프할 수 있음.

이건 화면엔 전혀 티가 안 나는 위반입니다. 마우스 사용자에겐 <div>든 <header>든 똑같아 보이니까요. 그래서 더 자주 방치됩니다. 하지만 보조기술 사용자에겐 "지도 위의 이정표가 있느냐 없느냐"만큼 큰 차이입니다.

위반 6) 모바일에서 헤더가 무너지거나 터치 영역이 작다

데스크톱 기준으로만 헤더를 만들고 모바일을 충분히 확인하지 않으면, 작은 화면에서 메뉴가 줄바꿈돼 깨지거나, 햄버거 버튼·아이콘이 손가락에 비해 너무 작아집니다. 헤더는 모든 페이지 공통이라, 헤더가 모바일에서 깨지면 사이트 전체가 모바일에서 깨진 것처럼 느껴집니다.

• 나쁜 예: 모바일에서 GNB가 두세 줄로 흘러넘쳐 본문을 밀어냄. 또는 햄버거 버튼이 너무 작아 옆의 검색 버튼을 잘못 누름.
• 올바른 예: 일정 너비 이하에서 GNB를 햄버거 메뉴로 접고, 헤더의 모든 터치 대상이 최소 권장 크기(보통 한 변 44px 이상)를 충족하도록 함. 버튼끼리 간격도 충분히 둬 오터치를 줄임.

위반 7) 검색이 "있는데 못 쓰는" 상태

헤더의 검색은 두 가지 방식이 흔합니다 — 항상 펼쳐진 입력창이거나, 평소엔 돋보기 아이콘만 있다가 누르면 입력창이 열리는 방식이거나. 후자에서 위반이 자주 납니다. 검색 아이콘 버튼에 이름이 없거나(위반 4와 겹침), 펼쳐진 검색 입력창에 라벨이 없거나, 키보드로는 검색창을 열 수 없는 경우입니다.

• 나쁜 예: 돋보기 버튼에 이름 없음. 펼친 입력창에도 라벨 없이 플레이스홀더 "검색어 입력"만 있음. 스크린리더 사용자는 그게 검색창인지조차 모름.
• 올바른 예: 돋보기 버튼에 "검색" 이름 부여, 검색 입력창에 보이는 또는 코드상의 라벨 연결, 검색 버튼(제출)에도 "검색 실행" 같은 이름. 키보드로 버튼 → 입력창 → 제출까지 자연스럽게 이동되게 함.

위반 8) 화면 라벨과 읽히는 이름의 불일치 / 중복 읽힘

헤더의 메뉴나 버튼에서, 화면에 보이는 글자와 스크린리더가 읽는 이름이 어긋나는 경우입니다. 또는 아이콘과 텍스트가 둘 다 읽혀 "돋보기 이미지 검색"처럼 중복으로 읽히기도 합니다.

• 나쁜 예: 메뉴에 "민원·신청"이라고 떠 있는데 aria-label="민원"이 따로 박혀 있어 화면과 음성이 다름. 또는 "검색" 글자 옆 돋보기 아이콘에 aria-hidden을 안 걸어 "돋보기 이미지 검색"으로 중복 읽힘.
• 올바른 예: 보이는 글자를 그대로 접근 가능한 이름으로 쓰고, 텍스트 옆 장식용 아이콘은 aria-hidden="true"로 숨겨 중복을 방지. 보이는 것과 읽히는 것을 일치시키는 게 원칙.

위반 9) 고정(sticky) 헤더가 본문을 가린다

스크롤해도 헤더가 화면 상단에 계속 붙어 있는 "고정 헤더"는 요즘 흔한 패턴입니다. 잘 쓰면 어디서든 메뉴에 접근할 수 있어 편리하지만, 잘못 쓰면 문제를 만듭니다. 특히 페이지 안에서 특정 항목으로 점프했을 때(예: 목차 링크를 눌러 해당 단락으로 이동), 고정 헤더가 그 단락의 제목을 덮어 버리는 경우가 있습니다. 사용자는 분명 점프했는데, 정작 보고 싶은 제목이 헤더 뒤에 가려 안 보이는 거죠.

• 나쁜 예: 고정 헤더 높이만큼의 여백 처리가 없어, 앵커 점프 시 도착 지점이 헤더에 가려짐. 또 모바일에서 고정 헤더가 화면을 너무 많이 차지해 본문 볼 공간이 좁아짐.
• 올바른 예: 앵커 점프 시 헤더 높이만큼 스크롤 보정(scroll-padding/scroll-margin)을 적용해 도착 지점이 헤더 아래에 오게 함. 모바일에서는 고정 헤더의 높이를 적정하게 유지하거나, 스크롤 방향에 따라 헤더를 자연스럽게 숨겼다 보이게 함.

이 위반은 키보드 사용자에게도 영향을 줍니다. Tab으로 본문 링크에 초점을 옮겼을 때, 그 링크가 고정 헤더 뒤에 가려 보이지 않으면 "지금 어디에 초점이 있는지" 시각적으로 확인할 수 없거든요. 고정 헤더를 쓸 거라면 초점 이동 시에도 대상이 가려지지 않게 보정해야 합니다.

위반 10) 헤더 안 링크들의 초점 순서가 뒤죽박죽이다

Tab을 눌렀을 때 초점이 이동하는 순서는, 사용자가 헤더를 머릿속으로 이해하는 순서이기도 합니다. 자연스럽게는 "건너뛰기 링크 → 로고 → 주 메뉴 → 유틸리티 → 검색" 정도로 흐르는 게 좋습니다. 그런데 화면 배치를 CSS로만 옮겨 놓고 마크업 순서는 그대로 두면, 보이는 순서와 Tab 순서가 어긋납니다. 화면 오른쪽 끝의 로그인 버튼에 초점이 먼저 가고, 왼쪽 로고는 한참 뒤에 오는 식이죠.

• 나쁜 예: 시각적으로는 왼쪽→오른쪽인데, tabindex를 임의로 박거나 CSS order/float로 위치만 바꿔 Tab 순서가 뒤섞임. 키보드 사용자는 초점이 화면을 멋대로 튀어 다니는 경험을 함.
• 올바른 예: 마크업 순서 자체를 시각적 순서와 일치시키고, tabindex는 0 또는 자연 순서를 쓰며 양수 tabindex(임의 순서 강제)는 피함. 초점이 화면을 따라 예측 가능하게 흐르게 함.

한 장면 — 같은 헤더, 두 사람

추상적인 위반 목록보다, 한 장면을 그려 보는 게 빠르겠습니다. 어느 공공 서비스의 헤더가 하나 있다고 합시다. 로고, GNB 5개 대분류, 검색 돋보기, 로그인. 흔한 구성입니다.

먼저 마우스를 쓰는 김 주무관. 사이트에 들어와 로고를 슥 보고 "아, 여기구나" 하고, GNB에 마우스를 올려 펼쳐진 메뉴에서 "민원 신청"을 누릅니다. 길을 잃으면 로고를 눌러 메인으로 돌아오고요. 김 주무관에게 이 헤더는 아무 문제가 없습니다. 그래서 이 헤더를 만든 팀도 "잘 작동한다"고 믿습니다. 검수할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 Tab을 누릅니다. 첫 Tab에서 "본문 바로가기" 링크가 나와야 하는데, 아무것도 안 나옵니다(위반 1). 그냥 로고 자리인데 — "이미지"라고만 읽힙니다. 기관명도, 홈 링크라는 안내도 없습니다(위반 2). 계속 Tab을 누르며 GNB로 들어가 대분류에 닿았는데, 거기서 하위 메뉴를 펼칠 방법이 없습니다. 호버에만 반응하는 메뉴거든요(위반 3). 검색을 해 보려고 돋보기 버튼에 닿았더니 "버튼"이라고만 읽힙니다. 무슨 버튼인지 모릅니다(위반 4). 박 선생님은 본문에 닿기도 전에, 매 페이지 이 미로를 헤매야 한다는 걸 깨닫고 지칩니다.

같은 헤더, 같은 화면. 한 사람에겐 1초짜리 무의식적 통과이고, 다른 한 사람에겐 페이지마다 반복되는 장애물 코스입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문입니다. KRDS의 헤더 기준은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 헤더 코드를 가져다 썼다면 어땠을까요. 박 선생님의 첫 Tab은 "본문 바로가기"에 닿았을 거고, 로고는 "○○ 홈, 링크"로 읽혔을 거고, GNB는 Enter로 펼쳐졌을 거고, 돋보기는 "검색, 버튼"으로 읽혔을 겁니다. 김 주무관과 똑같이 막힘없이 다녔겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

왜 헤더 위반이 유독 심각한가 — 원리와 배경

여기까지 읽고 "헤더 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 헤더는 다른 컴포넌트와 결정적으로 다른 점이 두 가지 있어서, 같은 실수라도 파급력이 훨씬 큽니다.

첫째, 헤더는 전 페이지 공통이다 — 실수가 곱해진다

푸터의 어떤 링크가 깨지면 그 페이지 하나의 문제입니다. 그런데 헤더는 보통 모든 페이지가 공유합니다. 그래서 헤더에 위반이 하나 있으면, 그건 "한 군데 위반"이 아니라 "페이지 수 × 위반"이 됩니다. 100페이지 사이트라면, 건너뛰기 링크 부재 하나가 100번 반복되는 장벽이 되는 거죠. 거꾸로 말하면, 헤더를 한 번 제대로 고치면 모든 페이지가 한꺼번에 좋아집니다. 투자 대비 효과가 사이트에서 가장 큰 영역이 헤더입니다.

둘째, 헤더는 "탐색의 출발점"이다 — 막히면 그다음이 없다

본문 콘텐츠는 못 읽어도 다른 경로로 정보를 얻을 여지가 있습니다. 그런데 헤더가 막히면 사용자는 다른 페이지로 갈 방법 자체를 잃습니다. 메뉴가 안 펼쳐지면 하위 페이지에 도달할 수 없고, 로고에 링크가 없으면 메인으로 돌아올 수 없고, 건너뛰기 링크가 없으면 본문에 닿기까지 매번 메뉴를 다 거쳐야 합니다. 헤더는 사이트라는 건물의 현관이자 복도입니다. 현관이 막히면 안에 아무리 좋은 게 있어도 들어갈 수가 없습니다.

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 헤더가 불편하면 사용자가 경쟁사로 떠나면 그만입니다. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 건강보험을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자에게 "안 쓸 자유"가 없어요. 그래서 공공 웹의 헤더가 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 박탈이 됩니다. 헤더의 메뉴가 키보드로 안 펼쳐지면, 손 사용이 불편한 사람은 그 사이트의 어느 서비스에도 도달할 수 없는 셈입니다.

일관성이 곧 학습 비용 절감

KRDS가 헤더의 구조와 동작을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 헤더가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 메뉴가 어디 있지? 검색은 어떻게 열지?"를 다시 배워야 합니다. 모든 공공 서비스의 헤더가 비슷한 자리에 비슷한 방식으로 작동하면, 한 번 익힌 사용법이 어디서나 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다. 헤더 표준화는 디자이너의 자유를 뺏는 게 아니라, 국민의 인지 부담을 덜어 주는 일입니다.

"보이는 것 ≠ 읽히는 것"이라는 함정

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 줄 세 개 모양을 보고 "아, 메뉴구나" 하고, 돋보기를 보고 "검색이구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 헤더는 "보기에 헤더 같은 것"으로는 부족하고, "코드 수준에서 헤더라고 선언된 것"이어야 합니다. <div>에 로고 이미지와 메뉴 글자를 늘어놓아 헤더처럼 보이게 만들어도, 코드가 그걸 "배너"라고, 메뉴를 "내비게이션"이라고 말해 주지 않으면 스크린리더에겐 그냥 의미 없는 글자 덩어리입니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 헤더 위반의 근본 원인 대부분을 차지합니다. 앞서 본 위반 5(랜드마크 부재), 위반 4(아이콘 버튼 이름 부재), 위반 8(이름 불일치)이 전부 이 한 가지 원리의 변주입니다. KRDS의 헤더 요건이 결국 "시각과 코드의 일치"로 수렴하는 셈입니다.

헤더는 "테스트에서 가장 잘 통과하는" 영역이다

역설적이게도, 헤더는 일반적인 사내 검수에서 거의 항상 "이상 없음" 판정을 받습니다. 왜냐하면 검수자가 마우스를 쓰니까요. 마우스로는 로고 클릭도, 호버 메뉴도, 아이콘 버튼도 다 잘 작동합니다. 그래서 팀은 "우리 헤더는 완벽하다"고 자신합니다. 그런데 그 자신감은 "마우스 사용자에게만"이라는 조건이 빠진 것입니다.

헤더 위반의 대부분은 마우스로는 절대 드러나지 않습니다. 건너뛰기 링크가 없어도 마우스 사용자는 불편함을 못 느끼고, 호버 메뉴가 키보드로 안 펼쳐져도 마우스로는 멀쩡하고, 아이콘 버튼에 이름이 없어도 눈으로는 모양으로 알아챕니다. 이게 헤더가 위반을 안고도 오래 방치되는 이유입니다. "잘 작동한다"는 착각이 가장 잘 생기는 영역이거든요. 그래서 헤더만큼은 키보드만으로(마우스를 치우고) Tab을 눌러 가며 확인하거나, 자동 점검 도구로 객관적으로 검증해 봐야 진짜 상태가 보입니다.

KRDS는 헤더에 무엇을 요구하나 — 기준으로 정리

위반들을 봤으니, 거꾸로 KRDS가 요구하는 "올바른 헤더"의 요건을 한 번에 정리해 두겠습니다. 앞의 위반들이 결국 이 요건들의 뒷면입니다.

1. 건너뛰기 링크: 화면 맨 앞에 "본문 바로가기"를 두고, 키보드 초점이 오면 나타나 본문으로 점프하게 한다.

2. 로고 = 홈 링크: 로고를 메인으로 가는 링크로 감싸고, 접근 가능한 이름과 대체 텍스트를 부여한다.

3. 키보드로 완전 조작 가능한 메뉴: GNB를 호버뿐 아니라 키보드 초점·Enter로 펼치고, 방향키 이동·Esc 닫기, aria-expanded 상태 전달까지 갖춘다.

4. 아이콘 버튼에 이름: 햄버거·검색·설정 등 아이콘 전용 버튼에 aria-label이나 숨김 텍스트로 이름을 준다.

5. 의미 있는 구조(landmark): 헤더는 <header>, 메뉴는 <nav>로 선언하고, 여러 <nav>는 이름으로 구분한다.

6. 반응형과 터치 영역: 모바일에서 헤더가 무너지지 않고, 모든 터치 대상이 최소 권장 크기(약 44px 이상)를 충족한다.

7. 검색의 접근성: 검색 버튼·입력창·제출에 각각 이름/라벨을 주고, 키보드로 열고 입력하고 제출할 수 있게 한다.

8. 시각·코드 일치: 보이는 글자와 읽히는 이름을 일치시키고, 장식 아이콘은 aria-hidden으로 중복 읽힘을 막는다.

정리하면, KRDS의 헤더 기준은 세 축으로 수렴합니다. ① 도달 가능성(건너뛰기 링크·키보드 메뉴로 누구나 본문과 하위 페이지에 닿게), ② 정체성 전달(로고·기관명·랜드마크로 "여기가 어디인지" 알리게), ③ 시각과 코드의 일치(보이는 것이 코드로도 전달돼 스크린리더가 읽게). 이 세 축은 그대로 ViewCheck가 헤더를 판정하는 기준이기도 합니다.

직접 적용하기 — 개발자·디자이너·기획자 가이드

KRDS의 좋은 점은, 위 요건들을 "알아서 잘 만드세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 헤더 마크업과 동작 코드가 들어 있어, 건너뛰기 링크·키보드 메뉴·aria-expanded·랜드마크 구조가 이미 구현된 상태로 시작할 수 있습니다. "헤더 접근성은 어렵다"는 말의 절반은 "직접 호버 메뉴를 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다. 특히 메뉴 펼침 로직과 모바일 전환은 직접 만들면 버그가 끝없이 나오는 영역이라, 표준 코드의 이점이 큽니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 헤더를 배치하면, 로고·메뉴·유틸리티의 간격과 크기, 모바일 전환 규칙이 기준에 맞춰집니다. 그리고 시안 단계에서 꼭 표시해 둘 것 두 가지 — "본문 바로가기 링크의 위치/스타일"과 "아이콘 버튼들의 이름(라벨)". 이 둘은 시안에 명시하지 않으면 개발에서 그대로 누락됩니다.

기획자라면 — 화면 정의서에 "상단 헤더"라고만 적지 말고, "헤더(로고=홈 링크, GNB 키보드 펼침, 본문 바로가기 포함, 검색 버튼 라벨='검색')"처럼 핵심 요건을 함께 명시하세요. 이 한 줄이 디자인·개발 단계의 누락을 막습니다. 헤더는 전 페이지 공통이라, 기획에서 한 번 제대로 정의해 두면 그 효과가 모든 페이지로 퍼집니다.

그래서 우리 사이트 헤더는? — ViewCheck로 5분 점검

여기까지가 헤더의 위반과 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 헤더는 이걸 지키고 있나?"를 확인하는 일입니다. 로고에 링크가 걸려 있는지, 메뉴가 키보드로 펼쳐지는지, 건너뛰기 링크가 있는지, 아이콘 버튼에 이름이 있는지, 헤더가 <header>로 선언됐는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 더구나 헤더는 전 페이지 공통이라, 한 페이지만 보고 "괜찮다"고 단정하기도 위험합니다(템플릿이 페이지 유형별로 다를 수 있으니까요).

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 헤더를 포함한 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 헤더는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다.

ViewCheck가 헤더에 대해 자동으로 보는 것들:

• 건너뛰기 링크 존재 여부: "본문 바로가기" 같은 skip 링크가 화면 앞쪽에 있고 본문으로 연결되는지
• 로고 링크와 대체 텍스트: 로고가 메인으로 가는 링크인지, 접근 가능한 이름·alt가 있는지
• 메뉴의 구조와 상태 속성: 메뉴가 <nav>로 선언됐는지, 펼침 메뉴에 aria-expanded 같은 속성이 있는지
• 아이콘 버튼의 이름: 햄버거·검색 등 아이콘 전용 버튼에 접근 가능한 이름이 있는지
• 랜드마크 구조: 헤더가 <header>/role="banner"로, 메뉴가 <nav>로 의미 있게 표시됐는지
• 반응형 헤더와 터치 영역: 모바일 뷰포트에서 헤더가 무너지지 않고 터치 대상이 최소 권장 크기를 충족하는지(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 모바일에서 햄버거로 전환된 실제 메뉴 모양, 펼쳐진 메뉴의 시각적 레이아웃)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드 구조는 애매한데 화면엔 분명히 헤더가 있는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 헤더도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 헤더 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "메인 페이지 헤더에 건너뛰기 링크 없음", "헤더 로고에 링크 미연결"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인 헤더는 멀쩡한데 게시판 상세 페이지의 헤더 템플릿엔 건너뛰기 링크가 빠졌다" 같은 페이지 유형별 편차도 한눈에 드러납니다. 헤더는 전 페이지 공통이라 믿었는데 실제론 템플릿이 갈라져 있는 경우가 의외로 많아서, 이 다중 페이지 비교가 특히 유용합니다.

어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다. 무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "잘하자"가 아니라, "이 페이지의 헤더에서 이걸 이렇게 고치자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 헤더를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. "본문 바로가기" 링크는 화면에 항상 보여야 하나요? 디자인이 지저분해지는데요.

항상 보일 필요는 없습니다. 오히려 평소엔 화면 밖으로 시각적으로 숨겨 두는 게 일반적입니다. 핵심은 "키보드 초점이 오면 나타나야 한다"는 것입니다. 마우스 사용자에겐 안 보이고, 키보드 사용자가 첫 Tab을 누르면 화면 좌상단에 또렷하게 나타나는 식이죠. 주의할 점은 display: none이나 visibility: hidden으로 숨기면 키보드 초점도 못 받아서 무용지물이 된다는 겁니다. 화면 밖으로 위치만 빼는 방식(visually hidden) + 초점 시 위치 복원을 써야 합니다. 디자인을 해치지 않으면서 접근성을 챙기는, 거의 표준화된 기법입니다.

Q. 로고에 굳이 alt와 링크를 둘 다 넣어야 하나요?

네, 둘 다 필요합니다. 링크는 "로고를 누르면 메인으로"라는 사용자 기대를 충족하기 위해, alt(또는 링크의 접근 가능한 이름)는 스크린리더 사용자가 "여기가 어디 사이트의 홈인지" 알기 위해 필요합니다. 보통 로고 링크에 "○○ 홈"이라는 이름을 주고, 로고 이미지 alt에는 기관명을 넣습니다. 둘 중 하나라도 빠지면, 마우스 사용자나 음성 사용자 중 한쪽이 정보를 잃습니다.

Q. 호버로 펼쳐지는 메뉴가 보기 좋은데, 꼭 키보드로도 펼쳐지게 해야 하나요?

네, 필수입니다. 호버에만 반응하는 메뉴는 키보드 사용자와 터치 사용자 모두에게 문제가 됩니다. 키보드 사용자는 호버를 흉내 낼 수 없고, 터치 기기에는 호버 개념이 모호해서 "한 번 누르면 펼쳐지는지 이동하는지" 헷갈립니다. 해법은 호버를 없애는 게 아니라, 호버에 더해 키보드 초점·클릭(탭)으로도 펼쳐지게 만드는 것입니다. 즉 "호버도 되고, 키보드도 되고, 터치도 되는" 메뉴여야 합니다. KRDS 킷 헤더 코드가 이걸 이미 처리해 두고 있어서, 직접 만드는 것보다 안전합니다.

Q. 헤더에 메뉴가 두세 개(주 메뉴, 유틸리티 메뉴, 푸터로 가는 빠른 메뉴 등)인데 다 `<nav>`로 감싸면 헷갈리지 않나요?

오히려 이름을 붙여 구분하면 더 명확해집니다. 각 <nav>에 aria-label="주 메뉴", aria-label="유틸리티 메뉴"처럼 다른 이름을 주면, 스크린리더 사용자는 "내비게이션이 세 개 있고, 그중 주 메뉴로 가자"처럼 골라서 점프할 수 있습니다. 이름 없이 <nav>만 여러 개 두면 "내비게이션, 내비게이션, 내비게이션"으로 구분이 안 되니, 여러 개일 때는 이름 부여가 거의 필수입니다.

Q. 모바일 햄버거 버튼은 무엇을 챙겨야 하나요?

세 가지입니다. 첫째, 이름 — aria-label="전체 메뉴 열기" 같은 접근 가능한 이름을 줍니다(아이콘만으론 안 됩니다). 둘째, 상태 — 메뉴가 열렸는지 닫혔는지 aria-expanded로 알립니다. 셋째, 크기 — 손가락으로 누를 수 있게 터치 영역을 충분히(약 44px 이상) 확보합니다. 추가로, 메뉴를 펼쳤을 때 키보드 초점이 메뉴 안으로 들어가고 Esc로 닫히면 더 좋습니다. 햄버거는 헤더에서 가장 자주 위반이 나는 단일 버튼이라, 이 세 가지를 체크리스트로 박아 두면 도움이 됩니다.

Q. 이미 운영 중인 사이트인데, 헤더를 전부 다시 만들어야 하나요?

전부 갈아엎을 필요는 없습니다. 헤더는 전 페이지 공통이라, 헤더 하나만 제대로 고치면 모든 페이지가 한꺼번에 좋아진다는 게 큰 장점입니다. 먼저 ViewCheck로 현황을 확인해 "지금 헤더가 어떤 문제를 일으키는지, 페이지 유형별로 헤더가 다른지"를 목록으로 만든 다음, 가장 영향 큰 것(건너뛰기 링크·키보드 메뉴)부터 차례로 고치면 됩니다. 헤더는 투자 대비 효과가 사이트에서 가장 큰 영역이라, 적은 작업으로 가장 많은 사용자를 구제할 수 있습니다.

Q. 디자인팀과 개발팀이 서로 "헤더 접근성은 너희 일"이라고 합니다.

헤더 접근성은 어느 한 팀의 책임이 아니라 합작입니다. 기획자는 헤더에 들어갈 요소(건너뛰기 링크 포함)와 각 버튼의 이름을 정의하고, 디자이너는 로고·메뉴·아이콘 버튼의 상태와 터치 영역을 시안에 명시하고, 개발자는 그걸 표준 마크업(<header>/<nav>)과 키보드 동작으로 구현해야 합니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 이겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

Q. 헤더가 페이지마다 똑같으니 한 페이지만 점검하면 충분하지 않나요?

그럴 것 같지만, 실제론 위험합니다. 많은 사이트가 메인·목록·상세·검색 페이지에서 서로 다른 템플릿을 쓰고, 그 과정에서 헤더가 미묘하게 갈라집니다. 메인 헤더엔 건너뛰기 링크가 있는데 게시판 상세엔 빠져 있거나, 검색 페이지 헤더만 구조가 다른 식이죠. 그래서 헤더야말로 다중 페이지 점검이 꼭 필요한 영역입니다. ViewCheck로 여러 페이지를 한꺼번에 돌려 보면 이런 템플릿별 편차가 한눈에 드러납니다.

Q. 고정(sticky) 헤더를 쓰면 안 되나요?

써도 됩니다. 고정 헤더 자체가 문제는 아닙니다. 다만 두 가지를 챙겨야 합니다. 첫째, 앵커 점프(목차 링크 등)나 키보드 초점 이동 시 도착 지점이 헤더에 가려지지 않게 스크롤 보정을 해야 합니다. 둘째, 모바일에서 고정 헤더가 화면을 너무 많이 차지하지 않게 높이를 적정하게 유지하거나, 스크롤 방향에 따라 헤더를 부드럽게 숨겼다 보이는 방식을 검토하세요. 고정 헤더의 편리함은 살리되, 본문을 가리지 않게 다듬는 게 핵심입니다.

Q. 헤더 메뉴 항목이 너무 많은데, 다 넣어야 하나요?

헤더는 "사이트의 큰 분류로 가는 길"을 보여 주는 곳이지, 모든 페이지로 가는 만능 목차가 아닙니다. 대분류가 지나치게 많으면 사용자는 무엇부터 봐야 할지 압도되고, 키보드·스크린리더 사용자는 본문에 닿기까지 더 많은 항목을 거쳐야 합니다. 가장 중요한 대분류만 헤더에 두고, 세부 항목은 하위 메뉴나 본문 내 탐색, 푸터의 사이트맵으로 분산하는 게 좋습니다. 그리고 항목이 많을수록 건너뛰기 링크의 중요성은 더 커집니다 — 다 거치지 않고 본문으로 갈 통로가 있어야 하니까요.

Q. 다국어 사이트의 언어 선택은 헤더의 무엇으로 봐야 하나요?

언어 선택은 유틸리티 영역의 일부로 봅니다. 셀렉트나 링크 묶음으로 구현되는데, 어느 쪽이든 접근성 요건은 그대로 적용됩니다. 언어 선택이 아이콘(지구본 모양 등)만으로 돼 있으면 "언어 선택"이라는 이름을 부여해야 하고, 현재 선택된 언어가 무엇인지 코드로도 알 수 있어야 합니다. 또 언어를 바꾸면 페이지 전체의 lang 속성도 함께 바뀌어야 스크린리더가 올바른 발음으로 읽습니다. 헤더의 작은 구석이지만, 다국어 서비스에서는 놓치기 쉬운 지점입니다.

점검했다면, 무엇부터 고칠까 — 우선순위

ViewCheck로 돌려 보면 보통 헤더 관련 문제가 한두 개로 끝나지 않습니다. 그래서 우선순위가 중요합니다. 헤더 위반을 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드로 펼쳐지지 않는 메뉴, 그리고 건너뛰기 링크의 부재. 이 둘은 특정 사용자가 하위 페이지나 본문에 도달하는 것 자체를 막는 문제라 1순위입니다. 헤더는 전 페이지 공통이라, 이 위반은 사이트 전체에서 반복되므로 영향도 가장 큽니다. "예쁘게 만든 호버 메뉴"가 사실 여기 해당하는 경우가 많습니다.

그다음(높음) — 로고 링크/대체 텍스트 부재, 아이콘 전용 버튼(햄버거·검색)의 이름 부재. 작동은 하지만 음성 사용자가 "여기가 어디인지", "이 버튼이 뭔지" 알 수 없으니 실질적 장벽입니다. 헤더가 <div> 더미로만 돼 있어 랜드마크 점프가 안 되는 것도 여기 포함됩니다.

그 후(보통) — 모바일 터치 영역 부족, 검색 입력창 라벨 누락, 화면-음성 이름 불일치. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 여러 <nav>에 이름 붙여 구분, 장식 아이콘 aria-hidden 정리 같은 다듬기. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다. 그리고 헤더는 한 번 고치면 전 페이지가 좋아지므로, 같은 노력이라도 다른 컴포넌트를 고칠 때보다 효과가 곱절입니다.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS의 헤더 기준을, 공공웹이 자주 틀리는 지점 위주로 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 문서(웹) — 헤더의 구성과 예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub) — 헤더 마크업·동작 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 헤더 컴포넌트와 상태.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트 헤더가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 헤더, 이것만은

마지막으로, 디자이너·개발자·기획자가 헤더를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 화면 맨 앞에 "본문 바로가기" 링크가 있고, 키보드 초점 시 나타나 본문으로 이동한다(display:none으로 숨기지 않았다).
• ☐ 로고가 메인 페이지로 가는 링크이고, 접근 가능한 이름("○○ 홈")과 alt(기관명)가 있다.
• ☐ GNB가 호버뿐 아니라 키보드 초점·Enter/Space로도 펼쳐지고, 방향키 이동·Esc 닫기가 된다.
• ☐ 펼침 메뉴에 `aria-expanded` 등 상태 속성이 있어 스크린리더가 펼침/접힘을 안다.
• ☐ 햄버거·검색·설정 등 아이콘 전용 버튼에 이름이 있다(aria-label 또는 숨김 텍스트).
• ☐ 헤더가 `<header>`/`role="banner"`, 주 메뉴가 `<nav>`로 선언돼 랜드마크 점프가 된다.
• ☐ 메뉴가 여러 개면 각 <nav>에 다른 이름(주 메뉴/유틸리티 메뉴 등)을 붙였다.
• ☐ 모바일에서 헤더가 무너지지 않고, 헤더의 터치 대상이 충분히 크다(약 44px 이상).
• ☐ 검색 버튼·입력창·제출에 각각 이름/라벨이 있고 키보드로 열고 제출할 수 있다.
• ☐ 보이는 글자와 읽히는 이름이 일치하고, 텍스트 옆 장식 아이콘은 aria-hidden으로 중복 읽힘을 막았다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 직접 호버 메뉴를 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 헤더 컴포넌트를 그대로 가져다 쓸 수 있습니다.

헤더는 작아 보이지만, 사용자가 사이트에서 가장 먼저 만나고 페이지마다 다시 만나는 영역입니다. 그 가로 띠 하나가 누군가에겐 모든 페이지로 통하는 복도이고, 또 누군가에겐 매번 다시 헤매야 하는 미로입니다. 우리가 무심코 넘긴 로고 링크 하나, 빠뜨린 건너뛰기 링크 한 줄이, 누군가에게는 그 사이트를 혼자 쓸 수 있느냐 없느냐를 가릅니다.

오늘 정리한 위반들이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 본문으로 건너뛸 길을 열어 두고, 로고를 홈 링크로 만들고, 메뉴를 키보드로도 펼치게 하고, 아이콘 버튼에 이름을 주는 것. 이 네 가지만 챙겨도 헤더 위반의 대부분은 사라집니다. 그리고 헤더는 한 번 고치면 전 페이지가 동시에 좋아지니, 가장 적은 노력으로 가장 큰 변화를 만드는 영역입니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 막히는 헤더 한 곳부터 고쳐 나가면, 우리 사이트는 분명히 더 많은 사람에게 열립니다. 다음 글에서는 헤더와 짝을 이루는 또 다른 공통 영역을 같은 방식으로 뜯어보겠습니다.

우리 사이트의 헤더는 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 — 그리고 페이지 유형별로 헤더가 갈라져 있지는 않은지 — 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #헤더Header #웹접근성 #ViewCheck #정부웹사이트 #UIUX #건너뛰기링크 #키보드접근성 #GNB #랜드마크 #헤더 #Header #흔한실수 #개선사례 #안티패턴 #UI컴포넌트 #컴포넌트설계 #전자정부