WCAG 2.4.11: 포커스 비가림 (최소)

WCAG 2.4.11은 UI 구성 요소가 키보드 포커스를 받을 때, 고정 헤더, 쿠키 배너, 채팅 위젯과 같은 제작자가 만든 콘텐츠에 의해 완전히 가려지지 않아야 한다고 요구합니다. 이 기준은 키보드 사용자가 페이지에서 자신이 어디에 있는지 항상 볼 수 있도록 보장하며, 이는 탐색과 사용성에 필수적입니다.

이 규칙의 의미

WCAG 2.4.11 Focus Not Obscured (Minimum)은 WCAG 2.2에서 도입된 레벨 AA 기준으로, 매우 흔하지만 심각한 접근성 문제를 다룹니다. 바로 포커스를 받은 요소가 페이지의 다른 콘텐츠 레이어 뒤에 완전히 가려지는 경우입니다. 이 기준은 어떤 사용자 인터페이스 구성 요소가 키보드 포커스를 받을 때, 그 구성 요소가 제작자가 만든 콘텐츠에 의해 완전히 가려져서는 안 된다고 규정합니다.

여기서 핵심 단어는 완전히(entirely)입니다. WCAG 2.4.11은 최소 기준을 설정합니다 — 포커스를 받은 요소의 일부라도 보이기만 하면 됩니다. 예를 들어, 스티키 내비게이션 바가 포커스된 버튼의 상단 절반을 가리더라도 하단 절반이 여전히 보인다면, 기술적으로는 2.4.11을 충족합니다. 더 엄격한 동반 기준인 WCAG 2.4.12 Focus Not Obscured (Enhanced) (레벨 AAA)는 한 단계 더 나아가, 포커스된 구성 요소가 제작자가 만든 콘텐츠에 의해 전혀 — 부분적으로도 — 가려지지 않도록 요구합니다.

이 문제를 가장 자주 유발하는 제작자 생성 콘텐츠 유형에는 스티키 또는 고정 위치 헤더와 푸터, 쿠키 동의 배너, 채팅 지원 위젯, 알림 토스트, 모달 오버레이, 플로팅 액션 버튼, 모바일 반응형 레이아웃의 하단 내비게이션 바 등이 있습니다. 이러한 요소는 position: fixed, position: sticky 또는 높은 z-index 값과 같은 CSS 속성을 사용해 렌더링되며, 이로 인해 일반 문서 흐름 위에 떠 있게 되고 포커스를 받는 인터랙티브 요소를 덮어버릴 수 있습니다.

통과란 키보드 사용자가 인터랙티브 요소를 탭으로 이동할 때, 스티키 UI 요소가 일부를 겹쳐 가리더라도 포커스된 각 요소의 시각적 표시 일부가 항상 화면에 보이는 상태를 의미합니다. 실패는 포커스된 요소가 제작자가 만든 레이어 아래에 완전히 숨겨져 사용자가 현재 포커스 위치에 대한 시각적 단서를 전혀 얻지 못하는 경우입니다. 브라우저 자체의 툴바와 같은 브라우저 렌더링 콘텐츠는 제작자 생성 콘텐츠로 간주되지 않으므로 이 기준의 범위에서 제외됩니다. 마찬가지로, 사용자가 직접 위치를 옮긴 콘텐츠(예: 사용자가 드래그할 수 있는 패널)도 제외됩니다.

이 기준은 기본적으로 키보드 포커스를 받을 수 있거나 tabindex를 통해 포커스를 받을 수 있게 만든 모든 인터랙티브 HTML 요소에 적용됩니다. 여기에는 <a>, <button>, <input>, <select>, <textarea> 및 tabindex='0' 또는 양수 tabindex 값을 가진 요소가 포함됩니다.

왜 중요한가

