직접 살펴보는 예제
반복 링크를 건너뛰고 본문으로 이동하기
바로가기 실행 후 Tab을 눌러 예제 본문의 자료 링크로 이어지는지 확인하세요.
아래 내용은 구조를 설명하기 위해 만든 예제입니다. 실제 상품·고객 성과 자료가 아닙니다.
예제 본문 바로가기예제 본문
반복 링크 세 개를 지나지 않고 이 영역으로 이동했습니다. 다음 Tab은 아래 자료 링크로 이어집니다.
예제 자료 설명 보기자료 설명
실제 페이지에서는 하나의 main을 본문 목적지로 사용할 수 있습니다. 이 글 안의 예제는 main을 중첩하지 않고 이름 있는 section으로 구분합니다.
건너뛰기 링크와 랜드마크 예제에서 나눈 판단
예제의 바로가기 링크는 반복 탐색 세 항목을 건너뛰고 본문 영역에 초점을 둡니다. 문서 전체에는 main을 하나만 유지하고, 예제 내부의 본문은 별도 이름이 있는 section으로 표시했습니다. 예제 안에 두 번째 main을 중첩하지 않습니다.
긴 페이지의 문제는 길이보다 본문 앞에서 반복되는 블록입니다
페이지가 길어도 독자가 제목과 본문으로 바로 들어갈 수 있다면 첫 탐색 부담은 크지 않을 수 있습니다. 반대로 모든 페이지 시작에 로고, 언어 선택, 계정 링크, 주 메뉴 열두 개, 검색, 공지, 카테고리 목록이 같은 순서로 반복되면 키보드 사용자는 방문할 때마다 여러 번 Tab을 눌러야 합니다. 화면을 확대해 한 번에 적은 영역만 보는 사람도 본문이 어디서 시작되는지 찾기 어렵습니다. 먼저 전체 높이를 줄이기보다 본문 전에 되풀이되는 블록과 필요한 이동 목적지를 목록화합니다.
WCAG 2.2의 Bypass Blocks 해설은 여러 웹페이지에서 반복되는 콘텐츠 블록을 우회할 수 있는 수단이 필요하다고 설명합니다. 반복 블록의 예로 내비게이션 링크, 헤더 콘텐츠, 광고 프레임 등을 들며, 건너뛰기 링크와 적절한 구조를 사용할 수 있는 방법을 다룹니다. 모든 단일 링크를 제거하라는 뜻이 아니라 반복 묶음을 지나 핵심 영역으로 갈 수 있게 하는 기준입니다. 이 글은 해당 문서를 긴 글 페이지의 편집·구현 점검 기준으로 사용하며 특정 페이지의 전체 적합성을 판정하지 않습니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
| 페이지 시작 블록 | 반복 여부 | 기본 처리 | 별도 목적지 판단 | 검수 질문 |
|---|---|---|---|---|
| 브랜드·홈 링크 | 대부분 반복 | 헤더에 유지 | 본문 바로가기 제공 | 첫 링크보다 본문이 지나치게 먼가 |
| 주 내비게이션 | 전체 사이트 반복 | 이름 있는 nav | 내비게이션 바로가기 선택 | 링크 수와 사용 빈도가 높은가 |
| 사이트 검색 | 여러 페이지 반복 | search 영역 또는 폼 | 검색 바로가기 선택 | 긴 메뉴 뒤에 숨어 있는가 |
| 글 목차 | 페이지마다 내용 다름 | 본문 내부 nav | 목차 건너뛰기 선택 | 본문 첫 문단 도달을 막는가 |
| 필터 묶음 | 목록 페이지 안에서 반복 | 이름 있는 영역 | 결과로 건너뛰기 제공 | 필터가 결과보다 먼저 긴가 |
| 광고·알림 | 배치에 따라 반복 | 의미와 닫기 제공 | 핵심 콘텐츠 우회 | 초점 순서를 불필요하게 늘리는가 |
링크 이름보다 먼저 이동 뒤 읽기 시작할 실제 목적지를 정합니다
‘본문 바로가기’가 있다고 해도 화면만 아래로 스크롤되고 키보드 초점은 헤더에 남으면 다음 Tab에서 다시 메뉴로 돌아갈 수 있습니다. 목적지는 문서의 핵심 내용을 감싸는 main 요소나 본문 시작 제목처럼 이동 뒤 읽기와 조작이 이어지는 지점이어야 합니다. 식별자는 페이지 안에서 유일해야 하며 링크의 href와 정확히 일치해야 합니다. 목적지 위에 고정 헤더가 겹쳐 제목을 가린다면 스크롤 여백을 조정하되 초점 표시 자체를 지우지 않습니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
- 페이지의 첫 Tab 순서에서 반복되는 블록과 핵심 콘텐츠 시작점을 표시합니다.
- 본문, 주 내비게이션, 검색, 필터 결과처럼 자주 필요한 목적지만 우선순위로 고릅니다.
- 각 목적지에 고유한 식별자를 두고 보이는 제목 또는 접근 가능한 이름과 의미를 맞춥니다.
- 링크 활성화 뒤 화면 위치와 키보드 초점이 같은 영역으로 이동하는지 확인합니다.
- 다음 Tab과 Shift+Tab이 목적지 주변의 예상 요소로 이어지는지 왕복합니다.
- 고정 헤더, 관리자 막대, 쿠키 알림이 목적지 제목과 초점 테두리를 가리지 않는지 봅니다.
- 하위 경로와 여러 템플릿에서 같은 식별자가 중복되거나 빠지지 않는지 검사합니다.
| 링크 문구 | 목적지 | 적합한 경우 | 실패 신호 |
|---|---|---|---|
| 본문 바로가기 | 현재 페이지의 main | 반복 헤더 뒤 핵심 내용 | 빈 컨테이너로 이동 |
| 주 메뉴 바로가기 | 주 내비게이션 | 첫 초점과 메뉴 사이에 긴 유틸리티 영역 | 메뉴 이름 없는 nav |
| 검색 바로가기 | 검색 입력 또는 search 영역 | 검색이 주요 과업 | 레이블 없는 입력으로 이동 |
| 결과 바로가기 | 필터 뒤 결과 제목 | 필터 항목이 길고 결과 갱신 | 이전 결과 식별자로 이동 |
| 목차 건너뛰기 | 첫 본문 절 | 목차가 매우 길고 반복 조작 필요 | 제목 없이 문단 중간으로 이동 |
| 푸터 바로가기 | 이름 있는 footer | 정책·연락 경로가 핵심 | 모든 페이지에 불필요하게 추가 |
건너뛰기 링크를 많이 제공하면 또 하나의 긴 메뉴가 될 수 있습니다. 자체 기준에서는 첫 링크로 본문을 두고, 주 메뉴나 검색처럼 페이지 성격상 반복 이동 수요가 분명한 목적지만 추가합니다. 글 페이지에는 본문, 검색 결과 페이지에는 결과, 상품 목록에는 필터 뒤 결과처럼 템플릿별로 다를 수 있습니다. 다만 같은 템플릿에서 링크 이름과 목적지가 페이지마다 달라지지 않게 공통 구조를 사용합니다. 실제 우선순위는 사용자 조사 없이 확정하지 않습니다.
건너뛰기 링크는 첫 초점에서 보이고 닫힌 메뉴에 가려지지 않아야 합니다
링크를 화면 밖에 숨겨 두었다가 키보드 초점을 받으면 보이게 하는 방식은 시각적 배치를 단순하게 할 수 있습니다. 하지만 초점 상태에서도 화면 밖에 남거나, overflow hidden이 적용된 헤더에 잘리거나, 배너 뒤 낮은 z-index에 놓이면 사용할 수 없습니다. 페이지를 새로 연 뒤 마우스를 움직이지 않고 Tab 한 번으로 링크가 나타나는지 확인합니다. 링크 문구, 테두리, 배경의 대비와 위치가 현재 화면에서 읽히고 고정 헤더가 움직여도 잘리지 않아야 합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
| 상태 | 예상 화면 | 예상 초점 | 검사 방법 | 오류 예 |
|---|---|---|---|---|
| 새로 열림 | 링크가 숨거나 상시 표시 | 첫 Tab 대상 | 키보드만 사용 | 로고 뒤에서 시작 |
| 초점 받음 | 문구와 경계가 완전히 보임 | 링크에 유지 | Tab 후 화면 확인 | 상단 밖에 일부 잘림 |
| 활성화 | 목적지 제목이 보임 | 목적지로 이동 | Enter로 실행 | 스크롤만 이동하고 초점 잔류 |
| 다음 이동 | 목적지 주변 콘텐츠 | 첫 조작 요소로 진행 | Tab 한 번 추가 | 헤더 링크로 되돌아감 |
| 역방향 | 이전 요소를 예측 가능 | Shift+Tab 경로 유지 | 왕복 시험 | 보이지 않는 요소에 갇힘 |
| 확대·고정 헤더 | 목적지와 초점 테두리 노출 | 변화 없음 | 200퍼센트 확대 | 헤더가 제목을 덮음 |
클릭 이벤트로 스크롤 좌표만 계산하는 방식보다 문서 안 링크의 기본 동작을 출발점으로 삼습니다. 스크립트가 없어도 href가 목적지 식별자와 연결돼야 하며, 필요한 초점 보완은 실제 브라우저에서 확인합니다. 목적지에 무조건 tabindex 0을 넣으면 원래 조작 대상이 아닌 컨테이너가 일반 Tab 순서에 추가될 수 있습니다. 일시적으로 초점을 받을 필요가 있다면 문서 순서를 늘리지 않는 방식의 적합성을 검토하고, 제목의 시각적 초점 표시가 이해 가능한지 확인합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
랜드마크는 보이는 상자 수가 아니라 페이지의 큰 기능 구역만 나타냅니다
WAI-ARIA Authoring Practices의 HTML 섹셔닝 요소 랜드마크 예제는 main, nav, aside 같은 여러 HTML 요소가 기본적으로 ARIA 랜드마크를 정의할 수 있음을 보여줍니다. 예제는 페이지에서 랜드마크와 제목을 시각적으로 표시해 구조를 살펴볼 수 있게 구성돼 있습니다. 따라서 모든 div에 role을 추가하는 방식보다 먼저 문서의 의미에 맞는 HTML 요소를 선택합니다. 랜드마크는 사이트 헤더, 주 탐색, 핵심 본문, 보조 정보, 검색, 푸터처럼 큰 기능 단위를 찾는 데 쓰고 카드와 소제목마다 남발하지 않습니다.참고: W3C Web Accessibility Initiative · HTML Sectioning Elements: ARIA Landmarks Example

