건너뛰기 링크(Skip link) 자가진단 — ViewCheck 5분 점검

키보드의 Tab 키만 눌러서 공공 사이트를 한 바퀴 돌아본 적 있으신가요. 마우스를 잠깐 치우고, 정말 Tab만으로 메인 페이지에서 "공지사항 첫 번째 글"까지 가 보세요. 한 번 세어 보면 깜짝 놀랍니다. 로고, 검색창, 로그인, 회원가입, 사이트맵, 그리고 1차 메뉴 7~8개, 거기에 마우스를 올리면 펼쳐지던 2차 메뉴까지 Tab으로는 하나하나 다 지나가야 하거든요. 본문에 도착하기까지 Tab을 30번, 많으면 50번 넘게 눌러야 하는 사이트가 수두룩합니다. 그것도 페이지를 옮길 때마다 매번 처음부터 다시.

마우스를 쓰는 사람에게는 이게 전혀 안 보입니다. 보고 싶은 곳을 그냥 클릭하면 되니까요. 그런데 키보드만 쓰는 사람, 스크린리더로 페이지를 듣는 사람에게는 이 "매번 메뉴를 처음부터 통과해야 하는 일"이 하루 종일 반복되는 고역입니다. 이 고역을 단 한 줄로 없애 주는 장치가 바로 건너뛰기 링크(Skip link) 입니다. "본문 바로가기"라고 적힌, 평소엔 안 보이다가 Tab을 누르면 화면 맨 위에 불쑥 나타나는 그 작은 링크요.

이 글은 "KRDS 완전해부" 시리즈 중에서도 조금 특별한 자리입니다. 앞선 글들이 "기준이 무엇인가"를 해부했다면, 이 글은 "우리 사이트가 그 기준을 지키는지 5분 만에 직접 확인하는 법" 에 무게를 둡니다. 건너뛰기 링크는 있고 없고가 비교적 명확해서 자가진단하기 딱 좋은 주제거든요. 그러니 이 글을 끝까지 읽고 나면, 거창한 도구 없이도 지금 당장 우리 사이트에 건너뛰기 링크가 있는지, 제대로 작동하는지 손수 점검할 수 있게 될 겁니다. 그리고 그 점검을 페이지 수십·수백 개로 확장하는 방법까지 이어가겠습니다.

미리 한 가지만 짚어 두면, 건너뛰기 링크는 "있으면 좋은 편의 기능"이 아니라 한국형 웹 접근성 지침(KWCAG)과 KRDS가 사실상 기본 요건으로 다루는 항목입니다. 작고 눈에 안 띄지만, 빠지면 키보드 사용자에게 매 페이지마다 수십 번의 헛수고를 강요하는, 결코 사소하지 않은 장치입니다.

건너뛰기 링크가 뭐길래 — 정의부터 정확히

먼저 정체를 분명히 하겠습니다. 건너뛰기 링크(Skip link, 또는 Skip navigation link)는 페이지의 반복되는 영역을 건너뛰고 곧장 원하는 영역(주로 본문)으로 이동시켜 주는 링크입니다. 영어로는 "Skip to content", 우리말로는 "본문 바로가기"가 가장 흔한 표현입니다.

핵심 특징이 셋 있습니다.

평소엔 숨어 있다: 마우스 사용자에게는 보이지 않습니다. 화면 위쪽 어딘가에 숨겨 두었다가, 키보드로 Tab을 처음 눌렀을 때 화면에 나타납니다.
페이지의 가장 첫 번째 초점 대상이다: Tab을 한 번만 눌러도 닿을 수 있도록, 보통 <body>가 열리자마자 가장 먼저 나오는 링크여야 합니다. 그래야 "메뉴를 다 지나가기 전에" 건너뛸 수 있으니까요.
누르면 본문으로 초점이 점프한다: 클릭(또는 Enter)하면 페이지의 본문 시작 지점으로 초점이 이동합니다. 그 뒤로 Tab을 누르면 본문 안의 링크부터 이어집니다.

쉽게 말하면, 긴 복도(반복 메뉴)를 매번 끝까지 걸어가지 않고 "본문 행 급행 엘리베이터"를 타는 장치입니다. 마우스 사용자는 이미 순간이동(클릭)을 쓰고 있으니 이 엘리베이터가 필요 없을 뿐입니다.

"본문 바로가기" 하나만 있으면 끝일까

가장 기본은 "본문 바로가기" 하나입니다. 하지만 KRDS가 권하는 잘 만든 형태는 건너뛰기 링크 묶음입니다. 페이지의 주요 영역으로 각각 점프하는 링크를 여러 개 둘 수 있습니다.

본문 바로가기 (가장 중요, 거의 필수)
주 메뉴(내비게이션) 바로가기
검색 영역 바로가기
(사이트에 따라) 푸터·로그인 영역 바로가기

이 묶음이 페이지 맨 위에 있으면, 키보드 사용자는 "지금 나는 본문을 보러 왔다 / 메뉴를 쓰러 왔다 / 검색하러 왔다"를 첫 Tab 몇 번 안에 선택할 수 있습니다. 매번 전체를 훑지 않아도 되는 거죠. 다만 너무 많은 건너뛰기 링크를 늘어놓으면 그것대로 부담이니, 본문·주메뉴·검색 정도의 핵심으로 절제하는 게 일반적입니다.

KRDS 공식 컴포넌트 문서와 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 보면, 이 "본문 바로가기/주요 영역 바로가기" 패턴이 헤더·레이아웃 구성의 일부로 정리되어 있습니다. KRDS가 이걸 굳이 표준 패턴으로 정의해 둔 이유는 단순합니다 — 모든 공공 사이트가 같은 방식으로 "맨 위에 본문 바로가기"를 두면, 키보드 사용자는 어느 정부 사이트에 가도 "첫 Tab을 누르면 본문 바로가기가 나온다"는 한 가지 습관만으로 통하게 되니까요.

