WCAG 達成基準 · Level AA
WCAG 1.4.5: 文字の画像
WCAG 1.4.5 は、特定の視覚的な表現が不可欠である場合、またはユーザーが画像を視覚的にカスタマイズできる場合を除き、情報を伝えるテキストはテキストの画像ではなく実際のテキストとして提示することを求めています。この基準は、快適に読めるようにテキストのサイズ変更、再配色、リフローを行う必要があるユーザーにとって極めて重要です。
- Level AA
- Wcag
- Wcag 2 2 aa
- 知覚可能
- アクセシビリティ
このルールの意味
WCAG 1.4.5 — 文字画像(レベルAA)は、同じ視覚的な表現が実際のテキストで実現できる場合は、テキストを含む画像ではなく、必ず実際のテキストを使用しなければならないと定めています。文字画像とは、伝えられている主な内容が文字であるあらゆる画像を指します。たとえば、見出しのJPEG、キャッチコピー入りのPNGバナー、ブランド名を装飾フォントで綴ったGIFロゴなどです。
合格と不合格の区別は明確です。その情報が、HTMLで実際の文字をマークアップし、CSSで同じ見た目になるようにスタイリングすることで伝えられるのであれば、代わりに画像を使うことは不合格になります。このルールは、装飾的な画像や、たまたまシーンの中に文字が写り込んでいる写真(例:写真の中の道路標識)を対象としているわけではありません。テキストそのものが意図されたコンテンツである画像を対象としています。
WCAGは、文字画像が許容される公式な例外を2つ定義しています。
- 本質的(Essential)な例外:特定の視覚的な表現が、伝えられる情報にとって本質的である場合です。典型例はロゴタイプで、特定の文字の描画がブランドアイデンティティと切り離せない場合です。スタイライズされた文字そのものがブランドである企業ロゴは、画像のままで構いません。
- カスタマイズ可能(Customizable)な例外:文字画像がユーザーの要件に合わせて視覚的にカスタマイズ可能な場合です。これは、ユーザーが画像内のテキストのフォント、サイズ、色、背景を変更できることを意味します。実際には、ほとんどの画像はユーザーの好みに合わせて動的に再レンダリングできないため、この例外が現実の実装で満たされることはほぼありません。
この達成基準が求めて「いない」ことを理解することも重要です。文字を含むすべての画像を禁止しているわけではありません。歴史的文書の写真、証拠として使われるスクリーンショット、軸ラベルがデータ可視化の一部であるグラフ画像などは、このルールの主な対象ではありませんが、その内容は代替テキスト(WCAG 1.1.1)で説明する必要があります。焦点となるのは、CSSで同じ結果が得られるにもかかわらず、デザイナーが純粋に美的な理由からスタイル付きテキストをラスター画像やベクター画像としてレンダリングすることを選んだケースです。
不適合の原因となることが多いHTML要素には、見出し、バナー、CTAボタン、ナビゲーションラベル、推薦文の引用、プロモーションテキストなどに使われる<img>タグがあります。テキストを<text>要素ではなくパスとして埋め込んでいるSVGファイルも問題です。こうした文字はブラウザで選択、拡大、リフローすることができないためです。
なぜ重要か
テキストがラスター画像の中に埋め込まれると、それは固定されたビットマップになります。ブラウザは画像を拡大・縮小することはできますが、テキストをリフローしたり、フォントを変更したり、太さを増したり、ピクセルに焼き込まれている以上の色コントラストを変更したりすることはできません。これは、いくつかの障害当事者グループにとって重大な障壁となります。
ロービジョンのユーザーは通常、ブラウザのズーム、OSのテキストスケーリング、または専用の拡大ソフトに依存しています。実際のテキストは、どのズームレベルでも鮮明に拡大されますが、文字画像はぼやけてピクセル化し、高倍率では判読不能になります。世界で約2.2億人が何らかの視覚障害を抱えており、その多くはスクリーンリーダーではなく、ズームや拡大を主な対処手段として利用しています。
ディスレクシアやその他の読字障害のあるユーザーは、フォントの上書き、文字間隔の拡大、ハイコントラスト配色への切り替えのために、ブラウザ拡張機能や支援技術を頻繁に使用します。これらのカスタマイズは文字画像には一切効きません。ピクセルは不変だからです。OpenDyslexicや字間の広いサンセリフ体を必要とするユーザーは、PNGとしてレンダリングされた見出しにはそれを適用できません。
カスタム配色に依存するユーザー — 光過敏症、片頭痛、コントラスト過敏などを持つ人を含む — は、OSをハイコントラストモードや反転色モードに設定している場合があります。CSSテキストはこうしたシステムレベルの上書きに反応しますが、文字画像は反応せず、色が予期せず反転したときにかえって読みにくくなることもあります。
具体的なシナリオを考えてみましょう。あるトルコのECサイトが、ブランドスタイルガイドで使用されているカスタムディスプレイフォントを維持するために、プロモーションキャンペーンの見出しを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のパス化されたテキスト:SVGがテキストを
<text>要素ではなくアウトラインパス(<path>要素)として書き出している場合、axe-coreはそのパスが単語を綴っていることを知る術がありません。テキストがアウトライン化されているか、代わりにWebフォントを適用した実際の<text>要素であるべきかを判断するには、SVGソースコードの手動確認が必要です。
テスト方法
- ベースラインとして自動スキャンを実行する。axe DevTools(ブラウザ拡張)やChrome DevToolsのLighthouseを使用して、ページ上でフラグが立っている問題を特定します。どちらのツールにも1.4.5専用ルールはありませんが、画像の
altテキストの欠如や、テキストノードのカラーコントラスト不良など、関連する問題が出力に現れる場合があります。フラグが立った画像をメモし、それらを手動レビューの候補とします。 - ページ上のすべての画像を目視で確認する。ブラウザでページを開き、すべての
<img>要素、インラインSVG、CSS背景画像、canvas要素を体系的に確認します。それぞれについて、「この画像の主な目的はテキストを表示することか?」と自問します。もし「はい」であれば、次のステップに進みます。 - CSSで同じ結果が得られるか確認する。ステップ2で特定した画像について、「Webフォント(
@font-face)とCSSプロパティ(color、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の組み込みユーザースタイルシート機能を使用して、フォントファミリーを上書きし、フォントサイズを全体的に大きくします。実際のテキストは変化しますが、文字画像は変化しません。これは、読字障害のあるユーザーが好みのフォントを適用したときに経験する状況を直接シミュレートします。
修正方法
装飾的なバナー見出し — 不適切な例
<!-- Failing: A marketing heading is rendered as a JPEG to preserve a custom font -->
<div class='hero'>
<img src='summer-sale-heading.jpg' alt='Summer Sale — Up to 50% Off' />
</div>
装飾的なバナー見出し — 適切な例
<!-- Fixed: The same custom font is delivered via @font-face and applied to a real heading.
The text is now selectable, scalable, and user-customizable. -->
<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 — 不適切な例
<!-- Failing: Text has been converted to paths in the SVG export,
making the characters inaccessible and non-scalable as text -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'>
<!-- Dozens of <path> elements that trace the letters of 'Accsible' -->
<path d='M10 60 L20 20 L30 60 ...' fill='#003087' />
</svg>
アウトライン化されたテキストを含むSVG — 適切な例
<!-- Fixed: SVG uses a real <text> element with a web font reference.
The text is now indexable, selectable, and scalable. -->
<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背景画像 — 不適切な例
<!-- Failing: The button label is part of the background image,
not a real text node -->
<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背景画像 — 適切な例
<!-- Fixed: The button uses a real text node styled with CSS.
The background image is purely decorative (gradient or texture). -->
<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>
ロゴタイプ — 許容される例外
<!-- Acceptable: A logotype where the specific letterform design
IS the brand identity. Alt text accurately conveys the text content.
CSS cannot replicate the hand-drawn letterforms. -->
<a href='/' aria-label='Accsible — Home'>
<img src='accsible-logo.svg'
alt='Accsible'
width='160'
height='48' />
</a>
よくある間違い
- デザインモックでGoogle Fontsにないフォントが使われているため、ページ見出しにJPEGやPNGを使用すること — 正しい修正は、見出しを画像に焼き込むことではなく、
@font-faceを使ってフォントをWOFF2ファイルとして自前ホスティングすることです。 - FigmaやPhotoshopのようなデザインツールから、ヒーローセクション全体を単一のフラット画像として書き出すこと。これにより、すべてのテキスト、ボタン、ラベルが1つのラスター画像に埋め込まれてしまいます。各テキスト要素は別々のHTMLノードでなければなりません。
- サーバー側のフォント読み込み依存を避けるために、書き出し時にSVGテキストをパスに変換すること。これはテキストのアクセシビリティと検索性を失わせます。代わりに、CSSフォント参照付きの
<text>要素を使用してください。 - レイアウトを厳密に制御するために、プロモーションや法的文言(利用規約、価格、キャンペーン規約など)を画像内に配置すること。ユーザーが読む必要のあるテキストはすべて、実際のHTMLテキストでなければなりません。
- あらゆるブランドテキストにロゴタイプの例外を主張すること — 例外が適用されるのは実際のロゴマークだけであり、ブランドの書体で組まれたすべての見出しやラベルではありません。Helvetica Neueで組まれた見出しはロゴタイプではありません。
- 正確な
alt属性を付ければ1.4.5の不適合が解消されると考えること — そうではありません。altテキストはWCAG 1.1.1(非テキストコンテンツ)には対応しますが、文字画像をユーザーカスタマイズ可能にするわけではなく、これは1.4.5の別個の要件です。 - 視覚効果のために、HTML5の
<canvas>要素でスタイル付きテキストをレンダリングし、DOM内に実際のテキスト代替を提供しないこと。canvasでレンダリングされたテキストは、文字画像とまったく同じ欠点を持ちます。 - Open Graphやソーシャル共有プレビュー画像にテキストを埋め込み、それらの画像がページ上にも表示されることを忘れること(たとえば、ブログ記事のアイキャッチ画像として)。アイキャッチ画像が装飾的な文脈であれば許容される場合もありますが、それが記事の主見出しである場合は不適合です。
- メールニュースレターテンプレートを無視すること — メールクライアントはブラウザWCAGの適用範囲外ですが、多くの組織はニュースレターをWebページとして公開しています。Webコンテンツとして埋め込まれたメールヘッダー画像内のテキストも、1.4.5の対象になります。
- 高解像度のRetina画像なら問題が解決すると考えること — 2×や3×解像度の文字画像は1×画像よりも鮮明ですが、テキストが依然としてカスタマイズ不可、リフロー不可であり、検索エンジンや支援技術から見えないままであるため、1.4.5には依然として不適合です。
トルコのアクセシビリティ規制との関係
トルコの大統領通達 2025/10は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い主体に対して、Webおよびモバイルのアクセシビリティ基準を義務付けています。この通達は、技術的な規範としてWCAG 2.2を明示的に参照しており、レベルAA準拠(WCAG 1.4.5を含む)が、家族・社会サービス省(Aile ve Sosyal Hizmetler Bakanlığı)が発行するErişilebilirlik Logosu(アクセシビリティロゴ)の取得要件となっています。このロゴは、デジタル製品が通達で定義されたアクセシビリティ要件を満たしていることを示す公式な認証マークとして機能します。
通達の対象となる主体は、トルコのデジタル経済の広い範囲に及びます。あらゆるレベルの公的機関・政府機関が遵守を求められるほか、BDDK(銀行規制監督庁)の規制下にある銀行・金融機関も対象です。公立・私立を問わず病院・医療提供者も含まれます。民間セクターでは、ECプラットフォーム、20万件以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、および国民教育省(MoNE / Milli Eğitim Bakanlığı)に認可された私立学校・教育機関が、通達の適用範囲に含まれます。
これらの組織にとって、WCAG 1.4.5は直接的かつ実務的な影響を持ちます。多くのトルコのECサイトや機関サイトでは、プロモーション画像、カスタムフォントのバナー、キャンペーンヘッダーにテキストをラスター画像として埋め込む手法が使われています。これは、ビジュアルデザインツールを起点とするWebデザインのワークフローで一般的な慣行です。しかし大統領通達の下では、このような実装はレベルAAの不適合となり、Erişilebilirlik Logosuの取得・維持資格を失うことになります。金利表を画像として表示する銀行、部門名をPNGバナーで掲載する病院、プロモーション料金をフラットな画像ファイルとして提示する通信事業者などは、いずれもこの達成基準に違反することになります。
準拠を目指す組織は、自社のWebプロパティ上のすべての画像について埋め込みテキストの有無を監査し、まずはホームページ、商品ページ、サービスのランディングページなどトラフィックの多いページの変換を優先し、テキストコンテンツを画像ファイル内で納品することを禁止するデザインから開発へのワークフローを確立すべきです。WOFF2形式と適切なfont-display値を用いた@font-faceによるWebフォント戦略に投資することで、デザイナーはブランドガイドラインで求められる同等のタイポグラフィ表現を実現しつつ、WCAG 2.2レベルAAとトルコの2025年アクセシビリティ義務の両方に完全準拠することができます。
