헤더(Header) 자가진단 — ViewCheck 5분 점검

공공 사이트에 처음 들어갔을 때, 우리 눈이 가장 먼저 닿는 곳이 어디일까요. 십중팔구 화면 맨 위입니다. 기관 로고, 검색창, 로그인, 메뉴 버튼 — 이 모든 게 모여 있는 띠 모양의 영역. 우리는 그걸 그냥 "맨 위 부분"이라고 부르지만, 디자인 시스템에서는 이걸 헤더(Header)라고 합니다. 그리고 솔직히 말하면, 사이트가 잘 만들어졌는지 아닌지는 이 헤더만 봐도 절반은 짐작이 갑니다.

저는 공공 웹사이트를 수백 개 들여다보면서, 헤더에서 똑같은 문제가 반복되는 걸 정말 많이 봤습니다. 로고를 눌렀는데 홈으로 안 가거나, 모바일에서 햄버거 메뉴를 열었더니 닫을 방법이 없거나, 키보드로는 메뉴에 아예 도달하지 못하거나. 마우스 쓰는 사람 눈엔 멀쩡해 보이는 헤더가, 키보드나 스크린리더로 들어가면 미로가 되는 경우가 부지기수입니다.

그래서 이번 글은 "헤더를 어떻게 자가진단할 것인가"에 초점을 맞췄습니다. KRDS(대한민국 정부 디자인 시스템)가 헤더를 어떻게 정의하고 무엇을 요구하는지 짚되, 거기서 그치지 않고 "그래서 우리 사이트 헤더가 이걸 지키고 있는지 5분 안에 확인하는 법"까지 끌고 가겠습니다. 읽고 나면 ViewCheck로 한 번 돌려 보고 싶어지실 겁니다. 그게 이 글의 목표입니다.

헤더가 대체 뭐길래 — 정의부터 정확히

먼저 용어를 맞추겠습니다. 헤더(Header)는 거의 모든 웹페이지의 가장 위쪽에 자리 잡는, 사이트의 정체성과 전역 기능을 담는 영역입니다. 페이지가 바뀌어도 헤더는 대체로 그대로 유지됩니다. 그래서 사용자에게 헤더는 "내가 지금 어느 사이트에 있고, 어디로 갈 수 있는지"를 알려 주는 일종의 고정 안내판 역할을 합니다.

헤더 안에는 보통 다음 요소들이 들어갑니다.

기관 식별: 로고와 기관명. "여기는 ○○부 / ○○시 사이트"라는 정체성.
전역 내비게이션(GNB): 사이트 전체를 가로지르는 주 메뉴.
검색: 사이트 내 검색 진입점.
유틸리티 영역: 로그인/로그아웃, 회원가입, 마이페이지, 언어 전환, 글자 크기 조절 등.
모바일 메뉴 토글: 작은 화면에서 메뉴를 펼치고 접는 햄버거 버튼.

여기서 한 가지 구분이 필요합니다. "헤더"와 "내비게이션"을 같은 말로 쓰는 경우가 많은데, 엄밀히는 다릅니다. 헤더는 화면 상단의 "영역" 전체를 가리키고, 내비게이션은 그 안에 담기는 "기능" 중 하나입니다. KRDS도 이 둘을 따로 다룹니다. 헤더는 컴포넌트(또는 글로벌 영역)로, 메인 메뉴·유틸리티 같은 내비게이션은 별도 컴포넌트로요. 이 글에서는 "헤더라는 영역과 그 안에 담기는 핵심 기능들"을 묶어서 점검 대상으로 삼겠습니다.

헤더가 특별한 이유 — "모든 페이지에 있다"

헤더가 다른 컴포넌트와 결정적으로 다른 점이 하나 있습니다. 바로 모든 페이지에 등장한다는 것입니다. 셀렉트나 모달은 특정 페이지에만 있지만, 헤더는 첫 화면부터 마지막 화면까지 늘 따라다닙니다. 이게 무슨 뜻이냐면, 헤더에 문제가 하나 있으면 그 문제가 사이트 전체에 곱하기로 퍼진다는 겁니다.

예를 들어 헤더의 검색 버튼에 접근 가능한 이름이 없다고 합시다. 그러면 그건 한 페이지의 버그가 아니라, 그 사이트의 모든 페이지에서 똑같이 발생하는 버그입니다. 100페이지짜리 사이트라면 같은 문제가 100번 반복되는 셈이죠. 반대로 헤더 하나만 제대로 고치면, 사이트 전체의 점수가 한꺼번에 올라갑니다. 그래서 헤더는 "고치면 가장 효과가 큰 컴포넌트"이기도 합니다. 자가진단을 헤더부터 시작하라고 권하는 이유가 이겁니다.

KRDS 공식 컴포넌트 문서를 열어 보면, 헤더가 단순히 "위쪽에 뭔가 배치하는 영역"이 아니라, 기관 식별·내비게이션·검색·유틸리티가 어떤 구조로 배치되어야 하는지를 가이드로 정리해 두고 있습니다. 데스크톱과 모바일에서 각각 어떻게 펼쳐지고 접히는지, 어떤 요소가 우선순위를 갖는지까지요. KRDS가 헤더를 별도 컴포넌트로 정의해 둔 것 자체가, "헤더는 아무렇게나 만들면 안 되는, 표준이 있는 영역"이라는 신호입니다.

KRDS는 헤더에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 한국형 웹 접근성 지침(KWCAG)을 종합해서, 헤더가 충족해야 하는 요건을 영역별로 정리하겠습니다. 자가진단할 때 이 목록 하나하나가 체크 항목이 됩니다.