KRDS와 KWCAG는 건너뛰기 링크에 무엇을 요구하나 — 기준 해부

이제 본론입니다. 건너뛰기 링크가 "제대로" 작동하려면 충족해야 하는 요건을, 영역별로 뜯어보겠습니다. 여기서 말하는 기준은 KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 한국형 웹 접근성 지침(KWCAG)의 "반복 영역 건너뛰기" 원칙을 종합한 것입니다.

1) 존재해야 한다 — 그것도 페이지 맨 앞에

가장 기본 중의 기본입니다. 건너뛰기 링크는 페이지에 존재해야 하고, 키보드 초점 순서상 가장 앞쪽에 있어야 합니다.

여기서 "가장 앞쪽"이 핵심입니다. 건너뛰기 링크를 만들어 놓고도 페이지 중간이나 헤더 아래쪽에 묻어 두면 의미가 없습니다. 메뉴를 다 지나간 다음에야 건너뛰기 링크가 나오면, 이미 건너뛸 게 없으니까요. 그래서 마크업상 <body> 바로 다음, 다른 어떤 링크보다도 먼저 나와야 합니다. Tab을 딱 한 번 눌렀을 때 건너뛰기 링크가 잡히는 게 이상적입니다.

2) 평소엔 숨고, 초점을 받으면 보여야 한다

건너뛰기 링크는 마우스 사용자에게는 보이지 않는 게 일반적입니다. 디자인을 해치지 않으면서 키보드 사용자에게만 기능을 제공하기 위해서죠. 그런데 여기서 흔히 두 가지 잘못된 방식으로 "숨김"을 구현합니다.

잘못된 숨김 ①: display: none 또는 visibility: hidden으로 숨김 → 이러면 키보드 초점도 못 받습니다. 즉 Tab을 눌러도 나타나지 않습니다. "있긴 한데 영영 안 보이는" 죽은 링크가 됩니다.
잘못된 숨김 ②: 화면 밖으로 보내 놓고 초점을 받아도 제자리로 돌아오지 않게 함 → 키보드 사용자가 Tab을 눌러 초점이 그 링크에 갔는데도 화면엔 아무것도 안 보입니다. 초점은 보이지 않는 곳에 가 있고, 사용자는 "지금 어디에 있지?" 길을 잃습니다.

올바른 방식은, 평소엔 화면 밖(또는 시각적으로 가려진 상태)에 두되, 초점을 받는 순간(`:focus`) 화면 안으로 또렷이 드러나게 하는 것입니다. Tab을 눌렀을 때 화면 맨 위에 "본문 바로가기"가 박스 형태로 쏙 나타나는 그 동작이 정답입니다. 보였다가, 초점이 떠나면 다시 숨습니다.

3) 눌렀을 때 정말로 본문으로 초점이 이동해야 한다

이게 의외로 가장 많이 깨지는 지점입니다. 건너뛰기 링크가 보이기까지는 하는데, 눌러도 본문으로 안 가는 경우가 정말 많습니다.

건너뛰기 링크는 보통 <a href="#main">본문 바로가기</a> 형태이고, 본문 영역에는 id="main"을 가진 대상이 있어야 합니다. 그런데 이 연결이 깨지는 경우가 흔합니다.

건너뛰기 링크의 href가 가리키는 id가 페이지에 아예 없음 → 눌러도 아무 일도 안 일어남
id는 있는데 그게 본문이 아니라 엉뚱한 곳을 가리킴
링크를 눌러 "위치"는 본문으로 갔는데 초점(focus) 은 안 따라감 → 화면은 본문으로 스크롤됐지만, Tab을 다시 누르면 또 맨 위 메뉴부터 시작

특히 마지막이 함정입니다. "본문으로 스크롤은 됐으니 됐다"고 착각하기 쉬운데, 정작 다음 Tab이 본문이 아니라 다시 헤더로 가 버리면 건너뛰기는 무효입니다. 그래서 대상 영역에 tabindex="-1"을 주어 그 지점이 실제로 초점을 받을 수 있게 만들고, 링크 클릭 시 그 대상으로 초점이 이동하도록 하는 게 정석입니다. "위치 이동"이 아니라 "초점 이동" 이 핵심입니다.

4) 링크 텍스트가 명확해야 한다

건너뛰기 링크의 텍스트는 그 자체로 무엇을 하는지 분명해야 합니다. "본문 바로가기", "주요 콘텐츠로 이동", "메뉴 건너뛰기"처럼요. 스크린리더 사용자는 페이지를 처음 들을 때 이 링크를 가장 먼저 만나게 되므로, 이름만 듣고 "아, 본문으로 점프하는 거구나"를 바로 이해할 수 있어야 합니다.

반대로 "skip", "이동", "여기" 같은 모호한 텍스트는 곤란합니다. 무엇을 건너뛰어 어디로 가는지가 드러나지 않으니까요. 짧되 목적이 분명한 표현이 좋습니다.

5) 초점 표시가 또렷해야 한다

건너뛰기 링크가 나타났을 때, 그게 "지금 초점을 받았다"는 게 시각적으로 분명해야 합니다. 다른 모든 키보드 조작 요소와 마찬가지로 포커스 표시(테두리·외곽선)가 또렷해야 하고, 배경과의 대비도 충분해야 합니다. 모처럼 나타난 건너뛰기 링크가 흐릿한 회색이라 잘 안 보이면, 키보드 사용자는 그게 나타난 줄도 모르고 지나칩니다.

