[접근성연구·모바일] 확대했더니 사라진 버튼

줌 대응 점검 관점

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

들어가며

글씨가 작다고 느낀 사람이 화면을 확대한다. 두 손가락을 벌려 키우거나, 운영체제의 글자 크기 설정을 한 단계 올린다. 여기까지는 누구나 하는 일상적인 동작이다. 그런데 확대한 그 순간, 방금 전까지 보이던 '신청' 버튼이 화면 어딘가로 사라진다. 손가락으로 화면을 이리저리 밀어 보지만 버튼은 잡히지 않는다. 분명히 존재하는데, 닿지 않는다.

우리는 이 장면을 '줌(zoom) 대응이 깨진 순간'이라고 부른다. 확대는 저시력 사용자에게 가장 기본적이고 강력한 보조 수단이다. 별도의 보조기기 없이, 누구나 지금 들고 있는 기기에서 바로 쓸 수 있다. 그런데 확대를 했더니 정작 필요한 컨트롤이 사라진다면, 그 화면은 확대를 '허용'은 했지만 '대응'은 하지 못한 것이다.

이번 편은 'C 점검' 관점이다. 줌 대응이 깨졌는지를 단정하려는 것이 아니라, 어떻게 확대해 보면 그 막힘이 드러나는지를 정리한다. 화면을 확대하고, 글자 크기를 키우고, 가로로 돌려 보는 — 누구나 따라 할 수 있는 점검 동선을 통해, "확대했더니 사라진 버튼"이라는 현상을 재현하고 발견하는 방법을 살펴본다. 점검의 목적은 사이트를 평가하는 데 있지 않다. 확대라는 흔한 동작 하나로 막히는 사람이 없는지를 확인하는 데 있다.

1. 무엇을 점검하려는가 — '확대 허용'과 '확대 대응'의 차이

먼저 두 가지를 구분해야 한다. 화면이 확대를 막지 않는 것과, 확대한 뒤에도 콘텐츠가 제대로 따라오는 것은 다른 문제다.

첫째는 '확대 허용'이다. 일부 화면은 viewport 설정에서 user-scalable=no나 maximum-scale=1.0 같은 값을 넣어, 사용자가 손가락으로 화면을 확대하는 동작 자체를 막아 둔다. 이 경우 사용자는 핀치 줌을 시도해도 화면이 커지지 않는다. WCAG 2.1의 1.4.4 'Resize Text'(텍스트 크기 조정)는 보조기술 없이도 텍스트를 200%까지 키울 수 있어야 한다고 설명하는데(W3C, 원문 확인이 안전하다), 확대 자체를 막는 설정은 이 기준의 취지와 충돌하는 것으로 이해된다.

둘째는 '확대 대응'이다. 확대는 허용되더라도, 확대한 뒤 레이아웃이 깨지거나 콘텐츠가 잘리거나 일부 컨트롤이 화면 밖으로 밀려나면, 사용자는 여전히 막힌다. WCAG 2.1의 1.4.10 'Reflow'(리플로)는 콘텐츠가 320 CSS 픽셀 폭(세로 스크롤 기준)에 맞춰 다시 흐를 수 있어야 하며, 양방향(가로·세로) 스크롤을 동시에 요구해서는 안 된다고 설명한다(W3C, 원문 확인 권장). 확대 대응이 깨진 화면은 바로 이 지점에서 무너진다.

우리가 이번에 점검하려는 것은 주로 둘째, '확대 대응'이다. "확대는 되는데 버튼이 사라진다"는 현상은 확대를 막은 게 아니라, 확대 후의 흐름을 설계하지 못한 결과로 나타나기 때문이다. 다만 점검의 첫 단계로 '확대 허용' 여부도 함께 확인하는 것이 자연스럽다. 둘은 같은 동작에서 연이어 드러난다.

1-1. '사라진다'는 말의 세 가지 의미

버튼이 '사라진다'고 할 때, 실제로는 서로 다른 상황이 섞여 있다. 점검할 때 이를 구분해 두면 기록이 정확해진다.

