[접근성연구·키보드] 우리 화면은 키보드로 완주되는가

키보드 점검 관점

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

들어가며

앞선 두 편에서 우리는 키보드 접근의 기준(047)과, 그 기준이 깨지는 현장의 모습(048)을 살펴봤다. 키보드로 닿고, 누르고, 빠져나올 수 있어야 한다는 원칙. 그리고 그 어느 하나라도 무너지면 마우스를 쓸 수 없는 사용자에게는 화면 전체가 멈춰 선다는 사실.

이번 편은 그 두 편을 바탕으로, 우리가 만든(혹은 운영하는) 화면을 직접 점검하는 방법을 정리한다. 거창한 도구나 전문 지식이 먼저 필요한 것은 아니다. 키보드 점검의 출발점은 의외로 단순하다. 마우스에서 손을 떼는 것.

마우스를 옆으로 밀어 놓고, Tab 키 하나로 화면을 처음부터 끝까지 다뤄 보는 것. 이 작은 동작 하나가, 평소에는 보이지 않던 문제들을 드러낸다. 닿지 않는 버튼, 빠져나올 수 없는 자리, 어디에 있는지 알 수 없는 초점. 마우스가 있을 때는 결코 만나지 않던 장면들이다.

이 글은 그 점검을 어떤 순서로, 무엇을 보며 진행할 수 있는지 하나의 관점으로 제안한다. 자가 진단은 진단의 끝이 아니라 시작이라는 점을 먼저 밝혀 둔다. 그러나 그 시작조차 하지 않은 화면이 많다는 것이, 이 점검이 의미를 갖는 이유다.

1. 점검의 첫 동작 — 마우스를 내려놓는다

1-1. 왜 마우스를 치워야 하는가

키보드 접근성을 점검하겠다고 마음먹어도, 마우스가 손 옆에 있으면 우리는 무의식적으로 마우스를 쓴다. 버튼이 잘 안 눌리면 클릭해 버리고, 초점이 어디 있는지 안 보이면 그냥 마우스로 짚는다. 그렇게 하면 문제가 보이지 않는다. 마우스가 모든 빈틈을 메워 버리기 때문이다.

그래서 키보드 점검의 첫 규칙은 물리적이다. 마우스를 손이 닿지 않는 곳으로 치우거나, 마우스에서 손을 완전히 떼는 것. 트랙패드를 쓴다면 노트북에서 한 뼘 거리를 둔다. 이 작은 강제가, 마우스 없이 살아가는 사용자의 조건을 잠시 빌려 보는 출발점이 된다.

1-2. 점검에 쓰이는 최소한의 키

마우스를 치웠다면, 이제 화면은 몇 개의 키로 다뤄진다. 점검에 자주 쓰이는 키를 미리 익혀 두면 흐름이 끊기지 않는다.

Tab — 다음 조작 요소로 초점 이동
Shift + Tab — 이전 요소로 되돌아가기
Enter / Space — 버튼·링크 누르기 (요소에 따라 다름)
방향키(↑↓←→) — 라디오 버튼, 메뉴, 슬라이더 같은 묶음 안에서 이동
Esc — 팝업·레이어 닫기

이 다섯 묶음이면 대부분의 화면을 다뤄 볼 수 있다. 운영체제·브라우저·보조기술마다 동작이 조금씩 다를 수 있으므로, 점검 환경의 기본 동작은 한 번 확인해 두는 편이 안전하다.

다섯 키를 하는 일·자주 막히는 자리와 함께 두면, 점검 중 어디를 살필지가 잡힌다.

키	하는 일	자주 막히는 자리
`Tab` / `Shift+Tab`	요소 사이 초점 이동	직접 만든 버튼·아이콘
`Enter` / `Space`	누르기	클릭만 얹은 `div`·`span`
방향키(↑↓←→)	묶음 안 이동	라디오·메뉴·슬라이더
`Esc`	팝업·레이어 닫기	닫기 키 없는 모달

(인용) 위 키별 동작은 공개 접근성 안내에서 알려진 일반 동작을 옮긴 것이며, 운영체제·브라우저·보조기술에 따라 다를 수 있어 환경의 기본 동작 확인이 안전하다. 이 표는 공식 해석이 아니라 점검을 돕기 위한 정리다.

2. 무엇을 보며 완주하는가 — 세 가지 질문

마우스를 치우고 Tab을 누르기 시작했다면, 화면을 따라가며 던질 질문은 세 가지다. 이 세 질문은 047편에서 정리한 키보드 접근의 세 조건(닿기·누르기·빠져나오기)과 그대로 맞닿는다.

2-1. 닿는가 — 모든 조작 요소에 초점이 가는가

