[접근성연구·모바일] '다음' 버튼이 화면 밖에

모바일 폼 점검 관점

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

들어가며

신청서를 다 채웠다. 이름도, 연락처도, 동의도 마쳤다. 이제 '다음'이나 '제출'만 누르면 끝이다. 그런데 그 버튼이 보이지 않는다. 화면을 아래로 내려도 키보드가 가로막고, 키보드를 닫으면 버튼이 어디 있는지 다시 찾아야 한다. 입력은 다 끝났는데, 마지막 한 번의 누름에 닿지 못해 멈춘다.

앞 편(021)에서 모바일 폼 완결성의 전체 그림을 그렸다면, 이번 편은 그 완결을 막는 가장 흔한 한 가지 증상에 집중한다. ''다음' 버튼이 화면 밖에' 있는 상황이다. 입력을 마치고도 다음 단계로 넘어가지 못하는 이 막힘은, 폼에서 가장 자주 보고되는 완결 실패다.

이 글은 그 막힘을 점검의 시선으로 다룬다. 왜 버튼이 화면 밖으로 밀려나는지, 어떤 상황에서 가려지는지, 그리고 점검에서 이 막힘을 어떻게 미리 찾아낼지를 정리한다. 특정 사이트를 지목하지 않고, 반복되는 패턴을 익명으로 모아 점검 관점으로 풀어낸다.

1. 버튼은 왜 화면 밖으로 밀려나나

핵심 버튼이 손에 닿지 않는 데는 몇 가지 정해진 원인이 있다.

첫째, 키보드가 버튼을 덮는다. 입력란을 누르면 화면 아래 절반가량을 키보드가 차지한다. 그런데 제출 버튼이 폼 맨 아래, 즉 화면 하단에 고정되어 있다면, 키보드가 올라온 순간 그 버튼은 키보드 뒤에 가려진다. 사용자는 버튼이 거기 있다는 것을 알아도 누를 수가 없다.

둘째, 폼이 너무 길어 버튼이 한참 아래에 있다. 입력란이 세로로 길게 쌓이면, 마지막 버튼까지 가려면 여러 번 스크롤해야 한다. 사용자가 '이게 끝인가' 싶은 지점에서 멈추면 버튼에 닿지 못한다.

셋째, 화면 하단의 고정 영역과 겹친다. 휴대폰 화면 맨 아래에는 주소창·홈 표시줄 같은 시스템 영역이 있다. 버튼이 이 영역과 겹치거나 그 아래로 밀리면, 일부가 잘려 누르기 어려워진다.

세 원인을 발생 조건·증상으로 정리하면, 막힘을 만났을 때 어디를 의심할지 가닥이 잡힌다.

원인	발생 조건	사용자가 보는 증상
키보드가 덮음	입력란을 눌러 키보드가 올라옴	하단 고정 버튼이 키보드 뒤로 사라짐
폼이 너무 긺	입력란이 세로로 길게 쌓임	'끝인 줄' 알고 멈춰 버튼에 못 닿음
하단 시스템 영역과 겹침	버튼이 화면 맨 아래에 배치	주소창·홈 표시줄에 일부 잘림

1-1. '있는데 못 누르는' 것이 가장 답답하다

이 막힘의 특이한 성질은, 버튼이 '없는' 게 아니라 '있는데 못 누르는' 것이라는 데 있다. 사용자는 버튼이 거기 있다는 것을 안다. 입력도 다 끝냈다. 그래서 포기하기도 애매하고, 계속 시도하다 지친다. 아예 없는 것보다, 보이는데 닿지 않는 것이 더 답답한 경험을 만든다. 점검에서 이 막힘을 중요하게 봐야 하는 이유다.

2. 어떤 상황에서 가려지나 — 막힘의 조건

같은 폼이라도 버튼이 가려지는지는 상황에 따라 달라진다. 점검은 이 '가려지는 조건'을 재현하는 데서 시작한다.

입력란을 누른 상태. 평소엔 보이던 버튼이 입력란을 눌러 키보드가 올라온 순간 가려진다. 그래서 키보드를 닫은 상태로만 보면 막힘을 놓친다. 점검은 반드시 키보드가 올라온 상태에서 버튼을 확인해야 한다.