1) 기관 식별 — 로고는 보이기만 해선 안 된다

헤더의 첫 번째 역할은 "여기가 어디인지"를 알리는 것입니다. 로고와 기관명이 명확히 보여야 하죠. 그런데 보이는 것만으로는 부족합니다. 두 가지가 더 필요합니다.

첫째, 로고를 누르면 홈(첫 화면)으로 가야 합니다. 이건 거의 모든 사용자가 무의식적으로 기대하는 규약입니다. 길을 잃었을 때 로고를 누르면 출발점으로 돌아온다는 약속. 이게 안 지켜지면 사용자는 당황합니다. 의외로 공공 사이트에서 로고가 그냥 이미지일 뿐 링크가 아닌 경우가 적지 않습니다.

둘째, 로고 이미지에 대체 텍스트가 있어야 합니다. 로고는 보통 이미지로 만들어지는데, 이미지에 alt 텍스트가 없으면 스크린리더 사용자는 "여기가 어느 기관 사이트인지"를 알 수 없습니다. "○○시청 홈으로 이동" 같은 식으로, 무엇이고 어디로 가는지 알 수 있게 해야 합니다. 로고가 단순 장식이 아니라 핵심 정보이자 기능(홈 링크)이기 때문에, 이 대체 텍스트는 선택이 아니라 필수입니다.

2) 전역 내비게이션(GNB) — 키보드로 끝까지 갈 수 있어야 한다

헤더의 핵심 기능인 주 메뉴. 여기서 가장 많이 깨지는 게 키보드 접근성입니다. 마우스를 올리면(hover) 하위 메뉴가 펼쳐지는 방식의 메뉴가 많은데, 키보드 사용자는 마우스를 올릴 수 없습니다. 그러니 hover에만 의존하면 키보드로는 하위 메뉴에 도달조차 못 합니다.

KRDS와 웹 접근성 기준이 요구하는 건 이렇습니다.

Tab으로 메뉴 항목을 순서대로 이동할 수 있어야 한다.
포커스를 받았을 때(또는 Enter/Space로) 하위 메뉴가 펼쳐져야 한다(hover뿐 아니라).
방향키로 메뉴 안을 탐색할 수 있으면 더 좋다.
Esc로 펼친 메뉴를 닫을 수 있어야 한다.
펼침/접힘 상태가 aria-expanded 같은 속성으로 코드에 표현되어, 스크린리더가 "펼침/접힘"을 읽어 줄 수 있어야 한다.

메뉴가 펼쳐졌는지 접혔는지를 눈으로만 알 수 있게 만들면, 음성으로 쓰는 사용자는 자기가 메뉴를 연 건지 닫은 건지 알 수 없습니다. 시각 정보가 반드시 코드로도 전달되어야 한다는 게 핵심입니다.

3) 검색 — 입력창과 버튼 모두 이름이 있어야 한다

헤더의 검색은 사용자가 가장 많이 쓰는 기능 중 하나입니다. 그런데 검색창이 돋보기 아이콘 버튼 하나로만 되어 있고, 입력 필드에 라벨이 없는 경우가 흔합니다.

검색 입력 필드에 접근 가능한 이름(label 또는 aria-label, 예: "사이트 내 검색")이 있어야 합니다.
검색 실행 버튼(돋보기 아이콘 전용)에도 이름이 있어야 합니다. 아이콘만 있고 텍스트가 없으면 스크린리더는 그냥 "버튼"으로만 읽습니다. aria-label="검색"처럼 이름을 줘야 합니다.
검색을 펼침/접힘 토글로 만든 경우, 그 토글 버튼에도 상태(aria-expanded)와 이름이 필요합니다.

검색은 "기능이 작동하는가"만 보면 안 됩니다. "모든 사용자가 그 기능에 도달할 수 있는가"까지 봐야 합니다.

4) 유틸리티 — 로그인 상태가 명확히 드러나야 한다

로그인/로그아웃, 회원가입, 마이페이지 같은 유틸리티 링크들. 여기서 중요한 건 현재 로그인 상태가 명확히 드러나는가입니다. 로그인했는데도 헤더에 여전히 "로그인" 버튼만 보이면 사용자는 헷갈립니다. 로그인 후에는 "로그아웃" 또는 사용자 이름이 보여서, 지금 인증된 상태임을 알 수 있어야 합니다.

언어 전환, 글자 크기 조절 같은 보조 기능들도 유틸리티 영역에 자주 들어가는데, 이것들도 마찬가지로 아이콘만 있다면 이름을 붙여야 하고, 키보드로 조작 가능해야 합니다.

5) 본문 바로가기(Skip to content) — 헤더의 숨은 필수 요건

이건 의외로 많이 빠뜨리는, 그러나 매우 중요한 요건입니다. 헤더에는 메뉴가 많습니다. 키보드 사용자가 매 페이지마다 그 많은 메뉴를 Tab으로 다 지나쳐야 본문에 도달한다면, 그것만으로도 엄청난 피로입니다.

그래서 페이지 맨 처음(헤더보다도 앞)에 "본문 바로가기" 링크를 두는 게 표준입니다. 이 링크는 평소엔 화면에서 보이지 않다가, 키보드로 Tab을 누르면 가장 먼저 나타납니다. 누르면 반복되는 헤더 메뉴를 건너뛰고 본문으로 바로 점프합니다. 한국형 웹 접근성 지침에서도 "반복 영역 건너뛰기"를 요구합니다. 헤더 자체의 요건은 아니지만, 헤더라는 "반복되는 영역"이 있기 때문에 생기는 짝꿍 요건이라, 헤더 점검 때 함께 봐야 합니다.

