홈페이지 화면을 확대하면 잘릴 때, 콘텐츠 재배치 점검

400% 확대에서 가로 스크롤 없이 읽히는지 확인하는 WCAG 리플로우 점검 가이드 (2026년 10월 기준, 개발자·디자이너·운영 담당자용)

홈페이지를 브라우저에서 크게 확대했더니 글자가 화면 밖으로 밀려나 문장을 읽을 때마다 좌우로 화면을 끌어야 하는 경험, 한 번쯤 해보셨을 겁니다. 저시력 사용자나 작은 화면에서 큰 글자로 읽는 사용자에게 이 상황은 예외가 아니라 일상입니다.

홈페이지 화면 확대 잘림 문제는 WCAG의 재배치(Reflow) 기준으로 점검할 수 있습니다. 핵심은 "확대했는데 불편해 보이는가"라는 느낌이 아니라, 정해진 기준 뷰포트에서 콘텐츠와 기능이 남아 있고 불필요한 양방향 스크롤이 없는가입니다.

이 글에서는 다음 내용을 순서대로 다룹니다.

① 재배치 기준이 요구하는 것과 320 CSS 픽셀, 400% 확대의 관계
② 본문·폼·이미지·긴 문자열 같은 일반 콘텐츠를 점검하는 방법
③ 표·지도 같은 예외 영역의 범위와 그 한계
④ 고정 헤더, 열 전환, 입력란 등 실제 시험 항목

읽고 나면 직접 브라우저를 열어 웹 콘텐츠 재배치 상태를 스스로 점검할 수 있습니다.

재배치 기준이 요구하는 것: 320 CSS 픽셀과 400% 확대의 관계

2026년 10월 9일 확인 기준, W3C WCAG 2.2의 성공 기준 1.4.10 '재배치(Reflow)'는 AA 기준입니다. W3C 퀵레퍼런스는 이 기준이 WCAG 2.1에서 추가된 AA 기준이라고 표시합니다. 즉 새로 생긴 개념이 아니라, 이미 여러 해 동안 접근성 점검의 표준 항목으로 쓰여 온 기준입니다.

기준의 요구는 단순합니다. 콘텐츠를 확대하거나 축소해도 내용이나 기능이 사라지지 않아야 하고, 예외 콘텐츠를 제외하면 두 방향 스크롤이 필요하지 않아야 합니다. 여기서 두 방향 스크롤이란 세로 스크롤과 가로 스크롤을 함께 써야 읽을 수 있는 상태를 말합니다.

기준 뷰포트: 320 CSS 픽셀 폭

세로로 읽는 일반 페이지는 기준 뷰포트가 320 CSS 픽셀 폭인 경우를 대상으로 합니다. 이 값은 처음 뷰포트 폭이 1280 CSS 픽셀일 때 400% 확대하는 상황과 대응합니다.

1280을 4로 나누면 320입니다. 브라우저를 400%로 확대하면 같은 물리 화면 안에 들어가는 CSS 픽셀 수가 4분의 1로 줄어듭니다. 그래서 데스크톱 창을 400%로 확대하는 것과 폭 320 CSS 픽셀의 좁은 화면을 만드는 것은 같은 조건으로 취급됩니다.

여기서 한 가지 오해를 짚어야 합니다. 400%는 면적이 아니라 너비와 높이 각각에 적용되는 배율입니다. 화면 면적이 4배가 되는 것이 아니라, 가로와 세로가 각각 4배 커진다는 뜻입니다. 그래서 결과적으로 한 줄에 들어가는 글자 수가 크게 줄어들고, 콘텐츠는 세로 방향으로 길게 이어져야 합니다.

가로 읽기 콘텐츠의 기준: 256 CSS 픽셀 높이

가로 스크롤을 전제로 만든 콘텐츠에는 별도 방향의 시험 기준이 있습니다. 예를 들어 세로쓰기처럼 가로 방향으로 읽는 콘텐츠는 256 CSS 픽셀 높이에서 검토하며, 이는 1024 CSS 픽셀 높이에서 400% 확대하는 경우와 대응합니다. 대부분의 한국어 웹페이지는 가로쓰기에 세로 스크롤 구조이므로 320 CSS 픽셀 폭 기준이 주된 점검 대상이 됩니다.

