WCAG 3.2.6: 일관된 도움

이 규칙의 의미

WCAG 성공 기준 3.2.6 일관된 도움말(Consistent Help) (레벨 AA, WCAG 2.2에서 도입)은 다음과 같이 규정한다. “웹 페이지에 다음과 같은 도움말 메커니즘 중 하나라도 포함되어 있고, 그 메커니즘이 여러 웹 페이지에서 반복되는 경우, 사용자가 변경을 시작하지 않는 한 다른 페이지 콘텐츠에 대한 동일한 상대적 순서로 나타나야 한다.” 이 기준에서 다루는 도움말 메커니즘은 다음과 같다. 사람의 연락처 정보(전화번호, 이메일 주소, 운영 시간 등), 사람과 연결되는 연락 메커니즘(라이브 채팅 위젯, 문의 양식 등), 셀프 헬프 옵션(FAQ 페이지, 도움말 센터, 지식 베이스 등), 그리고 완전 자동화된 연락 메커니즘(챗봇, 가상 비서 등).

핵심 요구 사항은 상대적 순서의 일관성이지, 픽셀 단위의 동일한 위치가 아니다. 예를 들어 라이브 채팅 버튼이 홈페이지의 오른쪽 하단에 나타난다면, 그 버튼이 표시되는 다른 모든 페이지에서도 동일한 오른쪽 하단 위치에 나타나야 한다. 어떤 페이지에서 상단 내비게이션 바의 세 번째 항목이 “Help” 링크라면, 그 내비게이션 바가 나타나는 다른 모든 페이지에서도 “Help” 링크는 세 번째 항목으로 남아 있어야 하며, 최소한 주변 콘텐츠와의 상대적 관계는 유지되어야 한다.

페이지가 이 기준을 준수하는 경우는 다음과 같다. (a) 사이트에 도움말 메커니즘이 전혀 없거나, (b) 도움말 메커니즘이 단 한 페이지에만 존재하거나, (c) 여러 페이지에 반복되는 도움말 메커니즘이 있을 때, 해당 메커니즘이 페이지 레이아웃 내에서 항상 동일한 상대적 순서로 나타나는 경우이다. 반대로, 도움말 메커니즘이 여러 페이지에 존재하면서 사용자가 변경을 시작하지 않았음에도 페이지마다 그 위치가 달라지는 경우 — 예를 들어 상품 목록 페이지에서는 오른쪽 하단에 떠 있는 채팅 위젯이 결제 페이지에서는 왼쪽 하단으로 이동하는 경우 — 해당 페이지는 실패하게 된다.

이 기준에는 명시적인 예외가 포함되어 있다. 사용자가 변경을 시작한 경우에는 순서가 바뀔 수 있다. 예를 들어 사용자가 떠 있는 도움말 위젯을 드래그해서 위치를 옮기거나, 사용자 설정을 통해 도움말 패널을 한쪽에서 다른 쪽으로 전환하는 경우, 이러한 재배치는 사용자에 의해 시작된 것이므로 실패로 간주되지 않는다. 이 예외는 SC 3.2.2(On Input)에 있는 사용자 주도 변경과 동일한 논리를 반영한다.

또한 이 기준은 모든 페이지에 도움말 메커니즘을 두도록 요구하지 않으며, 도움말 메커니즘이 반드시 효과적이거나 사용하기 쉬워야 한다고 요구하지도 않는다. 이 기준은 오직 도움말 메커니즘이 여러 페이지에 존재할 때 그 위치의 일관성만을 규율한다.

왜 중요한가

일관된 도움말 배치는 주로 인지 장애가 있는 사용자들을 위해 설계되었다. 여기에는 기억력 손상, 주의력 문제, 난독증과 같은 학습 장애, ADHD나 초기 치매와 같은 상태를 가진 사람들이 포함된다. 이 사용자들에게는 익숙한 인터페이스 요소를 찾는 것 자체가 상당한 인지적 노력을 요구한다. 도움말 버튼이나 연락 링크가 페이지마다 다른 위치에 나타나면, 그들은 매번 그 노력을 반복해야 하며, 이는 인지적 부담을 증가시키고 좌절감, 방향 감각 상실, 과업 포기 위험을 높인다.