6) 반복 영역마다 일관되게

다중 페이지 사이트에서는 모든 페이지에 건너뛰기 링크가 일관되게 있어야 합니다. 메인에는 있는데 신청 페이지에는 없으면, 정작 입력이 많아 키보드 부담이 큰 페이지에서 건너뛰기를 못 쓰게 됩니다. 보통 헤더를 공통 컴포넌트로 만들면 건너뛰기 링크도 자동으로 모든 페이지에 들어가지만, 일부 페이지가 다른 레이아웃을 쓰면 거기서 빠지기 쉽습니다. "전 페이지 일관성"이 중요한 이유입니다.

정리하면, 건너뛰기 링크의 요건은 네 가지로 압축됩니다. ① 존재(페이지 맨 앞에 있을 것), ② 노출(초점 받으면 보일 것), ③ 작동(누르면 본문으로 초점이 실제 이동할 것), ④ 일관성(모든 페이지에 같은 방식으로). 이 네 가지는 그대로 우리가 자가진단할 체크포인트가 됩니다.

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

"본문 바로가기 링크 하나에 뭘 이렇게까지" 싶으실 수 있습니다. 그런데 이 작은 링크의 가치는 "건너뛰는 횟수"를 헤아려 보면 분명해집니다.

Tab 50번 × 페이지 수 = 매일 쌓이는 피로

마우스 사용자는 본문을 보고 싶으면 본문을 클릭합니다. 한 번에 끝. 그런데 키보드 사용자는 페이지의 모든 초점 요소를 순서대로 지나가야 합니다. 공공 사이트의 헤더에는 로고, 검색, 로그인/회원가입, 사이트맵, 그리고 GNB(주 메뉴) 항목 7~8개와 그 하위 메뉴들이 줄지어 있죠. 본문에 닿기까지 Tab을 수십 번 눌러야 합니다.

문제는 이게 페이지를 옮길 때마다 처음부터 반복된다는 점입니다. 한 사이트에서 공지 → 상세 → 첨부파일 → 신청서로 넘어가며 다섯 페이지를 본다면, 매 페이지마다 메뉴를 다시 통과해야 합니다. 건너뛰기 링크 하나가 이 반복을 "첫 Tab 한 번 + Enter"로 끝내 줍니다. 작아 보이지만, 누군가의 하루에서 수백 번의 헛 Tab을 없애 주는 장치인 셈입니다.

키보드 사용자 = 시각장애인만이 아니다

흔한 오해가 "키보드 사용자는 시각장애인뿐"이라는 생각입니다. 아닙니다. 건너뛰기 링크의 수혜자는 생각보다 넓습니다.

스크린리더 사용자: 페이지를 순서대로 들으므로 반복 메뉴를 매번 다 듣지 않으려면 건너뛰기가 필수입니다.
지체장애·손 사용이 불편한 사용자: 마우스 대신 키보드나 스위치 장치를 쓰는 분들. Tab을 적게 누를수록 부담이 줍니다.
마우스를 일시적으로 못 쓰는 상황: 한 손에 짐을 들었거나, 트랙패드가 고장 났거나, 떨림이 있어 정밀 클릭이 어려운 경우.
고령 사용자: 정밀한 마우스 조작이 어려워 키보드를 선호하는 분들도 적지 않습니다.

즉 건너뛰기 링크는 특정 소수만의 기능이 아니라, "마우스 없이 웹을 쓰는 모든 상황"을 위한 장치입니다.

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

상업 사이트는 불편하면 떠나면 그만입니다. 그런데 공공 서비스는 대체재가 없습니다. 세금을 내고, 증명서를 떼고, 복지를 신청하는 일은 그 사이트에서만 됩니다. 키보드 사용자가 매 페이지 메뉴를 30번씩 통과해야 한다면, 그건 단순 불편이 아니라 행정 서비스 접근권의 실질적 침해입니다. 비장애인이 30초에 끝낼 민원을, 누군가는 Tab을 수백 번 누르며 몇 배의 시간을 들여야 한다면 그 자체가 불평등이죠. KWCAG가 "반복 영역 건너뛰기"를 기본 항목으로 두는 이유가 여기 있습니다.

보이는 것 ≠ 작동하는 것

건너뛰기 링크에서 특히 두드러지는 원리가 "보이는 것과 작동하는 것은 다르다"입니다. 코드에 <a href="#main">본문 바로가기</a>라고 떡하니 적혀 있어도, #main 대상이 없거나 초점이 안 따라가면 그건 작동하지 않는 장식일 뿐입니다. 마우스 사용자는 어차피 안 보이니 문제를 영영 모르고, 개발자도 마우스로만 테스트하니 "있으니 됐다"고 넘어갑니다. 그래서 건너뛰기 링크는 반드시 키보드로 직접 눌러 봐야 진짜 작동 여부를 알 수 있습니다. 이 점이 뒤에서 다룰 자가진단이 중요한 이유입니다.

작아서 방치되고, 안 보여서 잊힌다

건너뛰기 링크가 유독 자주 빠지거나 망가지는 데에는 구조적인 이유가 있습니다. 첫째, 평소엔 안 보입니다. 화면에 드러나지 않으니 디자인 검수에서도, QA에서도 시야 밖으로 밀려납니다. 누구도 "지금 화면에 안 보이는 그 링크"를 일부러 떠올려 점검하지 않거든요. 둘째, 만든 사람은 마우스로 테스트합니다. 개발·디자인·기획 모두 마우스를 쥐고 화면을 확인하는데, 건너뛰기 링크는 마우스로는 존재 자체가 드러나지 않습니다. 그래서 "작동한다"는 착각이 끝까지 깨지지 않습니다. 셋째, 리뉴얼·페이지 추가에서 가장 먼저 누락됩니다. 새 템플릿을 만들거나 특정 페이지만 별도 레이아웃을 쓰면, 헤더에 묻어 있던 건너뛰기 링크가 조용히 빠집니다. 이 세 가지가 겹쳐서, 건너뛰기 링크는 "있어야 하는데 슬그머니 사라지는" 대표적 요소가 됩니다. KWCAG와 KRDS가 이걸 굳이 명시적 항목으로 두는 건, 이렇게 잊히기 쉬운 곳에 최소한의 안전장치를 박아 두기 위해서입니다.

