[접근성연구·저시력] 초점이 사라진 화면

포커스 점검 관점

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

들어가며

앞 편(038)에서 초점 표시가 무엇이고 왜 보여야 하는지를 기준의 배경과 함께 따라가 보았다. 이번 편은 시선을 자신의 화면으로 돌린다. "우리 화면은 초점이 보이는가." 이 질문은 생각보다 답하기 어렵다. 만드는 사람은 거의 언제나 마우스로 화면을 다루기 때문에, 초점이 보이지 않는다는 사실 자체를 마주칠 기회가 드물기 때문이다.

초점이 사라진 화면은 조용하다. 깨진 이미지나 겹친 글자처럼 눈에 띄는 오류가 아니라서, 마우스로 보면 아무 문제가 없어 보인다. 그래서 이 문제는 의도적으로 마우스를 내려놓고 키보드로 화면을 지나가 보지 않으면 드러나지 않는다. 이 글은 그 '내려놓는 점검'을 어떻게 해 볼 수 있는지, 무엇을 살펴야 하는지를 점검의 관점에서 정리한다. 단정하기보다, 함께 따라가 볼 수 있는 동선을 그려 보는 데 목적이 있다.

1. 초점이 사라지는 흔한 경로

1-1. 외곽선을 지운 자리

초점이 보이지 않는 화면의 가장 흔한 원인은 브라우저가 기본으로 그려 주던 외곽선을 지운 것이다. 스타일을 다루는 코드에서 외곽선을 없애는 처리(흔히 outline: none으로 알려진 처리)를 넣으면, 마우스 사용자에게는 변화가 없지만 키보드 사용자에게는 초점이 보이지 않게 된다. 이 처리는 종종 '클릭할 때 남는 테두리가 보기 싫다'는 이유로 들어가는데, 마우스 클릭의 잔상만 지우려다 키보드의 초점 표시까지 함께 지우는 경우가 많다.

지웠다는 사실 자체가 문제는 아니다. 문제는 지운 자리에 대체할 표시를 마련했는가다. 기본 외곽선을 지우고 그 자리에 또렷한 다른 표시를 새로 둔 화면이라면, 초점은 여전히 보인다. 점검의 첫 질문은 그래서 "외곽선을 지웠는가"가 아니라 "지운 자리가 비어 있는가"가 된다.

1-2. 표시는 있으나 너무 옅은 경우

초점 표시가 있긴 한데 색이 배경과 너무 비슷해 잘 보이지 않는 경우도 있다. 이 시리즈의 명도 대비 편(029~031)에서 짚었듯, 표시도 일종의 비텍스트 요소이므로 주변과의 대비가 충분해야 알아챌 수 있다. 옅은 회색 화면에 옅은 회색 테두리가 그려지면, 있긴 하나 보이지 않는 표시가 된다. 저시력 사용자나 밝은 조명 아래에서 화면을 보는 사용자에게는 이 차이가 결정적이다.

1-3. 일부 요소만 보이는 경우

초점 표시가 어떤 요소에서는 보이고 어떤 요소에서는 보이지 않는 경우도 있다. 표준적인 버튼·링크에서는 초점이 잘 보이는데, 직접 만든 드롭다운이나 탭, 슬라이더 같은 맞춤 요소에서는 초점이 보이지 않는 식이다. 화면 전체가 일관되게 보이거나 일관되게 안 보이면 차라리 점검이 쉬운데, 군데군데 끊기면 사용자는 어디까지가 안전한지 가늠하기 어렵다.

초점이 사라지는 세 경로를 늘어놓으면, 점검할 때 무엇을 구분해 봐야 하는지가 분명해진다.

사라지는 경로	마우스로는	키보드로는	점검 질문
외곽선 제거	변화 없음	표시 전혀 안 보임	지운 자리에 대체 표시 있나
표시는 있으나 옅음	거의 안 보임	있어도 알아채기 어려움	배경과 대비 충분한가
일부 요소만 보임	알 수 없음	군데군데 끊김	맞춤 요소도 봤나