작은 기종. 화면이 작을수록 키보드가 차지하는 비율이 커지고, 볼 수 있는 폼 영역이 줄어든다. 큰 기종에서는 닿던 버튼이 작은 기종에서는 가려질 수 있다.

가로 모드. 화면을 가로로 돌리면 세로 높이가 더 줄어든다. 키보드가 올라오면 남는 세로 공간이 거의 없어, 버튼이 가려질 확률이 높아진다.

확대 상태. 글자를 키우거나 화면을 확대하면 같은 화면에 들어오는 영역이 줄어, 버튼이 보이는 범위 밖으로 밀려나기 쉽다.

네 가지 가려지는 조건을, 유리한 조건과 불리한 조건의 대비로 정리하면 점검에서 무엇을 재현해야 할지 분명해진다.

조건	유리한 상태(잘 보임)	불리한 상태(가려짐)	점검에서 재현할 것
키보드	닫힌 상태	입력란 눌러 올라온 상태	키보드 올린 채 버튼 확인
기종 크기	큰 기종	작은 기종	작은 화면 너비로 확인
화면 방향	세로 모드	가로 모드	가로로 돌려 확인
글자·확대	기본 크기	키운 글자·확대	확대 상태로 확인

2-1. '내 환경에서 됨'의 함정

작업자는 보통 큰 기종, 세로 모드, 기본 글자 크기로 점검한다. 그 조건에서는 버튼이 닿을 수 있다. 그러나 사용자는 작은 기종, 가로 모드, 키운 글자로 쓸 수 있다. '내 환경에서 된다'는 것은 점검의 끝이 아니라, 가장 유리한 조건 하나만 확인했다는 뜻이다. 막힘은 대개 불리한 조건의 조합에서 드러나므로, 점검은 의식적으로 불리한 조건을 만들어 확인해야 한다.

3. 표준은 이 막힘을 어떻게 보나

버튼이 가려져 누를 수 없는 상황은 미관의 문제가 아니라 '기능에 도달하지 못하는' 접근성의 문제다. 웹 콘텐츠 접근성 지침(WCAG)과 한국형 웹 콘텐츠 접근성 지침(KWCAG)이 공통으로 가리키는 방향은, 콘텐츠를 좁혀도(Reflow) 한 방향 스크롤만으로 내용과 기능에 닿을 수 있어야 한다는 것이다. 버튼이 화면 밖으로 밀려나 양방향으로 스크롤하거나 키보드를 닫는 별도 동작을 해야만 닿는 상황은 이 방향과 어긋난다.

또한 입력 폼의 '제출' 같은 핵심 동작은 사용자가 명확히 도달하고 작동시킬 수 있어야 한다는 일반 원칙과도 맞닿는다. 다만 '버튼이 키보드에 가려지면 안 된다'는 식의 구체적 수치 규정이 별도 항목으로 명문화되어 있다고 단정하기보다는, '기능에 닿을 수 있어야 한다'는 상위 취지에서 이 막힘을 해석하는 편이 정확하다. 정확한 항목·등급은 지침 원문과 공공 디자인 기준(KRDS)의 폼 관련 문서에서 확인하는 것이 안전하다.

4. 관찰 — 닿지 않는 버튼들

공공 영역의 신청·문의 폼을 모바일에서 끝까지 밟아본 관찰을 익명으로 정리한다.

한 장면에서는 마지막 입력란을 채운 뒤 제출 버튼이 키보드 뒤에 완전히 가려, 화면의 빈 곳을 눌러 키보드를 닫아야만 버튼이 나타났다. 키보드를 닫는 법을 모르는 사용자라면 입력을 다 하고도 거기서 멈췄을 것이다. 다른 장면에서는 폼이 매우 길어, 입력을 마친 줄 알고 멈췄던 지점 아래에 제출 버튼이 더 있었다. 진행 표시가 없어, 사용자는 자신이 끝에 닿았는지 알 수 없었다.

또 다른 장면에서는 화면을 가로로 돌린 상태에서 입력하자, 키보드가 화면 대부분을 덮어 버튼은 물론 입력 중인 칸조차 보이지 않았다. 세로 모드에서는 문제가 없었으나, 가로 모드라는 조건이 더해지자 폼이 사실상 쓸 수 없게 되었다. 이 장면들 모두 '특정 조건에서만' 막혔다는 공통점이 있다. 그래서 한 조건만 확인한 점검으로는 잡히지 않는다.

