WCAG 3.2.3: 일관된 탐색

WCAG 3.2.3은(는) 웹 페이지 집합 내의 여러 페이지에 나타나는 탐색 메커니즘이, 사용자가 변경을 시작하지 않는 한, 매번 동일한 상대적 순서로 제공되도록 요구합니다. 이러한 예측 가능성은 인지, 시각, 운동 장애가 있는 사용자가 사이트의 정신적 모델을 구축하고 효율적으로 탐색하는 데 도움이 됩니다.

이 규칙의 의미

WCAG 성공 기준 3.2.3 — 일관된 탐색(레벨 AA)은, 웹사이트의 여러 페이지에 반복해서 나타나는 탐색 구성 요소는 사용자가 그 순서의 변경을 직접 유발한 경우를 제외하고, 매번 마주칠 때마다 동일한 상대적 순서로 나타나야 한다고 규정한다. 이 기준은 공통된 목적을 공유하거나 동일한 사이트 또는 애플리케이션의 일부인 모든 웹 페이지 집합에 적용된다.

"동일한 상대적 순서"라는 표현이 중요하다. WCAG는 탐색에 항상 동일한 개수의 항목이 포함되어야 한다거나, 탐색 항목 사이에 다른 요소가 끼어들 수 없다고 요구하지 않는다. 요구하는 것은, 사용자가 인터페이스를 이동하면서 보게 되는 탐색 링크의 순서가 페이지마다 일관되게 유지되는 것이다. 예를 들어, 기본 탐색이 홈페이지에서 "Home", "Products", "About", "Contact" 순서로 나열되어 있다면, 그 탐색 블록이 존재하는 다른 모든 페이지에서도 동일한 항목이 동일한 순서로 나타나야 한다.

이 기준은 반복되는 모든 탐색 메커니즘을 포괄한다. 기본 사이트 탐색 메뉴, 브레드크럼(breadcrumb) 경로, 푸터 링크 그룹, 사이드바 메뉴, 탐색 건너뛰기 링크, 검색창, 그리고 사용자가 사이트를 이동하는 데 도움을 주는 기타 모든 인터랙티브 구성 요소가 포함된다. 이러한 구성 요소가 <nav> 랜드마크, <ul> 링크 목록, ARIA로 확장된 커스텀 메뉴, 또는 다른 어떤 마크업 패턴으로 구현되었는지와는 무관하게 적용된다.

충족으로 인정되는 경우: 탐색 블록이 반복되는 모든 페이지에서 동일한 상대적 순서로 나타난다. 항목을 추가하거나, 강조 표시하거나, 활성 상태로 표시(예: 현재 페이지 링크를 시각적으로 구분)할 수는 있지만, 전체적인 순서는 바뀌지 않아야 한다. 사용자가 직접 재정렬을 수행한 경우 — 예를 들어 사용자가 대시보드 패널을 드래그해 위치를 바꾸는 커스터마이즈 가능한 대시보드 — 역시 충족으로 본다. 변경이 사용자로부터 시작되었기 때문이다.

실패로 인정되는 경우: 메인 탐색이 홈페이지에서는 "Home → Products → Contact → About" 순서로 나열되지만, 제품 상세 페이지에서는 "Home → About → Products → Contact" 순서로 나열되는 경우 3.2.3을 충족하지 못한다. 마찬가지로, 사이트가 내부 로직에 따라(사용자 행동 없이) 탐색에 추가 링크를 임의의 위치에 조건부로 삽입하는 경우도 실패에 해당한다.

공식 예외: 명세는 사용자가 순서 변경을 시작한 경우에는 이 요구 사항이 적용되지 않는다고 명시적으로 밝히고 있다. 이것이 유일한 규범적 예외이다. 시스템, 서버 로직, 개인화 알고리즘에 의해 구동되는 변경 — 즉, 사용자가 직접 트리거하지 않은 변경 — 은 이 예외에 해당하지 않는다.

왜 중요한가