(관찰) 위 세 경로는 초점 점검 현장에서 되풀이되어 관찰되는 패턴을 정리한 것으로, 특정 화면을 가리키지 않는다. 빈도는 측정된 수치가 아니라 경험에 기반한 정리이며, 우리는 이를 단정이 아니라 '점검 시 구분해 볼 시선'으로 제시한다.

2. 점검의 출발 — 마우스를 내려놓기

2-1. Tab만으로 화면을 지나가 보기

초점 점검의 출발점은 도구가 아니라 손이다. 마우스에서 손을 떼고, Tab 키만으로 화면 맨 위부터 맨 아래까지 이동해 본다. 한 번 누를 때마다 초점이 어디로 갔는지 눈으로 분명히 알 수 있는지 살핀다. Shift와 함께 누르면 역방향으로도 이동하니, 양방향으로 한 번씩 지나가 보면 더 확실하다.

이 과정에서 '지금 초점이 어디 있는지 모르겠다' 싶은 구간이 생기면, 그 구간을 적어 둔다. 그 구간이 바로 키보드 사용자가 길을 잃는 자리다. 화면을 처음부터 끝까지 키보드로 통과해 보는 이 단순한 동작 한 번이, 마우스로는 평생 발견하기 어려운 빈자리를 드러낸다.

2-2. 어디서 끊기는지 표시해 두기

점검을 하다 보면 초점이 아예 보이지 않는 구간뿐 아니라, 초점이 화면 밖으로 나가 버려 보이지 않는 구간, 초점이 같은 자리를 맴도는 구간, 초점이 갑자기 엉뚱한 곳으로 튀는 구간이 함께 발견된다. 이들은 원인이 조금씩 다르지만, 사용자 입장에서는 모두 '따라갈 수 없는 화면'이다. 어떤 종류든 끊기는 자리를 기록해 두면, 나중에 원인을 살필 때 길잡이가 된다.

2-3. 사람마다 다르게 보일 수 있음을 전제로

같은 화면이라도 사용하는 브라우저, 화면 밝기, 사용자의 시력에 따라 초점 표시가 다르게 보일 수 있다. 만든 사람의 환경에서 잘 보였다고 모든 사용자에게 잘 보인다고 단정하기 어렵다. 그래서 점검은 한 환경에서 한 번으로 끝내기보다, 가능하면 밝은 화면과 어두운 화면, 다른 브라우저에서 한 번씩 더 확인해 보는 편이 안전하다는 관점이 가능하다.

마우스를 내려놓는 점검을 세 동작으로 나누면, 어느 동작을 빠뜨렸는지가 보인다.

동작	어떻게	기록할 것
양방향 통과	Tab/Shift+Tab으로 위↔아래	초점 모르겠는 구간
끊김 유형 표시	안 보임·화면 밖·맴돔·튐 구분	끊긴 자리와 종류
환경 바꿔 재확인	밝은/어두운 화면·다른 브라우저	환경마다 보임 차이

(관점) 위 동선은 "도구가 아니라 손에서 출발한다"는 관점의 정리다. 동작 순서나 환경 수는 상황에 따라 달라질 수 있으며, 핵심은 한 환경 한 번으로 단정하지 않는 것이다. 우리는 만든 사람의 환경이 모든 사용자를 대표하지 않는다는 전제에서 점검을 짠다.

3. 살펴볼 만한 질문들

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

먼저 닿는지를 본다. 링크·버튼·입력칸·체크박스처럼 사용자가 조작하는 요소에 Tab으로 초점이 이동하는가. 마우스로만 작동하고 Tab으로는 닿지 않는 요소가 있다면, 그 요소는 초점 표시 이전에 키보드 사용자에게 존재하지 않는 것과 같다. WCAG에 키보드만으로 기능을 사용할 수 있어야 한다는 취지의 항목(2.1.1로 알려진 항목)이 있다는 점은 038편에서 짚었다.

3-2. 초점이 갔을 때 그것이 보이는가

닿는 것을 확인했다면, 초점이 갔을 때 화면에 표시가 나타나는지를 본다. 표시가 전혀 없는지, 있으나 너무 옅은지, 일부 요소에서만 보이는지를 구분해 적는다. 이때 표시의 색이 배경과 충분히 구분되는지도 함께 보면 좋다. 표시가 존재해도 묻혀 버리면 보이지 않는 것과 같기 때문이다.

