WCAG 2.4.1: 블록 건너뛰기

WCAG 2.4.1은 웹 페이지가 내비게이션 메뉴와 같은 반복되는 콘텐츠 블록을 건너뛸 수 있는 메커니즘을 제공하도록 요구합니다. 이를 통해 키보드 및 보조 기술 사용자들은 모든 링크를 탭으로 하나하나 거치지 않고도 주요 콘텐츠에 도달할 수 있습니다. 이는 레벨 A 요구 사항으로, 접근 가능한 키보드 내비게이션을 위한 기본 기준을 의미합니다.

이 규칙의 의미

WCAG 2.4.1 Bypass Blocks는 다음과 같이 규정한다. "여러 웹 페이지에서 반복되는 콘텐츠 블록을 건너뛸 수 있는 메커니즘이 제공되어야 한다." 실질적으로 이는 여러 페이지에 걸쳐 일관되게 나타나는 링크 모음, 내비게이션 메뉴, 배너 또는 기타 콘텐츠 블록에 대해, 사용자가 이를 건너뛰고 현재 페이지의 고유한 콘텐츠로 바로 이동할 수 있는 방법이 반드시 있어야 함을 의미한다.

가장 널리 알려진 구현 방식은 스킵 내비게이션 링크(skip navigation link)이다. 이는 페이지에서 가장 먼저 포커스를 받는 앵커 요소로, #main-content와 같은 프래그먼트 식별자를 통해 메인 콘텐츠 영역에 연결된다. 그러나 WCAG는 HTML5 <main>, <nav>, <header> 요소나 그에 상응하는 ARIA 랜드마크, 그리고 스크린 리더 사용자가 섹션 간을 이동할 수 있도록 하는 적절한 헤딩 구조 등, 다른 우회 메커니즘도 인정한다.

다음 중 하나 이상을 충족하면 페이지는 이 기준을 준수한 것으로 본다. 스킵 링크가 존재하고 제대로 동작한다. 페이지가 보조 기술이 빠른 내비게이션을 위해 노출하는 의미 있는 HTML5 랜드마크 요소를 사용한다. 또는 동등한 키보드 단축키나 페이지 내 내비게이션 메커니즘이 있어 사용자가 반복되는 블록을 건너뛸 수 있다. 스킵 링크는 기본적으로 시각적으로 숨겨져 있어도 되지만, 키보드 포커스를 받으면 화면에 보여야 하며, 활성화 시 실제로 키보드 포커스를 대상 요소로 이동시켜야 한다. 단순히 뷰포트만 스크롤해서는 안 된다.

다음과 같은 경우 페이지는 이 기준을 위반한다. 스킵 링크, 랜드마크 구조, 기타 메커니즘이 전혀 없는 경우. 스킵 링크가 존재하지만 display:none 또는 visibility:hidden으로 완전히 숨겨져 포커스를 받을 수 없는 경우. 스킵 링크의 대상 앵커가 DOM에 존재하지 않는 경우. 또는 링크는 있지만 포커스를 이동시키지 않아, 키보드 사용자가 여전히 모든 내비게이션 항목을 탭으로 통과해야 하는 경우. WCAG는 반복되는 블록이 전혀 없는 페이지(예: 내비게이션 헤더가 없는 단일 페이지 문서)에 대해 예외를 인정하지만, 이 예외는 범위가 좁고 실제 웹사이트에는 거의 적용되지 않는다.

왜 중요한가

이 기준은 여러 사용자 그룹에 직접적인 영향을 미친다. 키보드만 사용하는 사용자 — 반복성 긴장 장애, 마비, 떨림 등 운동 장애가 있는 사람들을 포함 — 는 상호작용 가능한 요소 사이를 이동하기 위해 전적으로 Tab 키에 의존한다. 우회 메커니즘이 없으면, 이들은 방문하는 모든 페이지에서 첫 번째 고유 콘텐츠에 도달하기 위해 Tab 키를 수십 번씩 눌러야 한다. 링크가 10~20개인 일반적인 웹사이트 내비게이션 바가 수백 번의 페이지 방문과 결합되면, 상당한 신체적·시간적 부담이 된다.

스크린 리더 사용자인 시각장애인 또는 저시력 사용자는 랜드마크 영역과 헤딩을 통해 페이지 구조를 파악하고 섹션 간을 이동한다. 최신 스크린 리더(JAWS, NVDA, VoiceOver)는 랜드마크와 헤딩을 탐색하기 위한 자체 단축키를 제공하지만, 이러한 단축키는 페이지가 올바르게 구조화되어 있을 때만 제대로 작동한다. 랜드마크도 스킵 링크도 없는 페이지는, 페이지가 로드될 때마다 반복되는 내비게이션을 포함해 맨 위에서부터 모든 요소를 선형적으로 읽도록 강제한다.

