WCAG 2.4.3: 포커스 순서

WCAG 2.4.3은 웹 페이지를 순차적으로 탐색할 수 있고 그 탐색 순서가 의미나 동작에 영향을 미치는 경우, 포커스를 받을 수 있는 구성 요소들이 의미와 조작 가능성을 유지하는 순서로 포커스를 받아야 한다고 요구한다. 이 기준은 논리적이고 예측 가능한 포커스 순서에 의존하여 콘텐츠를 이해하고 상호작용하는 키보드 및 보조 기술 사용자들에게 필수적이다.

이 규칙의 의미

WCAG 2.4.3 Focus Order는 Operable 원칙 아래의 레벨 A 성공 기준이다. 이 기준은 다음과 같이 규정한다: "웹 페이지를 순차적으로 탐색할 수 있고 그 탐색 순서가 의미나 동작에 영향을 미치는 경우, 포커스를 받을 수 있는 구성 요소는 의미와 조작 가능성을 보존하는 순서로 포커스를 받아야 한다."

실질적으로 이는 사용자가 페이지의 인터랙티브 요소들 — 링크, 버튼, 폼 필드, 커스텀 위젯 및 기타 포커스 가능한 모든 구성 요소 — 사이를 이동하기 위해 Tab 키를 눌렀을 때, 그 요소들이 포커스를 받는 순서가 논리적으로 이해가 되어야 한다는 뜻이다. 사용자가 폼의 중간에서 푸터 링크로, 다시 모달 버튼으로, 또 내비게이션 메뉴 항목으로 예기치 않게 점프하는 상황이 발생해서는 안 된다.

이 기준은 키보드만 사용하는 사용자와 스크린 리더 사용자가 페이지를 탐색하는 기본 방식인 순차적 키보드 탐색에 적용된다. DOM 순서는 브라우저에서 포커스 순서의 기본 출처이다. CSS나 JavaScript가 의도적으로 그 순서를 변경하지 않는 한, 요소들은 Document Object Model(DOM)에 나타나는 순서대로 Tab 순서에 나타난다. CSS Flexbox나 Grid 재정렬로 인해 시각적 레이아웃이 DOM 순서와 달라지거나, tabindex 값이 부자연스러운 순서를 강제할 때 문제가 발생한다.

통과로 인정되는 경우: 포커스 순서는 논리적이고 의미가 있어야 한다. 시각적 읽기 순서와 반드시 동일할 필요는 없지만, 사용자가 페이지를 이해하고 조작할 수 있을 정도로 일관성이 있어야 한다. 모달 다이얼로그가 열릴 때 포커스를 자신에게 옮기고, 열려 있는 동안 포커스를 내부에 가두며, 닫힐 때 트리거 요소로 포커스를 되돌리는 경우 이 기준을 충족한다. Tab 키로 진행할 때 사용자가 실제로 입력할 순서(좌→우 언어에서는 위에서 아래, 왼쪽에서 오른쪽)대로 각 필드를 통과하는 다단계 폼 역시 통과한다.

실패로 인정되는 경우: 로그인 폼의 "Username" 필드에서 "Password" 필드에 도달하기 전에 전혀 관련 없는 프로모션 배너로 포커스가 점프하는 경우 실패이다. 단일 페이지 애플리케이션이 다이얼로그를 열지만 포커스를 배경 페이지에 그대로 두는 경우도 실패이다. 페이지 전체에 걸쳐 비논리적인 Tab 순서를 강제하는 양의 정수 tabindex 값(예: tabindex='2', tabindex='5')을 사용하는 경우 역시 실패이다.

공식 예외: WCAG는 의미와 조작 가능성이 보존되는 한, 포커스 순서가 시각적 읽기 순서와 일치할 필요는 없다고 명시한다. 또한 탐색 순서가 의미나 동작에 영향을 미치지 않는 경우 — 예를 들어 포커스 가능한 요소가 하나뿐인 페이지처럼 평가할 순서 자체가 없는 경우 — 는 허용된다. 더불어 의미를 모두 보존하는 여러 개의 유효한 순서가 있을 때는 그 어느 순서도 허용된다.