잠깐 — 건너뛰기 링크는 어디서 왔나

건너뛰기 링크는 디자인 트렌드가 아니라, 실제 사용자의 고통에서 역으로 도출된 장치입니다. 웹 초창기, 페이지마다 똑같은 메뉴가 상단에 길게 반복되던 시절부터 "스크린리더 사용자가 매 페이지 같은 메뉴를 처음부터 다시 듣는다"는 문제가 제기됐습니다. 그 해법으로 "반복되는 영역을 건너뛸 수 있는 메커니즘을 제공하라"는 원칙이 국제 웹 접근성 표준에 자리 잡았고, 한국의 KWCAG도 같은 취지의 항목을 둡니다. 즉 건너뛰기 링크는 누군가의 미적 취향이 아니라, 수많은 사용자가 "매번 같은 메뉴를 또 들어야 하는" 고통을 호소한 끝에 만들어진 합의입니다. 이 배경을 알면, 건너뛰기 링크를 "옵션"이 아니라 "기본"으로 다뤄야 하는 이유가 분명해집니다.

한 장면 — 같은 사이트, 두 사람

추상적인 설명보다 한 장면이 빠를 것 같습니다. 어느 ○○시 공공 서비스 사이트의 "지원금 신청 안내" 페이지. 헤더에 메뉴가 빼곡합니다.

먼저 마우스를 쓰는 김 주무관. 페이지가 열리자 본문 "신청 자격" 단락을 그냥 클릭해 읽기 시작합니다. 옆 페이지로 넘어가도 마찬가지. 메뉴가 몇 개든 그에게는 아무 상관이 없습니다. 그래서 이 사이트를 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 페이지에 들어옵니다. 첫 Tab. "○○시 로고, 링크." 두 번째 Tab. "통합검색, 입력란." 세 번째, 네 번째… "로그인", "회원가입", "사이트맵", 그리고 "주요사업", "시정소식", "정보공개"… 1차 메뉴를 다 듣고, 일부 메뉴는 펼쳐지며 하위 항목까지 줄줄이. 박 선생님이 "신청 자격" 본문에 닿았을 땐 이미 Tab을 40번 넘게 누른 뒤입니다. 그리고 다음 안내 페이지로 넘어가니, 또 처음부터.

같은 사이트, 같은 정보. 한 사람에겐 클릭 한 번이고, 다른 한 사람에겐 페이지마다 반복되는 40번의 Tab입니다. 그런데 이 사이트 헤더 맨 위에 "본문 바로가기" 링크 하나만 제대로 있었다면, 박 선생님의 첫 Tab은 "본문 바로가기, 링크"였을 거고, Enter 한 번에 곧장 "신청 자격"으로 갔을 겁니다. 김 주무관과 거의 같은 속도로요.

이 차이를 만드는 비용은 놀랄 만큼 작습니다. 헤더 맨 위에 링크 한 줄, 본문에 id 하나, 그리고 초점이 따라가게 하는 약간의 처리. 그게 전부입니다. 건너뛰기 링크 점검이 중요한 건, 이 작은 한 줄이 있는지 없는지가 누군가의 하루를 완전히 바꾸기 때문입니다.

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

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

실수 1) 아예 없다

가장 단순하고 가장 흔합니다. 건너뛰기 링크 자체가 없는 페이지. 헤더에 메뉴는 풍성한데 본문 바로가기는 없어, 키보드 사용자는 매번 전체 메뉴를 통과해야 합니다.

나쁜 예: <body>가 열리자마자 바로 로고·메뉴. 본문까지 Tab 수십 번.
올바른 예: <body> 바로 다음에 <a href="#main" class="skip-link">본문 바로가기</a>. 첫 Tab으로 잡힘.

실수 2) `display: none`으로 숨겨 죽은 링크가 됨

"마우스엔 안 보이게 하자"며 display: none이나 visibility: hidden을 써 버립니다. 그러면 키보드 초점도 못 받아, Tab을 눌러도 영영 안 나타납니다.

나쁜 예: .skip-link { display: none; } → 코드엔 있지만 키보드로도 못 씀.
올바른 예: 화면 밖으로 보내는 방식으로 숨기고(position: absolute; left: -9999px; 또는 clip 기법), :focus일 때 화면 안으로 끌어옴(.skip-link:focus { left: 0; top: 0; ... }).

실수 3) 초점을 받아도 안 보임

화면 밖으로 보내 놓고는, 초점을 받았을 때 제자리로 돌려놓는 :focus 스타일을 빠뜨립니다. 그러면 초점은 그 링크에 가 있는데 화면엔 아무것도 안 나타나, 키보드 사용자가 길을 잃습니다.

나쁜 예: 숨김만 있고 :focus 복귀 스타일 없음. Tab 눌렀는데 시각적으로 아무 변화 없음.
올바른 예: :focus 시 화면 상단에 또렷한 박스로 등장. 초점 표시도 분명히.

실수 4) 눌러도 본문으로 안 감 (대상 `id` 없음)