세 관찰 장면을 막힌 조건·사용자 결과로 정리한다.

관찰 장면(익명)	막힌 조건	사용자 결과
제출 버튼 가려짐	키보드 올라온 상태	빈 곳 눌러 키보드 닫아야 버튼 등장
폼이 매우 긺	진행 표시 없음	'끝인 줄' 알고 멈춰 제출 못 함
가로 모드 입력	가로 회전+키보드	버튼·입력 칸조차 안 보임

세 장면 모두 '특정 조건에서만' 막혔다. 익명 관찰이며, 정확한 원인은 각 폼의 구현을 직접 확인해야 단정할 수 있다. (관찰)

4-1. 막힘은 '완료 직전'에 가장 비싸다

이 막힘이 특히 아픈 이유는, 사용자가 모든 입력을 마친 '완료 직전'에 발생하기 때문이다. 들인 시간과 노력이 가장 큰 순간에 막히면, 포기의 손실도 가장 크다. 처음 한두 칸에서 막히는 것보다, 다 채우고 제출에서 막히는 것이 사용자에게 훨씬 큰 좌절을 남긴다. 점검에서 '제출 도달'을 마지막까지 따라가야 하는 실질적 이유다.

5. 점검의 관점 — 가려진 버튼을 찾아내려면

이 막힘은 실제 휴대폰에서 불리한 조건을 만들어 확인하는 것으로 가장 잘 드러난다. 점검의 시선은 다음과 같다.

입력란을 눌러 키보드가 올라온 상태에서 제출·다음 버튼이 보이고 닿는가. 작은 기종에서도 같은 버튼에 닿는가. 화면을 가로로 돌린 상태에서 입력하고 제출까지 닿는가. 글자를 키우거나 화면을 확대한 상태에서도 버튼이 보이는 범위 안에 있는가. 폼이 길다면, 사용자가 '제출 버튼이 더 아래에 있다'는 것을 알 수 있는 안내나 진행 표시가 있는가.

각 조건을 하나씩 만들어 '제출 완료 화면'까지 직접 닿아보는 것이 점검의 핵심이다. 어느 한 조건에서라도 버튼에 닿지 못한다면, 그 조건의 사용자에게 폼은 미완결이다.

5-1. 점검 결과를 조건과 함께 기록하기

이 막힘은 조건 의존적이므로, 기록도 조건과 함께 남겨야 한다. '제출 버튼 가려짐'만 적으면 다음에 재현하기 어렵다. '○○ 페이지 신청 폼 / 작은 기종 / 가로 모드 / 키보드 올라온 상태에서 제출 버튼 가려짐'처럼 조건을 함께 적으면, 무엇을 고쳐야 하고 어떻게 재확인할지가 분명해진다. 조건 없는 기록은 재현 없는 보고가 되어 흐지부지되기 쉽다.

점검 조건 조합별로 무엇을 확인할지 매트릭스로 정리하면, 빠뜨림 없이 불리한 조합을 훑을 수 있다.

점검 조합	확인 질문	통과 기준
키보드 올림	입력 중에도 제출 버튼이 보이고 닿는가	별도 동작 없이 제출 가능
작은 기종	작은 화면에서도 같은 버튼에 닿는가	가려짐 없음
가로 모드	가로로 돌려 입력·제출까지 닿는가	입력 칸·버튼 모두 보임
확대 상태	글자 키운 채 버튼이 범위 안에 있는가	보이는 범위 유지
긴 폼	제출이 더 아래 있음을 알 수 있는가	진행/안내 표시 존재

5-2. 반론·한계 — 이 점검의 약점

조건 의존적 막힘 점검에도 반론과 한계가 있다.

