WCAG 2.1.2: 키보드 함정 금지

WCAG 2.1.2는 키보드 사용자가 어떤 구성 요소 안에 갇히지 않도록 할 것을 요구합니다. 키보드를 사용해 포커스를 UI 요소 안으로 이동할 수 있다면, 키보드만 사용해서 포커스를 그 요소 밖으로 이동하는 것도 가능해야 합니다. 이 기준은 운동 장애가 있는 사람들과 스크린 리더 사용자 등, 키보드 탐색에만 전적으로 의존하는 사용자들에게 필수적입니다.

이 규칙의 의미

WCAG 2.1.2 — 키보드 함정 금지(No Keyboard Trap) — 는 ‘조작 가능(Operable)’ 원칙 아래의 A 레벨 성공 기준입니다. 이 기준은 다음과 같이 규정합니다. “키보드 인터페이스를 사용하여 페이지의 구성요소로 키보드 포커스를 이동할 수 있는 경우, 키보드 인터페이스만을 사용하여 해당 구성요소에서 포커스를 이동할 수 있어야 하며, 포커스를 이동하기 위해 수정되지 않은 화살표 키나 Tab 키 이상의 조작이 필요하다면, 사용자는 포커스를 이동하는 방법에 대해 안내를 받아야 한다.”

실질적으로 이는 키보드 사용자가 Tab 키로 진입할 수 있는 웹페이지의 모든 인터랙티브 구성요소는, 사용자가 그 구성요소에서 다시 Tab으로 빠져나올 수 있도록 해야 한다는 뜻입니다. 키보드 함정은 사용자가 위젯, 대화 상자, 커스텀 폼 컨트롤, 임베디드 미디어 플레이어 또는 기타 포커스를 받을 수 있는 영역으로 이동한 뒤, 표준 키보드 조작만으로는 그 영역을 벗어날 수 없을 때 발생합니다. 사용자는 사실상 그 안에 갇히게 됩니다.

이 기준은 키보드 포커스를 받을 수 있는 모든 HTML 요소를 포괄합니다. <input>, <select>, <textarea>, <button>, <a> 태그와 같은 기본 인터랙티브 요소뿐 아니라, tabindex, ARIA 역할, JavaScript 포커스 관리 등을 통해 포커스를 받는 커스텀 위젯도 포함됩니다. 채팅 위젯, 비디오 플레이어, 지도 임베드, 날짜 선택기, 리치 텍스트 에디터 등 임베디드 서드파티 구성요소에도 동일하게 적용됩니다.

어떤 구성요소가 이 기준을 준수하는 경우는, 키보드 사용자가 항상 표준 키 — 일반적으로 Tab, Shift+Tab, Escape, 화살표 키 — 만으로 그 구성요소에서 포커스를 이동할 수 있거나, 포커스를 이동하기 위한 비표준 키보드 메커니즘이 있을 경우 페이지가 이를 명확히 안내하는 경우입니다. 반대로 구성요소가 실패하는 경우는, 포커스가 그 안에 잠겨 키보드로 접근 가능한 탈출 경로가 전혀 없거나, 유일한 탈출 수단이 마우스 클릭, 터치 제스처 등 키보드가 아닌 입력에만 의존하는 경우입니다.

WCAG는 좁은 예외를 제공합니다. 의도적이고 접근 가능한 디자인 패턴의 일부로서, 일시적으로 키보드 포커스를 구성요소 내부에 제한하는 것은 허용됩니다. 대표적인 예가 모달 대화 상자입니다. 모달 대화 상자는 열려 있는 동안 포커스를 대화 상자 내부에 가두어(가려진 배경 콘텐츠와의 상호작용을 막기 위해)야 하지만, 항상 키보드로 대화 상자를 닫고 포커스를 해제할 수 있는 수단 — 예를 들어 Escape 키 핸들러나 Tab으로 도달 가능한 명확한 레이블의 닫기 버튼 — 을 제공해야 합니다. 이러한 의도적이고 탈출 가능한 포커스 제한은 키보드 함정이 아니라, 모달 대화 상자 패턴의 올바른 구현입니다. 사용자가 전혀 빠져나올 수 없을 때만 함정이 실패로 간주됩니다.

왜 중요한가

키보드 함정은 웹사이트가 가질 수 있는 접근성 실패 중 가장 심각한 문제에 속합니다. 다른 많은 접근성 문제는 특정 사용자에게 경험을 저하시키는 수준에 그치지만, 키보드 함정은 사용자가 페이지 사용을 계속하는 것을 완전히 차단할 수 있습니다. 이는 복도에 물리적인 장벽을 세워 두고 우회로를 전혀 제공하지 않는 것과 같습니다.