건너뛰기 링크는 멀쩡히 보이는데, href="#main"이 가리키는 id="main"이 페이지에 없습니다. 눌러도 아무 일이 안 일어납니다.

나쁜 예: 링크는 #content를 가리키는데 본문엔 id="content"가 없음. 클릭해도 그대로.
올바른 예: 본문 시작 요소에 id="main"(또는 링크가 가리키는 바로 그 id) 부여. <main id="main" tabindex="-1">.

실수 5) 위치는 가는데 초점이 안 따라감

링크를 누르면 본문으로 스크롤은 됩니다. 그런데 그다음 Tab을 누르면 또 헤더 메뉴부터 시작합니다. 초점이 본문으로 옮겨 가지 않았기 때문입니다.

나쁜 예: 대상에 tabindex가 없어 초점을 못 받음 → 스크롤만 되고 Tab은 다시 맨 위로.
올바른 예: 대상에 tabindex="-1"을 주어 초점을 받게 하고, 링크 동작 시 그 대상으로 초점 이동. 이후 Tab이 본문부터 이어짐.

실수 6) 페이지마다 들쭉날쭉

메인에는 건너뛰기 링크가 있는데, 하위 페이지나 신청 폼 페이지에는 없습니다. 정작 입력이 많아 키보드 부담이 큰 곳에서 빠지는 거죠.

나쁜 예: 메인만 있고 게시판·신청 페이지엔 없음. 일관성 붕괴.
올바른 예: 헤더를 공통 컴포넌트로 만들어 모든 페이지에 건너뛰기 링크가 동일하게 포함.

실수 7) 텍스트가 모호함

링크 텍스트가 "skip", "이동", "바로가기"처럼 무엇을 건너뛰어 어디로 가는지 알 수 없게 적혀 있습니다.

나쁜 예: <a href="#main">skip</a> → 무엇을 skip하는지 불명확.
올바른 예: "본문 바로가기", "주요 콘텐츠로 이동"처럼 목적이 분명한 한국어 표현.

실수 8) 초점 표시가 흐릿하거나 가려짐

건너뛰기 링크가 나타나긴 하는데 연한 색이라 잘 안 보이거나, 다른 고정 헤더에 가려져 화면 밖으로 밀려납니다.

나쁜 예: 흐린 회색 링크, 또는 position: fixed 헤더 뒤에 숨어 안 보임.
올바른 예: 충분한 대비의 또렷한 박스로, 다른 요소보다 위(z-index)에 화면 안에 분명히 표시.

5분 셀프 점검 — 지금 바로 해보기

자, 이제 이 글의 핵심입니다. 거창한 도구 없이, 지금 우리 사이트에서 건너뛰기 링크를 직접 점검해 볼 수 있습니다. 마우스에서 손을 떼고 키보드만으로 따라 해 보세요. 채 5분이 안 걸립니다.

1단계 — 첫 Tab을 눌러 보세요.

우리 사이트 메인 페이지를 열고, 페이지 안의 아무 곳도 클릭하지 않은 상태(주소창에서 막 들어온 상태)에서 키보드 Tab 키를 딱 한 번 누릅니다. 화면 맨 위에 "본문 바로가기" 같은 링크가 쏙 나타나나요?

나타난다 → ①요건(존재+노출) 통과. 다음 단계로.
아무것도 안 나타난다 → 건너뛰기 링크가 없거나, display:none으로 죽었거나, :focus 노출이 안 되는 상태. 실수 1·2·3 중 하나입니다.

2단계 — 나타난 링크가 또렷이 보이나요?

1단계에서 뭔가 나타났다면, 그게 "지금 초점을 받았다"는 게 한눈에 보이나요? 테두리나 박스가 분명한가요, 아니면 흐릿해서 있는 듯 없는 듯한가요?

또렷하다 → 통과.
흐릿하거나 다른 헤더에 가려진다 → 실수 8. 대비·z-index 문제입니다.

3단계 — Enter를 눌러 본문으로 가는지 확인하세요.

건너뛰기 링크에 초점이 있는 상태에서 Enter를 누릅니다. 본문 영역으로 화면이 이동하나요?

이동한다 → 다음 단계.
아무 일도 안 일어난다 → href가 가리키는 id가 없는 것. 실수 4입니다.

4단계 — Enter 후 Tab을 한 번 더 눌러 보세요. (가장 중요)

이게 진짜 핵심 테스트입니다. 3단계에서 본문으로 갔다면, 그 상태에서 Tab을 한 번 더 눌러 보세요. 초점이 본문 안의 링크로 가나요, 아니면 다시 맨 위 메뉴로 돌아가나요?

본문 안으로 이어진다 → 완벽합니다. 초점이 제대로 이동한 것.
다시 헤더 메뉴로 돌아간다 → 위치만 갔고 초점은 안 따라간 것. 실수 5입니다. 가장 흔하면서 놓치기 쉬운 함정이죠.

5단계 — 다른 페이지에서도 반복해 보세요.

메인이 통과했다고 끝이 아닙니다. 게시판 목록, 게시글 상세, 신청 폼, 검색 결과 등 성격이 다른 페이지 몇 개에서 1~4단계를 다시 해 보세요. 어떤 페이지는 되고 어떤 페이지는 안 되면 실수 6(일관성 문제)입니다.

이 다섯 단계만 해 봐도 우리 사이트의 건너뛰기 링크 상태가 거의 다 드러납니다. 다만 페이지가 수십·수백 개라면, 사람이 모든 페이지를 일일이 Tab으로 확인하기는 현실적으로 불가능합니다. 바로 그 지점에서 자동 점검이 필요해집니다.

그래서 우리 사이트는? — ViewCheck로 전 페이지 자동 점검