웹에 익숙하지 않거나 디지털 리터러시가 낮은 사용자들 — 터키 및 전 세계에서 상당한 비중을 차지하는 인구 — 역시 예측 가능한 배치에 크게 의존한다. 세계보건기구(WHO)에 따르면 전 세계 13억 명 이상의 사람들이 어떤 형태로든 장애를 가지고 있으며, 이 중 인지 및 신경학적 상태가 상당한 비중을 차지한다. 따라서 위치 일관성을 고려한 설계는 임상적으로 진단된 장애가 있는 사람들뿐 아니라 훨씬 더 넓은 사용자층을 포괄적으로 지원한다.

구체적인 상황을 생각해 보자. 초기 알츠하이머병을 앓고 있는 한 사용자가 온라인으로 항공권 예약을 완료하려고 한다. 그녀는 혼란스러울 때 사용할 수 있는 라이브 채팅 옵션이 항공사 웹사이트에 있다는 것을 기억한다. 검색 결과 페이지에서는 채팅 아이콘이 오른쪽 하단에 나타난다. 그러나 좌석 선택 페이지로 이동하자 채팅 위젯이 상단 오른쪽의 접이식 도움말 서랍 안으로 옮겨져 있다. 그녀는 이를 찾지 못하고 압도감을 느끼며 결국 예약을 완전히 포기한다. 이는 SC 3.2.6의 직접적이고 예방 가능한 실패 사례이다.

운동 장애가 있는 사용자들이 스위치 액세스, 시선 추적 소프트웨어, 헤드 포인터 등으로 탐색하는 경우, 도움말 메커니즘의 위치가 바뀌면 화면의 새로운 영역을 다시 스캔하고 다시 조준해야 한다. 이는 많은 노력과 시간이 드는 과정이며, 일관된 배치를 통해 이러한 부담을 줄일 수 있다.

스크린 리더 사용자 중에는 도움말 섹션에 빠르게 도달하기 위해 사이트의 탭 순서나 헤딩 구조를 암기하는 사람들도 있다. 이 경우 시각적 위치가 비슷해 보이더라도, 페이지마다 해당 메커니즘의 DOM 순서가 바뀌면 동일하게 영향을 받는다.

접근성 측면을 넘어, 이는 명확한 사용성 및 비즈니스 이점도 제공한다. 사용자가 도움말을 빠르게 찾을 수 있으면 거래를 포기할 가능성이 줄어들어 이탈률과 지원 비용이 감소한다. 일관된 UI 패턴은 브랜드 신뢰와 전문성도 강화한다.

관련 Axe-core 규칙

WCAG 3.2.6은 수동 테스트만 필요한 기준으로 분류되며, 위반 사항을 자동으로 표시할 수 있는 대응되는 axe-core 자동 규칙이 없다. 이는 의도된 설계이며, 그 이유를 이해하면 테스터들이 이 기준의 성격을 더 잘 파악할 수 있다.

• 수동 검사가 필요함 — 사용 가능한 axe 규칙 없음: axe-core, Lighthouse, IBM Equal Access Checker와 같은 자동화 도구는 단일 페이지를 고립된 상태로 분석한다. 이들은 “도움말 메커니즘”이 무엇인지에 대한 고유한 이해가 없고, 요소의 상대적 DOM 위치를 여러 페이지 로드나 URL에 걸쳐 비교할 수 있는 능력도 없으며, 특정 요소가 실제로 도움을 제공하는 기능적 역할을 하는지 판단할 수 있는 방법도 없다. 예를 들어 채팅 위젯은 일반 <div>, shadow DOM 컴포넌트, <iframe>, 또는 서드파티에서 주입한 스크립트 등으로 구현될 수 있는데, 이들 중 어느 것도 사람의 판단 없이 규칙 엔진이 신뢰할 수 있게 “도움말 메커니즘”으로 식별하기 어렵다. axe-core가 이를 표시하려면 페이지 간 상태 인식과 의미적 의도 인식이 필요하지만, 이는 단일 페이지 정적 분석의 범위를 벗어난다. 이러한 이유로 WCAG 2.2 자체가 3.2.6을 구조화된 수동 감사와 페이지 간 비교를 통해 사람의 평가가 필요한 기준으로 분류하고 있다.

테스트 방법