하나는 화면 밖으로 밀려난 경우다. 버튼은 존재하지만 확대로 인해 가시 영역(viewport) 바깥으로 나가, 스크롤하지 않으면 보이지 않는다. 가로 스크롤을 해야만 닿는다면 이는 리플로 관점에서 막힘으로 볼 여지가 있다.

둘은 다른 요소에 가려진 경우다. 확대 후 고정된 헤더나 떠 있는 배너가 버튼 위를 덮어, 버튼은 그 자리에 있지만 손가락이 닿는 곳에서는 가려진 요소가 먼저 반응한다.

셋은 레이아웃 붕괴로 자리를 잃은 경우다. 확대 후 요소들이 서로 겹치거나 0 크기로 찌그러져, 버튼이 시각적으로 사라지거나 누를 수 없는 상태가 된다.

점검할 때는 "버튼이 안 보인다"에서 멈추지 말고, 셋 중 어느 쪽인지까지 적어 두는 것이 좋다. 원인이 다르면 확인할 지점도 달라지기 때문이다.

세 가지를 표로 구분하면 다음과 같다.

'사라짐'의 종류	실제 상태	확인 방법	흔한 원인
밀려남	버튼은 있으나 가시 영역 밖	스크롤·가로 스크롤로 닿는지	고정 너비, 리플로 미설계
가려짐	자리에 있으나 다른 요소가 덮음	눌렀을 때 무엇이 반응하나	고정 헤더, 플로팅 배너
붕괴	겹치거나 0 크기로 찌그러짐	요소 크기·겹침 확인	가로 배치 고집, 레이아웃 깨짐

(관점) "안 보인다"는 결과는 같아도 원인은 셋으로 갈린다. 점검의 가치는 결과를 적는 데 있지 않고, 셋 중 어느 길로 막혔는지를 다시 찾을 수 있게 적는 데 있다.

2. 점검 준비 — 무엇을, 어떻게 확대해 볼 것인가

줌 점검은 특별한 장비가 필요하지 않다. 대부분 지금 쓰는 기기와 브라우저로 충분하다. 다만 '확대'에는 여러 종류가 있어, 한 가지만 해 보고 "괜찮다"고 결론 내리면 다른 경로의 막힘을 놓친다.

2-1. 점검에 쓰는 확대의 종류

브라우저 페이지 줌: 데스크탑 브라우저에서 Ctrl(또는 Cmd)와 +를 눌러 페이지 전체를 키우는 방식이다. 200%, 300%, 400%까지 단계적으로 올려 본다. WCAG의 1.4.4(200%)와 1.4.10(400% 상당의 좁은 폭) 점검에 주로 활용된다.

모바일 핀치 줌: 휴대폰에서 두 손가락으로 화면을 키우는 방식이다. 실제 사용자가 가장 흔히 하는 동작이다. 확대 자체가 막혀 있는지(허용 점검)와, 확대 후 가로 스크롤이 강제되는지(대응 점검)를 함께 본다.

OS 글자 크기 설정: 운영체제 설정에서 글자 크기를 키우는 방식이다. 페이지 줌과 달리 텍스트만 커지는 경우가 많아, 글자만 커졌을 때 레이아웃이 어떻게 반응하는지를 별도로 확인할 수 있다. 안드로이드·iOS 모두 글자 크기 옵션을 제공한다(각 OS 설정 화면 기준, 버전에 따라 위치가 다를 수 있어 확인이 안전하다).

OS 화면 확대(돋보기): 화면 일부를 크게 보여 주는 보조 기능이다. 페이지를 다시 흐르게 하지 않고 화면을 '확대경'처럼 키우므로, 콘텐츠가 잘리는지보다는 사용자가 얼마나 많이 움직여야 하는지를 본다.

이 네 가지는 사용자가 화면을 키울 수 있는 서로 다른 길이다. 점검에서는 적어도 페이지 줌과 핀치 줌, 글자 크기 설정 세 가지를 나눠 보는 것이 안전하다.

네 종류의 확대를 표로 정리하면 다음과 같다.