방금 5분 셀프 점검을 해 보셨다면, 한 가지가 분명해졌을 겁니다. "메인 한 페이지는 손으로 확인할 수 있지만, 사이트 전체를 이렇게 Tab으로 다 눌러 볼 수는 없다." 페이지가 100개면 위 5단계를 100번 반복해야 하니까요. 그리고 새 페이지가 추가되거나 리뉴얼될 때마다 또 처음부터.

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

ViewCheck가 건너뛰기 링크와 관련해 자동으로 보는 것들:

존재 여부: 페이지에 본문 바로가기(또는 주요 영역 건너뛰기) 링크가 있는지
초점 순서: 그 링크가 페이지 앞쪽(첫 초점 대상)에 위치하는지
대상 연결: 건너뛰기 링크의 href가 가리키는 대상(id)이 실제로 페이지에 존재하는지 — "눌러도 안 가는" 죽은 링크를 잡아냄
노출 방식: 초점을 받으면 보이도록 처리됐는지(완전히 숨겨져 죽은 링크는 아닌지)
페이지별 일관성: 여러 페이지를 분석하면, 어느 페이지엔 있고 어느 페이지엔 없는지 편차를 한눈에

DOM(코드)만으로 판단하기 어려운 시각적 부분 — 예를 들어 초점을 받았을 때 실제로 화면에 또렷이 나타나는지 — 은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정합니다. 그래서 "코드엔 건너뛰기 링크가 있는데 화면엔 안 나타나는" 어정쩡한 구현도 놓치지 않습니다. 사람이 키보드로 직접 눌러 보듯, 코드와 화면을 함께 보기 때문입니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 건너뛰기 링크 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix) 이 함께 나옵니다. 예를 들어 "신청 페이지에 본문 바로가기 링크 없음", "게시판 상세 페이지의 건너뛰기 링크가 가리키는 대상 id 없음"처럼 구체적으로요.

특히 ViewCheck의 강점은 다중 페이지 분석입니다. 메인부터 신청·검색·게시판까지 여러 페이지를 한꺼번에 돌리면, "메인은 건너뛰기 링크가 있는데 신청 페이지엔 없다" 같은 페이지별 편차가 즉시 드러납니다. 손으로 5단계 점검을 100번 할 일을, 한 번의 분석으로 끝내는 셈이죠. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)가 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 전 페이지 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "접근성 챙기자"가 아니라, "이 페이지에 본문 바로가기를 추가하고, 저 페이지의 대상 id를 연결하자"는 구체적인 작업 목록이 됩니다.

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

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

개발자라면 — 건너뛰기 링크 구현의 정석은 세 부분입니다. ① <body> 바로 다음에 건너뛰기 링크를 두고, ② 평소엔 화면 밖으로 보내되 :focus일 때 화면 안으로 끌어오는 CSS를 주고, ③ 대상 요소에 id와 tabindex="-1"을 주어 초점이 실제로 이동하게 합니다. 대략 이런 모습입니다.

```html

<body>

... 본문 ...

</main>

</body>

```

```css

.skip-link {

position: absolute;

left: -9999px; /* 평소엔 화면 밖 */

}

.skip-link:focus {

left: 0; top: 0; /* 초점 받으면 화면 안으로 */

z-index: 9999; /* 다른 요소 위에 */

padding: 8px 16px;

background: #1F4E79; /* 충분한 대비 */

color: #fff;

}

```

핵심은 display: none을 쓰지 말 것(초점 못 받음), 그리고 대상에 tabindex="-1"을 빠뜨리지 말 것(초점 이동 안 됨)입니다. KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN krds.min.css / krds.min.js)의 헤더·레이아웃 구조를 가져다 쓰면, 이 패턴이 이미 반영된 상태로 시작할 수 있습니다. 직접 만들다 ②·③을 빠뜨리는 사고를 줄일 수 있죠. 저장소의 html/code 폴더에 헤더·레이아웃 마크업 예시가 들어 있으니 그대로 참고하세요.

디자이너라면 — 건너뛰기 링크는 평소 안 보인다고 시안에서 빼먹기 쉽습니다. 하지만 "초점을 받았을 때의 모습"(화면 상단에 나타나는 박스의 색·여백·대비·위치)은 디자인 결정 사항입니다. KRDS 공식 Figma(@krds) 라이브러리의 헤더 패턴을 참고해, 초점 상태의 건너뛰기 링크 스타일을 시안에 명시해 두세요. 그래야 개발 단계에서 "어떻게 보여야 하는지" 합의된 상태로 만들 수 있습니다.

기획자라면 — 화면 정의서나 IA 문서에 "헤더 최상단: 본문 바로가기(+주메뉴/검색 바로가기) 링크"를 명시하세요. 그리고 "본문 영역 시작점에 초점 대상 지정"도 함께 적어 두면, 개발 단계에서 대상 id 연결이 누락되는 걸 막을 수 있습니다. 이 한두 줄이 나중의 접근성 결함을 미리 차단합니다.

자주 묻는 질문

현장에서 건너뛰기 링크를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 건너뛰기 링크는 꼭 화면에 안 보이게 숨겨야 하나요?

반드시 숨겨야 하는 건 아닙니다. 항상 보이게 둬도 접근성상 문제는 없습니다. 다만 디자인을 해치지 않으려고 평소엔 숨기고 초점 시에만 보이게 하는 방식이 일반적일 뿐입니다. 어느 쪽이든 핵심은 "키보드로 초점이 갔을 때 반드시 보여야 한다"입니다. 숨기는 게 목적이 아니라, "마우스 사용자에겐 방해 안 되게 + 키보드 사용자에겐 확실히 닿게"가 목적이라고 생각하시면 됩니다.