일관된 탐색은 인지적 접근성의 기초이다. 공간 기억과 예측 가능한 패턴에 의존해 방향을 잡는 사용자 — 인지 장애, 주의력 장애, 외상성 뇌 손상, 또는 노화 관련 인지 저하가 있는 사람들을 포함 — 는 사이트의 탐색이 매번 동일한 위치와 순서에 있을 것이라는 가정에 크게 의존한다. 탐색이 예기치 않게 바뀌면, 이 사용자는 페이지마다 레이아웃을 다시 학습해야 하며, 이는 인지적 부담과 오류 또는 이탈 가능성을 크게 높인다.

스크린 리더(NVDA, JAWS, VoiceOver)를 사용하는 시각장애 및 저시력 사용자에게 일관된 탐색은 익숙한 랜드마크를 찾는 데 소요되는 시간을 줄여준다. 예를 들어 스크린 리더 사용자가 메인 탐색에서 "Contact" 링크가 네 번째 항목이라는 것을 기억하고 있다면, 어떤 페이지에서든 Tab 키를 네 번 눌러 그 링크에 도달할 수 있다 — 단, 순서가 항상 동일하게 유지된다는 전제가 있을 때만 가능하다. 순서가 일관되지 않으면 이러한 효율성이 사라지고, 사용자는 페이지가 로드될 때마다 전체 탐색을 처음부터 끝까지 들어야 한다.

키보드만으로 탐색하거나 스위치 액세스, 시선 추적에 의존하는 운동 장애 사용자에게는, 키를 한 번 더 누르거나 머리를 한 번 더 움직이는 것에도 실제적인 비용이 따른다. 예측 가능한 탐색은 자주 방문하는 목적지에 도달하기 위해 필요한 상호작용 횟수를 줄여준다. 세계보건기구(WHO)에 따르면 전 세계 13억 명 이상이 어떤 형태로든 장애를 가지고 있으며, 이들 중 상당수는 일관되고 예측 가능한 인터페이스로부터 직접적인 혜택을 받는 보조 기술에 의존한다.

난독증 등 읽기 장애가 있는 사용자에게는 탐색 바를 훑어보는 것 자체가 이미 많은 노력이 든다. 위치, 형태, 색상과 같은 시각적 기준점을 반복적으로 신뢰할 수 있도록 탐색의 위치와 순서가 일관되면, 매번 레이블을 다시 읽지 않고도 이용할 수 있다.

구체적인 실제 시나리오를 생각해 보자. 한 환자가 병원 웹사이트를 사용해 추적 진료 예약을 잡으려 한다. 홈페이지의 탐색에는 "Services", "Appointments", "Doctors", "Contact"가 그 순서로 나열되어 있다. 환자는 의사 프로필 페이지로 이동한 뒤, 두 번째 위치에서 "Appointments"를 찾는다 — 그러나 그 페이지에서는 탐색이 "Doctors"를 먼저, 그 다음에 "Appointments"가 오도록 재구성되어 있다. 이미 스트레스를 받고 있는 환자는 전체 메뉴를 다시 훑어봐야 한다. 인지 장애나 문해력이 제한된 사용자에게는 이러한 마찰이 과제를 완료하느냐, 아예 포기하느냐를 가르는 차이가 될 수 있다.

접근성을 넘어, 일관된 탐색은 측정 가능한 SEO 및 사용성 이점도 제공한다. 검색 엔진 크롤러는 탐색 링크를 따라가며 콘텐츠를 발견하고 색인화하는데, 안정적인 링크 구조는 크롤 효율성과 내부 링크 자산을 향상시킨다. 사용성 테스트는 일관된 탐색이 장애가 있는 사용자뿐 아니라 모든 사용자의 과제 완료 시간과 오류율을 줄인다는 사실을 일관되게 보여준다.

테스트 방법