6) 시맨틱 구조 — `<header>`와 랜드마크

스크린리더 사용자는 페이지를 위에서 아래로 줄줄 읽기만 하는 게 아니라, "랜드마크(landmark)"라는 구조를 이용해 영역 단위로 빠르게 이동합니다. "배너 영역으로 가기", "내비게이션으로 가기"처럼요.

그래서 헤더는 단순한 <div>가 아니라 시맨틱한 구조로 만들어져야 합니다. 페이지 상단 헤더는 <header> 요소(또는 role="banner")로, 그 안의 주 메뉴는 <nav> 요소(또는 role="navigation")로 표시되어야 합니다. 이 구조가 있어야 스크린리더 사용자가 "헤더 건너뛰고 바로 본문"이나 "내비게이션으로 바로 이동" 같은 점프를 할 수 있습니다. <div class="header">처럼 의미 없는 껍데기로만 만들면, 보기엔 헤더지만 보조기술에겐 그냥 평범한 상자 덩어리입니다.

7) 모바일 대응 — 햄버거 메뉴의 함정

작은 화면에서 헤더는 보통 접힙니다. 메뉴는 햄버거(줄 세 개) 버튼 뒤로 숨고, 누르면 펼쳐지죠. 이 모바일 헤더가 데스크톱보다 훨씬 자주 깨집니다.

햄버거 버튼에 이름이 있어야 한다("메뉴 열기" 등). 아이콘만 있으면 안 됩니다.
펼침/접힘 상태가 aria-expanded로 표현되어야 한다.
메뉴를 펼쳤을 때 닫을 방법이 명확해야 한다(닫기 버튼, Esc, 바깥 영역 탭 등).
메뉴를 펼쳤을 때 포커스가 그 메뉴 안으로 들어가고, 닫으면 원래 자리로 돌아오면 더 좋다.
터치 영역이 충분해야 한다(메뉴 항목 한 변 약 44px 이상 권장).

특히 "닫을 방법이 없는 모바일 메뉴"는 생각보다 자주 봅니다. 펼치긴 했는데 X 버튼이 없고 Esc도 안 먹어서, 키보드 사용자가 메뉴 안에 갇히는 경우죠. 이건 사용자를 막다른 길에 가두는 치명적 결함입니다.

8) 일관성 — 모든 페이지에서 같은 헤더

헤더는 모든 페이지에 등장하니까, 페이지마다 헤더가 달라지면 사용자가 혼란스럽습니다. 메뉴 구성이 페이지마다 다르거나, 어떤 페이지엔 검색이 있고 어떤 페이지엔 없거나 하면, 사용자는 "여기가 같은 사이트가 맞나" 싶어집니다. 헤더의 구조와 동작은 사이트 전체에서 일관되어야 합니다. 이건 KRDS가 헤더를 표준 컴포넌트로 묶어 둔 핵심 이유이기도 합니다.

정리하면, KRDS의 헤더 기준은 크게 세 축입니다. ① 식별성(기관 정체성과 홈 복귀가 분명할 것), ② 조작 가능성(메뉴·검색·유틸리티가 키보드로 완전히 작동할 것), ③ 구조성(시맨틱 랜드마크와 본문 바로가기로 스크린리더가 영역을 넘나들 수 있을 것). 이 세 축이 그대로 ViewCheck가 헤더를 점검하는 기준이 됩니다.

왜 이렇게까지 따지나 — 원리와 배경

여기까지 읽고 "헤더 하나에 뭐 이리 따질 게 많나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만든 규칙이 아니라, 실제 사용자가 막히는 지점에서 거꾸로 도출된 것들입니다.

헤더는 "사이트의 첫인상이자 영구적 길잡이"

사용자가 사이트에 들어와 가장 먼저 보는 것도 헤더고, 길을 잃었을 때 돌아오는 곳도 헤더입니다. 헤더가 명확하면 사용자는 "여기가 어디고 어디로 갈 수 있는지"를 즉시 파악합니다. 헤더가 엉망이면, 사용자는 첫 화면부터 길을 잃습니다. 특히 공공 서비스는 "어쩌다 한 번" 방문하는 사용자가 많습니다. 매일 쓰는 사이트가 아니니까, 헤더의 안내가 부실하면 매번 헤매게 됩니다.

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

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

보이는 것과 읽히는 것의 분리

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

그래서 헤더는 "보기에 헤더 같은 것"으로는 부족하고, "코드 수준에서 헤더라고, 내비게이션이라고, 검색이라고 선언된 것"이어야 합니다. <div>에 메뉴처럼 보이는 글자를 늘어놓아도, 코드가 그걸 "내비게이션"이라고 말해 주지 않으면 스크린리더에겐 그냥 글자 덩어리입니다. 헤더 위반의 근본 원인 대부분이 이 "보이는 것 ≠ 읽히는 것" 문제로 수렴합니다.

곱하기 효과 — 한 번의 실수가 사이트 전체로

앞서 말했듯 헤더는 모든 페이지에 있습니다. 그래서 헤더의 작은 실수 하나가 사이트 전체로 증폭됩니다. 검색 버튼에 이름이 없으면 그건 100페이지짜리 사이트에서 100번 반복되는 실패입니다. 반대로 헤더를 한 번 제대로 만들면, 그 효과도 모든 페이지로 곱해집니다. 헤더가 "가장 먼저 점검하고 가장 먼저 고쳐야 할" 컴포넌트인 이유가 바로 이 곱하기 효과입니다. 투자 대비 효과가 가장 확실한 곳이거든요.

일관성이 곧 학습 비용 절감