포커스 순서에 영향을 미치는 핵심 HTML 및 JavaScript 메커니즘에는 다음이 포함된다: 인터랙티브 요소의 자연스러운 DOM 순서, tabindex 속성(특히 양의 정수 값), DOM을 변경하지 않고 시각적 레이아웃만 재배치하는 CSS 속성(order in Flexbox/Grid, position: absolute, float 등), 요소에 대해 .focus()를 호출하는 JavaScript 기반 포커스 관리, 그리고 명시적인 포커스 관리를 요구하는 ARIA 다이얼로그 패턴.

왜 중요한가

포커스 순서는 사소한 기술적 세부사항이 아니라, 상당수 사용자를 위한 웹의 탐색적 척추 역할을 한다. 여러 유형의 장애를 가진 사용자 그룹이 디지털 제품을 효과적으로 사용하기 위해 논리적인 포커스 순서에 의존한다.

마우스를 사용할 수 없는 운동 장애 사용자는 키보드(또는 sip-and-puff 스위치, 헤드 포인터, 시선 추적 시스템과 같은 키보드와 동등한 장치)에 전적으로 의존해 탐색한다. 이들에게 뒤죽박죽인 포커스 순서는 단순히 불편한 수준이 아니라, 페이지를 완전히 사용 불가능하게 만들 수 있다. Tab 키가 사용자를 페이지의 잘못된 위치로 데려가면, 필요한 컨트롤에 도달할 효율적인 방법이 없을 수 있고, 손을 움직여 다른 곳을 클릭하는 것도 불가능하다.

NVDA, JAWS, VoiceOver 같은 스크린 리더를 사용하는 시각장애인 및 저시력 사용자는 포커스가 도달하는 요소를 음성으로 듣는다. 논리적인 포커스 순서는 이들이 듣는 오디오 스트림이 인터페이스의 의도된 흐름을 반영한다는 뜻이다. 포커스가 불규칙하게 점프하면 사용자는 페이지에서 자신의 위치에 대한 정신적 모델을 잃게 된다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명의 사람이 어떤 형태로든 시각 장애를 가지고 있으며, 이들 중 많은 스크린 리더 사용자에게 포커스 순서는 페이지 구조를 경험하는 주요 수단이다.

인지 장애 사용자 역시 예측 가능한 포커스 순서로부터 큰 도움을 받는다. 폼 작성 중간에 예기치 않은 포커스 점프가 발생하면 혼란을 야기하고, 사용자가 작업 흐름을 다시 시작하게 만들거나 필수 필드를 놓치게 할 수 있다. 주의 집중에 어려움이 있거나 단기 기억에 문제가 있는 사용자는 사이트 사용에 대한 자신감을 쌓기 위해 일관되고 예측 가능한 탐색이 필요하다.

구체적인 실제 시나리오: 터키의 한 전자상거래 결제 페이지를 상상해 보자. 시각적 디자인은 CSS Grid를 사용해 주문 요약을 왼쪽에, 결제 폼을 오른쪽에 배치한다. 그러나 DOM에서는 결제 폼이 먼저, 주문 요약이 그 다음에 온다. 시각적 레이아웃은 시력이 있고 마우스를 사용하는 사용자에게는 올바르게 보이지만, 키보드 사용자가 Tab 키를 누르면 주문 요약을 검토할 기회도 갖기 전에 결제 폼 필드에 먼저 도달하게 된다. 사용자는 잘못된 주문을 모른 채 확정할 수 있다. 더 나아가, 양의 tabindex 오용으로 인해 "Confirm Purchase" 버튼이 "Apply Coupon" 필드보다 먼저 포커스를 받는다면, 사용자는 할인 적용을 의도했음에도 실수로 결제를 제출할 수 있다. 이는 포커스 순서가 깨짐으로써 발생하는 직접적이고 실제적인 재정적 결과이다.