현실적인 사례를 생각해 보자. 터키의 한 시각장애인이 전자정부 포털에 접속해 세금 신고를 하려 한다. 포털에는 링크 18개가 있는 상단 내비게이션 바, 링크 4개가 있는 브레드크럼, 링크 12개가 있는 보조 사이드바가 있어, 폼 필드에 도달하기 전까지 총 34번의 Tab 키 입력이 필요하다. 우회 메커니즘이 없다면, 이 사용자는 다단계 절차의 각 페이지마다 34개 요소를 모두 통과해야 한다. 제대로 구현된 스킵 링크는 이를 한 번의 키 입력으로 줄여 준다.

인지적 접근성도 중요한 요소다. 주의력 관련 어려움이 있는 사용자는 반복적이고 산만한 내비게이션 요소를 처리하지 않고도 관련 콘텐츠로 바로 이동할 수 있을 때 도움을 받는다. 장애인의 접근성을 넘어, 잘 구조화된 랜드마크 영역은 SEO에도 도움이 된다. 검색 엔진 크롤러는 문서 구조를 사용해 콘텐츠의 계층과 관련성을 이해하기 때문이다. 접근 가능한 내비게이션 아키텍처와 명확한 랜드마크 구조는 더 나은 인덱싱과 잠재적으로 더 높은 검색 순위에 기여한다.

테스트 방법