확대 종류	키우는 대상	점검에서 보는 것	참고 기준
브라우저 페이지 줌	페이지 전체	200~400% 단계별 붕괴	1.4.4 / 1.4.10
모바일 핀치 줌	화면 영역	확대 허용·가로 스크롤 강제	1.4.10
OS 글자 크기	텍스트만	글자 넘침·버튼 글자 잘림	1.4.4
OS 화면 확대(돋보기)	화면 일부	이동량(다시 흐르지 않음)	보조 기능

(인용) 위 참고 기준 번호는 WCAG 2.1의 표기이며 정확한 비율·등급은 원문 확인이 안전하다. 핵심은 '확대'가 한 종류가 아니라, 사용자가 화면을 키우는 여러 갈래라는 점이다.

2-2. 점검 기준선 — '확대해도 닿아야 하는 것'

확대한 뒤에도 사용자가 닿을 수 있어야 하는 것들을 미리 목록으로 잡아 두면, 점검이 흔들리지 않는다. 우리가 기준선으로 삼는 항목은 대체로 이렇다.

본문 텍스트가 잘리지 않고 끝까지 읽히는가
주요 행동 버튼('신청', '제출', '다음', '닫기' 등)에 닿을 수 있는가
입력 칸과 그 라벨이 함께 보이는가
메뉴·검색 등 탐색 수단에 접근할 수 있는가
오류 메시지나 안내 문구가 가려지지 않는가

이 목록은 화면마다 조정될 수 있다. 핵심은 "확대 후에도 사용자가 일을 끝낼 수 있는가"이며, 그 일을 끝내는 데 필요한 요소가 닿는 자리에 있는지를 본다.

3. 점검 동선 — 확대하며 따라가는 순서

이제 실제로 확대해 보며 막힘을 드러내는 순서를 정리한다. 한 화면을 처음부터 끝까지 따라가되, 확대를 단계적으로 올려 가는 것이 핵심이다.

3-1. 1단계 — 확대가 허용되는지 먼저 본다

휴대폰에서 두 손가락으로 화면을 키워 본다. 화면이 전혀 커지지 않는다면, 확대 자체가 막혀 있을 가능성을 의심한다. 이때는 페이지의 viewport 설정에 user-scalable=no 또는 maximum-scale이 낮게 잡혀 있는지 확인하는 단계로 넘어간다(개발자 도구나 페이지 소스에서 <meta name="viewport"> 확인). 확대가 막혀 있다면 이후 단계의 점검은 의미가 줄어들므로, 이 발견을 먼저 기록한다.

3-2. 2단계 — 200%로 키우고 본문을 읽어 본다

데스크탑 브라우저에서 페이지 줌을 200%로 올린다. 그리고 본문을 위에서 아래로 읽어 내려가며, 글자가 서로 겹치는지, 문장 끝이 잘리는지, 가로 스크롤이 생기는지를 본다. WCAG 1.4.4가 보는 지점이 대략 이 200% 구간이다. 이 단계에서 이미 가로 스크롤이 생긴다면, 더 키웠을 때의 붕괴는 거의 확실하므로 기록해 둔다.

3-3. 3단계 — 좁은 폭(리플로)에서 양방향 스크롤을 확인한다

브라우저 창을 좁히거나 줌을 400% 수준으로 올려, 콘텐츠가 좁은 폭에서 다시 흐르는지를 본다. WCAG 1.4.10은 콘텐츠가 한 방향 스크롤(보통 세로)만으로 읽히도록 다시 흐를 것을 설명한다. 여기서 가로와 세로 스크롤을 동시에 해야 내용을 다 볼 수 있다면 막힘으로 본다. 표나 넓은 이미지처럼 본질적으로 가로 공간이 필요한 콘텐츠는 예외로 다뤄지지만(원문 확인 권장), 일반 본문과 버튼은 그렇지 않다.

3-4. 4단계 — 주요 버튼이 닿는 자리에 있는지 확인한다

확대 상태를 유지한 채, 미리 잡아 둔 기준선 목록(2-2)의 버튼들을 하나씩 찾아 본다. '신청', '제출', '다음', '닫기'가 화면 안에 있는가. 화면 밖으로 밀려났다면, 스크롤로 닿을 수 있는지 / 가로 스크롤이 필요한지 / 아예 잡히지 않는지를 구분해 적는다. 1-1에서 나눈 세 가지(밀려남·가려짐·붕괴) 중 어디에 해당하는지까지 기록하면 가장 좋다.