1. 도움말 메커니즘 목록 작성: 개별 페이지를 테스트하기 전에, 사이트에 존재하는 모든 도움말 메커니즘 — 라이브 채팅 위젯, 연락처 전화번호, 이메일 링크, FAQ 링크, 챗봇 실행 버튼, 문의 양식, 도움말 센터 링크 등 — 을 목록으로 만든다. 각 메커니즘이 어떤 페이지에 나타나는지 기록한다. 특정 메커니즘이 한 페이지에만 나타난다면 이 기준의 범위에서 제외된다.
2. 기본 맥락을 위한 자동 스캔 실행: 대표 페이지에서 axe DevTools(브라우저 확장) 또는 Lighthouse를 사용해 DOM 순서 스냅샷을 캡처하고, 도움말 관련 요소의 구조적 위치를 파악한다. axe 규칙 중 SC 3.2.6을 직접 대상으로 하는 것은 없지만, 이 도구들이 보고하는 DOM 순서를 페이지 간에 수동으로 비교할 수 있다. 도움말 메커니즘이 포함된 각 페이지의 접근성 트리를 내보내거나 스크린샷으로 저장한다.
3. 페이지 간 상대적 위치 비교: 동일한 도움말 메커니즘을 공유하는 두 개 이상의 페이지를 나란히(또는 순차적으로) 연다. 각 메커니즘에 대해 주변 랜드마크 영역(<header>, <main>, <footer>, <nav>)과의 상대적 위치를 파악한다. 모든 페이지에서 해당 메커니즘이 동일한 랜드마크 영역에, 동일한 상대적 순서(인접 요소보다 앞/뒤)에 나타나는지 기록한다. 위치가 바뀌면 잠재적 실패로 간주한다.
4. 키보드 탐색으로 테스트(모든 브라우저): 도움말 메커니즘이 있는 각 페이지에서 탭 키로 페이지를 순차적으로 이동한다. 페이지 시작점에서 도움말 메커니즘에 도달하기까지 필요한 탭 횟수를 센다. 이 값을 페이지 간에 비교한다. 예를 들어, 홈페이지에서는 5번 탭으로 도달할 수 있지만 결제 페이지에서는 47번 탭이 필요하다면, 시각적 위치가 비슷해 보이더라도 DOM 순서가 바뀐 것이다.
5. NVDA + Firefox로 테스트: NVDA 요소 목록(NVDA 키 + F7)을 열고 링크 또는 버튼 보기로 전환한다. 목록에서 도움말 메커니즘을 찾고, 다른 요소들에 대한 상대적 위치를 기록한다. 이 메커니즘이 나타나는 각 페이지에서 동일한 과정을 반복하고 위치를 비교한다.
6. VoiceOver + Safari(macOS/iOS)로 테스트: VoiceOver 로터(VO + U)를 사용해 링크 또는 폼 컨트롤 목록을 연다. 도움말 메커니즘으로 이동해 목록 내 위치를 기록하고, 해당 메커니즘이 나타나는 각 페이지에서 이를 반복해 비교한다.
7. JAWS + Chrome으로 테스트: JAWS 링크 목록(Insert + F7)을 사용해 도움말 메커니즘을 찾는다. 그 순번과 인접 요소를 기록하고, 페이지마다 반복해 비교한다.
8. 사용자 주도 예외 확인: 사이트가 사용자가 도움말 메커니즘을 재배치하거나 숨길 수 있도록 허용하는 경우(예: 드래그 가능한 채팅 위젯), 재배치가 명시적인 사용자 행동에 의해 촉발되는지, 그리고 그 선호도가 논리적으로 유지되는지 확인한다. 이를 기준에 따른 유효한 예외로 문서화한다.
9. 모바일 뷰포트에서 검토: 반응형 레이아웃은 종종 다른 브레이크포인트에서 DOM 요소의 순서를 재배치한다. 데스크톱과 모바일 뷰포트(최소 375px 및 1440px 너비) 모두에서 테스트하여, 모든 일반적인 화면 크기에서 도움말 메커니즘이 일관된 상대적 위치를 유지하는지 확인한다.

수정 방법

떠 있는 채팅 위젯 — 잘못된 예

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

떠 있는 채팅 위젯 — 올바른 예

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

내비게이션의 도움말 링크 — 잘못된 예

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

내비게이션의 도움말 링크 — 올바른 예

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

조건부 도움말 표시 — 잘못된 예

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

조건부 도움말 표시 — 올바른 예

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

자주 발생하는 실수