기본 컨텍스트를 위한 자동 스캔 실행: 대표 페이지에서 axe DevTools, Lighthouse 또는 브라우저 확장 프로그램을 사용해 탐색 요소가 <nav> 랜드마크나 role='navigation'으로 올바르게 마크업되어 있는지 확인한다. 이 도구들은 순서 불일치를 표시하지는 않지만, 페이지 간에 무엇이 탐색으로 취급되는지 파악하는 데 도움이 된다. 수동 검사를 진행하기 전에 랜드마크 구조와 관련된 문제를 문서화한다.
대표 페이지 샘플 선택: 사이트의 서로 다른 섹션에서 최소 5~10개의 페이지를 선택한다 — 홈페이지, 카테고리 페이지, 제품 또는 기사 상세 페이지, 폼 페이지, 연락처 페이지 등. 사이트에 수천 개의 페이지가 있다면, 모든 주요 템플릿을 포괄하는 층화 샘플을 사용한다. 각 페이지의 URL과 페이지 유형을 기록한다.
탐색 순서를 수동으로 매핑: 샘플링한 각 페이지에서 브라우저의 접근성 트리를 연다(Chrome DevTools → Accessibility 패널 또는 Firefox Accessibility Inspector) 그리고 DOM에 나타나는 순서대로 기본 탐색 내의 모든 링크를 나열한다. 또한 시각적으로 보이는 순서도 기록한다. CSS가 flex-direction: row-reverse나 order 속성 등을 사용해 항목을 시각적으로 재배치하는 경우, 시각적 순서가 DOM 순서와 다를 수 있는데 — 둘 다 일관되어야 한다.
페이지 간 비교: 기록한 탐색 순서 목록을 나란히 놓고 비교한다. 홈페이지에서 확립한 기준과 비교했을 때, 공유된 탐색 항목의 시퀀스가 다른 페이지를 표시한다. 어떤 항목이 어느 방향으로 이동했는지 기록한다.
키보드 탐색 테스트(NVDA + Firefox): NVDA를 실행하고 Firefox를 연 뒤, 홈페이지로 이동한다. D 키를 눌러 다음 랜드마크 영역으로 이동하면서 메인 탐색을 찾는다. Tab 키를 사용해 탐색 링크를 이동하며 순서를 소리 내어 말하거나 기록한다. 그런 다음 두 번째 페이지(예: 내부 기사 페이지)로 이동해 동일한 과정을 반복한다. 링크가 읽어지는 순서에 변화가 있는지 듣고 확인한다.
스크린 리더 테스트(VoiceOver + macOS의 Safari): VoiceOver(Command + F5)를 활성화하고 Safari를 연 뒤, Web Rotor(Control + Option + U)를 사용해 Links 또는 Landmarks 메뉴를 연다. 메인 탐색으로 이동해 항목의 순서를 기록한다. 서로 다른 최소 세 가지 페이지 유형에서 반복하고 비교한다.
JAWS + Chrome 테스트: JAWS를 실행하고 Chrome을 연 뒤, R 키를 눌러 영역을 순환하며 메인 탐색에 도달한다. Tab 키로 링크를 이동하며 순서를 기록한다. 여러 페이지 유형에서 반복한다.
사용자 주도 예외 확인: 사이트에 개인화 또는 탐색 커스터마이즈 기능이 있다면, 재정렬이 명시적인 사용자 행동(예: 사용자가 "Customize Menu"를 클릭하고 항목을 드래그하는 경우) 이후에만 발생하는지 확인한다. 사용자가 설정한 재정렬 상태가 이후에도 일관되게 유지되는지 — 즉, 사용자가 설정한 새로운 순서 자체가 모든 페이지에서 일관되게 유지되는지도 확인한다.

해결 방법

서버 사이드 렌더링 불일치 — 잘못된 예

<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/products'>Products</a></li>
  </ul>
</nav>

서버 사이드 렌더링 불일치 — 올바른 예

<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/' aria-current='page'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->

CSS 시각적 재정렬로 인한 불일치 — 잘못된 예

<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
  /* Applied only on interior page templates */
  nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->

CSS 시각적 재정렬로 인한 불일치 — 올바른 예

<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->

알고리즘에 의해 동적으로 재정렬되는 탐색 — 잘못된 예