| 기능 구역 | 우선 검토 요소 | 이름이 필요한 경우 | 피할 구조 |
|---|---|---|---|
| 사이트 머리말 | header | 페이지 맥락에 따라 판정 | 카드마다 banner 역할 |
| 주 탐색 | nav | 여러 nav를 구분할 때 | 링크 하나마다 navigation 역할 |
| 검색 | search 또는 검색 폼 구조 | 목적이 분명하지 않을 때 | 모든 입력 묶음을 search로 지정 |
| 핵심 내용 | main | 일반적으로 하나의 핵심 영역 | 본문 카드마다 main |
| 보조 정보 | aside | 여러 보조 영역을 구분할 때 | 관련 없는 장식까지 complementary |
| 사이트 바닥글 | footer | 문서 맥락에 따라 판정 | 글의 모든 섹션 footer를 contentinfo로 강제 |
| 특정 중요 구역 | section과 접근 가능한 이름 | 랜드마크로 노출할 필요가 명확할 때 | 제목 없는 region 남발 |
같은 요소라도 문서 안 위치와 중첩에 따라 랜드마크로 노출되는 방식이 달라질 수 있으므로 요소 이름만 보고 역할을 단정하지 않습니다. 브라우저의 접근성 트리나 검사 도구에서 실제 역할과 이름을 확인합니다. 헤더 안의 nav, main 안의 목차 nav, 본문 옆 관련 글 aside처럼 의미 있는 중첩은 가능하지만, 구조가 깊어질수록 랜드마크 목록이 페이지 목차처럼 길어지지 않는지 봅니다. 큰 기능 구역과 글의 제목 계층은 서로 보완하며 어느 하나가 다른 하나를 대신하지 않습니다.참고: W3C Web Accessibility Initiative · HTML Sectioning Elements: ARIA Landmarks Example
자체 긴 글 예제에서 첫 Tab부터 본문 첫 링크까지 경로를 그립니다
자체 예제는 실제 사이트와 무관한 ‘도시 기록 읽기’ 페이지입니다. 상단에는 본문 바로가기, 홈 링크, 여섯 개의 주 메뉴, 검색이 있고, main 안에는 글 제목, 요약, 열두 항목의 목차, 여덟 개 본문 절이 있습니다. 본문 옆에는 관련 기록 세 개, 끝에는 이전·다음 글과 사이트 푸터가 있습니다. 사용자 수, 탐색 시간, 성공률은 가정하지 않습니다. 예제의 목적은 반복 블록과 기능 구역을 식별하고 건너뛰기 링크·랜드마크·제목을 한 문서 순서에 배치하는 것입니다.
| 문서 순서 | 요소 | 랜드마크·이름 | 건너뛰기 관계 | 다음 키보드 경로 |
|---|---|---|---|---|
| 1 | 본문 바로가기 | 별도 랜드마크 아님 | main 식별자로 이동 | 본문 제목 주변 |
| 2 | 사이트 header | banner 맥락 확인 | 필요 시 주 메뉴 링크 | 홈·주 메뉴·검색 |
| 3 | 주 메뉴 | nav ‘주요’ | 상단 선택 목적지 | 카테고리 링크 |
| 4 | 검색 | search ‘사이트 검색’ | 상단 선택 목적지 | 입력·제출 |
| 5 | 글 본문 | main | 기본 목적지 | 제목·요약·목차 |
| 6 | 글 목차 | nav ‘이 글의 목차’ | 긴 경우 목차 뒤 링크 고려 | 본문 절 링크 |
| 7 | 관련 기록 | aside ‘관련 읽을거리’ | 직접 목적지 없음 | 관련 글 링크 |
| 8 | 글 이동 | nav ‘다음 글과 이전 글’ | 직접 목적지 없음 | 인접 글 링크 |
| 9 | 사이트 footer | contentinfo 맥락 확인 | 필요성 별도 판단 | 정책·문의 링크 |
첫 Tab에서 본문 바로가기를 실행하면 main의 시작이 화면에 보이고, 다음 Tab은 main 안의 첫 조작 요소로 이어집니다. 목차가 길어 첫 문단까지 많은 이동이 필요하면 ‘목차 건너뛰기’를 목차 시작에 추가해 첫 본문 절로 연결할 수 있습니다. 다만 목차 링크 자체가 페이지 안 빠른 이동 수단이므로 항목 수와 사용 맥락을 보고 결정합니다. 주 메뉴 바로가기와 검색 바로가기는 항상 노출하지 않고 사이트에서 해당 과업이 중요하다는 근거가 있을 때 추가합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
랜드마크 목록에서는 주요, 사이트 검색, main, 이 글의 목차, 관련 읽을거리, 다음 글과 이전 글, 사이트 정보가 서로 구분됩니다. 제목 탐색에서는 글 H1과 각 H2가 내용의 세부 구조를 제공합니다. 건너뛰기 링크, 랜드마크, 제목은 같은 기능을 복제하는 장식이 아니라 시작점 이동, 큰 구역 이동, 내용 구조 탐색이라는 서로 다른 경로를 맡습니다. 한 경로가 존재한다는 이유로 다른 경로의 오류를 방치하지 않습니다.참고: W3C Web Accessibility Initiative · HTML Sectioning Elements: ARIA Landmarks Example · W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
필터 결과와 고정 배너가 바뀌어도 목적지와 초점 경로를 유지합니다
검색이나 목록 페이지에서는 필터를 적용한 뒤 결과 제목이 교체되거나 내용만 비동기로 갱신될 수 있습니다. ‘결과 바로가기’의 식별자가 사라지거나 같은 식별자가 이전 화면과 새 화면에 동시에 남지 않도록 합니다. 결과 수 변화는 별도 상태 메시지로 전달할 수 있지만, 필터를 선택할 때마다 무조건 결과로 초점을 이동하면 여러 조건을 연속 설정하기 어려울 수 있습니다. 적용 버튼을 눌렀을 때 이동할지, 결과 상태만 알릴지 상호작용을 정하고 예측 가능하게 유지합니다.
| 변화 상태 | 유지할 것 | 추가 확인 | 실패 신호 |
|---|---|---|---|
| 필터 적용 | 결과 목적지 식별자 | 초점 정책과 결과 수 알림 | 사라진 식별자 링크 |
| 무한 스크롤 | main과 결과 영역 관계 | 새 항목 뒤 대체 이동 | 푸터에 영구 접근 불가 |
| 고정 헤더 축소 | 목적지 노출 | 스크롤 여백과 확대 | 제목·초점 테두리 가림 |
| 쿠키 배너 표시 | 첫 초점 정책 | 동의 전후 순서 | 건너뛰기 링크를 배너 뒤에 숨김 |
| 관리자 도구막대 | 고유 목적지 | 로그인·비로그인 위치 | 상단 오프셋을 고정값으로 가정 |
| 언어 전환 | 링크 문구와 문서 방향 | 각 언어의 고유 식별자 | 번역 뒤 href 불일치 |
| 오류 메시지 | main 시작과 폼 관계 | 오류 요약으로 이동 | 본문 바로가기가 오류를 건너뜀 |
쿠키 배너나 긴급 공지가 모달인지 일반 문서 영역인지에 따라 첫 초점 정책이 달라집니다. 모달이라면 그 패턴의 초점 관리가 우선할 수 있고, 일반 배너라면 본문 바로가기를 사용할 수 있어야 합니다. 시각적으로만 위에 떠 있는 요소와 DOM의 순서가 다르면 Tab 순서가 화면을 왕복할 수 있으므로 둘을 함께 검사합니다. 공지가 닫힌 뒤 초점이 사라지거나 링크가 화면 밖으로 이동하지 않게 닫기 버튼과 복귀 지점을 정합니다.
고정 헤더의 높이를 JavaScript로 읽어 목적지마다 여백을 주는 경우 글꼴 확대, 줄바꿈, 언어 변경, 화면 회전 뒤 값을 다시 계산하는지 확인합니다. 가능하면 레이아웃 속성으로 스크롤 여백을 정의하고 동작을 단순화합니다. 애니메이션 스크롤은 목적지 도달 여부를 대신하지 않으며 움직임 선호 설정도 고려합니다. 부드러운 이동을 끄더라도 링크, 초점, 랜드마크 관계는 그대로 작동해야 합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks
키보드 경로와 랜드마크 목록을 별도 행렬로 검사합니다
화면에서 main 요소를 확인하는 것만으로 건너뛰기 동작이 검증되지는 않고, 링크가 움직인다는 사실만으로 랜드마크 구조가 적절한 것도 아닙니다. 자체 검수 행렬은 키보드 발견, 링크 실행, 목적지 표시, 다음 초점, 역방향 이동, 랜드마크 역할과 이름, 제목 계층을 별도 열로 둡니다. 홈·글·카테고리·검색 결과·문의·정책·404처럼 반복 헤더를 공유하는 템플릿마다 검사합니다. 한 페이지의 통과를 공통 템플릿 전체의 결과로 확대하지 않습니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks · W3C Web Accessibility Initiative · HTML Sectioning Elements: ARIA Landmarks Example
- 새로 연 페이지에서 첫 Tab으로 본문 바로가기 문구와 초점 표시를 확인합니다.
- Enter로 실행해 URL 조각, 화면 위치, 실제 키보드 초점이 같은 목적지인지 봅니다.
- 다음 Tab과 Shift+Tab으로 목적지 전후의 상호작용 순서가 문서 흐름과 맞는지 확인합니다.
- 200퍼센트 확대와 320픽셀 폭에서 링크와 목적지 제목이 고정 요소에 가리지 않는지 봅니다.
- 접근성 트리에서 main, navigation, search, complementary, contentinfo의 실제 노출을 확인합니다.
- 같은 종류의 랜드마크가 여러 개면 접근 가능한 이름이 짧고 서로 구분되는지 대조합니다.
- JavaScript 차단과 느린 로드에서도 문서 안 링크와 핵심 HTML 구조가 작동하는지 확인합니다.
- 존재하지 않는 URL과 빈 검색 결과에서도 본문 목적지가 사라지지 않는지 검사합니다.
| 검사 축 | 관찰값 | 통과 범위 | 기록할 한계 |
|---|---|---|---|
| 발견 | 첫 Tab 위치·문구·가시성 | 반복 블록 전에 사용 가능 | 마우스·음성 명령 별도 |
| 실행 | href·식별자·화면·초점 | 같은 목적지로 일치 | 브라우저별 동작 차이 |
| 연속 이동 | 다음·이전 초점 | 본문 주변으로 이어짐 | 동적 콘텐츠 변화 |
| 랜드마크 | 역할·이름·개수 | 큰 기능 구역만 구분 | 보조기술별 표현 차이 |
| 제목 | H1·H2 순서와 이름 | 랜드마크와 내용 구조 보완 | 시각 스타일과 별도 |
| 작은 화면 | 가림·가로 넘침·확대 | 링크와 제목 전부 노출 | 모든 기기 대표 아님 |
| 실패 상태 | 스크립트 차단·404·빈 결과 | 핵심 경로 유지 | 서드파티 배너 변동 |
공개 게이트는 이동 횟수가 아니라 우회 경로의 완전성을 확인합니다
건너뛰기 링크를 추가한 뒤 Tab 횟수가 줄었다는 숫자만 기록하지 않습니다. 첫 초점에서 발견되는지, 링크 문구가 목적지를 설명하는지, 식별자가 유일한지, 화면과 초점이 함께 이동하는지, 다음 조작이 본문 안에서 이어지는지 확인합니다. 랜드마크는 큰 기능 구역을 빠짐없이 나타내되 작은 카드까지 늘어나지 않는지 봅니다. 제목 계층과 문서 순서도 유지돼야 합니다. 어느 한 경로가 실패했을 때 다른 경로가 존재한다는 이유로 오류를 통과시키지 않습니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 2.4.1: Bypass Blocks · W3C Web Accessibility Initiative · HTML Sectioning Elements: ARIA Landmarks Example
- 반복 헤더보다 앞선 첫 Tab 위치에서 본문 바로가기를 발견할 수 있는가
- 링크의 href와 유일한 목적지 식별자가 모든 템플릿에서 일치하는가
- 실행 뒤 화면 위치와 키보드 초점이 같은 본문 시작점으로 이동하는가
- 고정 헤더·배너·확대 상태가 링크와 목적지 제목을 가리지 않는가
- 핵심 내용은 하나의 명확한 main으로 묶이고 복제된 main이 남지 않는가
- 여러 navigation과 complementary 영역의 이름이 목적에 따라 구분되는가
- 랜드마크 목록이 카드·소제목 단위로 과도하게 길어지지 않는가
- 제목 탐색과 랜드마크 탐색이 각각 내용 구조와 큰 기능 구역을 설명하는가
- 스크립트 실패·404·빈 결과·언어 전환에서도 목적지와 문서 구조가 유지되는가
공개 뒤 콘텐츠 편집자가 새 상단 배너, 긴 목차, 보조 패널을 추가하면 우회 경로를 다시 확인합니다. 개발자가 공통 헤더를 바꾸거나 식별자 생성 규칙을 수정했을 때도 전체 템플릿을 점검합니다. 자동 검사는 중복 식별자, main 개수, href 대상 존재 여부를 찾는 데 도움을 줄 수 있지만 초점 가시성, 고정 요소의 가림, 이름의 구체성, 다음 이동의 자연스러움은 사람의 키보드 검사가 필요합니다. 점검일을 자동 갱신하지 않고 실제 확인 범위를 남깁니다.
건너뛰기 링크와 랜드마크을 확인한 순서
- 예제 본문 바로가기를 키보드로 실행하고 실제 초점이 예제 본문에 도달하는지 확인합니다.
- 다음 Tab에서 자료 링크로 이어지는지 봅니다. 화면만 내려가고 반복 메뉴로 되돌아가면 이동 경로를 다시 확인합니다.
- 문서의 main은 하나로 유지합니다. 예제 section을 두 번째 main으로 바꾸지 않고 고정 헤더의 가림도 확인합니다.
건너뛰기 링크와 랜드마크 판단에서 제외한 범위
- 자체 긴 글은 문서 구조를 설명하기 위한 예제이며 실제 방문자 행동, 사이트 분석 또는 사용성 시험 자료가 아닙니다.
- 두 W3C 자료의 적용만으로 WCAG 전체 적합성이나 모든 브라우저·보조기술 조합의 작동을 보장하지 않습니다.
- 랜드마크로 노출되는 세부 방식은 요소의 문서 맥락과 사용자 환경에 따라 달라질 수 있어 실제 접근성 트리 확인이 필요합니다.
- 제시한 건너뛰기 목적지의 우선순위는 모든 사이트에 동일하지 않으며 콘텐츠와 사용자 과업에 맞게 조정해야 합니다.
- 키보드 경로가 짧아져도 실제 사용자의 이해, 탐색 속도, 성공률 또는 만족도 향상을 의미하지 않습니다.
건너뛰기 링크와 랜드마크에 사용한 원문
원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.
- Understanding Success Criterion 2.4.1: Bypass BlocksW3C Web Accessibility Initiative · 확인 2026-08-20
여러 페이지에서 반복되는 콘텐츠 블록을 우회하는 목적과 건너뛰기 메커니즘의 범위를 확인했습니다.
- HTML Sectioning Elements: ARIA Landmarks ExampleW3C Web Accessibility Initiative · 확인 2026-08-20
HTML 섹셔닝 요소가 정의하는 랜드마크와 페이지의 큰 기능 구역을 구분하는 예제를 확인했습니다.
건너뛰기 링크와 랜드마크 운영 점검 결과
공개 상태에서 재현할 수 있는 것만 남기기 위해 2026년 9월 23일 서버 응답과 문서 구조를 대조했습니다. 건너뛰기 링크의 도착 ID, 키보드 초점, main·nav·footer 랜드마크의 중복 여부를 함께 봅니다. 링크가 DOM에 있는 것을 실제 탐색 통과로 보지 않습니다.
| 확인 항목 | 2026.09.23 공개 응답 | 판단 범위 |
|---|---|---|
| 접속과 주소 | HTTP 200, H1 1개, canonical https://detailry.com/articles/web-skip-link-landmarks/ | 공개 URL과 대표 주소 일치만 확인 |
| 본문 구조 | 공백 제외 10,615자, H2 13개, 이미지 2개 | 길이가 아니라 주제별 판단 과정과 한계를 재검수 |
| 링크 경로 | 내부 7개, 외부 18개, w3.org | 출처 존재와 실제 접속 상태를 별도로 확인 |
이 기록은 해당 날짜의 공개 상태를 보여주며 사용자 성과, 고객 전환, 제품 성능을 증명하지 않습니다. 이후 본문·이미지·출처가 바뀌면 같은 URL을 다시 확인해야 합니다.