320 CSS 픽셀을 모든 기기 지원 의무로 읽지 마세요

자주 생기는 오해가 하나 있습니다. WCAG 2.2 이해 문서는 320·256 CSS 픽셀 기준이 모든 기기에서 해당 크기의 뷰포트를 지원하라는 뜻은 아니라고 설명합니다. 이 수치는 확대·축소 상황에서 콘텐츠가 어떻게 동작해야 하는지를 시험하기 위한 기준값입니다. "우리 사이트는 320 픽셀짜리 기기에 최적화해야 한다"로 읽으면 기준을 잘못 해석한 것입니다.

판정의 초점은 확대 자체가 아닙니다

판정에서 중요한 것은 사용자가 화면을 확대했는지가 아닙니다. 해당 기준 뷰포트에서 정보·기능 손실과 불필요한 양방향 스크롤이 발생하는지를 봅니다. 일반 본문을 읽을 때 좌우로 반복 이동해야 한다면 재배치 문제를 점검할 필요가 있습니다.

텍스트 확대 기준(1.4.4)과 구별하세요

재배치 기준과 텍스트 확대 기준은 서로 다른 항목입니다. WCAG 1.4.4는 텍스트를 200%까지 키워도 정보·기능 손실이 없어야 한다고 별도로 요구합니다. 반면 1.4.10은 지정된 좁은 뷰포트에서의 재배치를 다룹니다. 전자는 글자 크기 확대, 후자는 화면 전체 확대와 좁은 폭에서의 배치라는 점이 다릅니다. 점검할 때는 두 기준을 각각 따로 시험하는 것이 안전합니다.

일반 본문·폼·이미지·긴 문자열을 점검하는 방법

일반 콘텐츠는 320 CSS 픽셀 폭에서 한 열로 재배치되고 가로 스크롤이 생기지 않는 것이 점검의 기준입니다. 먼저 허용되는 변화와 허용되지 않는 변화를 구분해 두면 점검이 쉬워집니다.

재배치 자체는 손실이 아닙니다

콘텐츠를 한 열로 바꾸거나 영역의 위치를 옮기는 것은 허용됩니다. 재배치 뒤에도 사용자가 해당 콘텐츠와 기능에 접근할 수 있다면, 배치 변화 자체는 정보나 기능 손실로 보지 않습니다. 예를 들어 데스크톱에서 오른쪽에 있던 사이드바가 확대 시 본문 아래로 내려가도 문제가 되지 않습니다. 문제가 되는 것은 사이드바가 화면 밖으로 밀려나 접근할 방법이 없어지는 경우입니다.

열 전환: 미디어 쿼리와 CSS Grid

W3C는 미디어 쿼리와 CSS Grid로 열을 재배치하는 방법을 충분한 기법 사례로 제시합니다. 폭이 넓을 때는 여러 열로 배치하고, 폭이 좁아지면 한 열로 쌓이도록 규칙을 나누는 방식입니다. 다만 이것은 방법의 한 예입니다. 특정 CSS 속성이나 구현 방식 하나만으로 준수 여부를 단정할 수는 없습니다. Grid를 썼으니 통과, 미디어 쿼리가 있으니 통과라고 판단하면 안 되고, 실제로 320 CSS 픽셀 폭에서 결과를 확인해야 합니다.

열 전환을 점검할 때는 다음을 확인합니다.

① 여러 열로 나뉘어 있던 영역이 좁은 폭에서 한 열로 쌓이는가
② 쌓인 뒤에도 읽는 순서가 자연스러운가
③ 각 영역의 내용과 기능이 모두 남아 있는가
④ 영역 하나가 고정 폭이어서 페이지 전체에 가로 스크롤을 만들고 있지 않은가

이미지: 영역을 벗어나지 않게 하기

이미지는 고정 폭을 가진 채 삽입되면 좁은 화면에서 가장 먼저 영역을 넘칩니다. W3C의 이미지 맞춤 기법(C37)은 이미지에 max-width와 높이 조정을 적용해 콘텐츠 영역을 벗어나지 않게 하는 방법을 제시합니다.