키보드 내비게이션은 여러 사용자 그룹에게 접근성의 근간입니다. 마우스를 사용할 수 없는 운동 장애가 있는 사람들은 키보드, 스위치 장치, sip-and-puff 컨트롤러에 전적으로 의존해 웹 페이지를 이동합니다. 시각장애인은 스크린 리더와 키보드를 함께 사용합니다. 스크린 리더 없이 키보드 내비게이션을 사용하는 저시력 사용자는 자신이 어디에 있는지 이해하기 위해 시각적 포커스 표시기에 크게 의존합니다. 포커스된 요소가 스티키 헤더나 플로팅 위젯 뒤에 숨겨지면, 이 사용자들은 사실상 길을 잃게 됩니다 — Tab 키를 계속 눌러 추측하거나, 자신의 위치를 짐작하거나, 아예 작업을 포기해야 할 수도 있습니다.

구체적인 실제 상황을 생각해 봅시다. 손 움직임이 제한된 휠체어 사용자가 한 터키 항공사의 웹사이트에서 항공권 예약 양식을 작성하고 있습니다. 이 사용자는 Tab 키로 폼 필드를 이동합니다. 페이지 하단 뷰포트에는 스티키 쿠키 동의 배너가 있습니다. 사용자가 마지막 확인 체크박스로 탭 이동하면, 그 체크박스는 쿠키 배너 아래에 완전히 렌더링됩니다. 사용자는 체크박스에 포커스가 갔다는 시각적 표시를 전혀 볼 수 없습니다. Tab 키 입력이 제대로 작동했는지, Tab을 한 번 더 눌러야 하는지, 아니면 체크박스가 필수인지조차 알 수 없습니다. 이런 혼란은 폼 포기, 제출 누락, 의도치 않은 동작을 유발하는 반복 키 입력으로 이어질 수 있습니다.

이 영향은 장애가 있는 사용자에만 국한되지 않습니다. 속도를 위해 키보드 내비게이션을 선호하는 파워 유저 — 개발자, 데이터 입력 담당자, 숙련된 사용자 — 역시 명확한 포커스 가시성의 혜택을 봅니다. 세계보건기구(WHO)에 따르면 전 세계 약 13억 명이 어떤 형태로든 장애를 가지고 있으며, 그 중 상당수가 보조 기술이나 키보드 내비게이션에 의존합니다. 특히 터키에서는 터키 통계청(TÜİK)이 인구의 약 12.7%가 어떤 형태로든 장애를 가지고 있다고 보고하며, 이는 디지털 플랫폼에서 개선된 포커스 관리의 직접적인 혜택을 받을 수 있는 약 1,000만 명에 해당합니다.

비즈니스 관점에서 보면, 가려진 포커스 표시기는 작업 포기율을 높이고 전환율을 떨어뜨리며, 조직을 법적·규제적 위험에 노출시킵니다. 이 기준을 충족하지 못하는 사이트는 터키 법률에 따라 요구되는 접근성 감사에서도 실패할 가능성이 높으며, 공식 Erişilebilirlik Logosu(접근성 로고)를 취득하거나 유지할 수 있는 능력을 위태롭게 합니다.

테스트 방법