접근성을 넘어, 논리적인 포커스 순서는 속도를 위해 키보드 탐색을 선호하는 파워 유저의 경험도 향상시킨다. 또한 SEO를 간접적으로 지원한다. 자연스러운 포커스 순서를 만들어내는 잘 구조화된 DOM은 의미 있는 시맨틱 마크업을 반영하는 경우가 많으며, 검색 엔진은 이를 사용해 콘텐츠의 계층 구조와 중요도를 이해한다.

테스트 방법

출발점으로 자동 스캔 수행: 페이지에서 axe DevTools(브라우저 확장) 또는 Google Lighthouse를 실행한다. 양의 tabindex 값과 표시된 스크롤 영역에 대한 경고를 확인한다. 자동 결과가 깨끗하다고 해서 2.4.3이 충족되었다는 의미는 아니다 — 수동 테스트는 항상 필요하다. 표시된 문제는 추가 조사를 위해 기록한다.
마우스를 분리하고 Tab만으로 탐색: 브라우저 주소 표시줄 또는 페이지 상단에서 시작해, Tab 키를 반복해서 눌러 모든 포커스 가능한 요소를 순회한다. 순서를 주의 깊게 관찰한다. 스스로에게 질문해 보라: 포커스가 페이지의 논리적 읽기 및 상호작용 흐름과 일치하는 순서로 이동하는가? 포커스가 예기치 않은 영역으로 점프하는가? 의도된 다이얼로그 내부를 제외하고, 앞으로 또는 뒤로 이동할 수 없는 상태(포커스가 갇히는 상태)가 발생하는가?
동적 컴포넌트 테스트: 키보드를 사용해 모달, 다이얼로그, 드롭다운 메뉴, 아코디언, 탭 패널, 날짜 선택기 및 기타 인터랙티브 위젯을 활성화한다. 활성화 직후 포커스가 새로 드러난 콘텐츠로 즉시 이동하는지 확인한다. 다이얼로그를 닫은 후에는 포커스가 페이지 상단이나 임의의 위치가 아니라, 다이얼로그를 트리거한 요소로 돌아오는지 확인한다.
NVDA + Firefox로 테스트: NVDA를 실행하고 Firefox를 열어 페이지로 이동한다. Tab 키로 인터랙티브 요소를 이동하며 음성 출력을 듣는다. 안내되는 순서가 문맥상 의미가 있는지 확인한다. NVDA의 Browse Mode(화살표 키)를 사용해 정적 콘텐츠를 읽고, 그 읽기 순서가 해당 콘텐츠 내 인터랙티브 요소의 포커스 순서와 일치하는지 확인한다.
VoiceOver + Safari(macOS/iOS)로 테스트: VoiceOver를 활성화하고 Tab(데스크톱) 또는 스와이프 제스처(iOS)를 사용해 포커스 가능한 요소를 이동한다. 포커스 순서가 논리적인지 확인한다. iOS에서는 모달과 오버레이가 포커스를 올바르게 가두고, 닫힐 때 포커스를 되돌리는지 테스트한다.
JAWS + Chrome으로 테스트: JAWS의 Tab 탐색을 사용해 안내되는 포커스 순서가 일관적인지 확인한다. JAWS의 가상 커서를 사용해 읽기 순서와 인터랙티브 포커스 순서를 교차 검증하고, 불일치가 있는지 확인한다.
DOM과 시각적 레이아웃 비교: 브라우저 DevTools를 열어 DOM 구조를 살펴본다. DOM에서 인터랙티브 요소가 나타나는 순서와 화면에서의 시각적 위치를 비교한다. order, position: absolute, float 같은 CSS 속성이 큰 차이를 만들고 있다면, Tab 순서를 수동으로 추적해 의미나 조작 가능성이 영향을 받는지 판단한다.
DOM의 tabindex 값 확인: 브라우저 콘솔에서 document.querySelectorAll('[tabindex]')를 실행해 tabindex 속성이 명시된 모든 요소를 나열한다. 양의 정수 값을 가진 요소를 조사하고, 수정된 Tab 순서에서 그 위치가 논리적인지 평가한다.

해결 방법