3-5. 5단계 — 글자 크기만 키워 본다

마지막으로 OS 글자 크기 설정만 한 단계 올린다. 페이지 줌과 달리 텍스트만 커지므로, 글자가 커졌을 때 버튼 안의 글씨가 버튼 밖으로 삐져나오는지, 줄이 겹치는지, 컨테이너가 글자를 따라 늘어나는지를 본다. 이 경로에서만 드러나는 막힘이 의외로 많다.

4. 자주 마주치는 막힘의 모양

점검을 반복하다 보면, '확대했더니 사라진 버튼'이 몇 가지 비슷한 모양으로 되풀이된다는 것을 알게 된다. 패턴을 알아 두면 점검이 빨라진다. 다만 아래는 자주 관찰되는 경향일 뿐, 모든 화면에 해당하는 규칙은 아니다.

4-1. 고정 너비가 만든 가로 스크롤

요소의 너비가 픽셀 단위로 고정되어 있으면, 화면이 좁아지거나 확대될 때 그 너비를 유지하려다 화면 밖으로 넘친다. 결과적으로 가로 스크롤이 생기고, 오른쪽에 있던 버튼이 처음 화면에서는 보이지 않게 된다. 이는 본 시리즈의 '고정 너비' 편(023·024)에서 다룬 막힘과 같은 뿌리에서 나온다.

4-2. 고정 헤더·플로팅 요소의 가림

화면 위에 항상 떠 있는 헤더나, 화면을 따라다니는 버튼·배너가 있는 경우, 확대하면 이들이 차지하는 비율이 커진다. 그 결과 본문이나 다른 버튼을 덮어, 누르려는 곳 대신 떠 있는 요소가 먼저 반응한다. 작은 화면일수록 이 가림이 두드러진다.

4-3. 가로 배치가 무너지지 않은 경우

데스크탑에서 좌우로 나란히 두었던 요소가, 확대·좁은 폭에서 세로로 다시 쌓이지 않고 가로 배치를 고집하면, 각 칸이 좁아져 글자가 겹치거나 버튼이 찌그러진다. 다시 흐르도록 설계되지 않은 레이아웃에서 자주 보인다.

4-4. 확대 자체를 막아 둔 경우

앞서 말한 user-scalable=no 류의 설정으로 확대가 아예 되지 않는 경우다. 이 경우 '사라진 버튼'이 아니라 '키울 수 없는 화면'이 문제의 본체다. 점검에서는 이 발견을 다른 막힘보다 먼저, 가장 윗자리에 적는 것이 자연스럽다. 확대가 안 되면 이후의 모든 확대 점검이 성립하지 않기 때문이다.

자주 마주치는 네 모양을 표로 모으면 다음과 같다.

막힘의 모양	어떻게 드러나나	뿌리	사라짐의 종류
고정 너비 가로 스크롤	오른쪽 버튼이 첫 화면에서 사라짐	px 고정 너비	밀려남
고정 헤더·플로팅 가림	누르면 떠 있는 요소가 반응	항상 떠 있는 요소	가려짐
가로 배치 미붕괴	칸이 좁아 글자 겹침·찌그러짐	다시 흐르지 않는 레이아웃	붕괴
확대 차단	핀치 줌이 안 됨	`user-scalable=no` 등	(확대 불가)

(관점) 위는 자주 관찰되는 경향일 뿐, 모든 화면의 규칙은 아니다. 네 모양을 알아 두면 점검이 빨라지지만, 판정은 늘 실제 조작으로 확인한다.

5. 점검에서 빠지기 쉬운 함정

줌 점검에는 사람을 헷갈리게 하는 지점이 몇 가지 있다. 이를 알고 있으면 잘못된 결론을 줄일 수 있다.

5-1. "내 폰에선 괜찮다"의 함정