KRDS가 헤더를 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 헤더 구조가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 메뉴가 어디 있지?"를 다시 배워야 합니다. 모든 공공 서비스의 헤더가 비슷한 구조로 작동하면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다.

헤더는 "신뢰의 첫 신호"이기도 하다

조금 다른 각도의 이야기입니다. 공공 사이트에서 헤더는 접근성뿐 아니라 신뢰의 문제이기도 합니다. 기관 로고가 또렷하고, 메뉴가 잘 정돈되어 있고, 검색과 로그인이 제자리에 있으면, 사용자는 무의식적으로 "여기는 제대로 운영되는 공식 사이트구나"라고 느낍니다. 반대로 헤더가 깨져 있거나 로고가 흐릿하거나 메뉴가 엉성하면, "여기 정말 공식 사이트 맞나?" 하는 의심이 생깁니다. 요즘은 정부 기관을 사칭한 가짜 사이트(피싱)도 많아서, 사용자가 헤더를 보고 진위를 가늠하는 경우가 적지 않습니다. 잘 만든 헤더는 그 자체로 "우리는 믿을 만하다"는 무언의 신호인 셈입니다. KRDS 표준을 따르는 일관된 헤더가 신뢰를 더 빠르게 쌓는 이유입니다.

"어쩌다 한 번" 방문자를 위한 설계

상업 사이트의 단골은 헤더 구조를 외우고 있어서 좀 불편해도 적응합니다. 그런데 공공 사이트의 방문자 상당수는 "1년에 한두 번" 오는 사람입니다. 연말정산 시즌에 잠깐, 이사할 때 잠깐, 자녀 입학 때 잠깐. 이런 비정기 방문자는 헤더에 절대적으로 의존합니다. 외운 게 없으니 매번 헤더의 안내를 새로 읽어야 하거든요. 그래서 공공 헤더는 "단골이 아닌 사람도 처음 보고 바로 이해할 수 있는가"를 기준으로 설계되어야 합니다. 헤더가 직관적일수록, 어쩌다 한 번 오는 국민이 헤매지 않고 볼일을 봅니다. 이게 KRDS가 헤더의 구조와 명료성을 강조하는 또 하나의 배경입니다.

공공 사이트가 자주 틀리는 지점 — 그리고 올바른 예

이제 현업에서 실제로 반복되는 헤더 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) 로고가 홈으로 안 간다

가장 기본적이면서 의외로 자주 깨지는 실수입니다. 로고가 그냥 이미지일 뿐, 링크가 아닌 경우.

나쁜 예: 헤더 좌측 로고가 <img>로만 있고 클릭해도 아무 반응 없음. 사용자가 길을 잃어 로고를 눌렀는데 홈으로 안 감.
올바른 예: 로고를 <a href="/">로 감싸 홈으로 이동하게 하고, 이미지에 "○○기관 홈으로 이동" 대체 텍스트를 부여.

실수 2) hover로만 펼쳐지는 메뉴

데스크톱에서 마우스를 올려야만 하위 메뉴가 펼쳐지는 방식. 보기엔 깔끔하지만 키보드 사용자에겐 벽입니다.

나쁜 예: :hover에만 하위 메뉴 펼침을 걸어 둠. Tab으로는 하위 메뉴에 도달 불가. aria-expanded도 없음.
올바른 예: 포커스를 받거나 Enter/Space를 누르면 펼쳐지고, Esc로 닫히며, aria-expanded로 상태를 코드에 표현. 가능하면 KRDS 킷의 내비게이션 코드를 사용.

실수 3) 아이콘만 있는 버튼에 이름이 없다

헤더의 검색(돋보기), 메뉴(햄버거), 설정(톱니바퀴) 버튼이 아이콘만 있고 텍스트가 전혀 없는 경우. 공공웹에서 가장 흔한 헤더 사고입니다.

나쁜 예: <button><svg>...</svg></button> 형태로 아이콘만. 스크린리더는 "버튼"으로만 읽음. 무슨 버튼인지 알 수 없음.
올바른 예: aria-label="검색", aria-label="메뉴 열기"처럼 이름을 부여하거나, 화면엔 안 보이지만 코드엔 있는 텍스트(visually hidden)를 넣음.

실수 4) 본문 바로가기가 없다

키보드 사용자가 매 페이지마다 헤더 메뉴 수십 개를 Tab으로 다 지나쳐야 본문에 도달하는 경우.

나쁜 예: 페이지 맨 앞에 본문 바로가기 링크가 없음. 키보드 사용자는 본문에 닿기까지 메뉴를 끝없이 통과해야 함.
올바른 예: 페이지 최상단에 평소엔 숨겨졌다가 Tab 시 나타나는 "본문 바로가기" 링크를 두고, 누르면 본문 영역으로 점프.

실수 5) `<div>`로만 만든 헤더 (랜드마크 부재)

헤더를 의미 없는 <div>로만 구성해서, 스크린리더가 "배너"나 "내비게이션" 랜드마크로 인식하지 못하는 경우.

나쁜 예: <div class="header">, <div class="gnb">. 랜드마크가 없어 영역 단위 이동 불가.
올바른 예: <header>(또는 role="banner")와 <nav>(또는 role="navigation")로 시맨틱하게 구성. 스크린리더가 영역을 넘나들 수 있음.

실수 6) 닫을 수 없는 모바일 메뉴

모바일에서 햄버거 메뉴를 펼쳤는데 닫을 방법이 마땅치 않은 경우.

