[접근성연구·키보드] Tab으로 닿지 않는 버튼

키보드 함정 관찰

〈디지털 접근성 연구 048〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞 편(047)에서 마우스 없이 화면을 끝까지 다룰 수 있어야 한다는 것을, 그리고 키보드 접근이 접근성의 기초라는 점을 기준의 배경과 함께 따라가 보았다. 이번 편은 시선을 키보드 사용자에게로 옮겨, 키보드가 막히는 가장 답답한 경우를 관찰한다. 닿지 않는 버튼, 그리고 닿았다가 빠져나오지 못하는 자리 — 흔히 '키보드 함정' 또는 '키보드 트랩'으로 불리는 문제다.

키보드 사용자에게 Tab은 화면을 걷는 발걸음이다. 한 걸음씩 옮기며 요소에 닿는다. 그런데 어떤 버튼은 아무리 Tab을 눌러도 닿지 않는다. 화면에는 분명 보이는데, 발걸음이 그 앞을 그냥 지나친다. 또 어떤 자리는 한 번 들어가면 빠져나올 수 없다. 모달이 열렸는데 닫을 방법이 없고, 초점이 같은 자리를 무한히 맴돈다. 닿지 않는 버튼과 빠져나올 수 없는 자리는 방향이 반대지만, 둘 다 사용자를 그 자리에 묶어 둔다. 이 글은 그 묶임을 관찰의 눈으로 따라가, 키보드 함정이 어디서 어떻게 사용자를 가두는지를 들여다본다.

1. 닿지 않는 버튼

1-1. 보이는데 닿지 않는다

키보드 함정의 한 모습은 '보이는데 닿지 않는' 버튼이다. 화면에는 또렷이 보이는 버튼인데, Tab을 아무리 눌러도 초점이 그 버튼에 가지 않는다. 발걸음이 그 앞을 지나쳐 다음 요소로 건너뛴다. 마우스 사용자에게는 그냥 누르면 되는 버튼이지만, 키보드 사용자에게는 닿을 수 없는, 그래서 누를 수 없는 버튼이다.

이런 일은 흔히 표준이 아닌 방식으로 만든 요소에서 생긴다. 표준적인 링크·버튼은 키보드로 닿는 능력이 기본으로 따라오지만, 다른 요소를 버튼처럼 보이게 꾸민 경우에는 그 능력을 따로 마련해 주지 않으면 키보드 초점이 가지 않는다. 보이는 것과 닿는 것이 어긋난 자리다.

1-2. 그 버튼이 마지막 단계라면

닿지 않는 버튼이 화면의 핵심 단계라면 문제는 더 무겁다. 신청서를 다 채웠는데 '제출' 버튼에 키보드로 닿지 않으면, 사용자는 모든 칸을 채우고도 일을 끝내지 못한다. 동의 체크박스에 닿지 않으면 다음 단계로 넘어가지 못한다. 닿지 않는 버튼이 흐름의 마지막에 있을 때, 사용자는 거의 다 온 길 앞에서 멈춰 선다.

닿지 않는 버튼이 어디에 있느냐에 따라 사용자가 잃는 것이 달라진다.

닿지 않는 자리	사용자에게는	잃는 것
부가 기능 버튼	그 기능만 못 씀	한 가지 편의
다음 단계 버튼	흐름이 끊김	그 뒤 전체
제출·동의 버튼	거의 다 와서 멈춤	일을 끝내지 못함

(관찰) 위 구분은 닿지 않는 버튼이 흐름의 어디에 놓이는가에 따른 패턴을 정리한 것이며, 특정 사이트를 가리키지 않는다. 같은 결함도 버튼의 위치에 따라 무게가 달라진다.

2. 빠져나올 수 없는 자리

2-1. 들어갔는데 나올 수 없다

키보드 함정의 또 다른 모습은 '들어갔는데 나올 수 없는' 자리다. 어떤 요소에 초점이 들어갔는데, Tab을 눌러도 그 안을 맴돌 뿐 빠져나오지 못한다. 모달 창이 열렸는데 키보드로 닫을 방법이 없고, 위젯 안에서 초점이 무한히 순환한다. 사용자는 그 자리에 갇혀, 화면의 다른 부분으로 나아가지 못한다.

마우스 사용자라면 모달 바깥을 클릭하거나 닫기 버튼을 눌러 빠져나오면 된다. 그러나 키보드 사용자에게 빠져나올 키 동작이 마련되어 있지 않으면, 그는 그 안에 머문다. 이 갇힘은 단순한 불편을 넘어, 화면 전체의 사용을 중단시킨다. 047편에서 짚은 '갇히지 않아야 한다'는 기준(2.1.2로 알려진 항목)이 다루는 바로 그 문제다.

2-2. 갇힘이 더 치명적인 이유