Q. 본문 바로가기 하나만 있으면 충분한가요?

"충분하냐"고 묻는다면 본문 바로가기 하나로도 핵심은 충족합니다. 가장 많은 시간을 잡아먹는 게 본문 진입이니까요. 다만 검색이 핵심 기능인 사이트라면 "검색 바로가기"를, 메뉴 구조가 복잡하면 "주메뉴 바로가기"를 추가하면 더 좋습니다. 욕심내서 너무 많이 두면 그것대로 부담이니, 본문·주메뉴·검색 정도의 핵심만 추리는 게 좋습니다.

Q. 셀프 점검 4단계(Enter 후 Tab)에서 자꾸 메뉴로 돌아갑니다. 왜 그런가요?

가장 흔한 원인은 대상 요소에 tabindex="-1"이 없어서입니다. 링크를 누르면 위치(스크롤)는 본문으로 가지만, 그 지점이 초점을 받을 수 없는 요소라 초점은 여전히 링크(또는 그 근처)에 남아 있고, 다음 Tab이 문서 순서상 다음 요소(보통 헤더)로 가 버리는 거죠. 본문 시작 요소에 tabindex="-1"을 주고, 링크 클릭 시 그 대상으로 초점을 명시적으로 이동시키면 해결됩니다.

Q. `display: none`으로 숨기면 왜 안 되나요? 깔끔하게 안 보이는데요.

"안 보인다"는 점에선 깔끔하지만, display: none이나 visibility: hidden은 그 요소를 키보드 초점 대상에서도 제외합니다. 즉 Tab을 눌러도 그 링크에 초점이 가지 않으니, 영영 나타나지 않는 죽은 링크가 됩니다. 시각적으로 숨기되 초점은 받을 수 있게 하려면, 화면 밖으로 보내는 방식(position: absolute; left: -9999px;)이나 clip 기법을 써야 합니다.

Q. 스크린리더 사용자에게도 건너뛰기 링크가 도움이 되나요? 그들은 제목(heading)으로 이동하지 않나요?

좋은 질문입니다. 숙련된 스크린리더 사용자는 제목 단위 이동(H 키)이나 랜드마크 이동 같은 빠른 탐색을 쓰기도 합니다. 하지만 모든 사용자가 그 기능에 익숙한 건 아니고, 키보드만 쓰는(스크린리더 없는) 사용자에게는 그런 단축키가 없습니다. 건너뛰기 링크는 누구에게나 통하는 가장 보편적인 장치라, 다른 빠른 탐색 수단이 있더라도 함께 제공하는 게 원칙입니다. 둘은 대체재가 아니라 보완재입니다.

Q. 단일 페이지 앱(SPA)이라 페이지 이동이 없는데도 필요한가요?

필요합니다. SPA에서도 화면(뷰) 전환이 일어나면 사실상 새 페이지처럼 동작하고, 반복되는 헤더·내비게이션은 그대로 있습니다. 오히려 SPA는 라우팅 후 초점 관리가 까다로워, 건너뛰기 링크와 함께 "뷰 전환 시 본문으로 초점 이동" 처리를 함께 설계해야 합니다. "페이지 새로고침이 없으니 안 해도 된다"는 오해입니다.

Q. 이미 운영 중인 사이트인데, 전 페이지에 일일이 추가해야 하나요?

대부분의 사이트는 헤더가 공통 컴포넌트(또는 공통 템플릿)로 되어 있어서, 그 한 곳에 건너뛰기 링크를 추가하면 전 페이지에 한 번에 반영됩니다. 문제는 일부 페이지가 다른 레이아웃을 쓰는 경우인데, 그건 ViewCheck로 "어느 페이지에 빠졌는지"를 먼저 찾아낸 다음 그 페이지들만 손보면 됩니다. 무작정 전부 뒤지는 것보다, 빠진 곳을 특정해서 채우는 게 훨씬 빠릅니다.

Q. 점검해 보니 건너뛰기 링크는 있는데 "위치만 가고 초점이 안 따라가는" 상태입니다. 심각한가요?

시각적으로는 본문으로 스크롤되니 "되는 것처럼" 보이지만, 키보드·스크린리더 사용자 입장에선 사실상 작동하지 않는 것과 같습니다. 다음 Tab이 또 메뉴로 돌아가니 건너뛴 의미가 없거든요. "있는데 안 되는" 상태라 오히려 "없는데 명백한" 것보다 발견이 늦어지기 쉽습니다. 우선순위로는 높게 보고 고치는 게 맞습니다.

Q. 건너뛰기 링크 텍스트를 영어("Skip to content")로 둬도 되나요?

공공 서비스는 한국어 사용자가 절대다수이므로, 기본은 "본문 바로가기" 같은 명확한 한국어가 맞습니다. 스크린리더가 한국어 문맥에서 영어를 어색하게 읽거나, 한국어 사용자가 의미를 직관적으로 파악하기 어려울 수 있거든요. 다국어를 지원하는 사이트라면 언어 전환에 맞춰 라벨도 함께 바뀌게 하는 게 좋습니다. "남들이 쓰니까 영어로"가 아니라, "우리 사용자가 듣고 바로 이해하는가"가 기준입니다.

Q. 푸터(맨 아래)로 가는 건너뛰기 링크도 만들어야 하나요?

본문·주메뉴·검색이 우선이고, 푸터 바로가기는 사이트 성격에 따라 선택입니다. 푸터에 자주 쓰는 정보(연락처, 관련 사이트, 정책 링크 등)가 몰려 있고 본문이 매우 길다면 도움이 될 수 있습니다. 다만 건너뛰기 링크를 너무 많이 늘어놓으면 그 자체가 또 다른 통과 대상이 되어 부담이 되니, 정말 필요한 핵심만 추리는 절제가 중요합니다.