나쁜 예: 메뉴를 펼치면 화면을 다 덮는데, X 버튼도 없고 Esc도 안 먹고 바깥 탭도 안 됨. 사용자가 메뉴에 갇힘.
올바른 예: 명확한 닫기(X) 버튼 + Esc 키 + 바깥 영역 탭으로 닫기 지원. 닫으면 포커스가 햄버거 버튼으로 복귀.

실수 7) 로그인 상태가 안 보인다

로그인했는데도 헤더에 여전히 "로그인" 버튼만 보이거나, 로그인 여부가 헷갈리는 경우.

나쁜 예: 로그인 후에도 헤더가 그대로. 사용자는 자기가 로그인 상태인지 모름.
올바른 예: 로그인 후 "로그아웃" 또는 사용자 이름·마이페이지가 노출되어, 인증 상태가 명확히 드러남.

실수 8) 포커스 표시 제거

헤더 메뉴를 키보드로 이동할 때 지금 어디 있는지 안 보이는 경우. 디자인 통일성을 위해 outline: none으로 포커스 링을 지워서요.

나쁜 예: 메뉴 항목에 outline: none. 키보드로 옮겨 다녀도 현재 위치가 안 보임.
올바른 예: 포커스 시 또렷한 테두리·외곽선 유지. 디자인과 어울리게 다듬되 절대 지우지 않음.

실수 9) 검색 입력창에 라벨이 없다

검색 돋보기 버튼엔 신경 쓰면서, 정작 글자를 입력하는 입력창(<input>)에는 라벨을 안 다는 경우가 많습니다. 화면엔 입력창 안에 "검색어를 입력하세요"라는 플레이스홀더만 있고요.

나쁜 예: 입력창에 placeholder="검색어 입력"만 있고 라벨이 없음. 스크린리더는 "편집창"으로만 읽고, 무엇을 입력하는 칸인지 안내가 약함. 플레이스홀더는 글자를 치기 시작하면 사라져 버려 맥락도 잃음.
올바른 예: 화면엔 안 보이더라도 코드엔 "사이트 내 검색" 같은 라벨을 연결(visually hidden label 또는 aria-label). 플레이스홀더는 보조 안내로만 두고 라벨을 대체하지 않음.

실수 10) 헤더가 본문을 가리는 고정(sticky) 헤더의 함정

스크롤해도 헤더가 화면 위에 계속 붙어 있는 "고정 헤더"가 유행입니다. 보기엔 편한데, 잘못 만들면 접근성 함정이 됩니다.

나쁜 예: 고정 헤더의 높이가 너무 커서, 본문 바로가기로 점프하거나 페이지 내 앵커로 이동했을 때 목표 지점이 헤더에 가려 안 보임. 키보드로 본문에 포커스를 옮겼는데 그 요소가 헤더 뒤에 숨음.
올바른 예: 고정 헤더 높이를 적정하게 유지하고, 앵커 이동 시 헤더 높이만큼 여백(scroll-margin 등)을 확보해 목표 지점이 가려지지 않게 함. 모바일에서는 화면을 너무 많이 차지하지 않도록 주의.

실수 11) 메뉴 깊이가 너무 깊다

대형 공공 사이트일수록 메뉴를 3단, 4단까지 파고들게 만드는 경우가 있습니다. 마우스로도 따라가기 벅찬데 키보드·스크린리더로는 더더욱 미궁입니다.

나쁜 예: 대분류 > 중분류 > 소분류 > 세부 항목까지 hover로 펼쳐지는 4단 메가 메뉴. 키보드로는 단계마다 펼침 처리가 빠져 도중에 막힘.
올바른 예: 메뉴 깊이를 가능한 한 얕게(2단 권장) 설계하고, 깊은 구조가 불가피하면 메가 메뉴를 한 번에 펼쳐 키보드로 한눈에 탐색할 수 있게 구성. 구조가 복잡할수록 KRDS 표준 패턴을 따르는 게 안전.

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

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 헤더, 좌측에 로고, 가운데 주 메뉴, 우측에 검색·로그인이 있다고 합시다.

먼저 마우스를 쓰는 김 주무관. 메뉴에 마우스를 올리니 하위 메뉴가 스르륵 펼쳐지고, 원하는 항목을 클릭합니다. 검색 돋보기를 누르니 입력창이 나오고, 키워드를 칩니다. 3초도 안 걸렸습니다. 김 주무관에게 이 헤더는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 페이지에 들어옵니다. 그런데 "본문 바로가기"가 없어서, 본문을 들으려면 헤더의 메뉴 스무 개를 전부 Tab으로 지나쳐야 합니다. 겨우 검색에 도달했는데, 돋보기 버튼이 "버튼"으로만 읽히고 무슨 버튼인지 알 수 없습니다(아이콘 이름 없음). 주 메뉴에 닿아 Enter를 눌렀지만 하위 메뉴가 펼쳐지지 않습니다. hover에만 걸려 있어서요(키보드 미지원). 박 선생님은 결국 원하는 페이지를 못 찾고 사이트를 떠납니다.