• 페이지 템플릿마다 채팅 위젯을 다른 모서리에 배치하는 경우: 개발 팀이 채팅 위젯의 고정 위치를 전역 스타일시트가 아닌 템플릿별로 적용하는 경우가 많다. 이로 인해 마케팅 페이지에서는 오른쪽 하단, 앱 페이지에서는 왼쪽 하단에 위젯이 나타난다. 위치가 고정된 단일 전역 컴포넌트를 사용하라.
• 체크아웃 페이지에서 혼잡도를 줄이기 위해 내비게이션의 도움말 링크를 제거하는 경우: 일부 UX 패턴은 전환율 최적화를 위해 체크아웃 페이지에서 내비게이션을 의도적으로 최소화한다. 그러나 도움말 메커니즘이 그 내비게이션의 일부라면, 이 페이지 템플릿에서 제거하는 것은 일관성을 깨뜨린다. 대신, 체크아웃 흐름에서도 최소한의 헤더 안에 도움말 링크를 유지하라.
• DOM 위치가 예측 불가능하게 로드되는 서드파티 스크립트를 통해 도움말 메커니즘을 주입하는 경우: 많은 라이브 채팅 SDK는 위젯을 비동기적으로 DOM에 주입하며, 스크립트 로드 순서에 따라 삽입 지점이 달라질 수 있다. 이로 인해 페이지마다 접근성 트리에서 위젯의 위치가 달라질 수 있다. 서드파티 위젯이 항상 고정된, 알려진 DOM 앵커 요소에 추가되도록 구성하라.
• CSS order나 flexbox/grid 재정렬을 사용해 DOM 순서를 바꾸지 않고 시각적으로만 도움말 요소를 이동시키고, 이를 페이지마다 다르게 적용하는 경우: 시각적 위치는 일관되어 보일 수 있지만, 페이지별 CSS 오버라이드로 도움말 메커니즘의 시각적 순서를 변경하면 사용자에게 인지되는 순서가 바뀌며, DOM 순서를 따라 읽는 스크린 리더 사용자에게 혼란을 줄 수 있다.
• 도움말 요소의 위치를 테스트 변형 간에 바꾸는 A/B 테스트 도구에 의존하는 경우: 변형 A의 사용자는 상단 바에서 도움말 버튼을 보고, 변형 B의 사용자는 푸터에서 도움말 버튼을 보게 된다면, A/B 프레임워크가 페이지마다 다른 변형을 적용하는 동안 사용자들은 세션 내에서 페이지 간 도움말 위치의 불일치를 경험하게 된다. 도움말 메커니즘 배치에 영향을 주는 A/B 테스트는 세션 내 모든 페이지에서 변형이 일관되게 적용되도록 하라.
• 인증 상태(로그인/로그아웃)를 서로 다른 “사이트”로 간주하고 다른 도움말 레이아웃을 적용하는 경우: 사용자가 세션 중간에 로그인하면 도움말 메커니즘이 갑자기 새로운 위치에 나타날 수 있다. 인증 상태 변경은 도움말 배치의 관점에서 사용자 주도 변경이 아니므로 여전히 SC 3.2.6 실패에 해당한다. 모든 인증 상태에서 일관된 도움말 레이아웃을 적용하라.
• 일부 페이지에서는 도움말 전화번호를 푸터의 빽빽한 텍스트 안에만 넣고, 다른 페이지에서는 전용 헤더 바에 넣는 경우: 전화번호가 모든 페이지에 기술적으로 존재하더라도, 헤더의 첫 번째 인터랙티브 요소에서 수백 개의 링크 뒤에 있는 푸터로 위치가 크게 바뀐다면, 이는 일관된 순서 기준의 실패이다.
• 도움말 아이콘이 항상 시각적으로 “모서리에” 있기만 하면 기준을 충족한다고 가정하는 경우: 이 기준은 절대적인 픽셀 좌표가 아니라 페이지 콘텐츠 내의 상대적 순서를 측정한다. 채팅 아이콘이 항상 시각적으로 오른쪽 하단에 있더라도, 어떤 페이지에서는 <body> 태그 바로 뒤에, 다른 페이지에서는 </body> 바로 앞에 위치하는 등 DOM 순서가 크게 다르다면, 키보드 및 스크린 리더 사용자에게는 여전히 실패가 될 수 있다.
• 반응형 브레이크포인트 감사를 잊는 경우: 데스크톱 너비에서 일관된 도움말 메커니즘이 좁은 뷰포트에서는 숨겨지거나 모바일 햄버거 메뉴 안으로 이동해 모바일에서 다른 위치를 갖게 될 수 있다. 모바일 사용자가 데스크톱 사용자와 다른 상대적 위치를 경험한다면, 특히 모바일이 주요 접속 수단인 대상 사용자층이라면 이 기준에 비추어 평가해야 한다.
• 디자인 시스템에 도움말 메커니즘 위치를 문서화하지 않는 경우: 도움말 메커니즘이 어디에 나타나야 하는지에 대한 문서화된 표준이 없으면, 개별 개발자와 디자이너가 독립적으로 결정을 내리게 되고 시간이 지남에 따라 불일치가 발생한다. 도움말 메커니즘 배치 규칙을 디자인 시스템이나 컴포넌트 라이브러리 문서에 명시적으로 추가하라.

