tabindex 양수 지정이 초점 순서를 파괴하는 원리와 복구 순서

웹페이지 퍼블리싱이나 프론트엔드 컴포넌트 개발을 진행하다 보면, 디자인 시안 상의 시각적 배치와 실제 HTML 소스코드의 DOM 순서가 일치하지 않아 키보드 Tab 키를 눌렀을 때 초점이 부자연스럽게 이동하는 난관에 자주 봉착합니다. 이때 초보 개발자나 시간에 쫓기는 실무자가 가장 쉽게 유혹에 빠지는 치명적인 해결책이 바로 tabindex='1', tabindex='2', tabindex='3'과 같은 '양수(Positive) tabindex'를 코드 곳곳에 부여하여 강제로 키보드 이동 순서를 제어하려는 시도입니다. 그러나 양수 tabindex는 단 한 번 부여하는 순간 웹페이지 전체의 자연스러운 초점 흐름을 산산조각 내며, 유지보수가 불가능한 스파게티 포커스 트리를 만들어내는 웹 접근성의 가장 위험한 독약입니다. 이 글에서는 양수 tabindex가 브라우저 포커스 내비게이션 알고리즘을 파괴하는 매커니즘을 상세히 파헤치고, HTML DOM 순서 정렬을 통해 온전한 접근성을 복구하는 실무 프로세스를 제시합니다.

브라우저 포커스 순서 알고리즘과 양수 tabindex의 파괴적 동작

W3C HTML5 및 웹 브라우저의 키보드 초점 내비게이션 명세(Sequential Focus Navigation Order)는 사용자가 Tab 키를 눌렀을 때 다음 요소를 선택하는 순서를 명확하게 2단계로 규정하고 있습니다.

브라우저는 첫 번째 단계로, 문서 전체를 통틀어 tabindex 속성값이 0보다 큰 양수(1, 2, 3...)로 지정된 모든 요소를 가장 먼저 찾아서 숫자 크기 순서대로 순회합니다. 그리고 두 번째 단계로, 양수 요소들의 순회가 모두 끝난 뒤에야 비로소 tabindex='0'이거나 브라우저 기본 포커스 요소(<button>, <a>, <input> 등)들을 HTML DOM 트리에 작성된 물리적 순서대로 순회하기 시작합니다.

이 원리로 인해 웹페이지의 사이드바나 본문 중간에 위치한 특정 버튼에 무심코 tabindex='1'을 부여하는 순간, 사용자가 페이지에 진입하여 맨 처음 Tab 키를 눌렀을 때 사이트 상단의 로고나 메인 메뉴를 건너뛰고 페이지 한가운데로 난데없이 초점이 튀어버리는 기괴한 현상이 발생합니다. 사용자는 자신이 페이지의 어디에 위치해 있는지 완전히 길을 잃게 되며(Disorientation), 뒤이어 추가된 동적 컴포넌트와 번호 충돌을 일으키며 초점 순서는 완전히 수습 불가능한 혼돈에 빠집니다.

tabindex 속성이 허용하는 올바른 3가지 값과 용도

W3C 웹 표준 명세에서 실무 개발자에게 공식적으로 권장하고 허용하는 tabindex의 값은 오직 세 가지뿐입니다.

• 1. tabindex='-1' (프로그래밍적 초점 전용): 키보드 Tab 키 순회 목록에서는 완전히 제외되지만, 자바스크립트의 element.focus() 메서드를 호출했을 때는 정상적으로 초점을 받아올 수 있는 상태를 만듭니다. 모달 팝업이 열렸을 때 모달 컨테이너로 초점을 이동시키거나, SPA 페이지 전환 시 본문 <h1> 제목으로 초점을 보낼 때 필수적으로 사용됩니다.
• 2. tabindex='0' (키보드 순회 목록 편입): 본래 키보드 초점을 받지 못하는 일반 요소(<div role='button'>, 커스텀 위젯 등)를 브라우저의 자연스러운 키보드 Tab 키 순회 순서에 포함시킬 때 사용합니다. 초점 순서는 해당 요소가 DOM 트리 상에 위치한 물리적 순서를 그대로 따릅니다.
• 3. 양수 tabindex (tabindex > 0): 실무에서 '절대 사용 금지(Strictly Forbidden)'로 규정해야 하는 안티패턴입니다. W3C APG 가이드라인에서도 양수 tabindex의 사용을 심각한 안티패턴으로 규정하고 배제를 권고하고 있습니다.

CSS 레이아웃(Flex order, Grid)과 초점 순서의 괴리 해결법

개발자들이 양수 tabindex의 유혹에 빠지는 가장 큰 이유는 CSS의 flex-direction: row-reverse, order 속성, 혹은 CSS Grid의 grid-column/row 좌표 지정을 통해 시각적 순서만 뒤집어 놓았기 때문입니다.