3-3. 초점 순서가 흐름과 맞는가

표시가 보인다면, 그 표시가 이동하는 순서가 화면의 시각적·논리적 흐름과 맞는지를 본다. 위에서 아래로 읽히는 화면에서 초점이 아래로 튀었다가 위로 올라오는 식으로 어긋나면, 보이는 초점을 따라가면서도 혼란스럽다. WCAG에 초점 순서에 관한 취지의 항목(2.4.3으로 알려진 항목)이 있다는 점 역시 038편에서 짚었다. '보이는가'와 '순서가 맞는가'는 함께 본다.

3-4. 맞춤 요소도 함께 보는가

표준 버튼·링크만 보고 점검을 끝내기 쉽다. 그러나 직접 만든 드롭다운, 탭, 모달, 슬라이더 같은 맞춤 요소에서 초점이 어떻게 동작하는지가 종종 더 까다롭다. 모달이 열렸을 때 초점이 모달 안으로 들어가는지, 닫혔을 때 원래 자리로 돌아오는지처럼, 맞춤 요소에서만 생기는 질문들이 있다. 점검 동선에 이런 요소를 일부러 포함해 두면 빈틈이 줄어든다.

네 가지 점검 질문을 알려진 기준 항목과 나란히 두면, 무엇을 근거로 보는지가 분명해진다.

점검 질문	보는 것	알려진 항목
닿는가	조작 요소에 Tab 초점 이동	2.1.1 Keyboard
보이는가	초점 갔을 때 표시·대비	2.4.7 / 1.4.11
순서가 맞는가	초점 이동이 흐름과 일치	2.4.3 Focus Order
맞춤 요소는	모달·드롭다운 초점 동작	(구현별, 항목 외)

(인용) 위 항목 번호는 WCAG에서 알려진 것을 연구 관점에서 묶은 것으로, 번호·등급·문구는 판본에 따라 달라질 수 있다. 맞춤 요소의 초점 동작은 단일 항목으로 환원되지 않는 경우가 많아 '항목 외'로 두었다. 실제 적용은 기준 원문 확인이 안전하며, 본 표는 합격·불합격 기준이 아니다.

4. 점검을 일상에 두기

4-1. 자동 도구와 사람 눈을 함께

초점이 '닿는지'는 자동 점검 도구가 어느 정도 알려 줄 수 있다. 키보드로 도달할 수 없는 요소나 초점 순서의 이상을 기계적으로 짚어 주는 도구들이 알려져 있다. 그러나 초점 표시가 '충분히 또렷하게 보이는지'는 결국 사람이 화면을 보며 판단해야 하는 영역이 많다. 색이 묻히는 정도, 밝은 환경에서의 가독성 같은 것은 수치만으로 단정하기 어렵다. 자동 도구로 닿는지를 거르고, 사람 눈으로 보이는지를 확인하는 두 층의 점검이 함께 가는 관점이 가능하다.

4-2. 만들 때마다 한 번씩

초점 점검을 별도의 큰 작업으로 미뤄 두면, 화면이 다 만들어진 뒤에야 한꺼번에 떠안게 된다. 새 화면이나 새 요소를 만들 때마다 마우스를 잠깐 내려놓고 Tab으로 지나가 보는 습관을 두면, 빈자리가 쌓이기 전에 작게 발견된다. 점검이 마지막 검수가 아니라 만드는 과정의 일부가 될 때, 초점이 사라진 화면은 드물어진다.

4-3. 기준은 점검의 지도다

WCAG·KWCAG에 초점 관련 항목이 있다는 사실은, 무엇을 살펴야 하는지를 알려 주는 지도와 같다. 항목의 정확한 번호·등급은 기준 원문에서 확인하되, 지도를 들고 실제로 화면을 걸어 보는 일은 점검하는 사람의 몫이다. 이 글에서 정리한 질문들은 그 걸음을 돕기 위한 것이지, 그 자체로 합격·불합격을 가르는 기준은 아니다.

5. 반론·한계와 ViewCheck 관점

5-1. 반론과 한계