Tab을 반복해 누르며 화면을 처음부터 끝까지 훑는다. 이때 보는 것은 초점이 모든 조작 요소를 빠짐없이 지나가는가이다. 메뉴, 검색창, 버튼, 링크, 입력칸, 체크박스, 그리고 페이지 곳곳의 아이콘 버튼까지.

마우스로는 눌리는데 Tab으로는 초점이 가지 않는 요소가 있다면, 그 요소는 키보드 사용자에게 존재하지 않는 것과 같다(048편의 '닿지 않는 버튼'). 특히 <div>나 <span>에 클릭 동작만 얹은 요소, 이미지를 클릭 영역으로 쓴 메뉴 등이 자주 누락된다. 점검 중에는 "이 화면에서 마우스로 누를 수 있는 모든 곳에 Tab으로도 닿는가"를 거듭 확인한다.

2-2. 보이는가 — 지금 초점이 어디 있는지 알 수 있는가

Tab을 눌렀을 때 초점이 어디로 갔는지 눈으로 보이는가. 이것은 047·038편에서 다룬 초점 표시(focus indicator)의 문제다. 초점은 갔는데 그 자리에 아무 테두리도, 강조도 보이지 않는다면, 사용자는 자신이 지금 화면의 어디에 있는지 알 수 없다.

점검 중에 Tab을 눌렀는데 "어, 초점이 어디 갔지?" 하고 화면을 뒤지게 되는 순간이 있다면, 그 자리가 바로 초점 표시가 약하거나 사라진 곳이다. WCAG 2.4.7 Focus Visible는 초점이 보이도록 할 것을 다루며, 2.4.11 Focus Appearance(2.2에서 추가)는 초점 표시의 크기·대비를 더 구체적으로 다룬다 — 다만 버전과 등급에 따라 적용 범위가 다르므로 원문 확인이 안전하다.

2-3. 빠져나오는가 — 갇히는 자리는 없는가

화면 곳곳에서 Tab으로 들어간 자리에서 다시 빠져나올 수 있는가. 이것은 048편의 키보드 트랩, WCAG 2.1.2 No Keyboard Trap이 다루는 문제다. 특히 점검해 볼 자리는 정해져 있다.

팝업·모달이 떴을 때 Esc 또는 닫기 버튼으로 빠져나올 수 있는가
날짜 선택기, 자동완성 목록 안에 들어갔을 때 다시 나올 수 있는가
외부 위젯(지도, 영상, 채팅 등)에 초점이 들어갔을 때 그 안에 갇히지 않는가

한 자리에서 Tab을 아무리 눌러도 같은 곳만 맴돈다면, 거기가 트랩이다. 점검자는 그 화면을 그 지점에서 더 진행할 수 없으므로, 키보드 사용자도 마찬가지라는 뜻이 된다.

세 질문을, 무엇을 보는지·어긋나면 무슨 일이 생기는지와 함께 두면 완주 점검의 축이 잡힌다.

질문	무엇을 보나	어긋나면
닿는가	모든 조작 요소에 초점이 가나	버튼이 없는 것과 같음
보이는가	지금 초점이 어디인지 보이나	자기 위치를 모름
빠져나오는가	들어간 자리에서 나올 수 있나	그 자리에 갇힘

(관점) 위 세 질문은 키보드 완주를 점검할 때 들고 갈 만한 축을 정리한 것이며, 표준 절차가 아니다. 화면의 성격에 따라 더 살펴야 할 질문이 있을 수 있다.

3. 순서대로 점검하기 — 화면을 끝까지 다뤄 보는 동선

세 질문을 들고, 이제 실제 화면을 완주해 본다. 한 페이지를 정해 처음부터 끝까지 다뤄 보는 흐름을 정리하면 다음과 같다.

3-1. 진입과 초기 초점

페이지를 열고 가장 먼저 Tab을 한 번 누른다. 초점이 어디로 가는가. 많은 화면이 첫 Tab에서 '본문 바로가기(skip link)'를 노출하거나, 상단 메뉴의 첫 항목으로 간다. 만약 첫 Tab에서 초점이 보이지 않거나 엉뚱한 곳으로 튄다면, 그 자체가 점검 항목이 된다.

반복되는 상단 메뉴를 건너뛰고 본문으로 바로 갈 수 있는 길(skip navigation)이 있는지도 이 단계에서 확인한다. 이것은 매번 같은 메뉴를 Tab으로 다 지나가야 하는 사용자의 수고와 직접 연결된다.

3-2. 순서가 자연스러운가