점검자가 쓰는 기기가 크고 해상도가 높으면, 같은 확대를 해도 막힘이 덜 드러난다. 화면이 작은 보급형 기기, 글자 크기를 이미 키워 둔 기기에서는 같은 화면이 더 쉽게 무너진다. 한 기기에서만 보고 "괜찮다"고 적지 않도록, 가능하면 화면 크기가 다른 기기를 함께 본다.

5-2. 페이지 줌과 글자 크기 설정을 같다고 보는 함정

이 둘은 동작이 다르다. 페이지 줌은 레이아웃 전체를 키우고, 글자 크기 설정은 텍스트만 키우는 경우가 많다. 한쪽만 점검하고 다른 쪽을 생략하면, 그 경로에서만 나는 막힘을 놓친다. 3장의 동선에서 두 가지를 따로 둔 이유다.

5-3. '보인다'와 '닿는다'를 같다고 보는 함정

버튼이 화면에 보인다고 해서 누를 수 있는 것은 아니다. 다른 요소가 위에 겹쳐 있으면, 보이지만 누르면 다른 것이 반응한다. 점검에서는 눈으로 확인하는 데서 그치지 말고, 실제로 눌러 의도한 동작이 일어나는지까지 확인하는 것이 안전하다.

5-4. 캡처 한 장으로 단정하는 함정

확대 화면을 한 장 찍어 두면 기록에 도움이 되지만, 한 장만으로는 '밀려남·가려짐·붕괴'를 구분하기 어렵다. 스크롤을 움직이며 버튼이 닿는지, 다른 요소가 덮는지를 함께 확인한 뒤에 판단하는 것이 정확하다.

6. 점검 결과를 어떻게 적을 것인가

점검의 가치는 발견을 다시 찾을 수 있게 적어 두는 데 있다. '확대했더니 버튼이 사라졌다'를 다음과 같이 나눠 기록하면, 나중에 누가 봐도 같은 자리를 다시 확인할 수 있다.

어디서: 어느 화면의 어느 단계(예: 신청 화면 3단계)인가
무엇을: 어떤 확대(페이지 줌 / 핀치 줌 / 글자 크기 설정)를 몇 %까지 했는가
무엇이: 어떤 요소(예: '제출' 버튼)가 어떻게 됐는가
어떤 종류: 밀려남 / 가려짐 / 붕괴 중 무엇인가
재현 조건: 어떤 기기·화면 크기에서 일어났는가

이렇게 적힌 기록은 '평가표'가 아니라 '다시 찾아가는 지도'에 가깝다. 우리는 점검의 목적이 점수를 매기는 데 있지 않다고 본다. 확대라는 흔한 동작에서 막히는 사람이 있는지를 확인하고, 그 자리를 다시 찾을 수 있게 남겨 두는 것 — 그것이 줌 점검이 하는 일이다.

기록 항목을 표로 정리하면 다음과 같다.

기록 항목	적는 내용	예
어디서	화면·단계	신청 화면 3단계
무엇을	확대 종류·배율	페이지 줌 200%
무엇이	영향받은 요소·상태	'제출' 버튼이 사라짐
어떤 종류	밀려남/가려짐/붕괴	밀려남
재현 조건	기기·화면 크기	보급형 폰, 글자 키운 상태

(관점) 다섯 항목이 갖춰지면 같은 막힘을 누가 봐도 다시 재현할 수 있다. 기록은 평가가 아니라 재현 가능성을 위한 것이다.

6-1. 반론과 한계

이 점검 관점에도 반론과 한계가 있다.

반론·한계	내용	이 글의 입장
"표·넓은 이미지는 가로가 당연"	일부 콘텐츠는 가로 공간이 본질	인정. 일반 본문·버튼만 막힘으로 봄
"내 폰에선 멀쩡"	큰 기기에선 덜 깨짐	그래서 화면 작은 기기를 함께 봄
정적 점검의 한계	가려짐·닿음은 실제 눌러야 확인	viewport 설정은 자동, 닿음은 사람
수치 단정의 어려움	'200%·400%'는 원문 기준 대조 필요	수치 단정 않고 원문 확인 권장

(관점) 한계를 적는 이유는 이 점검이 '합격·불합격 판정'이 아니라 '막힘을 드러내는 관점'임을 밝히기 위해서다. 확대해도 일을 끝낼 수 있는가 — 그 하나를 본다.

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