먼저 자동 접근성 스캔을 실행합니다. axe DevTools(브라우저 확장), Chrome DevTools의 Lighthouse, 또는 CI에 통합된 axe-core 스캔을 사용해 페이지에서 자동으로 감지 가능한 문제를 식별합니다. 2.4.11 자체는 수동 검증이 필요하지만, 자동 스캔을 통해 포커스 표시기 누락(2.4.7)이나 겹치는 요소를 시사하는 잘못된 z-index 스태킹과 같은 관련 문제를 발견할 수 있습니다. 수동 테스트를 시작하기 전에 잠재적으로 문제가 있다고 표시된 모든 요소를 기록해 둡니다.
페이지의 모든 fixed 및 sticky 요소를 식별합니다. 브라우저 DevTools를 열고 페이지의 CSS를 검사합니다. position: fixed 또는 position: sticky를 사용하는 요소를 검색합니다. 또한 높은 z-index 값(예: 100 이상)을 가진 요소도 확인합니다. 헤더, 푸터, 배너, 채팅 위젯, 쿠키 알림 등 이러한 요소를 모두 문서화합니다. 이들이 포커스된 구성 요소를 가릴 가능성이 가장 높기 때문입니다. 브라우저 창 크기를 조정해 태블릿 및 모바일 폭을 포함한 다양한 뷰포트 크기를 시뮬레이션합니다. 스티키/고정 요소는 브레이크포인트에 따라 동작이 달라지는 경우가 많습니다.
전체 키보드 탭 순회를 수행합니다. 포커스가 페이지 상단에서 시작되도록 인터랙티브 요소 밖을 클릭한 뒤, Tab 키를 반복해서 눌러 모든 포커스 가능한 요소를 순회합니다. 각 요소가 포커스를 받을 때를 주의 깊게 관찰합니다. 고정 헤더나 푸터가 겹칠 가능성이 가장 높은 뷰포트 상단 또는 하단 근처의 요소에 특히 주의를 기울입니다. 어느 시점에서든 보이는 포커스 링이나 강조된 요소가 고정 레이어 뒤로 완전히 사라지면, 이는 2.4.11 실패입니다. Shift+Tab을 사용해 역방향으로도 순회합니다. 스크롤 위치와 레이아웃이 달라질 수 있기 때문입니다.
NVDA와 Firefox로 테스트합니다. NVDA(무료 오픈소스 Windows용 스크린 리더)를 실행하고 Firefox를 엽니다. NVDA의 브라우즈 모드를 활성화하고 Tab으로 페이지를 이동합니다. NVDA가 각 포커스 요소를 음성으로 알려주지만, 동시에 화면도 시각적으로 관찰합니다. NVDA가 포커스를 알리지만 가리는 콘텐츠 때문에 시각적 포커스 표시가 보이지 않는 요소를 기록합니다. 이 조합은 터키와 전 세계에서 널리 사용되며, 핵심 보조 기술 페어링을 대표합니다.
macOS/iOS에서 VoiceOver와 Safari로 테스트합니다. VoiceOver(맥에서는 Command+F5)를 활성화하고 Tab 또는 VoiceOver 내비게이션 제스처로 포커스 가능한 요소를 이동합니다. iOS에서는 스와이프 제스처를 사용합니다. 특히 모바일에서 내비게이션 바와 쿠키 배너가 뷰포트의 더 큰 비율을 차지할 수 있으므로, 포커스된 요소가 고정 UI 레이어 아래에 숨지지 않고 시각적으로 보이는지 확인합니다.
JAWS와 Chrome으로 테스트합니다. JAWS(Job Access With Speech)를 실행하고 Chrome을 사용합니다. 모든 인터랙티브 요소를 Tab으로 이동하며, JAWS 커서가 고정 레이어 아래에 시각적으로 숨겨진 요소로 이동하는 순간이 있는지 모니터링합니다. JAWS는 기업 및 공공기관 환경에서 널리 사용되므로, 이 조합은 공공 부문 및 기업 웹사이트 테스트에서 특히 중요합니다.
레이아웃을 변경하는 사용자 상호작용 이후에 테스트합니다. 쿠키 배너를 닫고, 내비게이션 메뉴를 열고 닫고, 알림 토스트를 트리거하고, 채팅 위젯을 엽니다. 각 상태 변경 후 새롭게 Tab 순회를 수행해, 새로운 레이아웃이 포커스 가려짐 사례를 새로 만들지 않는지 확인합니다. 동적 콘텐츠는 사용자 상호작용 이후에만 나타나는 2.4.11 실패의 흔한 원인입니다.
여러 스크롤 위치에서 테스트합니다. 긴 페이지의 중간이나 하단으로 스크롤한 뒤, 해당 영역의 요소를 Tab으로 이동합니다. 고정 헤더는 페이지 상단 근처 요소는 가리지 않지만, 사용자가 아래로 스크롤했을 때 뷰포트 상단에 나타나는 요소는 가릴 수 있습니다. 어떤 스크롤 위치와 포커스 요소 조합에서도 완전한 시각적 가려짐이 발생하지 않는지 확인합니다.

해결 방법

스티키 헤더가 포커스된 링크를 겹쳐 가리는 경우 — 잘못된 예

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