반론·한계	내용	보완 방향
"조건 조합이 너무 많다"	기종×방향×확대×키보드 경우의 수가 큼	가장 불리한 조합 몇 개로 우선 표본 점검
"기기마다 키보드가 다르다"	키보드 높이·동작이 OS·앱별로 다름	대표 기기로 표본, 단정은 보류
"사람이 매번 밟기 부담"	폼이 많으면 전수 어려움	자동 점검으로 버튼 위치 선별 후 사람 확인
"기준 항목은 확정이 아니다"	'키보드 가림 금지' 명문 항목 단정 곤란	상위 취지(기능 도달)에서 해석, 원문 대조

'내 환경에서 됨'은 가장 유리한 한 조건만 본 것이다. 점검은 의식적으로 불리한 조합을 만들어 확인할 때 의미가 있다. (관점)

5-3. ViewCheck 관점 — 가려진 버튼 점검의 분담

가려진 버튼 점검에서 사람과 자동 점검의 분담을 표로 정리한다. 특정 도구 사용을 권하는 것이 아니라 구조만 둔다.

점검 항목	자동 점검이 잘하는 것	사람이 잘하는 것
버튼 위치	제출 버튼의 좌표·하단 고정 여부 식별	키보드가 올라온 실제 상황에서 가림 체감
화면 방향	가로/세로 레이아웃을 자동 캡처·비교	가로 모드에서 실제 조작 가능성 판단
확대 대응	확대 시 요소 위치 변화 추적	확대 상태의 실제 도달감 확인
완료 도달	제출 버튼 존재를 구조적으로 확인	제출 완료 화면까지 끝까지 밟아 확인

자동 점검은 버튼의 위치·고정 여부를 빠르게 짚고, 사람은 '실제 조건에서 닿는가'를 판정한다. 둘의 분담이 조건 의존적 막힘을 촘촘히 잡는다. (관점)

6. 한 장 요약

구분	핵심
증상	입력을 마치고도 제출·다음 버튼에 닿지 못함
원인	키보드가 덮음·폼이 너무 긺·하단 시스템 영역과 겹침
성질	'없는' 게 아니라 '있는데 못 누름' — 더 답답함
가려지는 조건	키보드 올라온 상태·작은 기종·가로 모드·확대
표준 방향	좁혀도 기능에 닿아야(Reflow), 핵심 동작에 도달 가능 (항목은 원문 확인)
막힘의 비용	'완료 직전'에 발생해 손실이 가장 큼
점검 핵심	불리한 조건을 만들어 제출 완료까지, 조건과 함께 기록

맺으며

''다음' 버튼이 화면 밖에' 있는 상황은 작아 보이지만, 사용자가 들인 모든 노력을 마지막 한 번의 누름에서 무너뜨린다. 버튼이 없는 게 아니라 닿지 않는다는 점에서 더 답답하고, 입력을 모두 마친 완료 직전에 발생한다는 점에서 손실이 가장 크다. 그리고 이 막힘은 키보드가 올라온 상태, 작은 기종, 가로 모드, 확대 같은 불리한 조건에서만 드러나기에, 유리한 한 조건만 본 점검으로는 잡히지 않는다.

우리는 이 막힘을 '버튼의 위치 문제'가 아니라 '기능 도달의 문제'로 본다. 점검은 의식적으로 불리한 조건을 만들어 제출 완료까지 직접 닿아보고, 그 조건을 기록으로 남길 때 비로소 막힘을 미리 걷어낼 수 있다. 다음 편에서는 모바일에서 또 다른 흔한 붕괴, 즉 '가로 스크롤은 왜 생기나'라는 고정 너비 사고의 문제로 넘어간다.

다음 편 예고 (023): 〈가로 스크롤은 왜 생기나 / 고정 너비 사고 연구〉 — 좁은 화면을 옆으로 밀어내는 가로 스크롤. 그 뒤에 숨은 '고정 너비'라는 사고방식이 어떻게 붕괴를 만드는지 기준 연구의 관점에서 들여다본다.

---

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

• W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — Reflow(1.4.10), Labels or Instructions(3.3.2), Orientation(1.3.4) 등 (정확한 항목·등급은 원문 확인 권장)
• 한국지능정보사회진흥원(NIA), 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.x — 입력·기능 도달 관련 항목
• 행정안전부·디지털플랫폼정부, KRDS(공공 디자인 시스템) 폼·버튼 관련 공개 문서
• MDN Web Docs — Virtual keyboard, Forms, Viewport units 개요