Tab을 계속 누르며, 초점이 이동하는 순서가 화면에서 보이는 순서(대개 위→아래, 왼→오른쪽)와 어긋나지 않는가를 본다. WCAG 2.4.3 Focus Order가 다루는 지점이다. 화면 위쪽 메뉴를 지나다 갑자기 푸터로 튀고, 다시 본문 중간으로 돌아오는 식이라면, 시각적으로 화면을 보지 못하는 사용자는 페이지 구조를 머릿속에 그리기 어려워진다.

3-3. 주요 동선을 직접 끝까지 수행

마지막으로, 그 화면에서 사용자가 실제로 하려는 일을 키보드만으로 끝까지 수행해 본다. 검색이라면 검색어 입력 → 검색 실행 → 결과 확인까지. 신청서라면 입력 → 동의 → 제출까지. 048편에서 보았듯, 다른 곳은 멀쩡한데 마지막 제출 버튼 하나에 닿지 못해 절차가 통째로 막히는 경우가 적지 않다. 그래서 점검은 '닿는다'에서 멈추지 않고 '완주한다'까지 가야 한다.

완주 동선을 단계별로 모으면, 어디서 무엇이 자주 드러나는지가 보인다.

완주 단계	하는 일	자주 드러나는 것
진입·초기 초점	첫 `Tab` 한 번	본문 바로가기 유무·엉뚱한 초점
순서 따라가기	계속 `Tab`	시각 순서와 어긋난 초점 이동
주요 동선 완주	검색·신청을 끝까지	마지막 제출에서 막힘

(관찰) 위 동선은 키보드 완주를 따라갈 때 단계마다 드러나는 패턴을 정리한 것이며, 특정 사이트를 가리키지 않는다. 화면 구조에 따라 단계의 경계는 달라질 수 있다.

4. 자가 점검의 한계 — 어디까지 믿을 수 있는가

4-1. 점검자는 길을 알고 있다

자가 점검에는 구조적 한계가 있다. 점검하는 사람은 그 화면을 만들었거나, 적어도 어디에 무엇이 있는지 이미 알고 있다. 그래서 초점이 잠깐 사라져도 "여기 어디쯤이겠지" 하고 짐작으로 넘어간다. 처음 방문한 사용자, 화면을 볼 수 없는 사용자에게는 그 짐작이 없다. 점검 결과를 읽을 때는 이 차이를 늘 염두에 둬야 한다.

4-2. 환경에 따라 결과가 달라진다

키보드 동작은 브라우저, 운영체제, 보조기술(스크린리더 등)의 조합에 따라 달라질 수 있다. 한 환경에서 잘 되던 것이 다른 환경에서는 트랩이 되기도 한다. 그래서 한 환경의 점검 결과를 모든 환경의 결론으로 단정하기는 어렵다. 가능하면 대표적인 환경 몇 가지에서 교차로 확인하는 편이 안전하다.

4-3. 자동 도구와 사람 점검은 역할이 다르다

초점 이동 가능 여부, 일부 ARIA 속성 같은 항목은 자동 점검 도구가 빠르게 잡아낸다. 그러나 "초점 순서가 사용자에게 자연스러운가", "이 트랩이 실제로 절차를 막는가" 같은 판단은 결국 사람이 직접 다뤄 봐야 드러난다. 자동 도구로 1차 거르고, 사람이 키보드로 완주하며 확인하는 두 단계를 함께 두는 접근이 흔히 권장된다.

5. 점검을 기록으로 남기는 일

5-1. 막힌 자리를 구체적으로 적는다

점검은 "키보드로 안 됨"이라는 한 줄로 끝나면 고치기 어렵다. 어느 페이지의, 어느 요소에서, 무엇이(닿지 않음 / 초점 안 보임 / 빠져나올 수 없음) 일어났는지를 구체적으로 적는 편이 다음 단계로 이어진다. 048편에서 본 세 증상의 어휘 — 닿지 않는 버튼, 갇히는 자리, 사라지는 초점 — 가 그대로 기록의 항목이 될 수 있다.

5-2. 우선순위를 함께 본다

모든 문제가 같은 무게는 아니다. 주요 동선(검색·신청·로그인)을 막는 트랩은, 잘 쓰지 않는 페이지의 작은 누락보다 먼저 다뤄질 만하다. 다만 무엇이 '주요 동선'인지는 화면마다 다르므로, 사용자가 실제로 무엇을 하러 오는 화면인지를 함께 보는 것이 판단의 기준이 된다.

5-3. 가능한 반론과 우리가 인정하는 한계