같은 헤더, 같은 화면. 한 사람에겐 3초짜리 자연스러운 탐색이고, 다른 한 사람에겐 출구 없는 미로입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에 생긴 차이입니다. KRDS의 헤더 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 본문 바로가기를 넣고, 검색 버튼에 이름을 주고, 메뉴를 키보드로 펼치게 만들었다면 어땠을까요. 박 선생님의 스크린리더는 "본문 바로가기 링크"를 가장 먼저 읽어 한 번에 본문으로 점프했을 거고, 메뉴는 Enter로 펼쳐 방향키로 탐색했을 겁니다. 김 주무관과 비슷한 시간에 원하는 곳에 닿았겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 패턴을 따르느냐"라는 작은 선택입니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 헤더·내비게이션 관련 코드가 들어 있어, 키보드 동작과 ARIA 속성, 시맨틱 구조가 이미 구현된 상태로 시작할 수 있습니다. "헤더 접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다. 특히 본문 바로가기, hover/focus 양쪽 펼침, 모바일 메뉴 닫기 처리처럼 직접 만들다 빠뜨리기 쉬운 부분이 미리 들어 있습니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더와 내비게이션 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 데스크톱/모바일 분기, 메뉴 펼침 상태, 검색·유틸리티 배치가 기준에 맞춰집니다. 시안 단계에서 "포커스 상태는 어떻게 보일지", "모바일에서 메뉴를 어떻게 닫을지"까지 정의해 두면 개발 단계의 누락이 줄어듭니다.

기획자라면 — 화면 정의서에 "헤더"라고만 적지 말고, "헤더(로고=홈 링크, GNB 키보드 지원, 검색 입력+버튼 이름, 본문 바로가기, 모바일 메뉴 닫기 방법 포함)"처럼 요건을 함께 명시하세요. 특히 "로그인 전/후 헤더가 어떻게 달라지는가", "모바일에서 어떤 요소가 우선 노출되는가"를 정의해 두면 디자인·개발 단계의 혼선을 막습니다. 이 한 줄이 사이트 전체에 곱해지는 누락을 막습니다.

그래서 우리 사이트는? — ViewCheck로 5분 자가진단

여기까지가 KRDS의 헤더 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 헤더는 이걸 다 지키고 있나?"를 확인하는 일입니다. 로고가 홈으로 가는지, 검색 버튼에 이름이 있는지, 메뉴가 키보드로 펼쳐지는지, 본문 바로가기가 있는지, 모바일에서 메뉴가 닫히는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 게다가 헤더는 모든 페이지에 있으니, 페이지마다 확인하려 들면 정말 끝이 없죠.

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

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

기관 식별과 홈 링크: 헤더에 로고/기관 식별이 있는지, 그것이 링크로 연결되어 있는지, 로고 이미지에 대체 텍스트가 있는지
내비게이션 구조: 주 메뉴가 시맨틱하게(<nav> 등) 구성되어 있는지, 펼침/접힘 상태(aria-expanded)가 코드로 표현되는지
검색 접근성: 검색 입력 필드와 실행 버튼에 접근 가능한 이름이 있는지
랜드마크: 헤더가 <header>/role="banner"로 인식되는지, 본문 바로가기 같은 반복 영역 건너뛰기가 있는지
터치 영역: 모바일 뷰포트에서 헤더 메뉴·버튼이 최소 권장 크기를 충족하는지(반응형 품질 분석과 연계)

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

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 헤더 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "헤더 검색 버튼에 접근 가능한 이름 없음 — 전체 페이지" 처럼요. 헤더는 모든 페이지에 있으니, 한 번 미통과로 잡히면 보통 사이트 전체에 영향을 미치는 항목으로 표시됩니다. 그래서 헤더 항목은 고쳤을 때 효과가 가장 큰 개선 대상으로 우선순위(P0~P3)가 높게 매겨지는 경우가 많습니다.

여러 페이지를 한꺼번에 분석하면, "메인 페이지 헤더는 본문 바로가기가 있는데 하위 페이지엔 없다" 같은 페이지별 편차도 드러납니다(헤더가 페이지마다 다르게 들어간 경우). 이런 편차는 손으로는 절대 못 잡는 부분인데, 자동 점검이 한눈에 보여 줍니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 헤더 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "헤더 잘 만들자"가 아니라, "이 헤더의 검색 버튼에 이름을 주고, 본문 바로가기를 넣자"는 구체적인 작업 목록이 됩니다. 헤더는 곱하기 효과가 있으니, 이 작은 목록 하나가 사이트 전체 점수를 끌어올립니다.

자주 묻는 질문

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

Q. 헤더 메뉴를 hover로 펼치는 게 보기 좋은데, 꼭 키보드로도 펼쳐지게 해야 하나요?

네, 반드시요. hover는 마우스 사용자에게만 작동합니다. 키보드 사용자는 마우스를 올릴 수 없으니, hover에만 의존하면 그들은 하위 메뉴에 영영 도달하지 못합니다. 해결은 어렵지 않습니다. hover에 더해 포커스(focus)와 Enter/Space로도 펼쳐지게 하고, Esc로 닫히게 하면 됩니다. 둘 중 하나를 버리는 게 아니라 둘 다 지원하는 거죠. KRDS 킷의 내비게이션 코드에는 이게 이미 들어 있습니다. "예쁘게"와 "누구나 쓸 수 있게"는 충돌하는 목표가 아닙니다.

Q. 본문 바로가기(Skip to content)는 화면에 안 보이는데, 정말 필요한가요?

필요합니다. 오히려 "평소엔 안 보이고 키보드 Tab 시에만 나타나는" 게 정상 동작입니다. 마우스 사용자에겐 필요 없지만, 키보드 사용자에겐 매 페이지마다 헤더 메뉴 수십 개를 건너뛰게 해 주는 생명줄입니다. 헤더가 반복되는 영역이기 때문에 생긴 짝꿍 요건이라, 헤더 점검 때 꼭 함께 봐야 합니다. 구현도 간단합니다. 페이지 맨 앞에 본문 영역을 가리키는 링크를 두고, 평소엔 화면 밖으로 숨겼다가 포커스 시 나타나게 하면 됩니다.

Q. 로고에 alt 텍스트는 뭐라고 써야 하나요? "로고"라고만 쓰면 되나요?