Q. 건너뛰기 링크가 SEO(검색 최적화)에 나쁜 영향을 주지 않나요?

정상적으로 구현한 건너뛰기 링크는 SEO에 해롭지 않습니다. 오히려 의미 있는 내부 링크이자 접근성 신호로 작동합니다. 주의할 점은 "숨김" 방식인데, 검색엔진을 속이려는 은닉 텍스트(키워드 도배 등)와 건너뛰기 링크의 정당한 숨김은 목적이 다릅니다. 화면 밖 배치 + :focus 노출 같은 표준적 방식을 쓰면 문제가 없습니다. 접근성을 위한 숨김은 검색엔진도 정상적인 패턴으로 인식합니다.

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

ViewCheck로 돌려 보거나 손으로 점검해 보면, 건너뛰기 링크 문제가 한 가지로 끝나지 않는 경우가 많습니다. 페이지가 많을수록 "고칠 게 많다"는 압박이 들죠. 그래서 우선순위가 중요합니다. 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 건너뛰기 링크가 아예 없는 핵심 페이지. 특히 신청·로그인·검색처럼 입력과 단계가 많아 키보드 부담이 큰 경로. 여기에 건너뛰기가 없으면 키보드 사용자가 매번 메뉴를 통과해야 하므로 1순위입니다.

그다음(높음) — 링크는 있지만 눌러도 작동하지 않는 경우(대상 id 없음, 또는 위치만 가고 초점이 안 따라감). "있는데 안 되는" 상태라 사용자를 오히려 헷갈리게 합니다. 그리고 display: none으로 죽어 키보드로 나타나지 않는 링크도 여기 포함됩니다.

그 후(보통) — 페이지별 편차(일부 페이지에만 있음)와 초점 표시가 흐릿하거나 가려지는 문제. 사용은 가능하지만 특정 페이지·특정 상황에서 불편을 줍니다.

여력이 되면(낮음) — 본문 바로가기 외에 주메뉴·검색 바로가기 추가, 링크 텍스트를 더 명확하게 다듬기 같은 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트·레이아웃 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹) — 헤더·레이아웃과 본문 바로가기 패턴을 화면으로 확인.
KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 헤더·레이아웃 마크업과 건너뛰기 링크 구조를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
KRDS 공식 Figma(@krds) — 디자이너용 헤더·레이아웃 컴포넌트와 초점 상태.

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

오늘의 체크리스트 — 건너뛰기 링크, 이것만은

마지막으로, 디자이너·개발자·기획자가 건너뛰기 링크를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 앞의 5분 셀프 점검과 짝지어 쓰시면 좋습니다.

☐ 페이지 맨 앞에 건너뛰기 링크가 있다(첫 Tab으로 잡힌다).
☐ 평소엔 안 보여도 초점을 받으면 또렷이 나타난다(display:none이 아니다).
☐ 나타난 링크의 초점 표시가 또렷하고 배경과 대비가 충분하다.
☐ 누르면 본문으로 실제 이동한다(대상 id가 존재한다).
☐ 본문 이동 후 다음 Tab이 본문 안으로 이어진다(대상에 tabindex="-1", 초점이 따라간다).
☐ 링크 텍스트가 명확하다("본문 바로가기" 등, "skip"·"이동" 아님).
☐ 모든 페이지에 일관되게 있다(메인만 있고 신청·게시판에서 빠지지 않았다).
☐ 다른 고정 헤더에 가려지지 않는다(z-index·위치 확인).
☐ (선택) 본문 외에 주메뉴·검색 바로가기도 핵심 페이지에 제공한다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)의 헤더·레이아웃 구조를 쓰면 위 항목 대부분이 이미 반영된 상태로 시작할 수 있습니다. 직접 만들다 "초점 이동"이나 "대상 id 연결"을 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 초점 상태의 건너뛰기 링크 모습을 그대로 가져다 쓸 수 있습니다.

건너뛰기 링크는 작아 보이지만, 공공 서비스를 키보드로 쓰는 모든 사람이 매 페이지에서 처음 만나는 관문입니다. 그 한 줄이 있으면 누군가는 Enter 한 번으로 본문에 닿고, 없으면 매번 메뉴를 수십 번 통과해야 합니다. 우리가 무심코 빼먹은 링크 하나가, 누군가에게는 하루 종일 반복되는 헛수고가 됩니다.

오늘 정리한 기준이 길어 보일 수 있지만, 핵심은 결국 단순합니다. 맨 앞에 두고, 초점 받으면 보이게 하고, 누르면 본문으로 초점이 진짜 가게 하고, 모든 페이지에 일관되게. 이 네 가지만 챙기면 건너뛰기 링크 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는, 방금 해 보신 5분 셀프 점검으로 한 페이지를, ViewCheck로 전 페이지를 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 쓰이는 핵심 페이지의 건너뛰기 링크 하나부터 제대로 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다.

우리 사이트의 건너뛰기 링크는 지금 제대로 작동하고 있을까요? 방금 첫 Tab을 눌러 봤을 때 "본문 바로가기"가 떴는지 떠올려 보세요. 그리고 krds.viewcheck.co.kr에서 URL만 넣으면, 전 페이지의 건너뛰기 링크 상태를 무료로 한 번에 확인할 수 있습니다.

#KRDS #공공웹 #디자인시스템 #건너뛰기링크Skiplink #웹접근성 #ViewCheck #정부웹사이트 #UIUX #KWCAG #키보드접근성 #본문바로가기 #건너뛰기링크 #Skiplink #자가진단 #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부