다만 이 기법을 다룰 때는 위치를 정확히 알아야 합니다. W3C는 기법 문서가 규범 기준 그 자체는 아니며, 이를 따르는 것만이 적합성 달성 방법은 아니라고 명시합니다. 기준은 1.4.10이고, C37은 그 기준을 달성하는 여러 방법 중 하나로 소개된 권고 기법입니다. 같은 결과를 내는 다른 구현도 얼마든지 가능합니다.

이미지를 점검할 때는 다음을 봅니다.

① 320 CSS 픽셀 폭에서 이미지가 화면 밖으로 나가지 않는가
② 이미지 비율이 찌그러지지 않는가
③ 이미지 안의 글자가 정보 전달에 필요하다면, 줄어든 뒤에도 읽을 수 있는가

세 번째 항목은 특히 주의가 필요합니다. 이미지가 영역에 맞게 줄어들어도 이미지 속 글자가 읽을 수 없을 만큼 작아지면 정보가 손실된 것과 같습니다. 중요한 문구는 이미지 속 글자 대신 실제 텍스트로 두는 편이 안전합니다.

폼: 레이블과 입력란 폭

폼은 입력란 폭이 고정값으로 지정된 경우 좁은 화면에서 쉽게 넘칩니다. W3C는 레이블과 입력란 폭을 조절하는 방법도 충분한 기법 사례로 제시합니다. 레이블이 입력란 왼쪽에 나란히 놓여 있던 구조라면, 좁은 폭에서는 레이블을 입력란 위로 올려 한 열로 쌓는 방식이 대표적입니다.

폼을 점검할 때는 다음 항목을 확인합니다.

① 입력란이 화면 폭 안에 들어오는가
② 레이블과 입력란의 대응 관계가 유지되는가
③ 제출 버튼과 오류 안내가 화면 밖으로 밀리지 않는가
④ 선택 목록이나 날짜 입력 같은 보조 요소가 영역을 넘지 않는가

긴 URL과 긴 문자열

긴 URL이나 공백 없는 긴 문자열은 줄바꿈이 일어나지 않아 영역을 넘치는 대표적인 원인입니다. W3C는 긴 URL·문자열이 넘치지 않게 하는 방법을 기법으로 제시합니다.

여기서 눈여겨볼 점은 긴 URL 기법(C33)의 관점입니다. 이 기법은 긴 URL 자체를 그대로 보여주기보다 읽기 쉬운 링크 텍스트를 쓰는 편이 사용성과 접근성에 더 낫다고 설명합니다. 줄바꿈 설정으로 넘침을 막는 것도 방법이지만, 애초에 "자세히 보기"처럼 의미가 분명한 링크 텍스트를 쓰면 문제 자체가 줄어듭니다. 화면 낭독기 사용자에게도 긴 주소를 한 글자씩 듣는 것보다 의미 있는 링크 이름을 듣는 편이 훨씬 낫습니다.

긴 문자열을 점검할 때는 다음을 봅니다.

① 본문 안의 URL이나 코드, 제품 번호가 영역을 넘치지 않는가
② 긴 단어가 버튼이나 카드 안에서 잘리지 않는가
③ 링크 텍스트가 주소 그대로 노출되어 있다면 의미 있는 텍스트로 바꿀 수 있는가

표·지도 같은 예외 영역의 범위와 한계

예외는 의미나 사용에 2차원 배치가 필요한 콘텐츠에 한정되며, 그 영역 안에서만 인정됩니다. 예외 규정은 편리한 만큼 오해도 많아서, 범위를 정확히 알아 두어야 합니다.

예외가 될 수 있는 콘텐츠

의미나 사용에 2차원 배치가 필요한 콘텐츠는 예외가 될 수 있습니다. 대표적인 예는 다음과 같습니다.

① 표·그리드
② 지도·다이어그램
③ 영상
④ 게임
⑤ 프레젠테이션
⑥ 조작 중 계속 보여야 하는 도구막대

이런 콘텐츠는 억지로 한 열로 펴면 의미가 깨지거나 사용이 불가능해집니다. 열과 행의 관계가 핵심인 표를 한 줄로 늘어놓으면 데이터를 이해할 수 없게 되는 것과 같습니다.

예외는 그 영역에 한정됩니다

가장 중요한 주의점입니다. 예외는 그 콘텐츠 영역에 한정되며, 페이지의 다른 본문까지 가로 스크롤을 허용하는 근거가 되지는 않습니다. 페이지에 표가 하나 있다는 이유로 페이지 전체가 가로로 스크롤되는 구조를 만들면 안 됩니다.