가장 심각한 영향을 받는 집단은 마우스를 사용할 수 없고 전적으로 키보드 내비게이션에 의존하는 운동 장애 또는 신체 장애가 있는 사용자들입니다. 여기에는 반복성 스트레스 손상, 다발성 경화증, 파킨슨병, 사지마비, 뇌성마비 등의 상태를 가진 사람들이 포함됩니다. 세계보건기구(WHO)에 따르면 약 13억 명 — 전 세계 인구의 16% — 이 상당한 형태의 장애를 가지고 있으며, 그중 운동 장애가 상당한 비중을 차지합니다. 이러한 사용자에게 결제 페이지, 로그인 폼, 고객 서비스 채팅 위젯에서 키보드 함정을 만나게 되는 것은, 해당 작업을 전혀 완료할 수 없다는 의미입니다.

스크린 리더 사용자 — 주로 시각장애 및 저시력 사용자 — 역시 큰 영향을 받습니다. NVDA, JAWS, VoiceOver와 같은 스크린 리더는 전적으로 키보드 명령으로 내비게이션합니다. 포커스가 어떤 구성요소에 갇히면, 스크린 리더 사용자는 Tab을 누를 때마다 같은 요소만 반복해서 듣게 되고, 페이지를 앞뒤로 진행할 방법이 없습니다. 이는 매우 혼란스럽고, 사용자는 브라우저 탭을 닫거나 페이지를 새로고침할 수밖에 없으며, 그동안 진행한 작업은 모두 잃게 됩니다.

다음과 같은 실제 상황을 생각해 보십시오. 손 움직임이 제한적인 사용자가 어떤 상품을 구매하기 위해 터키의 한 전자상거래 사이트를 방문합니다. 사용자는 장바구니에 상품을 담고 결제 단계로 이동합니다. 결제 페이지에는 커스텀 JavaScript 프레임워크로 구현된 서드파티 주소 자동완성 위젯이 있습니다. 주소 필드에 포커스가 가면 위젯이 드롭다운 제안 목록을 엽니다. 그러나 개발자가 이 드롭다운을 닫기 위한 키보드 이벤트 처리를 추가하는 것을 잊었습니다. 그 결과 사용자가 주소 필드로 Tab으로 진입해 드롭다운이 열리면, Tab으로 빠져나갈 수도, Escape를 누를 수도, 마우스 클릭 없이 드롭다운을 닫을 수도 없습니다. 사용자는 구매를 완료하는 것이 완전히 차단됩니다. 이는 사소한 불편이 아니라, 서비스에서의 완전한 배제입니다.

장애와 무관하게, 키보드 함정은 속도를 위해 키보드 내비게이션을 선호하는 파워 유저, 마우스 사용이 제한된 엔터프라이즈 환경의 사용자, 하드웨어 키보드가 있는 일부 모바일 또는 하이브리드 기기 사용자에게도 영향을 줍니다. 따라서 키보드 함정을 해결하면 장애가 있는 사용자뿐 아니라 더 넓은 사용자층의 경험이 개선됩니다.

테스트 방법

