건너뛰기 링크(Skip link) 완전 해부 — KRDS 공식 기준

키보드만으로 정부 사이트를 써 본 적 있으신가요? 마우스를 잠시 내려놓고, Tab 키만으로 메인 페이지의 본문에 도달해 보세요. 상단 로고, 검색창, 로그인 버튼, 그다음 메인 메뉴 1번… 2번… 3번… 하위 메뉴까지 펼쳐지면 또 십수 개. 배너 영역의 버튼들, 빠른 서비스 바로가기 아이콘 수십 개. 그 모든 걸 Tab으로 한 칸씩 통과하고 나서야, 비로소 "오늘 내가 보러 온 그 공지사항" 본문에 닿습니다. 운이 나쁘면 Tab을 마흔 번, 쉰 번씩 눌러야 합니다. 페이지를 옮길 때마다 이 짓을 다시 합니다.

마우스 쓰는 사람은 평생 모를 고통입니다. 마우스는 그냥 본문을 클릭하면 끝이니까요. 그런데 키보드만 쓰는 사람, 스크린리더를 켠 시각장애인, 스위치 하나로 컴퓨터를 조작하는 지체장애인에게는 이 "메뉴 통과하기"가 매 페이지마다 반복되는 일상의 벽입니다. 바로 이 벽을 단숨에 뛰어넘게 해 주는 작은 장치가 오늘의 주인공, 건너뛰기 링크(Skip link)입니다.

건너뛰기 링크는 화면 맨 위 어딘가에 숨어 있다가, Tab 키로 페이지에 처음 진입하는 순간 가장 먼저 튀어나오는 링크입니다. "본문 바로가기", "주요 콘텐츠로 이동" 같은 문구로요. 이걸 누르면 반복되는 메뉴를 통째로 건너뛰고 곧장 본문으로 점프합니다. 평소엔 화면에 보이지 않다가 키보드 초점이 닿으면 나타나죠. 마우스 사용자에겐 평생 안 보이지만, 키보드 사용자에겐 매 페이지를 구원하는 비상구입니다.

문제는 이게 워낙 "안 보이는" 컴포넌트라서, 만드는 사람들도 자주 잊는다는 겁니다. 디자인 시안에는 안 그려지고, 화면에 안 보이니 QA에서도 놓치고, 마우스로 테스트하니 있는지 없는지조차 모릅니다. 공공 사이트를 수백 개 들여다보면, 건너뛰기 링크가 아예 없거나, 있긴 한데 작동을 안 하거나, 키보드로는 닿을 수조차 없게 만들어 놓은 경우가 정말 많습니다. 오늘은 이 작지만 결정적인 컴포넌트를 KRDS(대한민국 정부 디자인 시스템) 기준으로 처음부터 끝까지 해부해 보겠습니다.

이 글을 다 읽고 나면, 앞으로 어떤 사이트에서든 Tab 키 한 번만 눌러 보고 "이 사이트는 키보드 사용자를 생각했구나" 혹은 "이 사이트는 안 그랬구나"를 0.5초 만에 판별하실 수 있습니다. 그리고 우리 사이트가 그 기준을 지키고 있는지 어떻게 확인하는지까지, 함께 짚어 보겠습니다.

건너뛰기 링크가 대체 뭘까 — 정의부터 정확히

용어부터 맞추고 가겠습니다. 건너뛰기 링크는 영어로 Skip link, Skip navigation link, Skip to content link 등으로 불립니다. 한국어로는 "본문 바로가기", "건너뛰기 링크", "주요 콘텐츠 바로가기" 등으로 쓰이죠. 부르는 이름은 조금씩 달라도 역할은 하나입니다.

페이지 상단에서 반복되는 영역(로고, 검색, 메인 메뉴 등)을 키보드로 일일이 통과하지 않고, 한 번의 동작으로 본문(또는 원하는 주요 영역)으로 곧장 이동하게 해 주는 링크.

핵심은 "반복"과 "건너뛰기" 두 단어입니다.

반복 — 공공 사이트는 페이지마다 상단 구조가 거의 똑같습니다. 메인이든 공지사항 목록이든 신청서든, 위쪽엔 항상 같은 로고와 같은 메뉴가 있죠. 마우스 사용자에겐 이 일관성이 편리함이지만, 키보드 사용자에겐 "또 이 메뉴를 다 통과해야 한다"는 반복 노동이 됩니다. 한 페이지에서 메뉴를 30번 Tab 했는데, 다음 페이지로 가면 또 30번. 10페이지를 돌면 300번입니다.

건너뛰기 — 건너뛰기 링크는 이 반복 노동을 단 한 번의 Enter로 끝내 줍니다. 메뉴가 30개든 100개든, 건너뛰기 링크를 누르면 그 모든 걸 뛰어넘어 본문 첫 글자로 초점이 이동합니다. 그래서 이 컴포넌트를 "스킵(skip) 링크"라고 부르는 겁니다 — 말 그대로 "건너뛰는" 링크니까요.

여기서 한 가지 오해를 먼저 풀겠습니다. 건너뛰기 링크는 "장애인을 위한 특별한 기능"이 아닙니다. 키보드만 쓰는 모든 사람을 위한 기능입니다. 손목을 다쳐 마우스를 못 쓰는 직장인, 노트북 트랙패드가 고장 나 키보드로 버티는 사용자, 그리고 파워 유저 중에는 마우스보다 키보드가 빠르다며 일부러 키보드만 쓰는 사람도 있습니다. 건너뛰기 링크는 이 모두를 돕습니다. 다만 그중에서도 스크린리더 사용자와 키보드 전용 사용자에게는 "있으면 편한 것"이 아니라 "없으면 못 쓰는 것"에 가깝습니다.