스티키 헤더가 포커스된 링크를 겹쳐 가리는 경우 — 올바른 예

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

쿠키 배너가 하단의 포커스된 폼 필드를 가리는 경우 — 잘못된 예

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

쿠키 배너가 하단의 포커스된 폼 필드를 가리는 경우 — 올바른 예

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

서드파티 채팅 위젯이 포커스된 버튼을 겹쳐 가리는 경우 — 잘못된 예

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

서드파티 채팅 위젯이 포커스된 버튼을 겹쳐 가리는 경우 — 올바른 예

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

자주 발생하는 실수

position: fixed를 헤더와 푸터에 적용하면서 포커스 가능한 요소에 scroll-margin-top 또는 scroll-margin-bottom을 추가하지 않는 경우. 브라우저의 기본 포커스 스크롤은 고정된 겹치는 요소를 고려하지 않기 때문에, 포커스된 항목이 뷰포트 상단 또는 하단으로 스크롤되며 고정 레이어 뒤에 숨겨질 수 있습니다. * { scroll-margin-top: [header-height]px; }와 같은 전역 CSS 규칙으로 이 문제를 효율적으로 해결할 수 있습니다.
고정 헤더를 보정하기 위해 body { padding-top: 60px; }를 설정하면서 키보드 포커스를 위한 동일한 scroll-margin-top을 추가하지 않는 경우. 패딩은 초기 콘텐츠가 숨겨지지 않도록 보장하지만, 키보드 포커스가 브라우저 자동 스크롤을 트리거할 때 스크롤 대상이 여전히 헤더 뒤로 미끄러질 수 있습니다. 두 접근 방식을 함께 사용해야 합니다.
프로모션 배너나 채팅 위젯에 z-index: 9999를 설정하면서, 그 영역 안에 어떤 포커스 가능한 요소가 있는지 점검하지 않는 경우. 높은 z-index는 오버레이가 포커스된 버튼과 링크를 포함해 모든 것 위에 렌더링되도록 보장하며, 이는 2.4.11 실패의 가장 흔한 근본 원인입니다.
JavaScript로 쿠키 배너를 닫으면서 레이아웃에서 즉시 제거하지 않는 경우. 배너의 DOM 요소가 visibility: hidden 또는 opacity: 0 상태로 남아 있으면서도 여전히 공간을 차지하거나 0이 아닌 z-index를 가진다면, 특정 브라우저 렌더링 상황에서 시각적으로 포커스된 요소를 계속 가릴 수 있습니다.
서드파티 위젯(라이브 채팅, 접근성 오버레이, GDPR 매니저 등)을 임베드하면서 키보드 포커스 가시성에 미치는 영향을 검증하지 않는 경우. 서드파티 스크립트는 종종 매우 높은 z-index 값을 가진 고정 위치 요소를 삽입합니다. 팀은 이러한 통합을 접근성 QA 프로세스의 일부로 명시적으로 테스트해야 합니다.
반응형 브레이크포인트 변경 이후 2.4.11을 테스트하지 않는 경우. 데스크톱에서 높이 60px인 스티키 내비게이션 바가 태블릿에서는 햄버거 메뉴가 열릴 때 120px로 확장되어 훨씬 더 넓은 영역을 가리며, 데스크톱에서는 통과했던 브레이크포인트에서 새로운 실패를 만들 수 있습니다.
scroll-margin-top을 앵커 대상(<h2>, <section>)에만 적용하고, <input>, <button>, <a>와 같은 인터랙티브 요소에는 적용하지 않는 경우. 앵커 스크롤 오프셋은 흔히 처리되지만, 앵커가 아닌 요소에 대한 키보드 포커스 자동 스크롤도 동일하게 영향을 받으므로 같은 CSS 규칙으로 커버해야 합니다.
포커스된 요소가 스크린 리더에서 읽히면 시각적으로도 보일 것이라고 가정하는 경우. 스크린 리더는 시각 렌더링이 아니라 접근성 트리를 사용합니다. 요소가 고정 오버레이 뒤에 완전히 숨겨져 있어도 NVDA나 JAWS에서 정상적으로 읽힐 수 있습니다. 이는 서로 다른 두 문제이며, 2.4.11은 시각적 키보드 사용자용 포커스 가시성에만 초점을 맞춥니다.
단일 페이지 애플리케이션(SPA) 라우트 변경 이후 포커스 가려짐을 테스트하지 않는 경우. React, Vue, Angular 앱에서는 라우트 전환 시 업데이트된 상태로 고정 헤더를 다시 렌더링하는 경우가 많으며, 내비게이션 중 포커스 관리가 새 페이지를 사용자가 보기 전에 재마운트된 스티키 헤더에 즉시 가려지는 요소에 포커스를 둘 수 있습니다.
자동 테스트 도구에만 의존하고, 자동 규칙이 페이지를 표시하지 않았다는 이유로 2.4.11 문제가 없다고 결론 내리는 경우. Axe-core에는 이 기준에 대한 자동 규칙이 없으므로, 자동 보고서가 깨끗하다고 해서 페이지가 통과했다는 의미는 아닙니다. 모든 뷰포트 크기와 페이지 상태에서의 수동 키보드 순회가 필수입니다.

