WCAG 성공 기준 · Level AA
WCAG 1.4.4: 텍스트 크기 조정
- WCAG 1.4.4는 보조 기술 없이도 텍스트를 최대 200%까지 확대할 수 있어야 하며, 이때 콘텐츠나 기능의 손실이 없어야 한다고 요구한다. 이 기준은 브라우저 확대 기능이나 사용자 지정 글꼴 크기 설정에 의존해 웹 콘텐츠를 편안하게 읽는 저시력 사용자에게 필수적이다.
- Level AA
- Wcag
- Wcag 2 2 aa
- 지각 가능
- 접근성
이 규칙의 의미
WCAG 1.4.4 Resize Text (Level AA)는 보조 기술을 사용하지 않고도 텍스트를 최대 200퍼센트까지 확대할 수 있어야 하며, 이때 콘텐츠나 기능의 손실이 없어야 한다고 규정한다. 쉽게 말해, 사용자가 브라우저를 200%로 확대하거나 브라우저 또는 운영 체제 설정을 통해 기본 글꼴 크기를 키웠을 때, 페이지의 모든 텍스트는 여전히 읽을 수 있어야 하고 모든 기능은 그대로 작동해야 한다는 뜻이다.
이 기준은 웹 페이지에 렌더링되는 모든 텍스트에 폭넓게 적용된다. 본문 텍스트, 제목, 레이블, 버튼 텍스트, 폼 필드 안의 플레이스홀더 텍스트, 내비게이션 링크, 표 내용, 캡션 등이 모두 포함된다. 로고나 브랜드 이름의 일부인 텍스트에는 적용되지 않으며, 정보 전달 없이 순수하게 이미지 콘텐츠로만 제공되는 장식용 텍스트(예: 텍스트 자체가 접근 가능한 콘텐츠가 아닌, 손글씨 메모를 스캔한 사진 등)에도 적용되지 않는다.
통과하려면 200% 확대 상태에서 — 브라우저의 기본 페이지 확대 기능(Ctrl/Cmd + 플러스 키 또는 View > Zoom 메뉴)이나 브라우저의 최소 글꼴 크기 설정을 통해 달성한 200%에서 — 다음 조건이 모두 충족되어야 한다. 어떤 텍스트도 컨테이너에 의해 잘리거나 숨겨지지 않아야 하고, 텍스트가 다른 텍스트나 인터랙티브 요소와 겹치지 않아야 하며, 전체 뷰포트 너비에서 가로 스크롤바가 나타나지 않아야 한다(지도나 데이터 테이블처럼 실제로 2차원 스크롤이 필요한 콘텐츠는 예외). 또한 모든 인터랙티브 컨트롤이 계속 조작 가능해야 한다.
실패로 기록되는 경우는 다음과 같다. 고정 픽셀 값으로 텍스트 크기를 고정해 확대가 불가능하게 만든 경우, 고정 높이 컨테이너를 사용해 넘치는 텍스트를 잘라내는 경우, 뷰포트 메타 태그에서 user-scalable=no 또는 maximum-scale=1.0을 사용해 모바일에서 핀치 줌을 차단하는 경우, JavaScript가 확대 제스처를 가로채서 스케일링을 막는 경우 등이다. 이 기준은 명시적으로 기술 중립적이다. 구현에 CSS, SVG 텍스트, 캔버스 렌더링 텍스트 중 무엇을 사용하든, 사용자에게 어떤 결과를 제공하는지가 중요하다. SVG 텍스트와 캔버스 렌더링 텍스트는 본질적으로 크기 조정이 어렵고, 추가적인 엔지니어링 작업이 필요한 경우가 많다는 점에 유의해야 한다.
왜 중요한가
세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있다. 이들 중 상당수는 저시력에 해당한다. 저시력은 안경이나 콘택트렌즈로 완전히 교정할 수는 없지만, 완전 실명은 아닌 상태를 말한다. 저시력 사용자는 브라우저 확대를 150%, 200% 또는 그 이상으로 설정하거나, 운영 체제에서 텍스트를 더 큰 기본 크기로 렌더링하도록 설정하는 경우가 흔하다. 웹사이트가 이러한 행동을 차단하거나 깨뜨리면, 이 사용자는 콘텐츠에서 완전히 배제된다.
진단된 저시력 외에도, 상황적 요인은 사실상 모든 인터넷 사용자에게 어느 시점에는 영향을 미친다. 작은 화면, 강한 햇빛, 피로, 노화로 인한 시력 저하, 익숙하지 않은 언어로 읽기 등은 모두 작은 텍스트를 해독하기 어렵게 만든다. 특히 고령층은 — 전 세계적으로, 그리고 터키에서도 빠르게 증가하는 인구 집단인데 — 특수 보조 기술을 찾기 전에 1차적인 접근성 수단으로 확대 기능에 자주 의존한다.
구체적인 상황을 하나 생각해 보자. 60대 환자가 스마트폰으로 병원 포털에서 온라인 진료 예약 확인서를 읽으려 한다. 병원의 모바일 스타일시트는 본문 글꼴 크기를 고정 픽셀 값인 12px로 설정해 두었고, 뷰포트 메타 태그에는 maximum-scale=1.0이 포함되어 있다. 환자가 핀치 줌을 시도하지만 인터페이스가 확대를 막는다. 날짜나 진료과 이름을 확신할 만큼 분명하게 읽을 수 없다. 결국 병원 헬프데스크에 전화를 걸어 직원의 시간을 소모하게 되고, 환자에게는 불안감을 초래한다. 이 모든 것은 이 기준을 지켰다면 완전히 예방할 수 있었던 결과다.
순수하게 상업적인 관점에서도, 접근 가능한 텍스트 크기 조정은 모든 사용자에게 이득이 되는 전반적인 사용성 향상과 상관관계를 가진다. 검색 엔진 역시 일반 크기와 확대된 크기에서 읽기 쉬운 텍스트를 렌더링하는 사이트에 가점을 부여한다. Googlebot은 Core Web Vitals와 페이지 경험 순위 요소의 일부로 가독성 신호를 평가하기 때문이다. 따라서 크기 조정 문제를 해결하면 SEO가 개선되고, 지원 부담이 줄어들며, 잠재적인 사용자층이 확대되는 효과를 동시에 얻을 수 있다.
관련 Axe-core 규칙
WCAG 1.4.4는 주로 수동 테스트 기준이다. 자동화 도구는 텍스트 크기 조정을 방해하는 것으로 알려진 일부 조건만을 표시할 수 있으며, 200% 확대 상태에서의 모든 레이아웃 결과를 신뢰할 수 있게 시뮬레이션하고 평가할 수는 없다. 자동화 도구가 탐지하려고 시도하는 조건과, 그에 대해 수동 후속 조치가 필요한 항목은 다음과 같다.
- 뷰포트 메타 태그가 확대를 차단하는 경우(수동 확인 필요): Axe-core에는
meta-viewport규칙이 포함되어 있으며,user-scalable=no를 설정하거나maximum-scale을 1.0 이하로 설정한 모든<meta name='viewport'>태그를 표시한다. 이 경우는 위반이 선언적으로 드러나고 레이아웃 결과에 의존하지 않기 때문에, 완전 자동 탐지가 가능한 유일한 시나리오다. 그러나 이 규칙만으로는 사이트가 JavaScript를 사용해 프로그램적으로 확대를 차단하는지 여부를 알 수 없으므로, 항상 수동 검증이 필요하다. - 픽셀 단위의 고정 글꼴 크기(수동 확인 필요): 자동화 도구는 CSS의 font-size 값이 상대 단위(
em,rem,%또는 뷰포트 상대 단위)가 아니라 절대 픽셀 단위(px)로 설정된 경우를 보고할 수 있다. 그러나 현대 브라우저는 사용자가 브라우저 기본 글꼴 크기를 변경하면 절대 픽셀 글꼴 크기를 재정의하므로, 픽셀 값만으로는 실패가 보장되지는 않는다. 이는 브라우저 동작과 사이트가font-size상속을 어떻게 처리하는지에 따라 달라진다. 실제 실패 여부를 확인하려면 계산된 스타일을 수동으로 검사하고 시각적으로 검증해야 한다. - 200% 확대 시 콘텐츠 넘침과 잘림(수동만 가능): 어떤 자동화 도구도 페이지를 200%로 렌더링한 뒤 모든 텍스트가 계속 보이는지, 모든 인터랙티브 요소가 계속 조작 가능한지를 신뢰할 수 있게 평가할 수 없다. 이는 사람 테스트 담당자가 브라우저 확대 수준을 설정하고, 페이지를 스크롤하며, 각 콘텐츠 영역을 확인해야 한다. 자동화 도구는 확대 이후의 렌더링 상태에 접근할 수 없다.
- 이미지와 캔버스 안의 텍스트(수동만 가능): 래스터 이미지(
<img>태그에 포함된 텍스트 스크린샷 등)에 포함된 텍스트나<canvas>요소에 렌더링된 텍스트는 브라우저에서 전혀 크기 조정할 수 없다. 자동화 도구는 수동 검토를 위해 캔버스 요소의 존재를 표시할 수 있지만, 해당 캔버스 요소에 사용자가 읽어야 할 의미 있는 텍스트가 포함되어 있는지 여부는 판단할 수 없다.
테스트 방법
- 먼저 자동 스캔을 실행한다. Chrome 또는 Firefox에서 페이지를 열고 axe DevTools(브라우저 확장) 또는 Lighthouse(Chrome DevTools의 Lighthouse 탭)를 실행한다. 특히
meta-viewport규칙 위반이 있는지 확인한다. 표시되면 치명적인 실패로 기록한다. 또한 axe best-practices 경고에 나타나는px단위의 font-size 선언이 CSS 감사 결과에 있는지 확인한다. - 소스에서 뷰포트 메타 태그를 확인한다. DevTools(F12)를 열고 Elements 탭으로 이동한 뒤
meta name='viewport'를 검색한다. content 속성을 주의 깊게 읽는다. 여기에user-scalable=no,user-scalable=0또는maximum-scale=1(또는 2보다 작은 값)이 포함되어 있다면, 이는 1.4.4의 직접적인 실패다. - 브라우저 확대를 200%로 설정한다. Chrome 또는 Firefox에서 Ctrl + 플러스(Windows/Linux) 또는 Cmd + 플러스(macOS)를 반복해서 눌러 브라우저 확대 표시가 200%가 될 때까지 키운다. 또는 View > Zoom In 메뉴를 사용한다. macOS Safari에서는 View > Zoom In을 사용한다. 이 테스트에서는 운영 체제 수준의 디스플레이 스케일링을 사용하지 말고, 반드시 브라우저 확대 기능을 사용해야 한다.
- 200% 확대 상태에서 페이지의 모든 섹션을 스크롤한다. 위에서 아래까지 체계적으로 스크롤한다. 컨테이너에 의해 잘리거나 숨겨지는 텍스트, 박스를 넘쳐 인접 콘텐츠와 겹치는 텍스트, 입력 필드 뒤로 사라지는 폼 레이블, 텍스트가 잘려 나가는 버튼, 화면 밖으로 뻗어나가 스크롤할 수 없는 드롭다운 메뉴, 뷰포트를 넘어가지만 스크롤할 수 없는 모달 대화상자 등을 찾는다.
- 200% 확대 상태에서 모든 인터랙티브 기능을 테스트한다. 모든 내비게이션 메뉴를 열고, 모든 모달을 띄우고, 폼을 제출하고, 툴팁과 팝오버를 트리거하며, 캐러셀이나 아코디언이 있다면 모두 조작해 본다. 이 모든 것이 단지 시각적으로 보이는 것에 그치지 않고 완전히 조작 가능한지 확인한다.
- NVDA + Firefox(Windows)로 테스트한다. NVDA를 활성화하고 Firefox를 200% 확대 상태로 연다. Tab 키와 방향키로 탐색한다. 포커스를 받을 수 있는 요소가 실제로 포커스를 받는지, 포커스 표시가 보이는지(WCAG 2.4.7과도 관련 있지만 유용한 확인 사항), 확대된 크기에서 읽기 순서가 시각적 순서와 일치하는지 확인한다.
- VoiceOver + Safari(macOS/iOS)로 테스트한다. VoiceOver를 활성화한다. iOS에서는 설정 > 손쉬운 사용 > 디스플레이 및 텍스트 크기로 이동해 더 큰 텍스트를 활성화한다. 같은 페이지를 탐색하며 콘텐츠의 무결성을 확인한다. 또한 핀치 줌 제스처를 사용해 확대가 차단되지 않는지도 확인한다.
- 브라우저 최소 글꼴 크기 설정을 테스트한다. Firefox에서 설정 > 일반 > 글꼴 및 색상으로 이동해 최소 글꼴 크기를 24px로 설정한다. 페이지를 새로고침하고 모든 텍스트가 이 최소 크기를 충족하는지, 레이아웃이 깨지지 않는지 확인한다. 이는 같은 기준을 다른 경로로 테스트하는 것이다.
- JAWS + Chrome(Windows)으로 테스트한다. JAWS를 활성화한 상태에서 Chrome에서 페이지를 200% 확대 상태로 연다. JAWS 읽기 명령(Insert + 아래쪽 화살표로 커서부터 읽기)을 사용해 모든 텍스트 콘텐츠가 읽히는지, 오버플로우 잘림 때문에 숨겨진 콘텐츠가 건너뛰어지지 않는지 확인한다.
해결 방법
뷰포트 메타 태그가 확대를 차단하는 경우 — 잘못된 예
<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>
뷰포트 메타 태그가 확대를 차단하는 경우 — 올바른 예
<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>
픽셀 단위 고정 글꼴 크기 — 잘못된 예
<!-- WRONG: font-size in px ignores the user's browser font-size preference.
If the user sets a larger default, px values override that preference. -->
<style>
body {
font-size: 14px;
}
h1 {
font-size: 24px;
}
.caption {
font-size: 11px;
}
</style>
<p>Your appointment is confirmed.</p>
픽셀 단위 고정 글꼴 크기 — 올바른 예
<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
1rem = 16px by default, but scales with user preference.
Setting font-size on :root in % rather than px also respects user settings. -->
<style>
:root {
font-size: 100%; /* inherits browser default, typically 16px */
}
body {
font-size: 0.875rem; /* ~14px at default, but scales with user preference */
}
h1 {
font-size: 1.5rem; /* ~24px at default */
}
.caption {
font-size: 0.75rem; /* ~12px at default — still scalable */
}
</style>
<p>Your appointment is confirmed.</p>
텍스트를 잘라내는 고정 높이 컨테이너 — 잘못된 예
<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
.card {
height: 120px;
overflow: hidden;
}
</style>
<div class='card'>
<h2>Flight Confirmation</h2>
<p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>
텍스트를 잘라내는 고정 높이 컨테이너 — 올바른 예
<!-- CORRECT: Use min-height instead of height so the container grows
with the content when text is enlarged. -->
<style>
.card {
min-height: 7.5rem; /* sets a minimum but allows growth */
overflow: visible; /* or remove overflow:hidden entirely */
}
</style>
<div class='card'>
<h2>Flight Confirmation</h2>
<p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>
이미지에 구워 넣은 텍스트 — 잘못된 예
<!-- WRONG: A banner image containing text cannot be resized by the browser.
Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>
이미지에 구워 넣은 텍스트 — 올바른 예
<!-- CORRECT: Use real HTML text over a background image so the browser
can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
<p class='promo-text'>50% İndirim — Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
uses rem font-size and contrasts safely against the background. -->
자주 발생하는 실수
- 모바일에서 "레이아웃 깨짐"을 막기 위해 뷰포트 메타 태그에
user-scalable=no를 추가하는 것 — 이는 1.4.4의 직접적이고 테스트 가능한 위반이며 절대 사용해서는 안 된다. 사용자의 확대 기능을 억제하는 대신 레이아웃을 수정해야 한다. maximum-scale=1.0또는 2.0보다 작은 값을 설정하는 것 —user-scalable=no가 없더라도, 확대 상한을 1.0이나 1.5로 제한하면 사용자가 200%에 도달하는 것을 막게 되며 이 기준을 충족하지 못한다.- JavaScript 이벤트 리스너에서 핀치 줌이나 휠 이벤트에 대해
event.preventDefault()를 호출하는 것 — 네이티브 확대를 프로그램적으로 차단하는 것은 뷰포트 메타 태그 방식과 기능적으로 동일하며, 같은 기준을 위반한다. <html>또는<body>요소에 픽셀 단위로font-size를 설정한 뒤 나머지를 모두em단위로 사용하는 것 — 루트 글꼴 크기가 px로 고정되어 있으면, 모든em/rem하위 요소도 사실상 고정되며 사용자의 브라우저 글꼴 크기 선호에 반응하지 않는다.- 카드 컴포넌트, 사이드바, 모달 본문에
min-height대신height를 사용하는 것 — 200% 확대 시, 커진 텍스트가 고정 높이 박스를 넘치게 되고overflow: hidden에 의해 잘려 중요한 콘텐츠가 숨겨진다. - 중요한 텍스트를 오직
<canvas>요소 안에만 배치하는 것 — 캔버스에 렌더링된 텍스트는 래스터화된 비트맵이며, 브라우저의 텍스트 크기 조정이나 확대 메커니즘으로는 확대할 수 없다. 사용자가 읽어야 할 의미 있는 텍스트는 반드시 실제 HTML 텍스트로 제공되거나, 최소한 접근 가능한 대체 텍스트로 제공되어야 한다. - 절대 좌표와 viewBox 스케일링 없이 SVG
<text>요소를 사용하는 것 — SVG가viewBox를 사용하고 상대 단위로 크기를 지정하면 SVG 텍스트는 확대 가능하지만, 픽셀 단위의 고정x,y,font-size속성을 가진 텍스트를 고정width와height를 가진 SVG 안에 배치하면, 모든 브라우저에서 브라우저 확대에 따라 크기가 조정되지는 않는다. - 브라우저 확대가 자동으로 이 기준을 충족시킨다고 가정하고 수동 테스트를 생략하는 것 — 브라우저 확대는 이미지와 레이아웃을 포함한 전체 페이지를 스케일링하지만, 이미 100%에서 너무 작거나 잘리거나 겹치던 텍스트는 200%에서 더 큰 문제가 된다. 확대 수준에서의 수동 검증은 항상 필요하다.
- 서드파티 임베디드 위젯 테스트를 잊는 것 — 채팅 위젯, 결제 iframe, 쿠키 동의 배너, 분석 오버레이 등은 종종 서드파티가 고정 px 크기를 사용해 개발하며 확대를 차단할 수 있다. 코드가 서드파티 것이더라도, 이 기준은 사용자에게 제공되는 전체 페이지에 적용된다.
- 데스크톱 레이아웃의 확대만 수정하고 모바일 브레이크포인트는 방치하는 것 — 많은 팀이 데스크톱에서 확대를 테스트하고 성공했다고 판단하지만, 모바일 뷰포트에서 200% 확대는 별도의 레이아웃 문제를 야기한다. 특히 고정 픽셀 높이에 의존하는 내비게이션 메뉴, 고정 헤더, 하단 내비게이션 바에서 문제가 두드러진다.
터키 접근성 규정과의 관계
2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 특정 조직을 대상으로 의무적인 웹 및 모바일 접근성 요구 사항을 수립한다. 이 대통령령은 국제적으로 인정된 접근성 표준을 참조하고 있으며, 사실상 터키의 요구 사항을 WCAG 2.1 및 WCAG 2.2 Level AA와 정합되도록 설정하고 있다.
WCAG 1.4.4 Resize Text는 Level AA 기준이며, Level AA 준수는 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 접근성 로고(Erişilebilirlik Logosu)를 획득하기 위한 최소 요건이다. 접근성 로고는 대중에게 신뢰를 주는 신호이자 규제상의 체크포인트 역할을 한다. 대통령령의 적용을 받는 조직이 이 로고를 표시하거나 감사인에게 준수 여부를 입증하려면 1.4.4를 포함한 모든 Level AA 기준을 충족해야 한다.
대통령령 2025/10이 적용되는 주체 범주는 다음과 같다. 모든 수준의 정부에 속한 공공 기관 및 기관, 전자상거래 플랫폼과 온라인 마켓플레이스, 은행 규제감독청(BDDK)의 규제를 받는 은행 및 금융 서비스 제공자, 디지털 환자 대상 서비스를 제공하는 병원·보건소·기타 의료 기관, 가입자 200,000명 이상인 통신 사업자, 여행사 및 온라인 여행 플랫폼, 디지털 발권 또는 예약 서비스를 제공하는 민간 운송 회사, 그리고 교육부(Millî Eğitim Bakanlığı, MoNE)의 인가를 받은 민간 학교 및 교육 기관 등이 포함된다.
이들 각 유형의 주체에 대해 1.4.4의 실질적인 의미는 크다. 모바일에서 핀치 줌을 차단하는 은행의 인터넷 뱅킹 포털은 단순한 사용성 실패가 아니라, 감사 결과나 접근성 로고 프로그램에서의 제외로 이어질 수 있는 규제 비준수 사례다. 고정 픽셀 글꼴 크기를 클리핑 컨테이너 안에서 사용하는 병원 예약 시스템은 저시력 환자를 제대로 지원하지 못할 뿐 아니라, 동시에 대통령령에 따른 의무를 위반하는 것이다. 텍스트를 확장 가능한 HTML 텍스트 대신 이미지에만 담아두는 민간 학교의 입학 신청 플랫폼 역시 마찬가지로 비준수 상태다.
조직은 WCAG 1.4.4를 좁은 기술적 체크박스로 보지 말고, 시각 장애가 있는 사용자를 존중하기 위한 최소한의 기대치로 인식해야 한다. 이 기대치는 터키 법, 국제적 모범 사례, 기본적인 사용성이 모두 일치하는 지점이기도 하다. Accsible의 오버레이 SDK는 사용자가 브라우저 확대와 별개로 텍스트 크기를 키울 수 있는 구성 가능한 글꼴 스케일링 컨트롤을 제공함으로써 텍스트 크기 조정 준수를 지원한다. 이는 사이트 자체가 구현해야 하는 기본 요구 사항 위에 추가적인 편의 계층을 제공하는 것이다.