또한 모든 표나 가로 스크롤을 일괄 금지하는 것도 기준의 취지가 아닙니다. 표가 가로 스크롤을 가지는 것 자체는 문제가 아니고, 그 스크롤이 어디에 속해 있는지가 문제입니다.

표를 자체 스크롤 컨테이너로 분리하기

표처럼 예외에 해당하는 영역은 자체 스크롤 컨테이너로 분리할 수 있습니다. 이렇게 하면 표 내부에는 양방향 스크롤이 있어도 본문과 표 주변 콘텐츠는 좁은 폭에 맞춰 재배치될 수 있습니다. 표 안에서만 좌우로 움직이고, 페이지 전체는 세로 스크롤만으로 읽히는 구조입니다.

이 구조를 점검할 때는 다음을 확인합니다.

① 320 CSS 픽셀 폭에서 페이지 전체에 가로 스크롤바가 생기지 않는가
② 표 영역만 별도로 좌우 이동이 가능한가
③ 표 밖의 본문이 좁은 폭에 맞춰 한 열로 재배치되는가
④ 표 안으로 키보드 초점이 이동할 수 있고, 스크롤이 필요한 영역에 키보드로 접근할 수 있는가

표 옆의 제목·검색창·페이지 이동은 예외가 아닙니다

여기서 가장 자주 실수가 나옵니다. 표와 함께 놓인 제목·검색 입력란·페이지 이동 기능은 표의 2차원 배치 예외에 자동 포함되지 않으며 좁은 화면에 맞춰야 합니다.

게시판 목록이나 주문 내역 화면을 떠올려 보면 이해가 쉽습니다. 이런 화면은 보통 이렇게 구성됩니다.

① 화면 제목
② 검색어 입력란과 검색 버튼
③ 데이터 표
④ 하단의 페이지 이동 번호

이 가운데 2차원 배치가 필요한 것은
③번 표뿐입니다. 제목, 검색창, 페이지 이동은 일반 콘텐츠이므로 320 CSS 픽셀 폭에서도 화면 안에 들어와야 합니다. 표가 넓어서 페이지 전체가 가로로 늘어나고, 그 바람에 검색창과 페이지 이동 번호까지 오른쪽 화면 밖으로 밀려나는 구조가 흔한 실패 사례입니다. 표만 자체 컨테이너로 분리하면 나머지 요소는 자연스럽게 좁은 폭에 맞춰집니다.

예외 영역별 점검 요약

예외 가능 콘텐츠와 일반 콘텐츠를 나눠 보면 점검 기준이 한눈에 정리됩니다.

고정 헤더와 가려지는 초점: 확대 시 놓치기 쉬운 점검 항목

고정 헤더·푸터는 확대 시 화면의 큰 부분을 가려 본문 공간을 크게 줄일 수 있습니다. 가로 스크롤이 없어도 고정 영역 때문에 읽을 수 있는 면적이 거의 남지 않는다면 사용성 문제가 됩니다.

왜 확대하면 문제가 커지는가

1280 CSS 픽셀 폭 데스크톱 화면에서는 위쪽에 얇게 붙은 고정 헤더가 거슬리지 않습니다. 그러나 400%로 확대하면 뷰포트는 320 CSS 픽셀 폭에 대응하는 좁고 상대적으로 낮은 공간이 됩니다. 고정 헤더의 높이는 CSS 픽셀로 같아도, 사용자가 실제로 볼 수 있는 세로 공간은 확대에 따라 줄어들어 헤더가 차지하는 비율이 크게 늘어납니다. 위쪽 헤더와 아래쪽 고정 푸터가 함께 있으면 본문이 보이는 영역은 훨씬 더 좁아집니다.

고정 해제 방법

W3C의 관련 기법(C34)은 뷰포트 조건에 따라 고정을 해제하는 방법을 권고 사례로 설명합니다. 넓은 화면에서는 헤더를 고정하고, 좁은 폭이나 확대 상태에서는 일반 흐름대로 문서와 함께 스크롤되게 하는 방식입니다. 이 역시 기준 자체가 아니라 권고 기법이므로, 같은 목적을 달성하는 다른 방법도 있을 수 있습니다.