기본선으로 자동 접근성 스캔을 실행합니다. axe DevTools(브라우저 확장 프로그램)를 열거나 Chrome DevTools에서 Lighthouse 접근성 감사(audit)를 실행합니다. 두 도구 모두 키보드 함정을 직접 표시하지는 않지만, 포커스 가능한 요소, 누락된 ARIA 역할, 위험 신호가 될 수 있는 잘못된 Tab 순서를 식별해 줍니다. 커스텀 위젯, 임베디드 iframe, 서드파티 구성요소, 모달 대화 상자, 드롭다운 메뉴, 날짜 선택기, 캐러셀, 리치 텍스트 에디터 등을 기록해 두십시오. 이들이 키보드 함정의 가장 흔한 원인입니다.
마우스를 분리하거나 한쪽에 치워 둡니다. 수동 키보드 테스트가 유효하려면 마우스를 사용해서는 안 됩니다. 테스트 중 무심코 마우스에 의존하는 일을 피하기 위해, 마우스를 손이 닿지 않는 곳에 두거나 운영체제 설정에서 비활성화하십시오.
Tab과 Shift+Tab 키만 사용해 페이지 전체를 탐색합니다. 브라우저 주소 표시줄 또는 페이지 상단에서 시작해 Tab을 반복해서 누르며 포커스가 어디로 이동하는지 관찰합니다. 각 단계에서 포커스 표시를 시각적으로 추적하십시오. 각 인터랙티브 구성요소 — 특히 커스텀 위젯, 임베디드 콘텐츠, 복잡한 UI 요소 — 에 도달했을 때, Tab 또는 Shift+Tab을 눌렀을 때 포커스가 해당 구성요소를 벗어나 페이지의 다음 또는 이전 포커스 가능한 요소로 깔끔하게 이동하는지 확인합니다.
각 인터랙티브 구성요소를 개별적으로 테스트합니다. 모달 대화 상자의 경우: 모달을 열고, 포커스가 그 안으로 이동하는지 확인한 뒤, Escape를 눌러 포커스가 트리거 요소로 돌아오는지 확인합니다. 드롭다운 메뉴의 경우: 드롭다운을 열고 내부를 탐색한 뒤, Escape를 눌러 드롭다운이 닫히고 포커스가 트리거로 돌아오는지 확인합니다. 날짜 선택기, 색상 선택기 등 유사 위젯의 경우: Tab으로 진입해 상호작용한 뒤 Tab으로 빠져나갈 수 있는지 확인합니다. 임베디드 iframe(예: 지도, 비디오 플레이어, 채팅 위젯)의 경우: iframe으로 Tab으로 진입해 내부를 탐색한 뒤, 다시 Tab으로 메인 페이지로 포커스를 되돌릴 수 있는지 확인합니다.
NVDA와 Firefox로 테스트합니다. NVDA를 실행하고 Firefox에서 페이지를 연 뒤, Tab으로 인터랙티브 요소를 이동합니다. Tab을 누를 때마다 NVDA가 새로운 요소를 읽어 주는지, 아니면 같은 요소로 되돌아가는 것처럼 보이는지 주의 깊게 살펴보십시오. Tab이 어떤 구성요소를 지나 포커스를 더 이상 진행시키지 못한다면, 이는 키보드 함정입니다.
macOS에서 VoiceOver와 Safari로 테스트합니다. VoiceOver(Command + F5)를 활성화하고 Safari에서 페이지를 연 뒤, Tab 키로 탐색합니다. Tab을 누를 때마다 VoiceOver가 새로운 요소를 알려 주는지, 그리고 빠져나갈 수 없는 영역에 포커스가 갇히는 일이 없는지 확인합니다.
JAWS와 Chrome으로 테스트합니다. JAWS를 실행하고 Chrome에서 페이지를 연 뒤, Tab으로 모든 인터랙티브 구성요소를 탐색합니다. 특히 JavaScript 기반 포커스 관리를 사용하는 구성요소를 집중적으로 테스트하십시오. JAWS는 접근성 트리와 상호작용하는 방식 때문에, 시각적 테스트만으로는 드러나지 않는 함정을 드러낼 수 있습니다.
비표준 탈출 메커니즘을 확인합니다. 어떤 구성요소가 Tab, Shift+Tab, Escape 이외의 키를 사용해 빠져나가도록 요구한다면, 페이지가 이를 사용자에게 명확히 전달하는지 확인하십시오. 예를 들어, 화면 상의 안내 문구, 툴팁, 또는 포커스가 구성요소에 들어갈 때 ARIA 라이브 리전(ARIA live region) 알림을 통해 안내할 수 있습니다.

해결 방법

Escape 처리 없는 모달 대화 상자 — 잘못된 예

<!-- Modal opens but has no Escape key handler and no close button reachable by keyboard -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- No close button, no Escape key listener -- keyboard users are trapped -->
</div>

Escape 처리 없는 모달 대화 상자 — 올바른 예

<!-- Modal with proper focus trap, Escape handler, and accessible close button -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Close button is reachable by Tab and allows keyboard users to exit -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Escape key closes the modal and returns focus to trigger
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Return focus to opener
  }
</script>

모든 Tab 키 이벤트를 가로채는 커스텀 드롭다운 — 잘못된 예

<!-- Custom dropdown intercepts all keydown events including Tab, preventing focus from leaving -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // BUG: This captures ALL keyboard events and calls preventDefault on Tab,
  // meaning the user can never Tab out of this component
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // This traps the keyboard
    if (e.key === 'ArrowDown') { /* move focus down */ }
    if (e.key === 'ArrowUp') { /* move focus up */ }
  });
</script>

모든 Tab 키 이벤트를 가로채는 커스텀 드롭다운 — 올바른 예