왜 "안 보이는데 존재하는" 이상한 컴포넌트인가

건너뛰기 링크의 가장 독특한 점은, 평상시에는 화면에 보이지 않는다는 것입니다. 보통은 화면 밖으로 살짝 밀어 두거나 시각적으로 숨겨 둡니다. 그러다 키보드 Tab으로 초점이 닿는 순간, 화면 좌측 상단쯤에 "본문 바로가기" 같은 링크가 빵 하고 나타나죠.

왜 이렇게 만들까요? 두 종류의 사용자를 동시에 배려하기 위해서입니다.

마우스 사용자에게는 건너뛰기 링크가 필요 없습니다. 본문을 그냥 클릭하면 되니까요. 그들에게 화면 맨 위에 "본문 바로가기" 버튼이 늘 떠 있으면 오히려 화면이 지저분해집니다.
키보드 사용자에게는 이게 필수입니다. 그래서 키보드 초점이 닿을 때만 나타나게 합니다.

즉, "필요한 사람에게만, 필요한 순간에만" 나타나는 똑똑한 설계입니다. 이 "초점 시 노출" 패턴이 건너뛰기 링크의 핵심 기술이자, 동시에 가장 자주 망가지는 부분입니다. 화면에서 숨기겠다고 display: none이나 visibility: hidden을 써 버리면, 키보드 초점 자체가 닿지 않아 영원히 나타나지 않는 "유령 링크"가 되거든요. 이 얘기는 뒤에서 자세히 다루겠습니다.

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

이제 본론입니다. KRDS는 건너뛰기 링크를 컴포넌트의 하나로 정의하고, 디지털 정부서비스 UI/UX 가이드라인(2025.08판)과 컴포넌트 문서, 그리고 GitHub에 공개된 HTML 컴포넌트 코드(KRDS-uiux/krds-uiux)를 통해 "이렇게 만들라"는 기준을 제시합니다. KRDS 컴포넌트 요약 페이지(component_summary)에서도 건너뛰기 링크는 탐색(navigation) 계열의 기본 컴포넌트로 자리 잡고 있습니다.

KRDS가 건너뛰기 링크에 대해 요구하는 바를 영역별로 하나씩 뜯어보겠습니다. KRDS의 구체적인 수치를 임의로 지어내지 않고, 가이드라인과 컴포넌트 코드, 그리고 확립된 웹접근성 표준(KWCAG, WCAG)이 공통으로 요구하는 사실 기준으로만 정리합니다.

1) 페이지의 가장 처음에 와야 한다

건너뛰기 링크의 첫째가는 요건은 위치입니다. 이 링크는 페이지에서 키보드 Tab으로 가장 먼저 닿는 요소여야 합니다. HTML 구조상 <body>가 열리자마자, 로고보다도 먼저 와야 한다는 뜻입니다.

이유는 명확합니다. 건너뛰기 링크의 존재 이유 자체가 "메뉴를 통과하기 전에 건너뛸 기회를 주는 것"이기 때문입니다. 만약 건너뛰기 링크가 메뉴 다음에 있다면? 이미 메뉴를 다 통과한 뒤에 건너뛰기 링크가 나오니, 아무 의미가 없습니다. 비상구가 비상 상황이 다 끝난 다음에 나타나는 셈이죠.

그래서 코드 작성 순서가 곧 키보드 이동 순서가 되도록 설계해야 합니다. 시각적으로 어디에 그려지든(보통 화면 밖에 숨김), HTML 문서 흐름상으로는 맨 앞에 위치해야 합니다. 이 "코드 순서 = 초점 순서"의 원칙은 건너뛰기 링크뿐 아니라 모든 키보드 접근성의 기본입니다.

2) 평소엔 숨기되, 초점이 닿으면 반드시 보여야 한다

앞서 말한 "초점 시 노출" 패턴입니다. 건너뛰기 링크는 시각적으로 깔끔하게 숨겨 두되, 키보드 초점을 받으면 명확하게 화면에 나타나야 합니다.

여기서 결정적인 함정이 있습니다. "숨긴다"는 걸 잘못 구현하면 링크가 완전히 죽어 버립니다.

display: none → 요소 자체가 렌더 트리에서 빠지므로 키보드 초점이 닿지 않음. 영원히 안 나타남.
visibility: hidden → 마찬가지로 초점 대상에서 제외됨. 죽은 링크.

올바른 방법은 요소를 화면 밖으로 밀어내되 초점은 받을 수 있게 두는 것입니다. 흔히 쓰는 기법이 위치를 화면 바깥으로 이동시키거나(예: 음수 좌표) 클립 영역을 0으로 만드는 식의 "시각적으로만 숨기기(screen-reader-only / visually-hidden)"입니다. 그러다 :focus 상태가 되면 다시 화면 안으로 끌어와 보이게 합니다. KRDS 컴포넌트 코드도 이 원리로 만들어져 있어서, 직접 구현하다 함정에 빠질 위험을 줄여 줍니다.