키보드 점검을 사람이 직접 한다는 방식에는 여러 반론이 있을 수 있다. 우리는 그 지적을 부정하지 않고, 한계를 먼저 적어 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
점검자가 길을 알아서 막힘을 못 느낀다	익숙한 사람은 우회로를 무의식적으로 쓴다	처음 오는 사람처럼 동선을 따라가 본다
OS·브라우저마다 동작이 다르다	한 환경의 결과를 전부로 보기 어렵다	둘 이상 환경에서 같은 동선을 다시 본다
'완주'의 기준이 사람마다 다르다	어디까지가 주요 동선인지 합의가 필요하다	화면의 실제 목적을 기준으로 범위를 정한다

(관점) 위 반론은 점검 방식의 약점을 정리한 것으로, 특정 기관의 평가가 아니다. 한계를 먼저 인정하는 편이 점검 결과를 과신하지 않게 한다.

5-4. ViewCheck는 어디까지 보는가 — 사람과 도구의 분담

자동 점검은 키보드 접근의 일부 신호를 빠르게 훑을 수 있지만, '끝까지 완주되는가'는 결국 사람이 동선을 밟아 봐야 드러난다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
초점 도달	`tabindex`·상호작용 요소 존재 여부	실제로 모든 조작에 초점이 닿는지
초점 표시	포커스 스타일 선언 유무	화면에서 지금 위치가 보이는지
트랩 여부	모달·레이어 구조 신호	들어간 자리에서 빠져나와지는지

(관점) 표의 구분은 도구와 사람의 역할 차이를 정리한 것으로, 특정 제품의 성능 수치가 아니다. 자동 점검 결과는 사람 점검을 줄이는 근거가 아니라, 어디를 사람이 더 봐야 하는지 가리키는 출발점에 가깝다.

한 장 요약

점검 단계	무엇을 하는가	무엇을 보는가
0. 준비	마우스를 손이 닿지 않게 치운다	Tab·Shift+Tab·Enter·Space·방향키·Esc
1. 닿기	Tab으로 화면을 처음부터 끝까지 훑는다	모든 조작 요소에 초점이 가는가
2. 보이기	Tab을 누를 때마다 초점 위치를 확인	지금 초점이 어디 있는지 보이는가
3. 빠져나오기	팝업·위젯·선택기 안에서 나와 본다	갇히는 자리는 없는가 (Esc·닫기)
4. 순서	초점 이동 순서를 화면 순서와 비교	시각 순서와 어긋나지 않는가
5. 완주	주요 동선을 키보드만으로 끝까지	검색·신청·제출이 끝까지 되는가

※ 위 표는 점검의 한 흐름을 정리한 관점입니다. 적용 기준·등급은 WCAG/KWCAG 원문과 운영 환경에 따라 달라질 수 있습니다.

맺으며

키보드 점검은 특별한 자격이나 값비싼 도구로 시작되지 않는다. 마우스를 옆으로 밀어 놓고, Tab 키 하나로 화면을 끝까지 다뤄 보는 것. 그 단순한 동작이, 마우스 없이 살아가는 사용자가 매일 겪는 길을 잠시 빌려 보게 한다.

그 길을 직접 걸어 보면, 평소에는 보이지 않던 자리들이 드러난다. 닿지 않는 버튼, 보이지 않는 초점, 빠져나올 수 없는 자리. 이 세 가지를 찾아 기록하는 것만으로도, 화면은 '키보드로 완주되는가'라는 질문에 처음으로 답을 갖게 된다.

자가 점검은 진단의 끝이 아니라 시작이다. 그러나 그 시작을 한 화면과 하지 않은 화면 사이에는, 사용자가 실제로 체감하는 큰 차이가 놓인다. 우리가 만든 화면을 한 번이라도 키보드만으로 끝까지 다뤄 보는 일 — 키보드 접근성은 거기서부터 비로소 점검의 대상이 된다.

다음 편 예고 (050): 〈한국어가 벽이 될 때〉 — 다국어·외국인 흐름 연구. 한국어에 익숙하지 않은 사용자에게 공공 화면이 어떤 벽이 되는지, 그리고 디지털 포용의 관점에서 무엇을 살필 수 있는지를 다룬다.

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

W3C, 「Web Content Accessibility Guidelines (WCAG) 2.1」 — 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 2.4.7 Focus Visible
W3C, 「WCAG 2.2」 — 2.4.11 Focus Appearance (버전·등급별 적용 범위 상이)
한국지능정보사회진흥원(NIA), 「한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2」 — 운용 가능(키보드 접근성) 관련 항목
W3C WAI, 「Keyboard Accessibility」 해설 자료

※ 위 자료의 항목 번호·세부 기준은 개정·버전에 따라 달라질 수 있으며, 본문의 정리는 연구 관점의 요약입니다. 정확한 적용 기준은 각 출처의 원문 확인이 안전합니다.