시각적으로는 버튼 A가 왼쪽에 있고 버튼 B가 오른쪽에 있지만, 실제 HTML 코드에서는 버튼 B가 먼저 선언되어 있다면, 키보드 초점은 오른쪽(B)을 먼저 비추고 왼쪽(A)으로 역주행합니다. 이는 WCAG 2.2 성공 기준 2.4.3(Focus Order, Level A)의 명백한 위반입니다.

이 문제의 유일하고 올바른 해결책은 CSS로 순서를 비틀지 말고, 'HTML DOM 소스코드 자체를 시각적 탐색 흐름과 완벽히 동일하게 재배치'하는 것입니다. HTML 구조를 먼저 논리적인 순서로 올바르게 작성한 뒤, CSS는 오직 장식과 간격만을 조정하도록 설계해야 합니다.

양수 tabindex 제거 및 키보드 초점 복구 3단계 실무 가이드

기존 프로젝트에 난립한 양수 tabindex를 걷어내고 완벽한 키보드 접근성을 복구하는 3단계 작업 순서는 다음과 같습니다.

1단계: 전역 코드베이스에서 양수 tabindex 전수 색인 및 제거. 정규표현식(tabindex=['"][1-9][0-9]*['"])을 사용하여 프로젝트 내의 모든 양수 속성을 검색하고, 이를 tabindex='0'으로 바꾸거나 완전히 삭제합니다.

2단계: HTML 문서의 DOM 계층 구조 선형화. 헤더 ➔ 본문 주요 탐색 ➔ 보조 사이드바 ➔ 푸터 순으로 HTML 요소가 논리적인 읽기 순서대로 배치되어 있는지 점검하고 재정렬합니다.

3단계: No-Mouse 키보드 실증 주파 테스트. 마우스 없이 오직 Tab 키만 연속으로 누르며 화면의 초점 링이 좌상단에서 우하단으로 끊김 없이 유기적으로 이동하는지 시각적으로 검증합니다.

브라우저의 Sequential Focus Navigation Start와 양수 tabindex의 전역 오염

HTML 표준 명세에 규정된 Sequential Focus Navigation 알고리즘에 따르면, 브라우저가 Tab 키 입력을 받았을 때 문서를 순회하는 순서는 양수 tabindex 그룹이 먼저 오름차순(1 -> 2 -> 3...)으로 정렬된 후, 기본 대화형 요소 및 tabindex="0" 그룹이 DOM 순서대로 탐색됩니다.

이로 인해 발생하는 치명적인 부작용은 전역 오염(Global Contamination)입니다. 한 개발자가 특정 버튼에 tabindex="1"을 지정하는 순간, 페이지 상단의 메인 로고, 글로벌 내비게이션, 본문 링크 등 tabindex가 지정되지 않은 수백 개의 정상 요소들이 전부 최후순위로 밀려나 버립니다.

• 1단계 탐색: tabindex > 0 요소들을 숫자 오름차순(1 -> 2 -> 3)으로 전역 순회
• 2단계 탐색: 1단계가 모두 끝난 후 tabindex="0" 및 기본 네이티브 대화형 요소를 DOM 트리 순서로 순회
• 절대 금기 원칙: HTML 명세 및 W3C 접근성 지침에서 양수 tabindex(tabindex > 0)의 사용은 전면 금지(Anti-pattern)

Flexbox row-reverse 및 CSS grid order로 인한 시각 순서와 DOM 순서 불일치 해결

현대 웹 개발에서 tabindex 양수 지정만큼이나 빈번하게 초점 순서를 파괴하는 주범은 CSS Flexbox와 Grid의 시각적 재배치 속성입니다.

CSS flex-direction: column-reverse나 order: -1은 화면에 픽셀을 렌더링하는 위치만 바꿀 뿐 DOM 트리 순서는 변경하지 않습니다. 그 결과 마우스 사용자는 맨 위에 보이는 버튼을 보지만, 키보드 Tab 키를 누르면 시각적으로 아래에 있는 버튼으로 초점이 먼저 진입하는 심각한 시각-초점 불일치가 발생합니다.

• DOM 우선주의: 시각적 배치가 바뀌어야 한다면 CSS order 대신 HTML 마크업 순서 자체를 변경할 것
• 키보드 탐색 검증: CSS 레이아웃 변경 후 마우스 없이 Tab 키만으로 위에서 아래, 좌에서 우 순서 일치 여부 확인
• CSS Subgrid 활용: 구조적 마크업을 유지하면서 복잡한 그리드 정렬을 달성하는 현대적 레이아웃 도입