핵심은 이겁니다. 숨기는 것과 죽이는 것은 다르다. 건너뛰기 링크는 "보이지 않게" 하는 거지 "존재하지 않게" 하는 게 아닙니다.

3) 초점이 닿았을 때 또렷하게 보여야 한다

초점을 받아 나타날 때, 그 모습이 분명해야 합니다. 화면 좌측 상단 등 눈에 띄는 위치에, 충분한 크기와 대비로 나타나야 키보드 사용자가 "아, 건너뛰기 링크가 떴구나"를 인지합니다.

여기엔 두 가지가 함께 따라옵니다.

나타나는 위치와 모양 — 보통 페이지 최상단 왼쪽에 박스 형태로 등장합니다. 배경색과 글자색의 대비가 충분해야 하고(WCAG 색 대비 기준 충족), 글자 크기가 읽을 만해야 합니다.
초점 표시(focus indicator) — 링크 자체에 초점 외곽선이 또렷하게 보여야 합니다. outline: none으로 초점 링을 지워 버리면, 링크가 나타나도 "지금 여기에 초점이 있다"는 신호가 약해집니다.

평소 안 보이는 컴포넌트라고 해서 나타날 때도 흐릿하면 안 됩니다. 오히려 "한 번 나타날 때 확실하게" 보이는 게 중요합니다.

4) 링크 문구는 목적이 분명해야 한다

링크 텍스트는 사용자가 "이걸 누르면 어디로 가는지"를 바로 알 수 있어야 합니다. "본문 바로가기", "주요 콘텐츠로 이동", "본문 영역으로 건너뛰기" 같은 문구가 표준적입니다.

피해야 할 것은 "여기를 클릭", "이동", "건너뛰기"처럼 목적지가 빠진 모호한 문구입니다. 스크린리더 사용자는 링크 목록만 따로 뽑아 듣기도 하는데, 이때 "건너뛰기"만 덩그러니 읽히면 무엇을 건너뛰는지, 어디로 가는지 알 수 없습니다. 문구만 들어도 "본문으로 가는 링크구나"가 명확해야 합니다.

5) 실제로 작동해야 한다 — 초점 이동까지 완결

이게 의외로 가장 많이 깨지는 부분입니다. 건너뛰기 링크는 보이기만 하면 끝이 아니라, 눌렀을 때 실제로 본문으로 초점이 이동해야 합니다.

작동 원리는 이렇습니다. 건너뛰기 링크는 보통 <a href="#main">본문 바로가기</a> 형태이고, 본문 영역에는 id="main"을 가진 요소(예: <main id="main">)가 있습니다. 링크를 누르면 그 id로 화면이 스크롤되고, 동시에 키보드 초점이 그 본문 요소로 이동해야 합니다.

여기서 문제는, 단순히 href="#main"만 걸어 두면 브라우저에 따라 화면은 스크롤되는데 초점은 안 따라오는 경우가 있다는 점입니다. 그러면 사용자는 "본문으로 갔다"고 생각하고 다시 Tab을 눌렀는데, 초점이 여전히 상단 메뉴에 머물러 있어 처음으로 되돌아가는 황당한 일이 벌어집니다. 이걸 막으려면 본문 대상 요소가 초점을 받을 수 있도록 처리(예: tabindex="-1" 부여 후 초점 이동)하는 게 안전합니다. KRDS 컴포넌트 코드는 이 동작까지 고려해 만들어져 있어, "보이긴 하는데 눌러도 본문으로 안 가는" 절름발이 링크를 피할 수 있습니다.

6) 여러 개의 건너뛰기 링크도 가능하다

페이지 구조가 복잡하면 건너뛰기 링크가 하나일 필요는 없습니다. "본문 바로가기"뿐 아니라 "주메뉴 바로가기", "검색 바로가기"처럼 여러 개를 두어, 키보드 사용자가 원하는 주요 영역으로 곧장 갈 수 있게 할 수 있습니다.

다만 과하면 그 자체로 또 통과해야 할 목록이 됩니다. 핵심은 "사용자가 자주 가고 싶어 하는 곳"으로 추리는 것입니다. 대부분의 공공 사이트라면 "본문 바로가기" 하나만 제대로 있어도 큰 효과를 봅니다. 여러 개를 둘 때는 각 링크의 목적지가 실제로 존재하고 작동하는지 모두 확인해야 합니다.

7) 모든 페이지에 일관되게 있어야 한다

건너뛰기 링크는 메인 페이지에만 있으면 안 됩니다. 사용자가 방문하는 모든 페이지에 동일하게 있어야 합니다. 메인엔 있는데 공지사항 목록엔 없고, 신청서 페이지엔 또 없으면, 키보드 사용자는 페이지마다 운에 맡겨야 합니다.

공공 사이트는 페이지 수가 수십·수백 개에 이릅니다. 공통 헤더 템플릿에 건너뛰기 링크를 한 번 제대로 넣어 두면 모든 페이지에 자동으로 적용되지만, 일부 페이지가 별도 템플릿을 쓰거나 오래된 페이지가 남아 있으면 누락이 생깁니다. "메인은 됐는데 서브는 안 됐다"가 가장 흔한 패턴입니다. 그래서 단일 페이지가 아니라 사이트 전체를 점검하는 게 중요합니다.