터키 접근성 규정과의 관계

터키의 Cumhurbaşkanlığı Genelgesi 2025/10(대통령령 2025/10)은 2025년 6월 21일자, 번호 32933의 Resmî Gazete(공보)에 게재되었으며, 디지털 접근성에 대한 포괄적인 국가 프레임워크를 수립한다. 이 일반지침은 터키에서 운영되는 광범위한 디지털 서비스에 대해 WCAG 2.2 레벨 AA 준수를 기본 접근성 표준으로 의무화한다. WCAG 2.2에서 레벨 AA 기준으로 도입된 WCAG 3.2.6 일관된 도움말(Consistent Help)은 이 법적 의무의 범위에 직접 포함된다.

Genelge 2025/10의 적용 대상에는 다음과 같은 기관 유형이 포함된다. 중앙 및 지방 정부 수준의 공공 기관 및 조직, Bankacılık Düzenleme ve Denetleme Kurumu(BDDK, 은행 규제 및 감독 기관)의 규제를 받는 은행 및 금융 서비스 제공자, 전자상거래 플랫폼 및 온라인 마켓플레이스, 환자 대상 디지털 서비스를 제공하는 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 온라인 예약 시스템을 운영하는 여행사, 정기 운행 서비스를 제공하는 민간 운송 회사, Milli Eğitim Bakanlığı(MoNE, 교육부)의 인가를 받은 사립 학교 및 교육 기관 등이 있다. 이 모든 기관에 대해 WCAG 2.2 레벨 AA 기준 전체 — SC 3.2.6을 포함해 — 가 적용 표준이다.

WCAG 3.2.6 준수는 Aile ve Sosyal Hizmetler Bakanlığı(가족·사회서비스부)가 발급하는 Erişilebilirlik Logosu(접근성 로고)를 획득하기 위한 전제 조건이기도 하다. 이 로고는 접근성 준수의 공식 표시로, 터키 소비자와 조달 담당자들 사이에서 점점 더 품질 신호로 인식되고 있다. 이 로고를 얻고자 하는 조직은 디지털 자산 전반에 걸쳐 WCAG 2.2 레벨 AA를 완전히 준수해야 하며, 이때 도움말 배치의 사소해 보이는 불일치조차도 신청 자격을 박탈할 수 있다.

실질적인 준수 관점에서 SC 3.2.6은 특히 터키의 전자상거래 및 금융 서비스 제공자와 밀접한 관련이 있다. 이들의 웹사이트와 모바일 웹 앱은 일반적으로 라이브 채팅 위젯, WhatsApp 연락 링크, FAQ 섹션 등을 주요 고객 지원 채널로 제공한다. 이러한 도움말 메커니즘이 상품 목록 페이지, 장바구니 페이지, 결제 흐름, 계정 관리 섹션 전반에 걸쳐 일관된 위치에 나타나도록 보장하는 것은, Genelge에 따른 법적 의무이자 터키의 다양한 인터넷 사용자층 — 특히 예측 가능한 인터페이스 패턴에서 가장 큰 혜택을 받는 초보 및 저문해 디지털 사용자 — 을 위한 건전한 UX 관행이다.

Genelge의 적용 대상 조직 중 아직 도움말 메커니즘 배치를 감사하지 않은 곳은 WCAG 2.2 준수 로드맵의 일부로 페이지 간 일관성 감사를 우선순위에 두어야 한다. 이 기준은 수동 테스트가 필요하므로, 초기 준수 감사뿐 아니라 주요 리디자인이나 템플릿 변경 이후에 도움말 요소의 위치가 의도치 않게 바뀌었을 수 있는 경우를 대비해, 지속적인 품질 보증 사이클에도 포함되어야 한다.