닿지 않는 버튼은 그 버튼 하나를 못 쓰는 데서 그칠 수 있다. 그러나 빠져나올 수 없는 자리에 갇히면, 사용자는 그 자리 이후의 모든 것을 잃는다. 갇힌 모달 뒤에 있는 본문에도, 다른 메뉴에도 닿을 수 없다. 한 자리의 함정이 화면 전체를 막는 셈이다. 그래서 갇힘은 키보드 함정 중에서도 특히 치명적인 형태로 여겨진다.

방향이 반대인 두 함정을 나란히 두면, 무엇을 막고 어디까지 잃는지가 갈린다.

함정	무엇이 막히나	잃는 범위
닿지 않는 버튼	그 버튼에 초점이 안 감	그 버튼 하나
빠져나올 수 없는 자리	들어간 뒤 못 나옴	그 자리 이후 전체

(관점) 위 비교는 두 함정의 무게 차이를 보이기 위한 정리이며, 어느 하나가 늘 더 가볍다는 단정은 아니다. 닿지 않는 버튼이 제출 단계에 있으면 갇힘 못지않게 치명적일 수 있다.

3. 관찰 — 함정이 생기는 결

3-1. 마우스만 가정한 설계

키보드 함정의 바탕에는 대체로 '마우스만 가정한 설계'가 있다. 만든 사람은 마우스로 화면을 만들고 마우스로 점검한다. 마우스로는 어떤 버튼이든 클릭으로 닿고, 모달은 바깥을 클릭해 닫으면 된다. 그 익숙함 속에서 키보드만으로는 닿지 않거나 빠져나오지 못하는 자리가 생겨도, 마우스로 보면 아무 문제가 없으니 발견되지 않는다. 함정은 악의가 아니라, 키보드를 가정하지 않은 익숙함에서 생긴다.

3-2. 직접 만든 요소에 모이는 함정

키보드 함정은 표준 요소보다 직접 만든 요소에 모인다. 직접 만든 드롭다운, 모달, 탭, 슬라이더는 키보드로 닿고 누르고 빠져나오는 동작을 일일이 마련해 주어야 하는데, 그 중 하나라도 빠지면 함정이 된다. 화려하고 독특한 요소일수록 이 부담이 크다. 표준 요소로 될 일을 굳이 새로 만든 자리에서 함정이 자주 발견되는 것은 그래서다.

3-3. 발견되지 않는 함정

키보드 함정의 가장 큰 특징은 '발견되지 않는다'는 점이다. 마우스로 점검하면 보이지 않고, 자동 점검 도구도 모든 함정을 잡아내지는 못한다. 특히 '빠져나올 수 없는' 자리는 실제로 키보드로 들어가 빠져나와 보지 않으면 드러나지 않는 경우가 많다. 발견되지 않는 결함은 고쳐지지 않은 채 사용자에게 그대로 닿는다.

함정이 생기는 결을, 관련 기준의 취지와 나란히 두면 관찰이 기준과 잇닿아 있음이 보인다.

관찰한 결	관련 기준 취지(알려진 항목)
닿지 않는 버튼	키보드(2.1.1로 알려진 항목)
빠져나올 수 없는 자리	키보드 트랩 없음(2.1.2로 알려진 항목)
직접 만든 요소의 키보드 동작	이름·역할·값 전달(4.1.2로 알려진 항목)

(인용) 위 기준 취지는 WCAG에서 알려진 항목을 관찰의 결과 잇기 위해 옮긴 것이며, 번호·등급·문구는 판본에 따라 다를 수 있어 원문 확인이 안전하다. 이 표는 공식 해석이 아니라 관찰을 기준에 비추기 위한 정리다.

4. 관찰이 남기는 것

4-1. 한 번 갇혀 보기

키보드 함정을 이해하는 가장 빠른 길은, 만든 사람이 한 번 갇혀 보는 것이다. 마우스를 내려놓고 키보드만으로 화면을 다니다 보면, 어디서 발걸음이 막히는지, 어디서 빠져나올 수 없는지가 몸으로 느껴진다. 닿지 않는 버튼 앞에서 Tab을 거듭 누르는 답답함, 모달에 갇혀 화면 전체를 잃는 막막함을 직접 겪고 나면, 키보드 함정은 추상적인 규칙이 아니라 구체적인 막힘이 된다.

4-2. 관찰에서 점검으로

이 편은 키보드 함정이 어디서 어떻게 사용자를 가두는지를 관찰했다. 관찰이 보여 준 막힘을 실제 화면에서 어떻게 찾아낼지는 다음 편의 몫이다. 관찰이 '왜 문제가 되는가'를 보여 준다면, 점검은 '우리 화면의 어디가 그러한가'를 묻는다. 마우스를 내려놓고 화면을 완주해 보는 단순한 동작이, 두 시선을 잇는 다리가 된다.