정리하면 KRDS의 건너뛰기 링크 기준은 다섯 축으로 압축됩니다. ① 위치(페이지 맨 처음, 메뉴보다 먼저), ② 노출(평소 숨김, 초점 시 명확히 표시, 단 죽이지 말 것), ③ 명확성(목적이 분명한 링크 문구), ④ 작동(눌렀을 때 본문으로 초점까지 이동), ⑤ 일관성(모든 페이지에 동일하게). 이 다섯 가지가 그대로 ViewCheck가 건너뛰기 링크를 판정하는 기준이기도 합니다.

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

여기까지 읽고 "링크 하나 숨겼다 보이게 하는 건데 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 책상에서 만들어 낸 규칙이 아니라, 실제 키보드 사용자가 매일 막히는 지점에서 역으로 도출된 것들입니다.

키보드 사용자에겐 "Tab"이 곧 마우스다

비장애인은 화면 아무 데나 마우스로 콕 찍어 이동합니다. 본문이 화면 한가운데 있으면 거기를 클릭하면 끝이죠. 그런데 키보드만 쓰는 사람에게는 이 "콕 찍기"가 없습니다. 오직 Tab 키로 한 칸씩, 정해진 순서대로만 이동할 수 있습니다.

순서대로만 이동한다는 건, 본문에 닿으려면 그 앞에 있는 모든 걸 통과해야 한다는 뜻입니다. 상단 메뉴가 100개면 본문에 닿기 전에 Tab을 100번 눌러야 합니다. 마우스 사용자가 0.5초에 하는 일을, 키보드 사용자는 1분 넘게 걸려서 합니다. 그것도 페이지를 옮길 때마다 매번이요.

건너뛰기 링크는 이 불평등을 한 방에 해소합니다. Tab 한 번, Enter 한 번이면 본문에 도착하니까요. 마우스 사용자와 키보드 사용자의 출발선을 거의 같게 만들어 주는, 작지만 결정적인 장치입니다.

스크린리더 사용자에겐 더더욱 절실하다

시각장애인이 스크린리더로 페이지를 쓰는 모습을 상상해 보세요. 화면이 안 보이니, 스크린리더가 위에서부터 차례로 읽어 줍니다. "로고, 링크. 검색, 입력란. 메뉴, 정책정보, 링크. 메뉴, 알림마당, 링크. 하위 메뉴, 보도자료, 링크…" 본문에 닿기 전까지 이 낭독이 끝없이 이어집니다.

건너뛰기 링크가 없으면, 시각장애인은 페이지에 들어올 때마다 같은 메뉴 낭독을 처음부터 끝까지 다시 들어야 합니다. 공지사항 10개를 확인하려고 10페이지를 오가면, 같은 메뉴를 10번 듣는 겁니다. 상상만 해도 지치는 일이죠.

건너뛰기 링크가 있으면, 스크린리더가 페이지를 열자마자 가장 먼저 "본문 바로가기, 링크"라고 읽어 줍니다. Enter를 누르면 곧장 본문 낭독으로 점프합니다. 반복되는 메뉴 낭독에서 해방되는 거죠. 이게 KRDS가 건너뛰기 링크를 "있으면 좋은 것"이 아니라 탐색의 기본 컴포넌트로 두는 이유입니다.

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

상업 사이트는 불편하면 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 복지 급여를 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자에게 "안 쓸 자유"가 없어요.

그래서 공공 웹의 건너뛰기 링크가 없거나 망가져 있으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 침해가 됩니다. 키보드 사용자가 메뉴 100개를 매번 통과하다 지쳐 신청을 포기하면, 그 사람은 받아야 할 복지를 못 받는 겁니다. 건너뛰기 링크 하나가 누군가의 권리와 직결되는 셈이죠.

작고 안 보이는 것일수록 방치되기 쉽다

역설적이지만, 건너뛰기 링크처럼 "화면에 안 보이는" 컴포넌트일수록 품질 관리에서 가장 먼저 밀려납니다. 메인 비주얼이나 핵심 배너에는 모두가 눈을 부릅뜨지만, 화면에 보이지도 않는 링크 하나에는 아무도 신경 쓰지 않거든요.

게다가 만든 사람들 대부분이 마우스로 테스트합니다. 마우스로는 건너뛰기 링크가 있는지 없는지조차 알 수 없죠. 디자이너 시안에도 없고, QA 체크리스트에도 빠지기 쉽고, 마우스 테스트로는 발견되지 않는 — 이 삼중의 사각지대에 놓인 컴포넌트가 바로 건너뛰기 링크입니다. KRDS가 이걸 표준 컴포넌트로 명시해 둔 건, 바로 이 "방치되기 쉬운 곳"에서 접근성이 무너지는 걸 막기 위해서입니다.

표준화가 곧 학습 비용 절감

KRDS가 건너뛰기 링크의 문구와 동작을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 건너뛰기 링크의 문구와 위치가 제각각이면, 키보드 사용자는 사이트를 옮길 때마다 "여긴 건너뛰기가 어디 있지?"를 다시 찾아야 합니다. 모든 공공 서비스가 같은 위치에 같은 문구로 두면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다.

한 장면 — 같은 공지사항, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 ○○시 공공 서비스의 "공지사항" 페이지가 있다고 합시다. 상단엔 로고, 검색창, 로그인, 그리고 메인 메뉴 7개와 그 아래 하위 메뉴 수십 개, 빠른 서비스 바로가기 아이콘 12개가 늘어서 있습니다.