"로고"만 쓰는 건 부족합니다. 로고는 두 가지 정보를 담고 있습니다. 하나는 "어느 기관인가", 또 하나는 "누르면 어디로 가는가(보통 홈)". 그래서 "○○시청 홈으로 이동"처럼 기관과 동작을 함께 담는 게 좋습니다. 단순히 "로고 이미지"라고만 하면 스크린리더 사용자는 그게 클릭 가능한 홈 링크라는 걸 알기 어렵습니다.

Q. 헤더를 `<div>`로 만들어도 보기엔 똑같은데, 왜 `<header>`를 써야 하나요?

보기엔 똑같지만 스크린리더에겐 전혀 다릅니다. <header>(또는 role="banner")와 <nav>로 만들면 스크린리더 사용자가 "배너 영역", "내비게이션 영역"으로 인식해서 영역 단위로 빠르게 점프할 수 있습니다. <div>로만 만들면 그런 랜드마크가 없어서, 사용자는 페이지를 처음부터 줄줄 다 들어야 합니다. 모양은 CSS로 만들지만, 의미는 HTML 태그로 만든다 — 이게 시맨틱 마크업의 핵심입니다.

Q. 모바일 햄버거 메뉴, 어떻게 만들어야 접근성 문제가 안 생기나요?

네 가지를 챙기세요. ① 햄버거 버튼에 이름("메뉴 열기") 주기, ② 펼침/접힘 상태를 aria-expanded로 표현하기, ③ 닫는 방법 명확히 하기(X 버튼 + Esc + 바깥 탭), ④ 메뉴를 펼치면 포커스가 그 안으로 들어가고 닫으면 햄버거 버튼으로 복귀하기. 특히 "닫을 방법이 없는 메뉴"는 사용자를 가두는 치명적 결함이니 꼭 확인하세요. 이것도 KRDS 킷을 쓰면 대부분 해결됩니다.

Q. 헤더가 모든 페이지에 있는데, 점검도 모든 페이지를 다 해야 하나요?

헤더가 모든 페이지에서 동일하다면, 메인 페이지 하나만 점검해도 대표성이 있습니다. 다만 공공 사이트는 의외로 페이지마다 헤더가 미묘하게 다른 경우가 있습니다(메인엔 검색이 있는데 하위엔 없다거나, 본문 바로가기가 일부 페이지에만 있다거나). 그래서 ViewCheck로 여러 페이지를 한꺼번에 분석하면, 이런 페이지별 편차까지 잡아냅니다. 시간이 없다면 메인부터, 여유가 있다면 신청·로그인·검색 같은 핵심 페이지를 함께 돌려 보는 걸 권합니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 헤더의 어떤 부분이 무슨 문제를 일으키는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 고치면 됩니다. 헤더는 곱하기 효과가 있어서, 검색 버튼 이름 하나, 본문 바로가기 하나만 추가해도 사이트 전체 점수가 눈에 띄게 오릅니다. 리뉴얼 예산을 한 번에 들이지 않고도 가장 효율적으로 점수를 끌어올릴 수 있는 게 바로 헤더입니다.

Q. 디자인팀과 개발팀이 헤더 접근성을 서로 미룹니다.

헤더 접근성은 어느 한 팀의 책임이 아니라 합작입니다. 디자이너는 포커스 상태·모바일 메뉴 닫기·로그인 전후 변화를 시안에 명시하고, 개발자는 그걸 시맨틱 마크업과 키보드 핸들러로 구현하고, 기획자는 헤더에 들어갈 요소와 동작을 정의해야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

Q. 고정(sticky) 헤더를 써도 되나요? 접근성에 문제는 없나요?

고정 헤더 자체는 문제가 아닙니다. 다만 두 가지를 챙겨야 합니다. 첫째, 헤더 높이가 너무 크면 작은 화면에서 본문을 너무 많이 가립니다. 모바일에서는 스크롤 시 헤더를 살짝 줄이거나 일부만 남기는 것도 방법입니다. 둘째, 페이지 내 앵커로 이동하거나 본문 바로가기로 점프했을 때, 목표 지점이 고정 헤더 뒤에 가려지지 않도록 여백(scroll-margin 등)을 확보해야 합니다. 이 처리를 안 하면 "분명히 그 위치로 갔는데 화면엔 헤더만 보이는" 황당한 상황이 생깁니다. 키보드 사용자에게 특히 치명적이니 꼭 확인하세요.

Q. 메뉴가 너무 많은 대형 사이트인데, 메가 메뉴를 써도 되나요?

써도 됩니다. 다만 메가 메뉴일수록 키보드 접근성이 더 어려워지니 더 꼼꼼히 만들어야 합니다. 한 번에 펼쳐서 키보드로 한눈에 탐색할 수 있게 하고, Esc로 닫히게 하고, 펼침 상태를 코드로 표현하세요. 그리고 가능하면 메뉴 깊이를 줄이는 게 근본 해법입니다. 4단 깊이 메뉴는 마우스 사용자에게도 피곤합니다. 정보 구조를 한 번 정리해서 2단으로 줄일 수 있다면, 그게 어떤 기술적 보완보다 효과적입니다.

Q. 다국어(영어/중국어 등) 전환 버튼은 헤더 어디에 두나요?

보통 유틸리티 영역(우측 상단)에 둡니다. 중요한 건 이 언어 전환 버튼도 키보드로 조작 가능해야 하고, 아이콘(지구본 등)만 있다면 이름을 붙여야 한다는 점입니다. 또 언어를 바꿨을 때 페이지 전체의 lang 속성도 함께 바뀌어야 스크린리더가 올바른 언어로 읽습니다. 시각적으로 언어만 바뀌고 코드상 lang이 한국어 그대로면, 외국어 페이지를 한국어 발음으로 읽는 이상한 일이 생깁니다.