양의 tabindex 값으로 인한 비논리적 순서 — 잘못된 예

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

양의 tabindex 값으로 인한 비논리적 순서 — 올바른 예

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

CSS 시각적 재정렬과 DOM 순서 불일치 — 잘못된 예

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

CSS 시각적 재정렬과 DOM 순서 불일치 — 올바른 예

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

모달 다이얼로그의 포커스 관리 미흡 — 잘못된 예

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

모달 다이얼로그의 포커스 관리 미흡 — 올바른 예

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

자주 발생하는 실수

포커스 순서를 "제어"하기 위해 양의 정수 tabindex 값(예: tabindex='1', tabindex='5')을 사용하는 것으로 DOM 구조를 바로잡는 대신에 이를 택하는 경우. 양의 tabindex 값은 요소를 페이지의 모든 자연 포커스 가능 요소보다 앞에 배치해, 유지 관리가 극도로 어렵고 거의 항상 오류를 유발하는 혼란스러운 전역 Tab 순서를 만든다.
DOM을 재정렬하지 않은 채 Flexbox나 CSS Grid에서 CSS order를 사용해 콘텐츠를 시각적으로 재배치하고, 키보드 탐색을 테스트하지 않는 것. 시각적 레이아웃은 시력이 있는 사용자에게는 올바르게 보이지만, Tab 순서는 시각적 순서가 아니라 DOM 순서를 따른다 — 키보드 사용자에게는 보이지 않지만 심각한 불일치이다.
JavaScript의 .focus() 메서드를 사용해 모달이나 다이얼로그가 열릴 때 포커스를 프로그래밍 방식으로 그 안으로 이동시키지 않는 것. 스크린 리더 및 키보드 사용자는 배경 콘텐츠에 갇혀 다이얼로그를 찾거나 상호작용하지 못하는 경우가 많다.
모달, 드로어, 드롭다운을 닫은 후 포커스를 트리거 요소로 되돌리지 않는 것. 포커스를 페이지 상단으로 돌리거나 이제는 숨겨진 요소에 남겨두면, 사용자는 잠재적으로 긴 페이지의 처음부터 다시 탐색해야 하며, 자신의 위치를 잃게 된다.
동적으로 로드된 콘텐츠(예: 인라인 오류 메시지, 토스트 알림, 지연 로드 섹션)를 시각적으로는 앞에 보이는 포커스 가능한 요소 뒤의 DOM에 삽입하는 것으로, 키보드 사용자가 새 콘텐츠를 순서대로 만나지 못하거나 아예 만나지 못하게 만든다.
tabindex='-1'을 사용해 요소를 Tab 순서에서 제거하면서, 키보드로 접근할 수 있는 대체 수단을 제공하지 않는 것. tabindex='-1' 자체는(요소를 프로그래밍 방식으로는 포커스 가능하게 하지만 자연 Tab 순서에서는 제거함) 유효한 도구지만, 사용자가 실제로 접근해야 하는 컨트롤에 잘못 적용하면 키보드 사용자에게서 그 컨트롤을 사실상 숨기는 결과가 된다.
단일 페이지 애플리케이션의 라우트 전환 시 포커스를 새 페이지의 헤딩이나 스킵 내비게이션 랜드마크가 아니라 document body나 브라우저 크롬으로 재설정하는 것. 이 경우 사용자는 라우트가 바뀔 때마다 전체 내비게이션을 Tab으로 다시 통과해야 한다.
화살표 키 탐색이 구현되지 않고 Tab이 각 숨겨진 슬라이드를 통과하도록 만든 커스텀 캐러셀이나 슬라이더 위젯을 구현하는 것. 사용자는 이후 페이지 콘텐츠에 도달하기 전에 화면 밖의 수십 개 요소를 Tab으로 통과해야 한다.
항상 display:none 상태인 "보이지 않는" 스킵 내비게이션 링크를 DOM에 배치하는 것(.sr-only/clip 기법으로 시각적으로만 숨기는 대신). display:none 링크는 Tab 순서에서 완전히 제거되어 아무런 이점을 제공하지 못하는 반면, 제대로 구현된 스킵 링크는 Tab으로 포커스를 받고 시각적으로 표시되어, 메인 콘텐츠로의 논리적 포커스 흐름을 직접적으로 지원한다.
인터랙티브 요소 안에 다른 인터랙티브 요소를 중첩하는 것(예: <a> 태그 안에 <button>을 넣는 경우). 이는 브라우저마다 일관되지 않은 Tab 동작을 만들어, 포커스가 동일한 논리적 컨트롤에 여러 번 도달하거나 아예 건너뛰게 만들 수 있다.