먼저 마우스를 쓰는 김 주무관. 페이지가 열리자마자 본문의 공지 제목을 클릭합니다. 0.5초. 다음 공지를 보려고 목록으로 돌아와 또 클릭. 김 주무관에게 이 페이지는 아무 문제가 없습니다. 그래서 이 페이지를 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 페이지에 들어갑니다. 스크린리더가 읽기 시작합니다. "로고, 링크. 검색, 입력란. 통합검색, 버튼. 로그인, 링크. 회원가입, 링크. 메뉴, 시정소식, 링크. 하위, 보도자료… 하위, 공지사항… 하위, 입찰공고…" 메뉴 낭독이 끝없이 이어집니다. 박 선생님이 보러 온 건 그냥 공지사항 하나인데, 그 본문에 닿기까지 1분 넘게 메뉴를 들어야 합니다. 더 답답한 건, 공지 하나를 읽고 목록으로 돌아오면 또 처음부터 같은 메뉴를 들어야 한다는 겁니다.

같은 페이지, 같은 공지사항. 한 사람에겐 0.5초짜리 클릭이고, 다른 한 사람에겐 1분짜리 인내심 시험입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에 생긴 차이입니다.

만약 이 팀이 건너뛰기 링크를 제대로 넣었다면 어땠을까요. 박 선생님의 스크린리더는 페이지를 열자마자 "본문 바로가기, 링크"라고 읽었을 겁니다. Enter 한 번이면 끝없는 메뉴 낭독을 건너뛰고 곧장 공지 본문으로 점프했겠죠. 김 주무관의 마우스 클릭과 거의 같은 속도로요. 차이를 만드는 건 거창한 기술이 아니라, "화면 맨 위에 링크 하나를 제대로 넣느냐"라는 작은 선택입니다.

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

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

실수 1) 건너뛰기 링크가 아예 없다

가장 흔하고 가장 근본적인 실수입니다. 페이지 맨 위에 건너뛰기 링크 자체가 없어서, 키보드 사용자는 매 페이지 메뉴를 전부 통과해야 합니다.

나쁜 예: <body>가 열리자마자 로고부터 시작. Tab을 누르면 곧장 헤더 메뉴로 들어감. 본문까지 가려면 수십 번 Tab.
올바른 예: <body> 바로 다음에 <a href="#main" class="skip-link">본문 바로가기</a>를 두고, 본문은 <main id="main">으로 감싼다. Tab 한 번에 건너뛰기 링크가 뜨고, Enter로 본문 점프.

실수 2) `display: none`으로 숨겨 죽인 링크

"화면에 안 보이게 해야지" 하면서 손쉽게 display: none이나 visibility: hidden을 써 버립니다. 그러면 링크가 초점을 받지 못해 영원히 나타나지 않습니다.

나쁜 예: .skip-link { display: none; }. 코드엔 링크가 있지만 키보드로 절대 닿을 수 없는 유령 링크. 있으나 마나.
올바른 예: 화면 밖으로 밀거나 클립으로 시각적으로만 숨기고(visually-hidden), :focus 시 다시 화면 안으로 끌어와 보이게 한다. KRDS 킷의 건너뛰기 링크 CSS가 정확히 이 방식.

실수 3) 보이긴 하는데 눌러도 본문으로 안 간다

건너뛰기 링크가 뜨긴 하는데, 막상 Enter를 눌러도 초점이 본문으로 안 옮겨집니다. 화면만 살짝 스크롤되고 초점은 그대로 상단에 머뭅니다.

나쁜 예: href="#main"만 걸어 뒀는데 대상 요소가 초점을 못 받는 상태. 사용자는 본문으로 갔다고 착각하고 Tab을 눌렀다가 다시 메뉴로 돌아감. 오히려 더 혼란.
올바른 예: 대상 본문 요소에 tabindex="-1"을 부여하고 클릭 시 초점을 명시적으로 이동시켜, 화면 스크롤과 초점 이동이 함께 일어나게 한다.

실수 4) 링크 목적지가 존재하지 않는다

href="#content"라고 걸어 뒀는데, 정작 페이지엔 id="content"인 요소가 없습니다. 누르면 아무 일도 안 일어나거나 엉뚱한 곳으로 갑니다.

나쁜 예: 헤더 템플릿엔 건너뛰기 링크가 있는데, 본문 템플릿이 바뀌면서 대상 id가 사라짐. 링크와 목적지의 연결이 끊김.
올바른 예: 링크의 href 값과 본문 영역의 id가 정확히 짝지어져 있는지 모든 페이지에서 확인. 공통 템플릿을 쓰되 본문 id도 공통으로 고정.

실수 5) 모호한 링크 문구

"건너뛰기", "이동", "여기"처럼 목적지가 빠진 문구를 씁니다. 스크린리더로 링크만 뽑아 들으면 무슨 링크인지 알 수 없습니다.

나쁜 예: 링크 텍스트가 그냥 "건너뛰기". 무엇을 건너뛰어 어디로 가는지 불명확.
올바른 예: "본문 바로가기", "주요 콘텐츠로 이동"처럼 목적지가 분명한 문구. 들어도 보아도 의미가 명확.

실수 6) 초점 시 나타나는데 흐릿하거나 안 보이는 위치

초점을 받으면 나타나긴 하는데, 화면 구석에 작게 뜨거나 배경과 대비가 약해 눈에 안 띕니다.

