키보드 네비게이션 완전 가이드 — Tab, Arrow, Esc 패턴
접근성 시리즈
(5편)마우스 없이 웹사이트를 써본 적 있어요?
한번 해보세요. 키보드만으로 로그인하고, 메뉴를 열고, 폼을 제출해보면 — 생각보다 많은 사이트가 막혀요. 버튼에 포커스가 안 가거나, 모달이 열렸는데 빠져나올 수가 없거나, 드롭다운 메뉴를 화살표로 탐색할 수 없거나.
키보드 네비게이션은 접근성의 기본 중의 기본이에요. 오늘은 Tab, Arrow, Esc, Enter 각각의 역할과 실무 패턴을 정리해볼게요.
왜 키보드 네비게이션인가
키보드 사용자는 누구?
"시각장애인만 키보드를 쓴다"고 생각하기 쉬운데, 실제로는 훨씬 다양해요.
| 사용자 유형 | 이유 |
|---|---|
| 시각장애인 | 스크린 리더 + 키보드 조합 |
| 운동장애 | 마우스 조작이 어려움 (스위치, 헤드 포인터 등) |
| 파워 유저 | 키보드가 빠르니까 (개발자, 디자이너) |
| 일시적 부상 | 손목 골절, 마우스 고장 등 |
| 고령 사용자 | 미세한 마우스 조작이 어려움 |
KWCAG 2.2 지침 2.1.1에서도 "모든 기능은 키보드로 사용할 수 있어야 한다"를 명시하고 있어요.
키보드 네비게이션의 4가지 핵심 키
이 4가지만 제대로 구현하면 키보드 접근성의 80%는 해결돼요.
Tab 네비게이션 — 순서가 곧 UX
tabIndex의 3가지 값
tabIndex 양수값은 쓰면 안 돼요. 양수값을 쓰면 Tab 순서가 DOM 순서와 달라지면서 유지보수가 불가능해져요. 0 또는 -1만 사용하세요.
Tab 순서 = 시각적 순서
CSS의 order, float, position: absolute 등으로 시각적 순서를 바꿀 때 Tab 순서도 반드시 확인해야 해요.
포커스 가시성 — 보여야 누를 수 있다
outline: none은 접근성의 공공의 적이에요. 디자이너가 "포커스 링 안 예뻐요" 하면, outline: none 대신 :focus-visible로 예쁘게 만들어주세요.
HANUI 컴포넌트는 기본으로 :focus-visible 스타일이 적용되어 있어요:
Arrow 키 패턴 — 그룹 내부 탐색
Roving tabIndex 패턴
Tab으로는 그룹 사이를 이동하고, Arrow로는 그룹 안을 탐색하는 패턴이에요. WAI-ARIA에서 가장 많이 쓰이는 패턴이에요.
핵심은 활성 항목만 tabIndex={0}, 나머지는 tabIndex={-1}이에요. Tab으로 그룹에 들어오면 활성 항목에 포커스가 가고, Arrow로 이동하면서 tabIndex를 옮겨주는 거예요.
Arrow 키를 쓰는 WAI-ARIA 패턴들
| 컴포넌트 | Arrow 방향 | 순환 여부 |
|---|---|---|
| Tabs | ← → | 순환 |
| Menu | ↑ ↓ | 순환 |
| Radio Group | ← → 또는 ↑ ↓ | 순환 |
| Tree | ↑ ↓ (이동) + ← → (접기/펼치기) | 비순환 |
| Grid / Table | ↑ ↓ ← → | 비순환 |
| Combobox 목록 | ↑ ↓ | 비순환 |
HANUI에서는 이 패턴들을 각 컴포넌트에 내장해뒀어요:
Esc 패턴 — 탈출은 반드시 보장
모달의 포커스 트랩
모달이 열리면 포커스가 모달 안에 갇혀야 해요. 그리고 Esc로 탈출할 수 있어야 해요.
HANUI의 Modal은 이걸 전부 자동으로 처리해요:
Esc 키의 계층적 닫기
중첩된 UI가 있을 때 Esc는 가장 안쪽부터 닫아야 해요.
Enter/Space — 활성화 패턴
버튼과 링크의 차이
<button>을 쓰면 키보드 지원이 공짜예요. <div onClick>은 접근성 지옥의 시작이에요.
체크박스, 스위치
실무 체크리스트
프로젝트에서 키보드 접근성을 점검할 때 이 체크리스트를 써보세요.
기본 점검
컴포넌트별 점검
Skip Navigation
페이지마다 반복되는 헤더/메뉴를 건너뛸 수 있어야 해요:
Tab을 눌렀을 때 첫 번째로 "본문으로 건너뛰기" 링크가 나타나요. 매번 메뉴 10개를 Tab으로 지나가지 않아도 되는 거예요.
테스트 방법
키보드 접근성을 테스트하는 가장 좋은 방법은 마우스를 치우고 직접 써보는 것이에요.
자동화 도구로는 전체 키보드 문제의 일부만 잡아요. 직접 써봐야 진짜 문제를 발견할 수 있어요.
마무리
키보드 네비게이션은 접근성의 기반이에요. Tab, Arrow, Esc, Enter — 이 4가지 키의 역할만 확실히 구현하면 대부분의 키보드 사용자가 불편 없이 쓸 수 있어요.
디자인 시스템에서 이걸 한 번 잘 만들어두면, 매번 컴포넌트를 만들 때마다 키보드 처리를 고민할 필요가 없어요. HANUI가 그래서 모든 인터랙티브 컴포넌트에 WAI-ARIA 키보드 패턴을 내장한 거예요.
다음 편에서는 스크린 리더로 직접 앱을 테스트하는 방법을 다뤄볼게요. VoiceOver와 NVDA를 사용해서 실제로 접근성 문제를 찾고 고치는 실전 가이드예요.
관련 링크
시리즈
HANUI
KRDS 기반 React 컴포넌트 라이브러리. 공공 웹 개발을 더 쉽게.