WCAG 성공 기준 · Level AA
WCAG 1.4.5: 텍스트의 이미지
WCAG 1.4.5는 정보를 전달하는 텍스트는, 특정한 시각적 표현이 필수적이거나 사용자가 이미지를 시각적으로 사용자 지정할 수 있는 경우를 제외하고, 텍스트의 이미지가 아니라 실제 텍스트로 제공되어야 한다고 요구합니다. 이 기준은 텍스트를 편안하게 읽기 위해 크기를 조정하거나, 색을 변경하거나, 재흐름(reflow)해야 하는 사용자들에게 매우 중요합니다.
- Level AA
- Wcag
- Wcag 2 2 aa
- 지각 가능
- 접근성
이 규칙의 의미
WCAG 1.4.5 — 텍스트의 이미지(Level AA)는 동일한 시각적 표현을 실제 텍스트로 구현할 수 있다면, 텍스트를 포함한 이미지를 사용하는 대신 반드시 실제 텍스트를 사용해야 한다고 규정한다. 텍스트의 이미지란 전달되는 주요 콘텐츠가 텍스트 문자일 때의 이미지를 말한다. 예를 들어, 제목을 JPEG로 만든 것, 태그라인이 들어간 PNG 배너, 브랜드 이름을 스타일화된 글꼴로 표기한 GIF 로고 등이 이에 해당한다.
통과와 실패의 구분은 명확하다. HTML에서 실제 문자를 마크업하고 CSS로 스타일링하여 동일한 모양을 구현할 수 있음에도 이미지를 사용했다면, 이는 실패이다. 이 규칙은 장식용 이미지나 장면 속에 우연히 텍스트가 포함된 사진(예: 사진 속 도로 표지판)에 관한 것이 아니다. 텍스트 자체가 의도된 콘텐츠인 이미지를 대상으로 한다.
WCAG는 텍스트의 이미지가 허용되는 공식적인 예외를 두 가지 정의한다.
- 필수(essential) 예외: 특정 시각적 표현이 전달되는 정보에 필수적인 경우이다. 고전적인 예는 로고타입(logotype)이다. 특정 글자 형태의 렌더링이 브랜드 아이덴티티와 분리될 수 없을 때가 이에 해당한다. 스타일화된 글자 형태 자체가 곧 브랜드인 회사 로고는 이미지로 남아도 된다.
- 사용자 맞춤(customizable) 예외: 텍스트의 이미지를 사용자가 요구하는 대로 시각적으로 커스터마이즈할 수 있는 경우이다. 이는 사용자가 이미지 속 텍스트의 글꼴, 크기, 색상, 배경을 변경할 수 있음을 의미한다. 실제 구현에서는 대부분 이 예외를 충족하지 못하는데, 대부분의 이미지는 사용자 선호에 맞춰 동적으로 다시 렌더링될 수 없기 때문이다.
이 기준이 요구하지 않는 것, 즉 하지 않는 것을 이해하는 것이 중요하다. 텍스트를 포함하는 모든 이미지를 금지하는 것은 아니다. 역사적 문서의 사진, 증거로 사용되는 스크린샷, 축의 라벨이 데이터 시각화의 일부인 차트 이미지는 이 규칙의 주요 대상이 아니다. 다만 대체 텍스트(WCAG 1.1.1)는 여전히 그 내용을 설명해야 한다. 이 기준의 초점은 디자이너가 순전히 미적 이유로, CSS로도 동일한 결과를 얻을 수 있음에도 스타일링된 텍스트를 래스터 또는 벡터 이미지로 렌더링하기로 선택한 경우에 있다.
실패 사례에 가장 자주 연루되는 HTML 요소는 제목, 배너, 콜투액션 버튼, 내비게이션 라벨, 추천 인용구, 프로모션 텍스트에 사용되는 <img> 태그이다. 텍스트를 <text> 요소가 아닌 경로(path)로 내장하는 SVG 파일도 문제인데, 이러한 문자는 브라우저에서 선택, 크기 조정, 리플로우가 불가능하기 때문이다.
왜 중요한가
텍스트가 래스터 이미지 안에 포함되면 고정된 비트맵이 된다. 브라우저는 이미지를 확대·축소할 수는 있지만, 텍스트를 리플로우하거나 글꼴을 바꾸거나 두께를 늘리거나 픽셀에 이미 포함된 것 이상의 색 대비를 변경할 수는 없다. 이는 여러 장애 집단에 상당한 장벽을 만든다.
저시력 사용자는 일반적으로 브라우저 확대, 운영체제의 텍스트 크기 조정, 전용 화면 확대 소프트웨어에 의존한다. 실제 텍스트는 어떤 확대 수준에서도 선명하게 스케일링되지만, 텍스트의 이미지는 흐려지고 픽셀화되어 고배율에서는 읽을 수 없게 된다. 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 이들 중 상당수는 스크린 리더가 아니라 확대나 배율을 주요 대처 전략으로 사용한다.
난독증이나 기타 읽기 장애가 있는 사용자는 브라우저 확장 프로그램이나 보조 기술을 사용해 글꼴을 재정의하고, 글자 간격을 늘리고, 고대비 색 구성으로 전환하는 경우가 많다. 이러한 사용자 맞춤은 텍스트의 이미지에는 전혀 적용되지 않는다. 픽셀은 변하지 않기 때문이다. OpenDyslexic이나 자간이 넓은 산세리프 글꼴이 필요한 사용자는 PNG로 렌더링된 제목에는 이를 적용할 수 없다.
사용자 정의 색 구성에 의존하는 사용자 — 광과민증, 편두통 장애, 대비 민감성을 가진 사람들을 포함 — 는 운영체제를 고대비 모드나 색 반전 모드로 설정할 수 있다. CSS 텍스트는 이러한 시스템 수준의 재정의에 반응하지만, 이미지 텍스트는 그렇지 않으며 색이 예기치 않게 반전될 때 오히려 읽기 더 어려워질 수 있다.
구체적인 상황을 생각해 보자. 한 터키 전자상거래 사이트가 브랜드 스타일 가이드에 사용된 커스텀 디스플레이 폰트를 유지하기 위해 프로모션 캠페인 헤드라인을 JPEG 이미지로 렌더링한다. 저시력 사용자가 브라우저를 200%로 확대한다. 제품 이미지는 적절히 확대되지만, 캠페인 헤딩(이미지)은 픽셀 덩어리로 흐릿해진다. 사용자는 프로모션을 읽지 못해 할인 혜택을 놓친다. 동일한 글꼴을 @font-face로 제공하고 실제 <h2> 요소에 적용했다면, 벡터 기반 글꼴 렌더링은 무한히 스케일링되므로 어떤 확대 수준에서도 텍스트는 선명하게 유지되었을 것이다.
접근성을 넘어, 실제 텍스트 사용은 측정 가능한 SEO 이점도 있다. 검색 엔진 크롤러는 텍스트 노드를 직접 인덱싱하지만, OCR 없이 이미지의 텍스트 콘텐츠를 신뢰성 있게 추출할 수는 없다. PNG에 내장된 제목은 Google의 랭킹 알고리즘에 보이지 않는다. 실제 텍스트로 전환하면 동일한 콘텐츠에 대해 키워드 인덱싱과 페이지 랭킹이 개선될 수 있다.
관련 Axe-core 규칙
WCAG 1.4.5는 수동 테스트를 요구한다. 아래에서 설명하는 이유로, 텍스트의 이미지를 신뢰성 있게 감지하는 단일 자동 axe-core 규칙은 존재하지 않는다.
- 수동 테스트 필요 — 전용 자동 규칙 없음: 자동 도구는
<img>요소의 존재와alt속성 유무는 감지할 수 있지만, 해당 이미지의 시각적 콘텐츠가 주로 렌더링된 텍스트인지 여부는 판단할 수 없다. 이를 위해서는 페이지의 모든 이미지에 대해 이미지 인식/OCR이 필요하며, 이는 계산 비용이 크고 맥락에 따라 달라진다. 페이지를 스캔하는 도구는 우연히 단어가 적힌 표지판이 포함된 사진과 의도적으로 렌더링된 제목 이미지를 구분할 수 없다. 특정 이미지가 CSS 스타일링을 적용한 실제 HTML 텍스트로 대신 표현할 수 있는 스타일화된 텍스트를 제시하기 위한 목적으로 존재하는지 평가하려면 사람의 판단이 필요하다. - 색 대비 규칙에서의 부분적인 신호:
color-contrast와 같은 axe-core 규칙은 DOM 텍스트 노드와 계산된 CSS 색 값을 기반으로 동작하기 때문에, 이미지 안에 포함된 텍스트에는 적용되지 않는다. 텍스트의 이미지에 대비가 부족한 경우, 자동 대비 검사는 이를 조용히 놓친다. 이는 텍스트의 이미지가 자동 경고 없이 동시에 1.4.5와 1.4.3(최소 대비)을 모두 위반할 수 있음을 의미하며, 철저한 수동 감사를 수행해야 하는 강력한 이유가 된다. - SVG의 path로 된 텍스트: SVG가 텍스트를
<text>요소가 아닌 윤곽 경로(<path>요소)로 내보낼 때, axe-core는 이 경로들이 단어를 구성한다는 사실을 알 방법이 없다. 텍스트가 윤곽선으로 변환되었는지, 그리고 웹 폰트를 적용한 실제<text>요소여야 하는지를 판단하려면 SVG 소스 코드에 대한 수동 검사가 필요하다.
테스트 방법
- 기본선으로 자동 스캔을 실행한다. axe DevTools(브라우저 확장) 또는 Chrome DevTools의 Lighthouse를 사용해 페이지에서 플래그된 문제를 식별한다. 두 도구 모두 전용 1.4.5 규칙은 없지만, 스캔 결과는 이미지의
alt텍스트 누락이나 텍스트 노드의 색 대비 실패와 같은 관련 문제를 드러낼 수 있다. 플래그된 이미지를 기록하고, 이를 수동 검토 후보로 삼는다. - 페이지의 모든 이미지를 시각적으로 검사한다. 브라우저에서 페이지를 열고 모든
<img>요소, 인라인 SVG, CSS 배경 이미지, canvas 요소를 체계적으로 살펴본다. 각 이미지에 대해 “이 이미지의 주요 목적이 텍스트를 표시하는 것인가?”를 자문한다. 그렇다면 다음 단계로 진행한다. - CSS로 동일한 결과를 얻을 수 있는지 확인한다. 2단계에서 식별한 각 이미지에 대해, 웹 폰트(
@font-face)와 CSS 속성(색상, text-shadow, letter-spacing, 그라디언트 배경)을 조합해 시각적으로 동등한 결과를 만들 수 있는지 묻는다. 답이 “예”라면, 로고타입 예외가 적용되지 않는 한 해당 텍스트의 이미지는 실패이다. - 로고타입 예외를 검증한다. 사이트가 로고타입 예외를 주장하는 경우, 해당 이미지가 실제로 글자 형태 디자인이 브랜드 아이덴티티와 분리될 수 없는 진정한 브랜드 로고인지, 단지 브랜드 폰트로 설정된 헤딩이 아닌지를 확인한다.
- 브라우저 확대 기능으로 테스트한다. 브라우저를 200%와 400%로 확대(Ctrl/Cmd + 또는 브라우저 설정 사용)한다. 페이지의 텍스트가 선명하게 유지되는지 관찰한다. 텍스트의 이미지는 흐려지거나 픽셀화되고, 실제 텍스트는 선명하게 유지된다. 이 테스트는 1.4.5 위반과 관련 리플로우 문제(WCAG 1.4.4 및 1.4.10)를 동시에 점검한다.
- SVG 소스 코드를 검사한다. SVG를 마우스 오른쪽 버튼으로 클릭해 “소스 보기”를 선택하거나 브라우저 DevTools로 SVG DOM을 검사한다. 텍스트 콘텐츠가 글자 윤곽을 그리는
<path>요소가 아니라<text>요소를 사용하고 있는지 확인한다. 모든 텍스트가 경로로 변환되었다면, 해당 SVG는 텍스트의 래스터 이미지와 동일한 문제를 가진다. - 스크린 리더로 테스트해 복합적인 영향을 이해한다. NVDA+Firefox, macOS/iOS의 VoiceOver+Safari, 또는 JAWS+Chrome을 사용한다. 텍스트의 이미지로 이동해
alt속성이 텍스트 콘텐츠를 정확히 전달하는지 확인한다. 의미 있는alt속성은 WCAG 1.1.1(비텍스트 콘텐츠)을 충족하지만, 1.4.5 실패를 해결하지는 못한다. 텍스트는 여전히 사용자 맞춤이 불가능하기 때문이다. 두 문제를 별도로 문서화한다. - 사용자 정의 스타일시트나 브라우저 확장을 적용한다. Stylus와 같은 브라우저 확장을 설치하거나 Firefox의 내장 사용자 스타일시트 기능을 사용해 전역적으로 글꼴 패밀리를 재정의하고 글꼴 크기를 키운다. 실제 텍스트는 변경되지만, 이미지 텍스트는 변경되지 않는다. 이는 읽기 장애가 있는 사용자가 선호 글꼴을 적용할 때 겪는 경험을 직접적으로 시뮬레이션한다.
해결 방법
장식용 배너 헤딩 — 잘못된 예
<!-- 실패: 마케팅 헤딩이 커스텀 폰트를 유지하기 위해 JPEG로 렌더링됨 -->
<div class='hero'>
<img src='summer-sale-heading.jpg' alt='Summer Sale — Up to 50% Off' />
</div>
장식용 배너 헤딩 — 올바른 예
<!-- 수정: 동일한 커스텀 폰트를 @font-face로 제공하고 실제 헤딩에 적용.
이제 텍스트는 선택, 확대, 사용자 맞춤이 가능하다. -->
<style>
@font-face {
font-family: 'BrandDisplay';
src: url('/fonts/brand-display.woff2') format('woff2');
font-display: swap;
}
.hero-heading {
font-family: 'BrandDisplay', sans-serif;
font-size: clamp(2rem, 5vw, 4rem);
color: #c0392b;
text-shadow: 2px 2px 4px rgba(0,0,0,0.3);
}
</style>
<div class='hero'>
<h1 class='hero-heading'>Summer Sale — Up to 50% Off</h1>
</div>
윤곽선 텍스트가 있는 SVG — 잘못된 예
<!-- 실패: SVG 내보내기에서 텍스트가 path로 변환되어
문자가 텍스트로서 접근 불가능하고 비확장 가능해짐 -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'>
<!-- 'Accsible' 글자를 추적하는 수십 개의 <path> 요소 -->
<path d='M10 60 L20 20 L30 60 ...' fill='#003087' />
</svg>
윤곽선 텍스트가 있는 SVG — 올바른 예
<!-- 수정: SVG가 웹 폰트를 참조하는 실제 <text> 요소를 사용.
이제 텍스트는 인덱싱, 선택, 확장이 가능하다. -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'
role='img' aria-label='Accsible'>
<defs>
<style>
.svg-label {
font-family: 'BrandDisplay', sans-serif;
font-size: 48px;
fill: #003087;
}
</style>
</defs>
<text class='svg-label' x='10' y='60'>Accsible</text>
</svg>
텍스트가 포함된 CSS 배경 이미지 — 잘못된 예
<!-- 실패: 버튼 라벨이 실제 텍스트 노드가 아니라
배경 이미지의 일부로 포함됨 -->
<a href='/shop' class='cta-button'></a>
<style>
.cta-button {
display: block;
width: 200px;
height: 60px;
background: url('shop-now-button.png') no-repeat center;
background-size: cover;
}
</style>
텍스트 오버레이가 있는 CSS 배경 이미지 — 올바른 예
<!-- 수정: 버튼이 CSS로 스타일링된 실제 텍스트 노드를 사용.
배경 이미지는 순수하게 장식용(그라디언트 또는 텍스처)이다. -->
<a href='/shop' class='cta-button'>Shop Now</a>
<style>
.cta-button {
display: inline-block;
padding: 1rem 2rem;
background: linear-gradient(135deg, #e74c3c, #c0392b);
color: #ffffff;
font-family: 'BrandDisplay', sans-serif;
font-size: 1.25rem;
font-weight: 700;
text-decoration: none;
border-radius: 4px;
}
</style>
로고타입 — 허용되는 예외
<!-- 허용: 특정 글자 형태 디자인 자체가
브랜드 아이덴티티인 로고타입. Alt 텍스트가 텍스트 내용을 정확히 전달함.
CSS로 손으로 그린 글자 형태를 복제할 수 없다. -->
<a href='/' aria-label='Accsible — Home'>
<img src='accsible-logo.svg'
alt='Accsible'
width='160'
height='48' />
</a>
자주 발생하는 실수
- 디자인 목업에 Google Fonts에 없는 글꼴이 사용되었다는 이유로 페이지 헤딩을 JPEG나 PNG로 사용하는 것 — 올바른 해결책은 헤딩을 이미지로 굽는 것이 아니라, 글꼴을 WOFF2 파일로 자체 호스팅하고
@font-face로 제공하는 것이다. - Figma나 Photoshop 같은 디자인 도구에서 전체 히어로 섹션을 하나의 평면 이미지로 내보내는 것. 이 경우 모든 텍스트, 버튼, 라벨이 하나의 래스터 파일에 포함된다. 각 텍스트 요소는 별도의 HTML 노드여야 한다.
- 서버의 폰트 로딩 의존성을 피하기 위해 내보내기 시 SVG 텍스트를 path로 변환하는 것. 이는 텍스트의 접근성과 검색 가능성을 제거한다. 대신 CSS 폰트 참조가 있는
<text>요소를 사용해야 한다. - 정확한 레이아웃 제어를 유지하기 위해 프로모션 또는 법적 텍스트(약관, 가격, 이벤트 규정 등)를 이미지 안에 배치하는 것. 사용자가 읽어야 하는 모든 텍스트는 실제 HTML 텍스트여야 한다.
- 모든 브랜드 텍스트에 로고타입 예외를 주장하는 것 — 예외는 실제 로고 마크에만 적용되며, 브랜드 서체로 설정된 모든 헤딩이나 라벨에 적용되는 것이 아니다. Helvetica Neue로 설정된 헤딩은 로고타입이 아니다.
- 정확한
alt속성을 제공하면 1.4.5 실패가 해결된다고 가정하는 것 — 그렇지 않다. Alt 텍스트는 WCAG 1.1.1(비텍스트 콘텐츠)을 충족하지만, 텍스트의 이미지를 사용자 맞춤 가능하게 만들지는 못한다. 이것이 1.4.5의 별도 요구 사항이다. - 시각 효과를 위해 스타일링된 텍스트를 렌더링하는 HTML5
<canvas>요소를 사용하면서 DOM에 실제 텍스트 대안을 제공하지 않는 것. canvas에 렌더링된 텍스트는 이미지 텍스트와 동일한 단점을 모두 가진다. - Open Graph나 소셜 공유 미리보기 이미지에 텍스트를 포함하고, 이 이미지가 페이지에도 나타난다는 사실을 잊는 것(예: 블로그 게시물의 대표 이미지). 대표 이미지가 장식적 맥락이라면 허용될 수 있지만, 기사 주요 헤딩이라면 실패이다.
- 이메일 뉴스레터 템플릿을 무시하는 것 — 이메일 클라이언트는 브라우저 WCAG 범위 밖이지만, 많은 조직이 뉴스레터를 웹 페이지로도 게시한다. 웹 콘텐츠로 임베드된 이메일 헤더 이미지의 텍스트는 여전히 1.4.5를 트리거한다.
- 고해상도 Retina 이미지를 사용하면 문제가 해결된다고 가정하는 것 — 2× 또는 3× 해상도의 텍스트 이미지는 1× 이미지보다 선명하지만, 텍스트가 여전히 사용자 맞춤 불가능하고 리플로우되지 않으며 검색 엔진과 보조 기술에 보이지 않기 때문에 여전히 1.4.5를 위반한다.
터키 접근성 규정과의 관계
터키의 2025/10번 대통령 공고(Presidential Circular 2025/10)는 2025년 6월 21일 관보(Official Gazette) 제32933호에 게재되었으며, 터키에서 운영되는 광범위한 주체에 대해 웹 및 모바일 접근성 표준을 의무화한다. 이 공고는 WCAG 2.2를 규범적 기술 표준으로 명시적으로 참조하며, Level AA 준수 — 여기에는 WCAG 1.4.5가 포함된다 — 는 Aile ve Sosyal Hizmetler Bakanlığı(가족·사회서비스부)가 발급하는 Erişilebilirlik Logosu(접근성 로고) 자격 요건이다. 이 로고는 디지털 제품이 공고에서 정의한 접근성 요구 사항을 충족함을 나타내는 공식 인증 마크 역할을 한다.
공고의 적용 대상은 터키 디지털 경제의 광범위한 영역을 포괄한다. 모든 수준의 공공 기관 및 정부 기관이 준수해야 하며, BDDK(Banking Regulation and Supervision Agency, 은행 규제·감독 기관)의 규제를 받는 은행 및 금융 기관도 포함된다. 공공 및 민간 병원과 의료 서비스 제공자도 대상이다. 민간 부문에서는 전자상거래 플랫폼, 가입자 200,000명 이상인 통신 사업자, 여행사, 민간 운송 회사, Milli Eğitim Bakanlığı(MoNE, 교육부)가 인가한 민간 학교 및 교육 기관이 모두 공고의 범위에 포함된다.
이러한 조직에 대해 WCAG 1.4.5는 직접적이고 실질적인 영향을 미친다. 많은 터키 전자상거래 및 기관 웹사이트는 프로모션 이미지, 커스텀 폰트 배너, 캠페인 헤더에 텍스트를 래스터 이미지로 임베드하는데, 이는 시각적 디자인 도구에서 시작되는 웹 디자인 워크플로에서 흔한 관행이다. 대통령 공고에 따르면 이러한 구현은 Level AA 비준수에 해당하며, 사이트가 Erişilebilirlik Logosu를 취득하거나 유지하는 것을 불가능하게 만든다. 금리 표를 이미지로 표시하는 은행, 부서 이름을 PNG 배너로 나열하는 병원, 프로모션 요금을 평면 이미지 파일로 제시하는 통신 사업자는 모두 이 기준을 위반하게 된다.
준수를 목표로 하는 조직은 웹 자산의 모든 이미지를 감사해 임베드된 텍스트 콘텐츠를 확인하고, 트래픽이 많은 페이지(홈페이지, 제품 페이지, 서비스 랜딩 페이지)를 우선적으로 변환하며, 텍스트 콘텐츠를 이미지 파일 안에 전달하는 것을 금지하는 디자인-개발 워크플로를 수립해야 한다. WOFF2 형식과 적절한 font-display 값을 사용한 @font-face 기반 웹 폰트 전략에 투자하면, 디자이너는 브랜드 가이드라인이 요구하는 동일한 타이포그래피적 풍부함을 유지하면서도 WCAG 2.2 Level AA와 터키의 2025년 접근성 의무를 모두 완전히 준수할 수 있다.