<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
  // Anti-pattern: fetches user behaviour data and reorders nav items automatically
  fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
    const nav = document.querySelector('nav ul');
    order.forEach(id => nav.appendChild(document.getElementById(id)));
  });
</script>
<nav aria-label='Main navigation'>
  <ul>
    <li id='nav-home'><a href='/'>Home</a></li>
    <li id='nav-products'><a href='/products'>Products</a></li>
    <li id='nav-about'><a href='/about'>About</a></li>
    <li id='nav-contact'><a href='/contact'>Contact</a></li>
  </ul>
</nav>

알고리즘에 의해 동적으로 재정렬되는 탐색 — 올바른 예

<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->

자주 발생하는 실수

각각 독립적으로 탐색을 정의하는 서로 다른 CMS 템플릿을 사용하는 것. 이렇게 하면 템플릿이 단일 공유 컴포넌트나 파셜이 아니라 개별적으로 업데이트되는 과정에서, 시간이 지남에 따라 미묘한 순서 차이가 스며들 수 있다.
마케팅 캠페인을 이유로 "추천" 또는 "시즌성" 탐색 항목을 다른 위치로 승격시키는 것. 이때 나머지 탐색 순서가 변경되지 않도록 보장하지 않으면, 예를 들어 일부 페이지에서는 "Sale"을 두 번째 위치로, 다른 페이지에서는 다섯 번째 위치로 임시 이동시키는 식으로 일관성이 깨질 수 있다.
CSS의 order, flex-direction: row-reverse, CSS Grid 배치를 사용해 탐색 항목을 시각적으로 재정렬하는 것. 페이지 템플릿마다 다르게 적용하면, 시각적 순서(시력이 있는 사용자가 보는 순서)와 DOM 순서(키보드 및 스크린 리더 사용자가 따르는 순서) 사이에 불일치가 생긴다.
문맥에 따라 달라지는 탐색 항목을 임의의 위치에 삽입하는 것. 예를 들어, 제품 페이지에서만 두 번째 항목으로 "Back to Category" 링크를 추가해 이후 모든 항목을 한 칸씩 뒤로 밀어, 기대되는 시퀀스를 깨뜨리는 경우가 이에 해당한다.
A/B 테스트나 분석 플랫폼이 실험 변형의 일환으로 탐색 링크를 재정렬하도록 허용하는 것. 이때 재정렬이 페이지와 세션 전반에 걸쳐 일관되지 않게 적용된다는 점을 고려하지 않는 경우가 많다.
브레드크럼 경로를 이 기준에서 예외로 취급하는 것. 실제로 브레드크럼은 반복되는 탐색 메커니즘이며, 다른 페이지 요소에 비해 서로 다른 위치에 나타나는 브레드크럼은 3.2.3을 위반한다.
푸터 탐색을 메인 탐색과 다르게 재정렬하는 것. 푸터 링크가 메인 탐색을 복제하는 경우, 둘 다 모든 페이지에서 나타난다면 각각 독립적으로, 그리고 서로의 관계에서도 일관된 순서를 유지해야 한다.
스크롤 위치, 뷰포트 크기, 세션 데이터에 따라 항목을 재정렬하는 JavaScript 기반 탐색 향상을 적용하는 것. 예를 들어, 사용자가 어느 섹션에 있는지에 따라 서로 다른 최상위 카테고리를 동적으로 노출하는 메가 메뉴가 이에 해당하며, 사용자 주도 없이 재정렬이 이루어지는 경우 문제가 된다.
사이트 리디자인이나 CMS 마이그레이션 이후 탐색 일관성을 감사하지 않는 것. 개발자가 원래 순서를 자연스럽게 재현할 것이라고 가정하지만, 실제로는 서로 다른 페이지 유형을 서로 다른 팀원이 처음부터 다시 구축하는 과정에서 순서가 달라지는 경우가 많다.
"일관된 탐색"을 "모든 페이지에서 동일한 탐색"으로 혼동하는 것. 일부 팀은 특정 사용자 역할(예: 로그인 사용자 vs. 비로그인 사용자)에 따라 탐색 항목을 추가하거나 제거하는 것이 3.2.3을 위반한다고 잘못 결론 내리기도 한다. 공유된 항목의 상대적 순서가 변하지 않는 한, 이는 위반이 아니다.