나쁜 예: 흰 배경에 연한 회색 글씨로 화면 모서리에 살짝 등장. 떴는지 안 떴는지 헷갈림.
올바른 예: 화면 좌측 상단에 또렷한 박스로, 충분한 색 대비와 읽을 만한 크기로 나타나게. 초점 외곽선도 분명히.

실수 7) 메인에만 있고 서브 페이지엔 없다

메인 페이지엔 건너뛰기 링크를 넣었는데, 공지 목록·신청서·검색 결과 같은 서브 페이지엔 빠져 있습니다.

나쁜 예: 메인은 통과되지만 정작 사용자가 작업을 하는 신청서 페이지엔 건너뛰기 링크가 없어 매번 메뉴를 다 통과.
올바른 예: 공통 헤더 템플릿에 건너뛰기 링크를 넣어 모든 페이지에 일관 적용. 별도 템플릿 페이지도 빠짐없이 점검.

실수 8) 건너뛰기 링크가 메뉴 뒤에 있다

링크는 있는데 HTML 순서상 메뉴 다음에 위치합니다. 이미 메뉴를 다 통과한 뒤에 나타나니 무의미합니다.

나쁜 예: 헤더와 메뉴 코드 다음에 건너뛰기 링크 배치. 비상구가 비상 상황 끝난 뒤에 등장.
올바른 예: <body> 바로 다음, 어떤 메뉴보다도 먼저 배치해 Tab으로 가장 먼저 닿게.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. GitHub 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 건너뛰기 링크 마크업과 "초점 시 노출" CSS, 초점 이동 처리가 이미 구현된 상태로 들어 있습니다. 직접 visually-hidden을 짜다 display: none 함정에 빠지거나, 초점 이동을 빠뜨리는 실수를 처음부터 피할 수 있죠. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다.

구체적으로는 이런 골격입니다(개념 설명용):

```html

<body>

... 본문 ...

</main>

</body>

```

.krds-skip-link는 평소 화면 밖에 숨어 있다가 :focus 시 화면 안으로 나타나고, <main>은 id="main"과 tabindex="-1"로 초점을 받을 준비를 합니다. 이 세 가지(맨 앞 배치 / 초점 시 노출 / 초점 받을 수 있는 대상)가 갖춰지면 건너뛰기 링크의 기본은 끝납니다.

디자이너라면 — 건너뛰기 링크는 평소 안 보이는 컴포넌트라 시안에서 빠지기 쉽습니다. 그래서 시안에 "초점 시 나타나는 건너뛰기 링크" 상태를 따로 그려 두는 게 좋습니다. 어떤 색, 어떤 위치, 어떤 크기로 나타날지를 명시하면 개발 단계에서 "흐릿하게 떠서 안 보이는" 문제가 줄어듭니다. KRDS 공식 Figma(@krds) 라이브러리를 참고하면 표준 모습을 가져다 쓸 수 있습니다.

기획자라면 — 화면 정의서나 IA 설계 단계에서 "모든 페이지 상단에 건너뛰기 링크"를 명시적으로 적어 두세요. 한 줄 적는 것만으로 개발·QA 단계의 누락을 크게 줄일 수 있습니다. 또 "본문 바로가기"라는 표준 문구를 사이트 전체에서 통일하도록 정해 두면, 페이지마다 문구가 달라지는 일을 막습니다.

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

여기까지가 KRDS의 건너뛰기 링크 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트는 이걸 지키고 있나?"를 확인하는 일입니다. 건너뛰기 링크는 화면에 안 보이는 컴포넌트라, 사람이 눈으로만 봐서는 있는지 없는지조차 모릅니다. 매 페이지를 키보드로 Tab 해 가며 일일이 확인하려면 끝이 없죠. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

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

ViewCheck가 건너뛰기 링크에 대해 자동으로 보는 것들:

존재 여부: 페이지 상단에 건너뛰기 링크(또는 그 역할을 하는 요소)가 있는지
위치: 메뉴보다 앞에, 키보드로 가장 먼저 닿는 위치에 있는지(코드 순서 확인)
목적지 연결: 링크의 href 대상(#main 등)이 실제로 페이지에 존재하는지, 끊긴 링크가 아닌지
숨김 방식: display: none처럼 초점을 죽이는 방식으로 숨겨 두지 않았는지(초점 시 노출 패턴인지)
링크 문구: 목적이 분명한 문구인지("건너뛰기"만 있는 모호한 경우 탐지)

DOM만으로 판단하기 어려운 시각적 부분(예: 초점 시 실제로 화면에 또렷이 나타나는지)은 KRDScan Vision AI가 스크린샷과 초점 상태를 함께 보고 보강 판정합니다. 그래서 "코드엔 링크가 있는데 화면엔 안 뜨는" 절름발이 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 키보드로 Tab 하듯 동작을 함께 확인하기 때문에, 코드만으로는 안 보이는 문제까지 잡아냅니다.

리포트를 어떻게 읽나

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

특히 건너뛰기 링크는 다중 페이지 분석에서 진가를 발휘합니다. 메인엔 있는데 서브 페이지엔 없는 경우가 워낙 흔한데, 여러 페이지를 한꺼번에 분석하면 "메인·로그인엔 있고 공지 목록·신청서엔 없다" 같은 페이지별 편차가 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 키보드로 일일이 확인하면 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "접근성 챙기자"가 아니라, "이 페이지에 건너뛰기 링크를 이렇게 넣자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

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

Q. 건너뛰기 링크는 화면에 안 보이는데, 정말 꼭 필요한가요?

네, 키보드 사용자와 스크린리더 사용자에게는 사실상 필수입니다. 마우스 사용자에겐 안 보이고 필요도 없지만, 키보드만 쓰는 사람에게는 페이지마다 반복되는 메뉴를 통째로 건너뛰게 해 주는 유일한 비상구입니다. "안 보이니까 없어도 되겠지"가 아니라 "안 보이지만 누군가에겐 꼭 필요한" 컴포넌트라고 이해하시면 됩니다. 그리고 한국형 웹 접근성 지침(KWCAG)도 반복 영역을 건너뛸 수 있는 수단을 요구합니다.

Q. `display: none`으로 숨기면 왜 안 되나요?

display: none이나 visibility: hidden은 요소를 키보드 초점 대상에서 완전히 빼 버리기 때문입니다. 그러면 Tab을 눌러도 링크에 닿을 수가 없어 영원히 나타나지 않습니다. 코드엔 분명히 링크가 있는데 키보드로는 절대 만날 수 없는 "유령 링크"가 되는 거죠. 올바른 방법은 화면 밖으로 밀거나 클립으로 시각적으로만 숨기고(visually-hidden), 초점(:focus)을 받으면 다시 화면 안으로 끌어와 보이게 하는 것입니다.

Q. 링크는 떴는데 눌러도 본문으로 안 가요. 왜죠?

href="#main"만 걸어 두면 브라우저에 따라 화면은 스크롤되는데 키보드 초점은 상단에 그대로 머무는 경우가 있습니다. 그러면 사용자는 본문으로 갔다고 착각하고 Tab을 눌렀다가 다시 메뉴로 돌아가는 황당한 경험을 합니다. 대상 본문 요소에 tabindex="-1"을 주고, 링크 클릭 시 그 요소로 초점을 명시적으로 이동시키면 화면 스크롤과 초점 이동이 함께 일어나 문제가 해결됩니다. KRDS 킷 코드는 이 처리까지 포함하고 있습니다.

Q. 건너뛰기 링크 문구는 뭐라고 써야 하나요?

목적지가 분명한 문구가 좋습니다. "본문 바로가기", "주요 콘텐츠로 이동", "본문 영역으로 건너뛰기"가 표준적입니다. "건너뛰기", "이동", "여기"처럼 어디로 가는지 빠진 문구는 피하세요. 스크린리더 사용자는 링크 목록만 따로 뽑아 듣기도 하는데, 그때 문구만으로 의미가 통해야 합니다. 그리고 사이트 전체에서 같은 문구로 통일하는 게 좋습니다.

Q. 건너뛰기 링크를 여러 개 둬도 되나요?

됩니다. "본문 바로가기"뿐 아니라 "주메뉴 바로가기", "검색 바로가기"처럼 여러 개를 둘 수 있습니다. 다만 너무 많으면 그 자체로 또 통과해야 할 목록이 되니, 사용자가 자주 가고 싶어 하는 곳으로 추리는 게 좋습니다. 대부분의 공공 사이트라면 "본문 바로가기" 하나만 제대로 있어도 큰 효과를 봅니다. 여러 개를 둘 때는 각 링크의 목적지가 실제로 존재하고 작동하는지 모두 확인하세요.

Q. 우리 사이트는 메인엔 건너뛰기 링크가 있는데, 이걸로 충분한가요?

아닙니다. 건너뛰기 링크는 사용자가 방문하는 모든 페이지에 있어야 합니다. 정작 사용자가 시간을 많이 쓰는 곳은 신청서·검색 결과·목록 같은 서브 페이지인데, 거기에 건너뛰기 링크가 없으면 매번 메뉴를 다 통과해야 합니다. 공통 헤더 템플릿에 한 번 제대로 넣으면 모든 페이지에 자동 적용되지만, 별도 템플릿을 쓰는 페이지나 오래된 페이지가 누락되기 쉬우니 사이트 전체를 점검하는 게 안전합니다. ViewCheck로 여러 페이지를 한꺼번에 돌리면 어느 페이지가 빠졌는지 바로 드러납니다.

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

전혀 그렇지 않습니다. 건너뛰기 링크는 오히려 가장 적은 노력으로 가장 큰 접근성 개선을 얻을 수 있는 컴포넌트입니다. 공통 헤더 템플릿에 링크 한 줄과 CSS 몇 줄만 넣으면 사이트 전체에 한꺼번에 적용되니까요. 먼저 ViewCheck로 현황을 확인해 "어느 페이지에 건너뛰기 링크가 없고, 어떤 게 작동을 안 하는지" 목록을 만든 다음, 공통 템플릿부터 손보면 됩니다. 리뉴얼 예산을 들이지 않고도 며칠 만에 키보드 접근성을 크게 끌어올릴 수 있는, 가성비 최고의 개선입니다.

Q. 스크린리더에는 랜드마크(landmark)도 있다던데, 건너뛰기 링크가 또 필요한가요?

좋은 질문입니다. <main>, <nav> 같은 시맨틱 랜드마크가 있으면 일부 스크린리더 사용자는 랜드마크 단위로 점프할 수 있긴 합니다. 하지만 이건 스크린리더에 익숙한 사용자, 특정 보조기술에 한정된 기능입니다. 건너뛰기 링크는 랜드마크를 모르는 사용자, 스크린리더 없이 키보드만 쓰는 사용자까지 모두 도와줍니다. 둘은 서로 대체재가 아니라 보완재입니다. 랜드마크도 잘 갖추고, 건너뛰기 링크도 두는 게 가장 안전합니다.

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

ViewCheck로 돌려 보면 건너뛰기 링크 관련 문제가 한두 가지로 끝나지 않는 경우가 많습니다. 그래서 우선순위가 중요합니다. 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 건너뛰기 링크가 아예 없거나, display: none으로 죽어 있어 키보드로 닿을 수 없는 경우. 이건 키보드·스크린리더 사용자에게 매 페이지 메뉴 통과를 강제하는 문제라 1순위입니다. 특히 신청·로그인·검색처럼 사용 빈도가 높은 핵심 경로 페이지부터 먼저 손봐야 합니다.

그다음(높음) — 링크는 있는데 눌러도 본문으로 초점이 안 가거나, 목적지 id가 존재하지 않아 작동하지 않는 경우. 있으나 마나 한 절름발이 링크라, 사용자에게 오히려 혼란을 줍니다. 작동하는 링크로 고치는 게 두 번째 순위입니다.

그 후(보통) — 메인엔 있는데 일부 서브 페이지에 누락된 경우, 초점 시 나타나긴 하지만 흐릿하거나 위치가 어색한 경우. 사용은 가능하지만 특정 페이지·특정 상황에서 불편을 주는 문제입니다.

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

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

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹, component_summary) — 건너뛰기 링크를 포함한 탐색 컴포넌트의 정의와 예시를 화면으로 확인.
KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 건너뛰기 링크 마크업과 초점 노출 CSS, 초점 이동 처리를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
KRDS 공식 Figma(@krds) — 디자이너용 컴포넌트와 상태 참고.

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

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