터키 접근성 규제와의 관계

WCAG 2.4.11 Focus Not Obscured (Minimum)은 터키에서 새롭게 형성되고 있는 법적 접근성 프레임워크와 직접적으로 관련이 있습니다. 2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 WCAG 2.2와 정렬된 의무적 디지털 접근성 요구사항을 수립합니다. 이 대통령령은 터키의 디지털 포용에 대한 약속을 크게 확장하는 조치로, 터키 디지털 시장에서 활동하는 광범위한 주체에 대해 집행 가능한 의무를 부과합니다.

이 대통령령은 공공기관 및 정부 기관, 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 의료 기관, 가입자 200,000명 이상 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교 등 폭넓은 조직을 포괄합니다. 이들 모든 주체는 웹사이트, 모바일 애플리케이션, 웹 기반 도구 등 디지털 인터페이스가 WCAG 2.2 레벨 AA에 부합하도록 보장해야 합니다.

WCAG 2.4.11은 WCAG 2.2에서 레벨 AA 기준이기 때문에, 이 규칙 준수는 해당 주체에게 선택 사항이 아닙니다. 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 공식 Erişilebilirlik Logosu(접근성 로고)를 취득하거나 유지하려는 조직은 레벨 AA 적합성을 충족해야 합니다. 접근성 로고는 디지털 포용에 대한 약속을 대중에게 알리는 신호로 기능하며, 터키 소비자와 정부 조달 기관에서 점점 더 당연하게 기대하는 요소가 되고 있습니다.

실질적으로 이는 스티키 내비게이션 헤더가 있는 터키 공공기관 웹사이트, 지속적인 프로모션 배너가 있는 전자상거래 사이트, 플로팅 도움말 위젯이 있는 은행 포털, 쿠키 동의 오버레이가 있는 의료 예약 시스템 등이 모두 2.4.11에 따른 포커스 가려짐 문제에 대해 테스트 및 개선되어야 함을 의미합니다. 이 기준의 실패는 특히 복잡하고 마케팅 요소가 많은 인터페이스에서 발생하기 쉬운데, 이는 바로 대통령령이 적용되는 대형 상업 주체들이 운영하는 사이트 유형과 일치합니다.

대통령령 적용 대상 조직은 정기적인 접근성 감사 주기에 2.4.11 테스트를 포함해야 합니다. 이 기준은 수동 테스트가 필요하므로, 자동 스캔에만 의존하는 것은 적절한 주의 의무를 충족하지 못합니다. 완전한 준수를 추구하는 터키 조직은 적합성 문서화의 일부로, 모든 뷰포트 크기와 동적 페이지 상태에서 수동 키보드 순회 테스트를 수행하고, 접근성 로고 신청 또는 갱신 전에 발견된 포커스 가려짐 문제를 개선 로드맵의 일부로 해결할 것을 권장합니다.