터키 접근성 규정과의 관계

터키의 2025/10번 대통령령은 2025년 6월 21일 관보(번호 32933)에 게재되었으며, 터키에서 디지털 서비스를 운영하는 광범위한 공공 및 민간 기관에 구속력 있는 접근성 의무를 부과한다. 이 대통령령은 국제적으로 인정된 접근성 표준 준수를 의무화하며 — WCAG 2.2 레벨 AA를 주요 기술 기준으로 삼고 — 준수 여부를 Erişilebilirlik Logosu(접근성 로고)와 연계한다. 이 로고는 요구되는 접근성 기준을 충족한 기관에 대해 가족·사회서비스부가 부여하는 인증 마크이다.

WCAG 3.2.3 일관된 탐색은 레벨 AA 기준으로, Erişilebilirlik Logosu를 취득하려는 기관에 의무적인 요구 사항이다. 디지털 서비스 전반에서 일관된 탐색을 제공하지 못하는 조직은 다른 기준에서의 성과와 관계없이, 인증에 필요한 전체 AA 적합 프로파일을 충족하지 못한다.

다음 유형의 기관은 2025/10번 대통령령의 적용 대상이며, 따라서 3.2.3 준수를 모범 사례 권고가 아닌 법적 의무로 취급해야 한다.

모든 수준의 공공 기관 및 정부 기관. 부처, 지방자치단체, 공공기관 등은 웹사이트와 디지털 포털 전반에서 모든 섹션에 걸쳐 일관된 탐색을 제공해야 한다.
터키에서 운영되는 전자상거래 플랫폼. 사용자가 홈페이지, 카테고리, 제품, 장바구니, 결제 페이지 등 — 일반적으로 동일한 탐색 바를 공유하는 — 여러 페이지를 오가므로, 탐색 일관성이 특히 중요하다.
터키 은행법의 규제를 받는 은행 및 금융 기관. 온라인 뱅킹 포털과 정보 제공 웹사이트는 인지 또는 운동 장애가 있는 고객을 포함한 모든 고객에게 예측 가능한 탐색을 제공해야 한다.
병원 및 의료 서비스 제공자. 환자는 종종 스트레스 상황에서, 예약, 검사 결과, 응급 연락처 정보를 인지적 마찰 없이 찾기 위해 일관된 탐색에 의존한다.
20만 명 이상의 가입자를 보유한 통신사. 고객 포털, 지원 사이트, 계정 관리 인터페이스는 수천 개의 페이지와 사용자 대상 템플릿 전반에 걸쳐 탐색 일관성을 유지해야 한다.
여행사 및 민간 운송 회사. 검색, 선택, 승객 정보, 결제 페이지에 이르는 다단계 예약 흐름 전반에서 탐색이 일관된 순서로 제시되어야 한다.
국가교육부(MoNE)의 인가를 받은 사립학교. 이들 웹사이트는 학생, 학부모, 교직원을 대상으로 하며, 학습 장애가 있어 예측 가능한 탐색에 크게 의존해 교육 자료에 접근하는 사람들도 포함된다.

터키에서 디지털 서비스를 구축하거나 감사를 수행하는 조직은 템플릿 및 컴포넌트 설계 단계에서부터 3.2.3을 품질 보증 프로세스에 포함해야 한다. 서버 사이드 인클루드, 프런트엔드 프레임워크 컴포넌트, 헤드리스 CMS의 글로벌 요소 등 단일 소스에서 렌더링되는 공유 탐색 컴포넌트를 사용하는 것이, 기술적으로 가장 신뢰할 수 있는 접근 방식이자 대통령령 요구 사항 하에서 가장 방어 가능한 준수 태도이다. Erişilebilirlik Logosu 신청 과정의 일환으로 제출되는 접근성 감사에는, 문서화된 테스트 단계로서 페이지 간 탐색 순서 검증이 포함되어야 한다.