<!-- Correct: Only prevent default for arrow keys used for internal navigation;
     allow Tab and Escape to function normally so users can exit -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Only prevent default for internal navigation keys
      // move focus between options
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // Do NOT call preventDefault -- allow Tab and Escape to propagate
      // so the browser can move focus away from this component naturally
      closeDropdown();
    }
  });
</script>

탈출 경로가 없는 임베디드 서드파티 iframe — 잘못된 예

<!-- An embedded chat widget iframe that absorbs all Tab keypresses
     and never returns focus to the parent page -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- The iframe's internal JavaScript consumes Tab events, trapping users inside it -->

탈출 경로가 없는 임베디드 서드파티 iframe — 올바른 예

<!-- Use a button to open the chat in a new window rather than embedding
     an iframe that may trap keyboard users -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- If an iframe must be used, add a visible skip link before it
     so keyboard users can bypass it if they choose -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

자주 발생하는 실수

keydown 리스너 안에서 특정 키로 범위를 한정하지 않고 event.preventDefault()를 호출하는 경우 — 포커스 가능한 구성요소에서 모든 키보드 이벤트에 preventDefault()를 적용하면 Tab과 Shift+Tab이 동작하지 않게 되어 즉시 키보드 함정이 만들어집니다. 항상 preventDefault()는 구성요소 내부에서 처리해야 하는 특정 키(예: 리스트박스의 화살표 키)에만 한정해야 합니다.
포커스를 모달 내부로 이동시키지만 Escape 키 핸들러나 닫기 버튼이 없는 모달 대화 상자를 만드는 경우 — 개발자는 종종 모달 패턴의 포커스 진입 부분은 올바르게 구현하지만, 모달 내부의 포커스 제한은 항상 키보드로 접근 가능한 탈출 수단이 있을 때만 허용된다는 점을 잊습니다. 모든 모달은 Escape 키를 처리하고 Tab으로 접근 가능한 닫기 버튼을 포함해야 합니다.
컨테이너 요소에 tabindex='-1'을 사용해 Tab 순서에서 제외하면서도 JavaScript로 해당 요소에 프로그래밍 방식으로 포커스를 이동시키는 경우 — element.focus()를 통해 tabindex='-1' 요소로 포커스를 이동시키면, 그 요소를 벗어나기 위한 자연스러운 Tab 대상이 없어집니다. 추가적인 키보드 처리가 구현되지 않았다면 사용자가 그 안에 갇힐 수 있습니다.
키보드 함정 여부를 검토하지 않은 채 서드파티 위젯(채팅, 지도, 비디오)을 임베드하는 경우 — 공급업체가 임베디드 위젯을 항상 키보드 접근 가능하게 만들지는 않습니다. 사이트 소유자는 서드파티 임베드를 포함해 페이지의 모든 콘텐츠에 대해 책임을 집니다. 임베디드 구성요소는 항상 수동으로 테스트하고, 키보드 사용자를 가두는 경우 건너뛰기 링크로 감싸거나 키보드에 안전한 대체 수단으로 교체해야 합니다.
모달이나 드로어에 포커스 함정을 구현했지만 구성요소가 닫힐 때 함정을 해제하지 않는 경우 — 포커스를 제한하는 JavaScript가 모달이 닫힐 때 적절히 정리되지 않으면, 보이지 않는 레이어에서 계속 Tab 이벤트를 가로채 사용자를 가둘 수 있습니다.
시각적 디자인을 이유로 대화 상자의 닫기 버튼에 CSS visibility: hidden 또는 display: none을 사용하면서 대체 키보드 탈출 수단을 제공하지 않는 경우 — 닫기 버튼이 시각적으로만 숨겨지고 접근성 트리에서는 제거되지 않았다면 스크린 리더 사용자는 여전히 이를 찾을 수 있습니다. 그러나 접근성 트리에서도 숨겨진 경우, 탈출 수단이 전혀 없을 수 있습니다. 닫기 메커니즘이 시각적으로 눈에 띄지 않게 스타일링되었더라도 키보드로 조작 가능함을 반드시 확인해야 합니다.
제안 목록을 열고, Tab 키 입력을 모두 제안 항목 순환에만 사용하도록 하는 커스텀 자동완성 또는 타이프어헤드(type-ahead) 구성요소를 만드는 경우 — 사용자는 Escape를 눌러 제안 목록을 닫고, 그 다음 Tab으로 다음 폼 필드로 이동할 수 있어야 합니다. Tab을 내부 내비게이션으로 재지정하는 자동완성 위젯은 이 기준을 위반합니다.
TinyMCE, CKEditor, Quill과 같은 리치 텍스트 에디터(WYSIWYG 에디터)를 테스트하는 것을 잊는 경우 — 이러한 구성요소는 내부적으로 자체 키보드 상호작용을 관리하며, 키보드 함정의 빈번한 원인입니다. Escape 또는 문서화된 키 시퀀스를 눌렀을 때 에디터를 빠져나와 페이지의 일반 Tab 순서로 포커스가 돌아오는지 항상 확인해야 합니다.
기본 HTML 요소를 사용했기 때문에 키보드 함정이 발생할 수 없다고 가정하는 경우 — JavaScript로 blur 이벤트를 오버라이드한 폼 내부의 <select> 요소도 여전히 포커스를 가둘 수 있습니다. 의미론적 HTML을 사용했다고 해서, 그 위에 커스텀 JavaScript 이벤트 처리가 추가되었을 때까지 키보드 함정이 없다고 보장할 수는 없습니다.
구성요소에서 빠져나가기 위해 비표준 키가 필요할 때 화면 상 안내를 제공하지 않는 경우 — WCAG 2.1.2는 비표준 키를 사용해 빠져나가야 하는 구성요소를 허용하지만, 그 경우 사용자에게 이를 알려야 한다고 명시합니다. 위젯이 F6 또는 커스텀 키 조합을 눌러야만 빠져나갈 수 있도록 요구한다면, 구성요소 인접의 눈에 보이는 안내 문구나 포커스 진입 시 ARIA 라이브 리전 알림을 통해 이를 명확히 전달해야 합니다.