4-3. 기준은 갇힌 사람 편이다

WCAG의 키보드 트랩 관련 항목은 갇힌 사용자 편에 서 있다. 들어갈 수 있다면 나올 수도 있어야 한다는 그 요구는, 화면의 어느 자리도 사용자를 묶어 두지 않게 하려는 장치다. 항목의 정확한 번호·등급은 기준 원문에서 확인하되, 그 항목이 누구를 위한 것인지를 떠올리면, 키보드 함정을 줄이는 일은 규칙 준수가 아니라 갇힌 사람을 풀어 주는 일이 된다.

5. 반론·한계와 ViewCheck 관점

5-1. 가능한 반론과 우리의 한계

키보드 함정을 관찰하는 일에도 다른 시각이 있을 수 있다. 몇 가지 반론을 미리 적고, 우리의 한계도 함께 밝혀 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
일부 위젯은 의도적으로 초점을 가둔다	모든 가둠이 결함은 아니다	빠져나올 길이 있는지를 함께 봄
브라우저·보조기술마다 동작이 다르다	한 환경의 결과로 단정하기 어렵다	대표 환경으로 보되 일반화 자제
점검자가 모든 함정을 다 밟지 못한다	한 번 완주로 빈틈이 남는다	핵심 흐름을 거듭 들어갔다 나옴

5-2. ViewCheck의 관점 — 사람과 도구의 분담

키보드 함정은 '구조상 초점 가능한가'와 '실제로 들어갔다 나올 수 있는가'가 다르다. 자동 점검이 거르는 자리와 사람이 봐야 하는 자리를 나누어 둔다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
닿지 않는 버튼	초점 가능 속성·tabindex	실제로 `Tab`이 닿는가
모달·위젯	닫기 요소·초점 관리 속성	키보드로 정말 나올 수 있는가
직접 만든 요소	역할·키 핸들러의 존재	누르고 빠져나오는 동작이 되나

(관점) 위 분담은 점검을 돕기 위한 정리이며, 자동/사람의 경계는 도구와 화면에 따라 달라질 수 있다. ViewCheck는 초점 가능 여부 등을 거르는 데 쓰일 수 있으나, 함정에 들어갔다 빠져나올 수 있는지에 대한 판단은 사람의 몫으로 남는다.

한 장 요약

구분	핵심 내용
닿지 않는 버튼	보이는데 `Tab`으로 초점이 가지 않아 누를 수 없음
빠져나올 수 없는 자리	들어간 뒤 키보드로 나오지 못해 갇힘 (2.1.2 관련)
어느 쪽이 치명적	갇힘 — 그 자리 이후 화면 전체를 잃음
함정의 결	마우스만 가정한 설계, 직접 만든 요소에 집중
왜 안 보이나	마우스 점검·자동 도구로는 발견되지 않는 경우가 많음
발견 방법	마우스를 내려놓고 키보드로 들어갔다 나와 보기

맺으며

키보드 함정은 화면 위의 보이지 않는 벽이다. 닿지 않는 버튼 앞에서 사용자는 멈추고, 빠져나올 수 없는 자리에서 사용자는 갇힌다. 마우스로 보면 멀쩡한 그 벽은, 만든 사람이 한 번 키보드로 갇혀 보지 않으면 드러나지 않는다. 들어갈 수 있다면 나올 수 있어야 한다는 단순한 원칙이, 그 벽을 허무는 출발점이다.

이 글은 키보드 함정이 어떻게 사용자를 가두는지를 관찰의 눈으로 따라가 보았다. 다음 편에서는 시선을 자신의 화면으로 돌린다. 우리 화면이 키보드로 완주되는지를 어떻게 스스로 점검해 볼 수 있는지를 정리하며, 키보드 분야를 마무리한다.

다음 편 예고 (049): 〈우리 화면은 키보드로 완주되는가 / 키보드 점검 관점〉 — 마우스를 내려놓고 Tab만으로 화면을 끝까지 다뤄 보며, 닿지 않는 버튼과 갇히는 자리를 찾아내는 점검의 동선을 정리한다.

참고한 공개 자료(출처):

WCAG(Web Content Accessibility Guidelines) — 키보드(2.1.1) · 키보드 트랩 없음(2.1.2) 관련 항목 및 해설
W3C WAI(Web Accessibility Initiative) — 키보드 함정·초점 이동 해설 자료
KWCAG(한국형 웹 콘텐츠 접근성 지침) — 키보드 사용 보장 관련 항목
행정안전부 등 공공기관 웹 접근성 안내 자료

※ 위 자료의 항목 번호·등급·세부 문구는 판본에 따라 달라질 수 있으므로, 실제 적용 시에는 각 기준의 원문을 직접 확인하는 것이 안전합니다. 이 글은 특정 기준의 공식 해석이 아니라 하나의 연구 관점입니다.