줌 점검은 자동 도구가 빠르게 훑는 영역과 사람이 직접 확대해야 하는 영역이 갈린다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
확대 허용	viewport의 `user-scalable`·`maximum-scale`	실제 핀치 줌해 본 느낌
리플로	좁은 폭에서 가로 스크롤 발생 신호	양방향 스크롤의 실제 불편
버튼 닿음	요소 위치·겹침 신호	밀려남/가려짐/붕괴 구분
글자 확대	글자 키운 뒤 넘침·겹침	버튼 기능이 식별되는지
가려짐	고정 요소의 겹침 영역	눌렀을 때 무엇이 반응하는지

(관점) 자동 점검은 viewport 설정·레이아웃 깨짐 같은 '신호'를 빠르게 모으고, 사람은 '확대한 뒤에도 끝까지 닿는가'를 손으로 확인한다. ViewCheck는 둘을 합쳐, 가장 흔한 보조 동작인 확대에서 막히는 사람이 없는지를 본다.

한 장 요약

점검 항목	무엇을 보는가	막힘의 신호
확대 허용	핀치 줌이 되는가	확대 자체가 안 됨(`user-scalable=no` 의심)
200% 본문	글자 겹침·잘림·가로 스크롤	200%에서 이미 가로 스크롤 발생
리플로(좁은 폭)	한 방향 스크롤로 읽히는가	가로·세로 동시 스크롤 강제
주요 버튼	닿는 자리에 있는가	밀려남 / 가려짐 / 붕괴
글자 크기 설정	텍스트만 키웠을 때	버튼 밖 글자 삐짐·줄 겹침

맺으며

확대는 저시력 사용자가 가장 먼저, 가장 자주 쓰는 수단이다. 별도의 도구 없이 지금 이 기기에서 바로 할 수 있기 때문이다. 그래서 '확대했더니 사라진 버튼'은 작은 문제처럼 보여도, 가장 기본적인 보조 동작을 무력화한다는 점에서 무겁다.

이번 편에서 정리한 점검 동선 — 확대가 허용되는지, 200%에서 본문이 읽히는지, 좁은 폭에서 다시 흐르는지, 주요 버튼이 닿는 자리에 있는지, 글자만 키웠을 때 어떻게 되는지 — 은 누구나 따라 할 수 있는 순서다. 우리는 이 점검이 어떤 화면을 합격·불합격으로 가르기 위한 것이 아니라, 확대라는 흔한 동작에서 막히는 사람이 없는지를 함께 확인하기 위한 것이라고 본다. 줌 대응은 특별한 배려가 아니라, 화면을 키운 사람도 똑같이 일을 끝낼 수 있게 하는 기본에 가깝다.

다음 편 예고 (029): 다음 편부터는 '저시력' 묶음으로 넘어갑니다. 화면을 키우는 것만으로는 닿지 않는 영역 — 글자와 배경의 대비, 색만으로 구분되는 정보, 흐릿하게 보이는 경계 — 을 연구 관점에서 살펴봅니다. 029편은 '저시력 사용자에게 화면은 어떻게 보이는가'를 기준 연구의 시선으로 정리합니다.

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

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — 1.4.4 Resize Text, 1.4.10 Reflow, 1.4.11 Non-text Contrast (원문 확인 권장)
W3C, Understanding WCAG 2.1 — Understanding Resize Text / Understanding Reflow
한국웹접근성 관련 지침(KWCAG) — 텍스트 콘텐츠의 명도 대비·크기 조정 관련 항목 (원문 확인 권장)
행정안전부, 「전자정부 웹사이트 품질관리 지침」 — 접근성 영역 (고시 원문 확인 권장)
각 모바일 OS(Android·iOS) 글자 크기·화면 확대 설정 — 버전별 위치 상이, 설정 화면 확인 권장

※ 위 자료의 구체 조항·수치는 인용 시점과 버전에 따라 달라질 수 있어, 실제 적용 전 원문 확인이 안전합니다. 본 글은 연구·관점 정리이며 특정 기관의 평가가 아닙니다.