자동 검사: 페이지에서 axe DevTools(브라우저 확장) 또는 Lighthouse(Chrome DevTools > Lighthouse > Accessibility)를 실행한다. bypass, skip-link, tabindex 규칙 아래의 위반 항목을 특히 확인한다. axe DevTools에서는 이 규칙 ID로 결과를 필터링한다. Lighthouse에서는 접근성 감사의 "Navigation" 섹션을 확인한다. "Needs Review" 항목에 주의한다. axe는 일부 우회 관련 검사를 수동 확인이 필요한 것으로 표시한다.
키보드 테스트(모든 브라우저): 스크린 리더를 실행하지 않은 상태에서 브라우저로 페이지를 연다. Tab 키를 한 번 누른다. 가장 먼저 포커스를 받는 요소가 스킵 링크인지 확인한다(이전에 화면 밖에 있었다면 이 시점에 시각적으로 나타날 수 있다). Enter 키로 스킵 링크를 활성화한다. 키보드 포커스가 메인 콘텐츠 영역으로 이동했는지 확인한다. 다음 Tab 키 입력은 첫 번째 내비게이션 링크가 아니라 메인 콘텐츠 내부의 첫 번째 상호작용 요소로 이동해야 한다. 포커스가 이동하지 않으면 스킵 링크는 잘못 구현된 것이다.
NVDA + Firefox: NVDA를 실행하고 Firefox에서 페이지를 연다. Insert+F7 단축키를 눌러 요소 목록을 열고 랜드마크를 확인한다. 또는 D 키를 눌러 랜드마크 영역 간을 이동하며 main 랜드마크가 존재하고 명확하게 레이블링되어 있는지 확인한다. H 키로 헤딩 단위 탐색을 수행해 페이지 섹션을 식별할 수 있는 헤딩 구조인지 검증한다. 스킵 링크로 Tab 키로 이동해 Enter로 활성화한 뒤, NVDA가 메인 영역 내부의 콘텐츠를 읽기 시작하는지 확인한다.
VoiceOver + Safari(macOS/iOS): VoiceOver를 활성화한다(Mac에서는 Command+F5). Rotor(Control+Option+U)를 사용해 랜드마크 메뉴를 열고, 이름이 지정된 랜드마크 영역이 나타나는지 확인한다. 스킵 링크로 Tab 키로 이동해 Enter를 누르고, VoiceOver가 활성화 직후 메인 콘텐츠 영역의 내용을 읽는지 확인한다. iOS에서는 Rotor 제스처로 랜드마크로 전환한 뒤 스와이프로 순회한다.
JAWS + Chrome: JAWS를 실행한 상태에서 Q 키를 눌러 메인 콘텐츠 랜드마크로 바로 이동한다. JAWS가 메인 영역에 진입했음을 알리는지 확인한다. Insert+F3으로 랜드마크 목록을 열고 적절한 레이블이 있는지 확인한다. 페이지 시작 지점에서 Tab 키를 눌러 스킵 링크가 가장 먼저 안내되는지, 그리고 "Skip to main content"와 같이 접근 가능한 이름으로 읽히는지 확인한다.
포커스 대상 검증: 스킵 링크의 href 값(예: #main-content)을 확인한다. 브라우저 개발자 도구를 사용해 id='main-content'를 가진 요소가 DOM에 존재하는지 확인한다. 해당 요소가 <div>와 같은 비대화형 컨테이너라면, Tab 순서에 삽입하지 않고도 프로그래밍적으로 포커스를 받을 수 있도록 tabindex='-1'이 설정되어 있는지 확인한다.

수정 방법

스킵 링크 누락 — 잘못된 예

<!-- Navigation appears first with no bypass mechanism -->
<div class='nav-wrapper'>
  <a href='/home'>Home</a>
  <a href='/about'>About</a>
  <a href='/services'>Services</a>
  <a href='/contact'>Contact</a>
</div>
<div class='content'>
  <h1>Welcome</h1>
  <p>Page content here.</p>
</div>

스킵 링크 누락 — 올바른 예

<!-- Skip link is the first focusable element; visually hidden until focused -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<nav aria-label='Primary navigation'>
  <a href='/home'>Home</a>
  <a href='/about'>About</a>
  <a href='/services'>Services</a>
  <a href='/contact'>Contact</a>
</nav>

<!-- tabindex='-1' allows the div to receive programmatic focus without
     entering the natural tab order -->
<main id='main-content' tabindex='-1'>
  <h1>Welcome</h1>
  <p>Page content here.</p>
</main>

존재하지 않는 대상을 가리키는 스킵 링크 — 잘못된 예

<!-- The skip link exists but points to an ID that is not in the DOM -->
<a href='#content' class='skip-link'>Skip to main content</a>

<nav>...navigation links...</nav>

<!-- The id here is 'main', not 'content' — the skip link target is broken -->
<div id='main'>
  <h1>Page Title</h1>
</div>

존재하지 않는 대상을 가리키는 스킵 링크 — 올바른 예

<!-- href value exactly matches the id of the target element -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<nav>...navigation links...</nav>

<!-- id matches the href fragment; tabindex='-1' ensures focus is received -->
<main id='main-content' tabindex='-1'>
  <h1>Page Title</h1>
</main>

영구적으로 숨겨진 스킵 링크 — 잘못된 예

<!-- display:none removes the element from the accessibility tree entirely -->
<a href='#main-content' style='display:none'>Skip to main content</a>

<!-- visibility:hidden also hides from screen readers and keyboard -->
<a href='#main-content' style='visibility:hidden'>Skip to main content</a>

영구적으로 숨겨진 스킵 링크 — 올바른 예

<!-- CSS moves the link off-screen visually but keeps it in the tab order.
     On :focus, it becomes visible so sighted keyboard users can see it. -->
<style>
  .skip-link {
    position: absolute;
    left: -9999px;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
  }
  .skip-link:focus {
    position: static;
    width: auto;
    height: auto;
    overflow: visible;
  }
</style>

<a href='#main-content' class='skip-link'>Skip to main content</a>

랜드마크 구조 없음 — 잘못된 예

<!-- Generic divs with no semantic role — screen readers cannot identify regions -->
<div class='header'>...logo and nav...</div>
<div class='sidebar'>...secondary links...</div>
<div class='page-body'>...main content...</div>
<div class='footer'>...footer links...</div>

랜드마크 구조 없음 — 올바른 예

<!-- HTML5 semantic elements expose landmark roles to assistive technologies.
     Multiple nav elements are distinguished with aria-label. -->
<header>
  <nav aria-label='Primary navigation'>...main nav links...</nav>
</header>
<aside aria-label='Related resources'>...secondary links...</aside>
<main id='main-content' tabindex='-1'>...main content...</main>
<footer>
  <nav aria-label='Footer navigation'>...footer links...</nav>
</footer>

자주 발생하는 실수

스킵 링크를 화면 밖으로 보내는 CSS 기법 대신 display:none 또는 visibility:hidden으로 숨겨, 시각적 표시뿐 아니라 접근성 트리에서도 제거해 모든 사용자에게 완전히 비작동 상태로 만드는 경우.
href='#main-content'를 가진 스킵 링크를 추가했지만, 대상 요소에 일치하는 id='main-content' 속성을 누락해, 링크를 활성화해도 아무 일도 일어나지 않게 만드는 경우.
<div>나 <section>과 같은 비대화형 컨테이너 요소를 스킵 링크의 대상으로 지정하면서 tabindex='-1'을 추가하지 않아, 브라우저가 뷰포트만 스크롤하고 키보드 포커스는 대상 요소로 이동시키지 않는 경우.
스킵 링크를 DOM에서 가장 첫 번째 포커스 가능한 요소가 아닌 위치 — 예를 들어 로고 뒤나 첫 번째 내비게이션 링크 뒤 — 에 배치해, 사용자가 스킵 링크에 도달하기 위해서도 Tab 키로 콘텐츠를 통과해야 하도록 만드는 경우.
페이지 어디에서든 tabindex='1'과 같은 양수 tabindex 값을 사용해, 탭 순서를 예측 불가능하게 재구성하고 스킵 링크를 기대되는 첫 번째 위치에서 멀어지게 만드는 경우.
페이지에 기본 내비게이션, 브레드크럼, 푸터 내비게이션 등 여러 내비게이션 영역이 있음에도, 이름 없는 <nav> 랜드마크 하나만 제공해, 스크린 리더 사용자가 랜드마크 단축키로 이들 영역을 구분할 수 없게 만드는 경우.
모든 스크린 리더 사용자가 랜드마크 단축키를 알고 사용한다고 가정하고, 스킵 링크 없이 랜드마크 구조에만 의존하는 경우. 스크린 리더를 사용하지 않는 시각적 키보드 사용자는 랜드마크만으로는 이득을 얻지 못하며, 눈에 보이는 스킵 링크에 의존한다.
내비게이션, 헤더, 푸터를 포함한 전체 페이지 본문을 하나의 <main> 요소로 감싸, <main>을 페이지의 고유 콘텐츠에만 한정하지 않는 경우.
여러 내비게이션 랜드마크가 존재할 때, 내비게이션을 담은 <div>에 role='navigation'만 지정하고 aria-label을 제공하지 않아, 스크린 리더가 단지 "navigation"이라고만 안내하고 영역을 구분할 수 없게 만드는 경우.
정적 HTML 프로토타입에서는 스킵 링크를 올바르게 구현했지만, JavaScript 프레임워크(예: React, Angular, Vue) 렌더링 과정에서 루트 레이아웃에 스킵 링크 컴포넌트를 포함하지 않거나 클라이언트 측 하이드레이션 중 조건부로 제거해, 실제 서비스에서는 스킵 링크가 사라지는 경우.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.1 레벨 AA 및 WCAG 2.2 레벨 A 적합성 기준을 기반으로 한 웹 및 모바일 접근성 의무 요건을 수립한다. WCAG 2.4.1 Bypass Blocks는 레벨 A 기준으로, 이 대통령령에서 가장 기본적인 요구사항에 속한다. 이는 해당 기준이, 규율 대상 기관의 디지털 서비스가 결코 그 아래로 떨어져서는 안 되는 최소 기준선을 의미한다.

대통령령은 공공 및 민간 부문의 광범위한 기관을 포괄한다. 공공 기관 — 부처, 지방자치단체, 국가 기관, 정부 산하 기관 등을 포함 — 은 대통령령 발효일로부터 1년 이내에 완전한 적합성을 달성해야 한다. 규제 대상인 민간 부문 기관은 2년의 준수 기간을 가진다. 대상 민간 부문 범주에는 전자상거래 플랫폼, 은행 및 금융기관, 병원 및 의료 서비스 제공자, 가입자 200,000명 이상인 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교가 포함된다.

이들 기관의 경우, WCAG 2.4.1을 구현하지 못하면 그 웹사이트는 표준의 가장 기본 수준에서조차 비준수 상태가 된다. 스킵 내비게이션 메커니즘이 없는 정부 포털, 온라인 뱅킹 플랫폼, 병원 예약 시스템, 전자상거래 결제 흐름은 대통령령의 요구사항을 직접적으로 위반하는 것이다. 키보드 내비게이션이 운동 장애가 있는 사용자에게 기본적이라는 점, 그리고 스크린 리더 사용성이 랜드마크 구조에 크게 의존한다는 점을 고려하면, 이 기준은 접근성 감사와 규제 평가에서 상당한 비중을 차지한다.

규정 준수를 준비하며 내부 접근성 감사를 수행하거나 제3자 평가를 의뢰하는 기관은 WCAG 2.4.1을 1차 점검 항목으로 다루어야 한다. 구현이 가장 쉽고, 키보드 및 보조 기술에 의존하는 사용자에게 가장 큰 영향을 주는 항목 중 하나이기 때문이다. 이를 해결하지 않으면, 규제 검토에서 기본적인 비적합 사례로 구체적으로 지적될 수 있으며, 대통령령 하에서 기관의 전반적인 준수 상태에 영향을 미칠 수 있다.