터키 접근성 규정과의 관계

터키의 2025년 6월 21일 관보 제32933호에 게재된 대통령령 2025/10은 터키에서 운영되는 광범위한 공공 및 민간 부문 기관에 대해 구속력 있는 디지털 접근성 요구사항을 수립합니다. 이 대통령령은 국제적으로 인정된 웹 접근성 표준 준수를 의무화하며, WCAG 2.1 AA 레벨을 기준선으로 삼고 있습니다. 여기에는 WCAG 2.1.2 키보드 함정 금지를 포함한 모든 A 레벨 기준이 포함됩니다.

WCAG 2.1.2는 최소 수준의 준수를 의미하는 A 레벨 기준입니다. 대통령령에 따라 A 레벨 준수는 모든 해당 기관에 의무적입니다. 공공 기관은 대통령령 공포 후 1년 이내에 이 수준의 준수를 달성해야 하며, 민간 부문 기관에는 2년의 이행 기간이 주어집니다.

대통령령의 적용 대상은 매우 광범위합니다. 모든 수준의 공공 기관 및 정부 부처, 전자상거래 플랫폼 및 온라인 마켓플레이스 운영자, 은행 및 금융 서비스 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교 등이 포함됩니다. 이는 이러한 기관이 운영하는 웹사이트나 웹 애플리케이션에서 키보드 함정을 해결하지 못하는 것이 터키의 의무적 접근성 규정을 직접적으로 위반하는 것임을 의미합니다.

복잡한 웹 애플리케이션에서 키보드 함정 실패가 빈번히 발생한다는 점 — 특히 온라인 뱅킹 포털, 병원 진료 예약 시스템, 전자상거래 결제 플로우, 통신사 계정 관리 페이지 등에서 — 을 고려할 때, WCAG 2.1.2는 터키의 컴플라이언스 맥락에서 특히 주의 깊게 다루어져야 합니다. 이들 인터페이스는 상호작용이 많고 JavaScript 기반으로 구동되며, 커스텀 위젯, 모달 대화 상자, 서드파티 임베드를 포함할 가능성이 높아 키보드 사용자를 의도치 않게 가두기 쉽습니다.

대통령령의 적용을 받는 조직은 키보드 함정 테스트를 접근성 감사 프로세스에서 절대 양보할 수 없는 요소로 취급해야 합니다. 자동화 도구로는 키보드 함정을 신뢰성 있게 탐지할 수 없기 때문에, 해당 기관은 자격을 갖춘 접근성 전문가(가능하다면 장애가 있는 사용자 포함)에 의해 수행되는 수동 키보드 테스트에 투자해야 합니다. 감사 과정에서 식별된 키보드 함정을 시정하지 않는 것은 대통령령에 따른 법적 위험일 뿐 아니라, 키보드 내비게이션에 의존해 디지털 서비스를 이용하는 운동 장애 및 시각 장애 사용자에게 심각한 접근 장벽을 의미합니다.