이 글의 점검 동선에도 반론과 한계가 있다. 덮기보다 함께 적어 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
"자동 도구가 초점을 다 잡아 주지 않나"	도구는 '닿음'은 잡아도 '또렷이 보임'은 단정하기 어렵다	도구로 거르고 사람 눈으로 확인한다
"한 번 통과해 보면 충분하지 않나"	한 환경 한 번이 모든 사용자를 대표하진 않는다	밝기·브라우저 바꿔 다시 본다
"표준 요소만 보면 되지 않나"	맞춤 요소에서 더 자주 끊긴다	모달·드롭다운을 동선에 포함한다

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

초점 점검에서 자동 점검과 사람의 눈은 보는 자리가 다르다. 도구는 '닿는지'와 순서 이상을 빠르게 훑지만, '또렷이 보이는지'는 사람이 화면을 보며 판단해야 하는 영역이 많다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
초점 도달	focusable 여부·도달 가능성	Tab으로 끝까지 닿는 느낌
초점 표시	outline:none 등 제거 신호	표시가 실제로 또렷한지
표시 대비	표시색-배경색 대비 수치	밝은 환경·저시력에서 알아채지는지
맞춤 요소	모달 초점 트랩 코드 패턴	열림·닫힘 때 초점이 자연스러운지

자동 점검은 '초점이 코드에서 닿고 표시될 수 있는가'를 빠짐없이 훑고, 사람은 '그 표시가 화면에서 또렷이 보이는가'를 손과 눈으로 확인한다. 두 시선이 만나는 자리에서 초점 점검이 완성된다고 우리는 본다.

한 장 요약

점검 질문	무엇을 보는가
닿는가	모든 조작 요소에 Tab으로 초점이 이동하는가 (2.1.1로 알려진 항목)
보이는가	초점이 갔을 때 화면에 표시가 나타나고, 충분히 또렷한가 (1.4.11 함께)
순서가 맞는가	초점 이동 순서가 화면 흐름과 어긋나지 않는가 (2.4.3으로 알려진 항목)
맞춤 요소는	직접 만든 드롭다운·모달·탭에서도 초점이 동작하는가
점검 방법	마우스를 내려놓고 Tab/Shift+Tab으로 양방향 통과해 보기
누가 보나	자동 도구로 닿음을 거르고, 사람 눈으로 보임을 확인

맺으며

초점이 사라진 화면은 소리 없이 만들어진다. 마우스로 보면 멀쩡하고, 자동 점검에서도 종종 비켜 가며, 만든 사람은 끝까지 모를 수 있다. 그것을 드러내는 거의 유일한 방법은 마우스를 내려놓고 키보드로 화면을 한 번 통과해 보는 일이다. 도구도 비용도 들지 않는 이 한 번의 통과가, 키보드로 화면을 더듬는 사용자가 길을 잃지 않게 한다.

이 글은 초점이 사라진 화면을 어떻게 점검해 볼 수 있는지를 동선으로 정리했다. 저시력 분야의 다음 주제는 화면의 '읽힘'에서 다시 한 걸음 나아간다. 다음 편에서는 표(table)를 다룬다. 눈으로 보면 한눈에 읽히는 표가, 소리로 읽힐 때는 왜 그토록 혼란스러워지는지를 따라가 본다.

다음 편 예고 (040): 〈표를 소리로 읽는다는 것 / 데이터 표 접근성 연구〉 — 눈으로는 한눈에 읽히는 데이터 표가 스크린리더에서는 어떻게 읽히는지, 표 머리글이 왜 중요한지를 기준의 배경과 함께 살핀다.

---

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

• WCAG(Web Content Accessibility Guidelines) — 키보드·초점 표시·초점 순서·비텍스트 대비 관련 항목(2.1.1 / 2.4.7 / 2.4.3 / 1.4.11 등으로 알려진 항목)
• W3C WAI(Web Accessibility Initiative) — 키보드 접근성 점검 및 초점 가시성 해설 자료
• KWCAG(한국형 웹 콘텐츠 접근성 지침) — 키보드 사용 및 초점 이동 관련 항목
• 행정안전부 등 공공기관 웹 접근성 점검 안내 자료

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