[접근성연구·저시력] 지금 어디에 있는가
마우스를 쓰는 사람에게 "지금 화면의 어디를 만지고 있는가"는 거의 질문이 되지 않는다. 커서가 곧 손끝이기 때문이다. 화살표 모양의 포인터가 버튼 위에 올라가면 색이 살짝 바뀌고, 그 자리를 누르면 그 버튼이 눌린다. 손과 화면 사이의 거리가 거의 0에 가깝다. 그런데 마우스를 쓰지 않는, 혹은 쓸 수 없는 사람이 있다
![[접근성연구·저시력] 지금 어디에 있는가](https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/8mm5yd4s-114693.jpeg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC84bW01eWQ0cy0xMTQ2OTMuanBlZyIsInNjb3BlIjoiZG93bmxvYWQiLCJpYXQiOjE3ODQ0NjU3NjksImV4cCI6MjA5OTgyNTc2OX0.5D0boiQhkNBWzRg7hA0B_MGHXNkFAp7GnrRNGZdWxZs)
키보드 초점 표시 연구
〈디지털 접근성 연구 038〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.
들어가며
마우스를 쓰는 사람에게 "지금 화면의 어디를 만지고 있는가"는 거의 질문이 되지 않는다. 커서가 곧 손끝이기 때문이다. 화살표 모양의 포인터가 버튼 위에 올라가면 색이 살짝 바뀌고, 그 자리를 누르면 그 버튼이 눌린다. 손과 화면 사이의 거리가 거의 0에 가깝다.
그런데 마우스를 쓰지 않는, 혹은 쓸 수 없는 사람이 있다. 손의 떨림 때문에 작은 표적을 정확히 겨누기 어려운 사람, 한 손만 쓰는 사람, 스크린리더와 키보드로 화면을 더듬는 시각장애·저시력 사용자, 그리고 단지 키보드가 더 빠른 사람. 이들은 화면 위를 Tab 키로 이동한다. 한 번 누를 때마다 초점(focus)이 다음 조작 가능한 요소로 건너뛴다. 입력칸에서 다음 입력칸으로, 버튼에서 다음 링크로.
이때 결정적으로 중요한 한 가지가 있다. 지금 초점이 어디에 가 있는지가 화면에 보여야 한다는 것. 보이지 않으면 사용자는 자신이 Enter를 눌렀을 때 무엇이 실행될지 알 수 없다. 보이지 않는 손으로 보이지 않는 버튼을 누르는 셈이다.
이 글은 그 '보이는 초점', 즉 초점 표시(focus indicator)를 하나의 연구 주제로 놓고 살핀다. 초점이란 무엇이고, 왜 그것이 보여야 한다고 이야기되는지, 그리고 공개된 기준들은 이를 어떻게 다루는지를 따라가 본다. 결론을 먼저 내리기보다, 기준의 배경을 이해하는 데 무게를 둔다.
1. 초점이란 무엇인가
1-1. 키보드 초점의 정의
웹 화면에는 사용자가 조작할 수 있는 요소가 있다. 링크, 버튼, 입력칸, 체크박스, 드롭다운 같은 것들이다. 이런 요소들은 하나씩 '초점을 받을 수 있는(focusable)' 상태가 된다. 키보드의 Tab 키를 누르면 초점이 이 요소들 사이를 순서대로 이동한다. 초점을 받은 요소가 바로 지금 사용자가 조작 대상으로 삼고 있는 요소다. 그 상태에서 Enter나 Space를 누르면 그 요소가 작동한다.
마우스 사용자에게 포인터의 위치가 "지금 여기"를 알려 주듯, 키보드 사용자에게는 초점의 위치가 "지금 여기"를 알려 준다. 차이가 있다면, 포인터는 사용자가 직접 움직여 늘 눈으로 좇지만, 초점은 키를 누르는 순간 화면이 알아서 다음 자리로 옮겨 준다는 점이다. 그래서 초점은 그 자리가 어디인지를 스스로 표시해 주어야 사용자가 따라갈 수 있다.
1-2. 표시되지 않으면 생기는 일
초점이 표시되지 않는 상태를 상상해 보자. 사용자는 Tab을 한 번 눌렀다. 초점은 분명 어딘가로 이동했지만 화면에는 아무 변화가 없다. 두 번째, 세 번째 Tab을 눌러도 마찬가지다. 사용자는 지금 자신의 초점이 화면 상단의 메뉴에 있는지, 본문 중간의 링크에 있는지, 하단의 버튼에 있는지 알 길이 없다.
이 상태에서 Enter를 누르는 것은 도박에 가깝다. 운이 좋으면 의도한 버튼이, 운이 나쁘면 엉뚱한 링크가 실행된다. 신청·결제·삭제처럼 되돌리기 어려운 동작 앞에서는 이 불확실성이 그대로 위험이 된다. 초점 표시는 단순한 시각 장식이 아니라, 키보드 사용자가 자신의 행동 결과를 예측하기 위한 최소한의 정보라는 관점이 여기서 나온다.
2. 기준은 초점을 어떻게 다루는가
2-1. '보이는 초점'에 관한 항목
웹 접근성을 다루는 공개 기준에서 초점 표시는 비교적 분명하게 언급되는 주제다. 국제 기준인 WCAG(Web Content Accessibility Guidelines)에는 키보드 초점이 어떤 요소에 가 있을 때 그 초점을 시각적으로 알아볼 수 있어야 한다는 취지의 항목(2.4.7 Focus Visible로 알려진 항목)이 있는 것으로 정리된다. 한국의 KWCAG(한국형 웹 콘텐츠 접근성 지침) 계열 문서에서도 키보드 사용과 초점 이동에 관한 항목이 다루어지는 것으로 알려져 있다.
다만 항목의 정확한 번호·등급·문구는 기준 문서의 판본에 따라 달라질 수 있다. 이 글에서 항목을 거론하는 이유는 특정 조항을 인용해 점수를 매기기 위해서가 아니라, '초점이 보여야 한다'는 생각이 한두 사람의 취향이 아니라 여러 공개 기준이 공통으로 짚는 지점이라는 사실을 보이기 위해서다. 구체적인 적용은 각 기준의 원문을 직접 확인하는 편이 안전하다.
2-2. 키보드로 도달할 수 있어야 한다는 전제
초점 표시 이야기에 앞서 한 가지 전제가 있다. 애초에 모든 조작 요소에 키보드로 도달할 수 있어야 한다는 것이다. WCAG에는 키보드만으로 모든 기능을 사용할 수 있어야 한다는 취지의 항목(2.1.1 Keyboard로 알려진 항목)이 있는 것으로 정리된다. 마우스로만 작동하는 버튼, Tab으로는 닿지 않는 메뉴가 있다면, 그 요소는 초점 표시 이전에 키보드 사용자에게 아예 존재하지 않는 것과 같다.
그래서 초점에 관한 점검은 두 층으로 나누어 생각하면 정리가 쉽다. 첫째, 닿을 수 있는가 — 키보드로 그 요소까지 초점이 이동하는가. 둘째, 보이는가 — 초점이 그 요소에 갔을 때 그것이 화면에 표시되는가. 이 글은 주로 둘째 층, 즉 '보이는가'를 다루지만, 첫째 층이 충족되지 않으면 둘째 층은 의미를 잃는다는 점은 기억해 둘 만하다.
2-3. 순서도 함께 본다
초점이 보인다고 끝이 아니다. 초점이 이동하는 순서가 화면의 시각적·논리적 흐름과 크게 어긋나면, 사용자는 보이는 초점을 따라가면서도 길을 잃는다. 위에서 아래로, 왼쪽에서 오른쪽으로 읽히는 화면에서 초점이 갑자기 화면 맨 아래로 튀었다가 다시 위로 올라온다면 혼란스럽다. WCAG에는 초점 이동 순서가 의미와 작동을 보존하는 합리적 순서를 따라야 한다는 취지의 항목(2.4.3 Focus Order로 알려진 항목)이 있는 것으로 정리된다. 보이는 초점과 합리적인 순서는 한 쌍으로 작동한다.
초점에 관한 항목들을 한자리에 모으면, '보이는가'가 혼자 서 있는 항목이 아니라 도달·순서·대비와 한 묶음이라는 것이 드러난다.
| 알려진 항목 | 다루는 것 | 이 글에서의 위치 |
|---|---|---|
| 2.1.1 Keyboard | 키보드만으로 모든 기능 사용 | 전제(닿을 수 있는가) |
| 2.4.7 Focus Visible | 초점이 시각적으로 보임 | 본 주제(보이는가) |
| 2.4.3 Focus Order | 초점 이동 순서의 합리성 | 함께 보는 것 |
| 1.4.11 Non-text Contrast | 초점 표시의 색 대비(약 3:1) | 함께 보는 것 |
(인용) 위 항목 번호·등급·문구는 WCAG 판본에 따라 달라질 수 있으며, 표는 '초점이 보여야 한다'는 생각이 여러 공개 기준에 걸쳐 있음을 보이기 위한 정리다. 특정 조항으로 점수를 매기려는 것이 아니므로, 실제 적용은 각 기준 원문을 직접 확인하는 편이 안전하다.
3. 초점은 어떻게 '보이게' 되는가
3-1. 브라우저가 기본으로 주는 표시
대부분의 브라우저는 초점을 받은 요소 주위에 외곽선(outline)을 그려 준다. 점선이나 실선의 테두리, 혹은 옅은 띠 형태로 "지금 여기에 초점이 있다"를 알려 주는 이 기본 표시는, 디자이너가 아무것도 하지 않아도 작동하는 일종의 안전망이다. 키보드 사용자에게 이 기본 외곽선은 길을 잃지 않게 해 주는 중요한 단서다.
문제는 이 기본 외곽선이 종종 '디자인을 해친다'는 이유로 제거된다는 점이다. 스타일을 다루는 코드에서 외곽선을 없애는 한 줄(흔히 outline: none으로 알려진 처리)을 넣으면 그 표시는 사라진다. 마우스 사용자에게는 아무 변화가 없으니 만든 사람은 문제를 눈치채기 어렵다. 그러나 키보드 사용자에게는 그 순간부터 초점이 보이지 않는 화면이 된다. 기본 표시를 지웠다면, 그 자리를 대신할 다른 표시를 마련했는지가 핵심 질문이 된다.
3-2. 비텍스트 대비라는 또 하나의 관점
초점 표시가 화면에 그려진다고 해서 늘 충분한 것은 아니다. 표시 자체가 배경과 너무 비슷한 색이라 잘 보이지 않으면, 보이긴 하나 알아채기 어려운 표시가 된다. 명도 대비를 다룬 이 시리즈의 029편에서 짚었듯, WCAG에는 버튼 경계나 초점 표시 같은 비텍스트 요소도 인접 색과 일정 수준(대략 3대 1로 알려진 기준)의 대비를 갖추는 것이 바람직하다는 취지의 항목(1.4.11 Non-text Contrast로 알려진 항목)이 있는 것으로 정리된다.
즉 초점 표시는 '있는가'와 '보이는가'를 함께 본다. 표시가 존재하더라도 그 색이 주변에 묻혀 버리면, 저시력 사용자나 밝은 환경에서 화면을 보는 사용자에게는 없는 것과 다르지 않다. 외곽선의 두께, 색, 배경과의 대비가 함께 고려될 때 초점 표시는 비로소 제 역할을 한다.
3-3. 마우스와 키보드를 가려서 보여 주는 방식
근래에는 마우스로 눌렀을 때는 외곽선을 보이지 않게 하고, 키보드로 초점이 이동했을 때만 외곽선을 보이게 하는 방식이 알려져 있다. 마우스 사용자가 클릭할 때마다 외곽선이 남는 것을 부담스러워하는 디자인 요구와, 키보드 사용자에게는 초점이 보여야 한다는 접근성 요구를 함께 풀려는 시도다. 이런 방식이 모든 환경에서 동일하게 동작하는지는 브라우저와 구현에 따라 차이가 있을 수 있으므로, '키보드로 만졌을 때 초점이 실제로 보이는지'를 사람이 직접 확인하는 절차는 여전히 남는다.
초점이 '보이게' 되는 방식을 늘어놓으면, 각각이 무엇을 풀고 무엇을 남기는지가 보인다.
| 방식 | 어떻게 보이나 | 남는 질문 |
|---|---|---|
| 브라우저 기본 외곽선 | 아무 처리 없이 자동 표시 | 미관 이유로 지워지기 쉬움 |
| 외곽선 제거 | 표시 사라짐(마우스는 무변화) | 대체 표시를 마련했는가 |
| 대비 갖춘 커스텀 표시 | 디자인에 맞춘 또렷한 표시 | 배경과 약 3:1 대비 되는가 |
| 마우스/키보드 구분 표시 | 키보드 때만 외곽선 노출 | 모든 환경에서 동작하는가 |
(관점) 위 구분은 초점 표시 구현 방식을 연구 관점에서 정리한 것으로, 어느 한 방식이 항상 정답이라는 뜻은 아니다. 핵심은 '키보드로 만졌을 때 또렷이 보이는가'이며, 어떤 방식을 쓰든 그 확인은 사람이 직접
Tab을 눌러 봐야 끝난다고 우리는 본다.
4. 만드는 사람의 시선에서
4-1. 마우스를 내려놓아 본다
초점 표시를 점검하는 가장 단순한 방법은 마우스를 잠시 내려놓는 것이다. 마우스에 손을 대지 않고 Tab 키만으로 화면 위쪽부터 아래쪽까지 이동해 본다. 한 번 누를 때마다 초점이 어디로 갔는지 눈으로 분명히 알 수 있는가. 알 수 없는 구간이 있다면, 그 구간이 바로 키보드 사용자가 길을 잃는 구간이다.
이 작업은 특별한 도구 없이 누구나 할 수 있다. 그런데도 마우스로 화면을 만드는 일이 워낙 익숙한 탓에, 정작 키보드만으로 자신의 화면을 끝까지 지나가 본 적이 없는 경우가 적지 않다. 만드는 사람이 한 번이라도 마우스를 내려놓고 화면을 통과해 보면, 보이지 않던 초점의 빈자리가 드러난다.
4-2. '예쁨'과 '보임'은 충돌하지 않는다
초점 외곽선을 지우는 흔한 이유는 미관이다. 기본 외곽선이 투박하다고 느껴질 수 있다. 그러나 외곽선을 지우는 것과 보기 좋은 초점 표시를 만드는 것은 서로 다른 일이다. 기본 표시를 지우되 그 자리에 디자인에 어울리는 또렷한 표시를 새로 마련하면, 미관과 접근성은 충돌하지 않는다. 충돌이 생기는 것은 '지우기만 하고 대체하지 않을 때'다.
이 시리즈가 반복해 온 관점이 여기서도 이어진다. 접근성은 디자인을 포기하라는 요구가 아니라, 디자인을 더 많은 사용자에게 닿게 만드는 작업이라는 것. 또렷한 초점 표시는 키보드 사용자만을 위한 것이 아니라, 화면 위에서 자신의 위치를 잃지 않으려는 모든 사용자에게 도움이 된다.
4-3. 기준은 출발선이다
WCAG나 KWCAG에 초점 관련 항목이 있다는 사실은 '이 표시가 중요하다'는 합의가 공개되어 있다는 뜻이다. 그러나 기준의 항목을 외우는 것과, 실제 화면에서 초점이 보이는 것은 다른 문제다. 기준은 무엇을 살펴야 하는지를 알려 주는 출발선이지, 그 자체로 화면을 또렷하게 만들어 주지는 않는다. 항목의 정확한 번호와 등급은 기준 원문에서 확인하되, 점검은 결국 마우스를 내려놓고 Tab을 눌러 보는 사람의 손에서 완성된다.
초점 표시를 둘러싼 흔한 오해를 정리해 두면, 점검할 때 같은 자리에서 헷갈리지 않는다.
| 흔한 오해 | 실제로는 | 짚어 둘 점 |
|---|---|---|
| "마우스로 잘 되니 키보드도 될 것" | 마우스 동작과 초점 표시는 별개 | 마우스 내려놓고 직접 확인 |
| "외곽선이 디자인을 해친다" | 지우기≠개선, 대체 표시가 핵심 | 지웠다면 무엇으로 대신했나 |
| "표시만 있으면 충분" | 배경에 묻히면 없는 것과 같음 | 색 대비(약 3:1) 함께 봄 |
| "기준 항목을 지키면 끝" | 기준은 출발선, 화면이 결과 | Tab으로 끝까지 통과해 봄 |
(관찰) 위 오해는 화면을 만드는 현장에서 되풀이되어 관찰되는 것을 정리한 것으로, 특정 제작자나 사이트를 가리키지 않는다. 빈도는 측정된 수치가 아니라 경험에 기반한 정리이며, 우리는 이를 비판이 아니라 '점검할 때 의식하면 좋은 시선'으로 제시한다.
5. 반론·한계와 ViewCheck 관점
5-1. 반론과 한계
초점 표시를 '보여야 한다'고 정리했지만, 여기에도 반론과 한계가 있다. 덮기보다 함께 적어 둔다.
| 가능한 반론 | 우리의 한계 인정 | 보완하는 태도 |
|---|---|---|
| "마우스/키보드 구분 표시면 다 풀리지 않나" | 모든 브라우저·구현에서 동일 동작을 보장하긴 어렵다 | 키보드로 만져 실제로 보이는지 확인한다 |
| "기준 항목만 충족하면 되지 않나" | 항목 충족이 곧 또렷한 화면을 뜻하진 않는다 | 기준은 출발선, 통과 점검을 더한다 |
| "초점 표시는 소수만의 문제 아닌가" | 사용 빈도를 단정할 데이터는 없다 | 위치를 잃지 않으려는 모든 사용자로 본다 |
5-2. ViewCheck 관점 — 사람과 도구의 분담
초점 점검에서 자동 점검과 사람의 눈은 보는 자리가 다르다. 도구는 외곽선 제거나 대비 부족 같은 코드 신호를 빠르게 훑지만, '키보드로 만졌을 때 초점이 또렷이 보이는지'는 사람이 직접 따라가 봐야 안다.
| 점검 항목 | 자동 점검이 보는 것 | 사람이 봐야 하는 것 |
|---|---|---|
| 초점 표시 존재 | outline:none 등 제거 신호 |
키보드 이동 시 실제로 보이는지 |
| 표시 대비 | 표시색-배경색 대비 수치 | 밝은 환경·저시력에서 알아채지는지 |
| 초점 순서 | DOM 순서와 시각 순서 차이 | 따라갈 때 길을 잃지 않는지 |
| 키보드 도달 | 조작 요소의 focusable 여부 | Tab으로 끝까지 닿는지 |
자동 점검은 '초점이 코드에서 표시될 수 있는가'를 빠짐없이 훑고, 사람은 '그 표시가 화면에서 실제로 보이는가'를 손으로 확인한다. 두 시선이 만나는 자리에서 초점 점검이 완성된다고 우리는 본다.
한 장 요약
| 구분 | 핵심 내용 |
|---|---|
| 초점이란 | 키보드 Tab으로 이동하는, 지금 조작 대상이 되는 요소의 위치 |
| 왜 보여야 하나 | 보이지 않으면 키보드 사용자가 Enter 결과를 예측할 수 없음 |
| 관련 기준 | 초점이 시각적으로 보여야 한다는 취지의 항목(2.4.7로 알려짐) 등 — 번호·등급은 원문 확인 |
| 함께 보는 것 | 키보드 도달 가능성(2.1.1), 초점 순서(2.4.3), 표시의 비텍스트 대비(1.4.11) |
| 흔한 실수 | 미관을 이유로 기본 외곽선만 지우고 대체 표시를 마련하지 않음 |
| 점검 방법 | 마우스를 내려놓고 Tab만으로 화면을 끝까지 지나가 보기 |
맺으며
초점 표시는 화면 위의 작은 테두리 하나일 뿐이다. 마우스를 쓰는 사람에게는 평생 한 번도 의식되지 않을 수 있다. 그러나 키보드로 화면을 더듬는 사람에게 그 테두리는 "지금 당신은 여기에 있다"고 알려 주는 유일한 신호다. 신호가 꺼진 화면에서 그는 보이지 않는 손으로 보이지 않는 버튼을 누른다.
이 글은 초점이 무엇이고 왜 보여야 하는지를 기준의 배경과 함께 따라가 보았다. 다음 편에서는 시선을 돌려, 실제로 초점이 보이지 않게 된 화면이 어떤 모습인지, 그리고 그것을 어떻게 점검해 볼 수 있는지를 관찰의 관점에서 이어 본다.
다음 편 예고 (039): 〈초점이 사라진 화면 / 포커스 점검 관점〉 — 외곽선이 지워진 화면에서 키보드 사용자가 마주하는 막막함을 따라가며, 우리 화면의 초점을 어떻게 스스로 점검해 볼 수 있는지를 살핀다.
참고한 공개 자료(출처):
- WCAG(Web Content Accessibility Guidelines) — 초점 표시·키보드·초점 순서·비텍스트 대비 관련 항목(2.4.7 / 2.1.1 / 2.4.3 / 1.4.11 등으로 알려진 항목)
- W3C WAI(Web Accessibility Initiative) — 키보드 접근성 및 초점 가시성 해설 자료
- KWCAG(한국형 웹 콘텐츠 접근성 지침) — 키보드 사용 및 초점 이동 관련 항목
- 행정안전부 등 공공기관 웹 접근성 안내 자료
※ 위 자료의 항목 번호·등급·세부 문구는 판본에 따라 달라질 수 있으므로, 실제 적용 시에는 각 기준의 원문을 직접 확인하는 것이 안전합니다. 이 글은 특정 기준의 공식 해석이 아니라 하나의 연구 관점입니다.
관련 글
[접근성연구·디지털포용] 한 사람이 여러 벽을 동시에
앞 편(081)에서 디지털 포용이 여러 갈래의 사용자를 하나의 목표로 묶는다고 봤다. 그리고 끝에서 한 가지를 남겼다 — 현실의 한 사람은 여러 조건을 동시에 가질 수 있다고. 이 시리즈를 닫는 이번 편은 그 '겹침'을 정면으로 본다. 영역의 경계를 가로질러, 조건이 겹칠 때 접근성이 어떻게 더 가팔라지는지를 관찰한다.
[접근성연구·디지털포용] 디지털포용법이 말하는 '포용'
앞 편(080)에서 초고령사회라는 인구구조의 신호를 봤다. 그리고 끝에서 한 가지를 분명히 했다 — 디지털 격차는 고령에만 있는 것이 아니라고. 이번 편은 그 여러 갈래의 격차를 '디지털 포용(digital inclusion)'이라는 하나의 정책 틀에서 함께 본다. 이 시리즈는 그동안 사용자를 영역별로 나눠 다뤘다. 고령
[접근성연구·디지털포용] 초고령사회, 공공웹은 준비됐나
공공앱 세 편(077~079)으로 매체의 확장을 닫았다. 이제 시선을 한 번 더 넓힌다. 지금까지 이 시리즈는 주로 '한 사람이 화면 앞에서 겪는 어려움'을 다뤘다. 고령(001~014), 저시력(029~043), 키보드(047~049)처럼, 개별 사용자의 자리에서 벽을 봤다. 이번 묶음(080~082)은 그 시선을 거시