터키 접근성 규정과의 관계

WCAG 2.4.3 Focus Order는 터키의 획기적인 접근성 입법인 2025/10번 대통령령(2025년 6월 21일 관보 제32933호에 게재)과 직접적으로 관련이 있다. 이 대통령령은 터키에서 운영되는 광범위한 공공 및 민간 부문 기관에 대해, 국제적으로 인정된 지침 — 여기에는 2.4.3을 포함한 모든 WCAG 2.x 레벨 A 성공 기준이 포함된다 — 을 준수해야 하는 의무적인 웹 접근성 표준을 수립한다.

이 대통령령은 폭넓은 기관 유형을 포괄한다. 공공 기관 — 부처, 지방자치단체, 국립 대학, 정부 기관 등을 포함 — 은 대통령령 공포일로부터 1년 이내에 완전한 준수에 도달해야 한다. 해당 범주에 속하는 민간 부문 기관은 동일한 준수 수준에 2년 이내에 도달해야 한다. 해당 민간 부문 범주에는 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 민간 의료 서비스 제공자, 가입자 200,000명 이상인 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받아 운영되는 민간 학교가 포함된다.

이 모든 조직에 대해, 깨졌거나 비논리적인 포커스 순서는 단순한 사용성 문제를 넘어, 대통령령의 집행 조항에 따라 법적·행정적 결과를 초래할 수 있는 규정 위반이다. 예를 들어, 터키의 한 은행 인터넷 뱅킹 포털에서 자금 이체 화면의 포커스 순서가 금액 필드에서 수취인 IBAN 필드를 건너뛰고 확인 버튼으로 점프한다면, 키보드만 사용하는 — 예를 들어 운동 장애가 있는 고객 — 사용자가 필수 필드를 제대로 채우지 않은 채 이체를 시작할 수 있다. 이 시나리오는 동시에 WCAG 2.4.3 실패, 대통령령 요구사항 위반, 그리고 사용자에게 잠재적으로 심각한 재정적 피해를 의미한다.

마찬가지로, 대통령령 적용 대상인 한 전자상거래 사이트가 CSS Grid 재정렬을 사용해 시각적으로 매력적인 상품 페이지를 구성했지만, Tab 순서가 상품 이미지에서 푸터 링크로 점프한 뒤에야 "Add to Cart" 버튼에 도달한다면, 이는 2.4.3을 정면으로 위반하는 것이며 따라서 대통령령 비준수 상태가 된다. 1년 및 2년의 기한은 조직이 포커스 순서 개선을 접근성 로드맵에서 후순위가 아닌 우선순위로 다루어야 함을 의미한다. 포커스 순서 문제는 종종 DOM 구조와 JavaScript 상호작용 패턴에 대한 아키텍처적 결정에서 비롯되므로, 개발 과정 초기에 이를 해결하는 것이 출시 후에 수정하는 것보다 훨씬 비용이 적게 든다.

Accsible의 오버레이 SDK는 구성 가능한 포커스 관리 향상을 제공함으로써 조직이 준수에 이르는 여정을 지원하지만, 오버레이 솔루션은 애플리케이션 자체 코드베이스에서 올바른 시맨틱 HTML 구조와 책임 있는 포커스 관리와 함께 사용할 때 가장 효과적이라는 점을 유념해야 한다. 2025/10번 대통령령에 대한 지속 가능하고 감사 가능한 준수를 달성하려면, 기본 제품이 올바른 개발 관행을 통해 2.4.3을 충족해야 한다.