키보드 초점이 고정 영역 뒤에 가려지는지

C34 기법은 한 가지 주의도 함께 줍니다. 키보드 초점이 고정 영역 뒤에 가려지는지도 함께 점검하라는 것입니다. 키보드로 탭 이동을 하다 보면 현재 초점을 받은 링크나 버튼이 스크롤 위치에 따라 고정 헤더 뒤로 들어가 보이지 않을 수 있습니다. 사용자가 어디에 있는지 알 수 없게 되므로, 확대 상태에서 키보드 이동을 반드시 함께 시험해야 합니다.

고정 영역을 점검할 때는 다음 항목을 확인합니다.

① 320 CSS 픽셀 폭 또는 400% 확대에서 헤더·푸터가 화면의 과도한 부분을 차지하지 않는가
② 고정 영역이 본문 일부를 영구적으로 가리고 있지 않은가
③ Tab 키로 이동할 때 초점이 놓인 요소가 고정 영역 뒤에 숨지 않는가
④ 고정 해제 조건을 두었다면, 해제된 상태에서도 메뉴 접근이 유지되는가
⑤ 고정 도구막대가 조작에 필수라서 예외로 볼 수 있는 경우인지, 단순한 편의 요소인지 구분되는가

마지막 항목은 판단이 필요합니다. 조작 중 계속 보여야 하는 도구막대는 예외가 될 수 있지만, 단순히 편의를 위해 고정한 헤더까지 예외로 삼을 수는 없습니다.

직접 해보는 재배치 점검 절차와 흔한 실수

점검은 브라우저 확대와 폭 조절만으로 시작할 수 있고, 판단은 항상 "정보·기능 손실과 불필요한 양방향 스크롤이 있는가"로 합니다. 아래 절차를 순서대로 따라 하면 됩니다.

점검 절차

Step 1. 브라우저 창을 1280 CSS 픽셀 폭에 가깝게 맞춥니다. 개발자 도구의 반응형 모드에서 폭을 직접 입력하면 정확합니다.

Step 2. 브라우저 확대를 400%까지 올리거나, 개발자 도구에서 폭을 320 CSS 픽셀로 맞춥니다. 두 조건은 서로 대응하므로 어느 쪽으로 시험해도 됩니다.

Step 3. 페이지 위에서 아래까지 천천히 내려가며 가로 스크롤바가 생기는지 확인합니다. 본문을 읽을 때 좌우로 반복 이동해야 한다면 재배치 문제입니다.

Step 4. 메뉴, 검색, 버튼, 입력란, 탭 같은 기능이 모두 남아 있고 조작 가능한지 확인합니다. 보이지 않거나 닿을 수 없는 기능이 있다면 기능 손실입니다.

Step 5. 표·지도 같은 예외 영역이 있다면, 가로 스크롤이 그 영역 안에만 있는지, 주변 콘텐츠는 좁은 폭에 맞춰졌는지 확인합니다.

Step 6. Tab 키로 이동하며 키보드 초점이 고정 헤더나 푸터 뒤에 가려지지 않는지 확인합니다.

Step 7. 별도로 텍스트 크기만 200%까지 키워 정보나 기능이 사라지지 않는지 확인합니다. 이는 1.4.4의 영역이므로 재배치 점검과 따로 시험합니다.

점검 결과를 판정하는 기준

시험 결과는 다음 질문으로 판정합니다.

① 320 CSS 픽셀 폭에서 정보나 기능이 사라졌는가
② 예외 영역이 아닌 콘텐츠에서 가로 스크롤이 필요한가
③ 예외로 주장하는 영역이 실제로 2차원 배치를 필요로 하는가
④ 예외 영역의 스크롤이 그 영역 밖으로 번져 있지 않은가

흔한 실수

점검 과정에서 자주 마주치는 실수는 다음과 같습니다.

첫째, 특정 CSS 사용 여부로 통과를 단정하는 것입니다. max-width를 썼다, 미디어 쿼리를 넣었다는 사실만으로는 충분하지 않습니다. 결과를 320 CSS 픽셀 폭에서 직접 봐야 합니다.

둘째, 표 하나 때문에 페이지 전체의 가로 스크롤을 허용하는 것입니다. 예외는 표 영역 안으로 한정해야 합니다.