마지막으로, 디자이너·개발자·기획자가 건너뛰기 링크를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 실제로 가장 빠른 검수 방법은 마우스를 내려놓고 페이지에 들어가 Tab 키를 한 번 눌러 보는 것입니다. 건너뛰기 링크가 가장 먼저 또렷하게 뜬다면 합격, 안 뜬다면 불합격입니다.

☐ 페이지에 들어가 Tab을 한 번 눌렀을 때 건너뛰기 링크가 가장 먼저 나타난다.
☐ 건너뛰기 링크가 HTML 구조상 메뉴보다 앞(<body> 바로 다음)에 있다.
☐ 평소엔 숨겨져 있되 display: none / visibility: hidden으로 죽이지 않았다(visually-hidden + :focus 노출).
☐ 초점 시 화면에 또렷하게(충분한 대비·크기·눈에 띄는 위치) 나타난다.
☐ 링크 문구가 목적이 분명하다("본문 바로가기" 등, "건너뛰기"만 X).
☐ 링크를 눌렀을 때 실제로 본문으로 초점이 이동한다(화면만 스크롤되고 끝나지 않는다).
☐ 링크의 href 대상 `id`가 페이지에 실제로 존재한다(끊긴 링크 X).
☐ 초점 외곽선(focus indicator)을 outline: none으로 지우지 않았다.
☐ 메인뿐 아니라 모든 페이지(목록·신청서·검색 결과 등)에 일관되게 있다.
☐ 가능하면 네이티브 마크업 또는 KRDS 킷 코드를 사용해 직접 구현 실수를 줄였다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 직접 visually-hidden을 짜다 display: none 함정에 빠지거나 초점 이동을 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 초점 시 나타나는 모습까지 표준대로 가져다 쓸 수 있습니다.

건너뛰기 링크는 화면에 보이지 않아 가장 자주 잊히지만, 사실 가장 적은 노력으로 가장 큰 접근성 개선을 만드는 컴포넌트입니다. 링크 한 줄과 CSS 몇 줄, 그리고 본문에 id 하나. 그게 전부인데, 키보드 사용자에게는 매 페이지 수십 번의 Tab을 단 한 번으로 줄여 줍니다. 우리가 무심코 빠뜨린 이 작은 링크 하나가, 누군가에게는 그 공공 서비스를 혼자 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 기준이 많아 보여도, 핵심은 결국 단순합니다. 페이지 맨 앞에 두고, 평소엔 숨기되 초점 시 또렷이 보이게 하고, 누르면 본문으로 초점까지 보내고, 모든 페이지에 일관되게 둘 것. 이 네 가지만 챙기면 건너뛰기 링크의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 30초면 확인할 수 있고, 더 간단하게는 마우스를 내려놓고 Tab을 한 번 눌러 보면 됩니다. 완벽을 한 번에 만들 필요는 없습니다. 공통 헤더에 건너뛰기 링크 하나부터 제대로 넣으면, 우리 사이트는 단번에 모든 페이지에서 더 많은 사람에게 열립니다. 다음 글에서는 건너뛰기 링크와 함께 탐색을 이루는 또 다른 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트엔 건너뛰기 링크가 제대로 있을까요? 지금 마우스를 내려놓고 Tab을 한 번 눌러 보세요. 그리고 krds.viewcheck.co.kr에서 URL만 넣으면, 모든 페이지에 건너뛰기 링크가 제대로 작동하는지 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #건너뛰기링크Skiplink #웹접근성 #ViewCheck #정부웹사이트 #UIUX #키보드접근성 #스크린리더 #KWCAG #건너뛰기링크 #Skiplink #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부