Q. 헤더에 공지/긴급 배너를 띄우는데, 접근성 주의점이 있나요?

긴급 공지를 헤더 위나 안에 띄우는 경우가 많은데, 두 가지를 챙기세요. 하나는 닫을 수 있게 하되 닫기 버튼에 이름을 줄 것("공지 닫기"). 또 하나는 자동으로 사라지거나 빠르게 슬라이드되는 배너는 피할 것. 천천히 읽는 사용자나 스크린리더 사용자가 내용을 미처 파악하기 전에 사라지면 의미가 없습니다. 중요한 긴급 공지일수록 충분히 머무르게 하고, 사용자가 직접 닫게 하는 게 안전합니다.

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

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

가장 먼저(치명적) — 키보드로 메뉴가 아예 펼쳐지지 않거나(hover 전용), 모바일 메뉴를 닫을 방법이 없어 사용자가 갇히는 문제. 이건 특정 사용자에게 사이트 탐색 자체를 완전히 차단하는 문제라 1순위입니다. 헤더는 모든 페이지에 있으니, 여기가 막히면 사이트 전체가 막힙니다.

그다음(높음) — 아이콘 전용 버튼(검색·메뉴·설정)에 이름이 없는 문제, 본문 바로가기가 없는 문제, 헤더가 랜드마크로 인식되지 않는 문제. 작동은 하지만 스크린리더 사용자가 헤더를 이해하거나 빠져나갈 수 없으니 실질적 장벽입니다. 로고가 홈으로 안 가는 것도 여기 포함됩니다.

그 후(보통) — 로그인 상태가 명확하지 않은 문제, 포커스 표시가 제거된 문제, 모바일 터치 영역이 부족한 문제. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 페이지별 헤더 편차 정리, 유틸리티 영역 정돈 같은 일관성·사용성 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 특히 헤더는 곱하기 효과가 크니, 한정된 인력으로 가장 효과 큰 개선에 집중할 수 있습니다. 헤더 P0 하나를 고치는 게, 본문 어딘가의 P2 열 개를 고치는 것보다 사이트 전체에 미치는 영향이 클 때가 많습니다.

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

이 글은 KRDS의 헤더 기준을 자가진단 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

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

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

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

마지막으로, 디자이너·개발자·기획자가 헤더를 만들거나 검수할 때 바로 쓸 수 있는 자가진단 체크리스트로 정리합니다. ViewCheck를 돌리기 전에 눈으로 한 번 훑어도 좋고, 돌린 뒤 대조용으로 써도 좋습니다.

☐ 로고가 보이고, 누르면 홈으로 이동하며, 이미지에 "○○기관 홈으로 이동" 같은 대체 텍스트가 있다.
☐ 주 메뉴(GNB)가 키보드만으로 펼침·이동·확정·닫기(Esc)가 전부 된다(hover 전용이 아니다).
☐ 메뉴 펼침/접힘 상태가 `aria-expanded`로 코드에 표현된다.
☐ 검색 입력 필드에 접근 가능한 이름이 있다.
☐ 검색·메뉴·설정 등 아이콘 전용 버튼에 이름(aria-label 등)이 있다.
☐ 페이지 맨 앞에 본문 바로가기 링크가 있다(Tab 시 나타난다).
☐ 헤더가 `<header>`/`role="banner"`, 주 메뉴가 `<nav>`/`role="navigation"`으로 시맨틱하게 구성됐다.
☐ 모바일 햄버거 버튼에 이름이 있고, 메뉴를 닫을 방법(X 버튼·Esc·바깥 탭)이 명확하다.
☐ 로그인 상태가 헤더에 명확히 드러난다(로그인 후 로그아웃/사용자명 노출).
☐ 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
☐ 모바일에서 헤더 메뉴·버튼의 터치 영역이 충분하다(약 44px 이상).
☐ 헤더 구조와 동작이 모든 페이지에서 일관된다.

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

헤더는 작아 보이지만, 사용자가 사이트에서 하는 거의 모든 여정의 출발점이자 길잡이입니다. 그 맨 위의 띠 하나가 누군가에겐 서비스로 들어가는 문이고, 또 누군가에겐 출구 없는 미로입니다. 우리가 무심코 만든 hover 메뉴 하나가, 누군가에게는 그 사이트의 모든 서비스에 닿을 수 있느냐 없느냐를 가릅니다. 그것도 한 페이지가 아니라 모든 페이지에서요.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 단순합니다. 로고로 집에 갈 수 있게 하고, 메뉴를 키보드로 쓸 수 있게 하고, 아이콘 버튼에 이름을 주고, 본문 바로가기를 넣고, 헤더를 시맨틱하게 만드는 것. 이 다섯 가지만 챙겨도 헤더 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많은 사람을 막고 있는 헤더 문제 하나부터 고쳐 나가면, 그 효과가 사이트 전체로 곱해집니다. 다음 글에서는 헤더와 짝을 이루는 또 다른 전역 영역, 푸터(Footer)를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 헤더는 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 컴포넌트(Components) 탭에서 바로 보입니다. 헤더는 모든 페이지에 있으니, 여기 하나만 제대로 고쳐도 사이트 전체가 달라집니다.

#KRDS #헤더Header #공공웹 #디자인시스템 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #키보드접근성 #본문바로가기 #네비게이션 #자가진단 #헤더 #Header #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부