셋째, 표 옆의 검색창과 페이지 이동까지 예외로 보는 것입니다. 이들은 좁은 화면에 맞춰야 합니다.

넷째, 320 CSS 픽셀을 모든 기기 지원 의무로 오해하는 것입니다. 이 값은 확대 상황을 시험하기 위한 기준입니다.

다섯째, 재배치와 텍스트 확대를 같은 기준으로 묶는 것입니다. 1.4.10과 1.4.4는 각각 따로 시험해야 합니다.

여섯째, 기법 문서를 기준 자체로 착각하는 것입니다. C37, C33, C34 같은 기법은 달성 방법의 사례이지 필수 구현 방식이 아닙니다.

일곱째, 화면 모양만 보고 정보 손실을 놓치는 것입니다. 가로 스크롤이 없어도 메뉴가 숨겨져 접근할 수 없다면 기능 손실입니다.

판단이 애매할 때

예외 여부가 애매하다면 먼저 "이 콘텐츠를 한 열로 펴면 의미나 사용이 깨지는가"를 물어보세요. 깨지지 않는다면 일반 콘텐츠로 보고 재배치하는 쪽이 맞습니다. 깨진다면 그 영역만 자체 컨테이너로 분리하고, 주변은 좁은 폭에 맞추는 구조를 택합니다. 예외를 넓게 해석할수록 접근성 문제를 키울 수 있으므로, 의심스러우면 예외 범위를 좁게 잡는 것이 안전합니다.

자주 묻는 질문

Q. 모바일 반응형 홈페이지라면 재배치 기준은 자동으로 충족되나요?

그렇지 않습니다. 반응형으로 만들었다고 해서 400% 확대나 320 CSS 픽셀 폭의 시험을 통과한다고 단정할 수 없습니다. 휴대폰 화면에서 잘 보이는 구조여도, 고정 폭 요소나 넓은 표, 긴 문자열이 특정 조건에서 영역을 넘칠 수 있습니다. 반응형 홈페이지 접근성은 구현 방식이 아니라 실제 시험 결과로 판단하세요.

Q. 가로 스크롤이 조금이라도 생기면 무조건 기준 위반인가요?

그렇지 않습니다. 기준은 가로 스크롤 자체를 일괄 금지하지 않습니다. 표·지도 같은 예외 콘텐츠는 그 영역 안에서 2차원 이동이 허용됩니다. 문제가 되는 것은 일반 본문처럼 예외가 아닌 콘텐츠를 읽기 위해 좌우로 반복 이동해야 하는 경우입니다.

Q. 표를 모바일에서 카드 형태로 바꾸는 것도 방법인가요?

표의 구조를 다른 형태로 바꾸는 것도 선택지가 될 수 있습니다. 중요한 것은 바꾼 뒤에도 정보의 관계와 기능이 유지되는가입니다. 표를 그대로 두고 자체 스크롤 컨테이너로 분리하는 방식과 구조를 바꾸는 방식 중 어느 쪽이 적합한지는 데이터의 성격에 따라 달라집니다. 특정 방식이 필수라고 단정할 수는 없습니다.

마무리: 느낌이 아니라 기준 뷰포트에서 판단하세요

홈페이지 화면 확대 잘림은 감각이 아니라 기준 뷰포트에서의 결과로 점검합니다. 핵심은 세 가지로 정리됩니다.

① 세로로 읽는 일반 페이지는 320 CSS 픽셀 폭, 곧 1280 CSS 픽셀 폭에서 400% 확대한 상황에서 정보·기능 손실과 불필요한 양방향 스크롤이 없는지를 봅니다.
② 표·지도 같은 예외는 그 영역 안에서만 인정되며, 표 옆의 제목·검색창·페이지 이동은 좁은 화면에 맞춰야 합니다.
③ C37·C33·C34 같은 기법은 달성을 돕는 권고 사례이므로, 구현 방식이 아니라 실제 시험 결과로 판정합니다.

오늘 바로 해볼 수 있는 일은 간단합니다. 운영 중인 홈페이지를 열어 폭을 320 CSS 픽셀로 맞추고, 위에서 아래까지 내려가며 가로 스크롤과 사라지는 기능을 확인해 보세요. 한 번의 점검만으로도 재배치 문제가 어디에 몰려 있는지 분명히 보입니다.