WCAG 1.4.5: Images of Text

What This Rule Means

WCAG 1.4.5 — Images of Text (Level AA) states that if the same visual presentation can be achieved using real text, you must use real text instead of an image that contains text. An image of text is any image where text characters are the primary content being conveyed — for example, a JPEG of a heading, a PNG banner with a tagline, or a GIF logo that spells out a brand name in a stylized font.

The distinction between a pass and a fail is straightforward: if the information could be conveyed by marking up actual characters in HTML and styling them with CSS to achieve the same look, then using an image instead is a failure. The rule is not about decorative images or photographs that happen to contain text in the scene (such as a street sign in a photo). It targets images where text itself is the intended content.

WCAG defines two official exceptions where images of text are permitted:

• Essential exception: The particular visual presentation is essential to the information being conveyed. The classic example is a logotype — where the specific rendering of letterforms is inseparable from the brand identity. A company logo where the stylized letterforms ARE the brand can remain as an image.
• Customizable exception: The image of text can be visually customized to the user's requirements. This means the user can change the font, size, color, and background of the text in the image. In practice this exception is almost never met by real implementations, because most images cannot be re-rendered to user preferences dynamically.

It is important to note what this criterion does NOT require: it does not prohibit all images containing text. A photograph of a historical document, a screenshot used as evidence, or a chart image where axis labels are part of the data visualization are not the primary target of this rule, though alternative text (WCAG 1.1.1) must still describe their content. The focus is on cases where a designer chose to render styled text as a raster or vector image for purely aesthetic reasons when CSS could achieve the same result.

HTML elements most commonly implicated in failures include <img> tags used for headings, banners, call-to-action buttons, navigation labels, testimonial pull-quotes, and promotional text. SVG files that embed text as paths (rather than <text> elements) are also a concern, since those characters cannot be selected, resized, or reflowed by the browser.

Why It Matters

When text is embedded inside a raster image, it becomes a fixed bitmap. The browser can scale the image up or down, but it cannot reflow the text, change its font, increase its weight, or alter its color contrast beyond what is already baked into the pixels. This creates significant barriers for several disability groups.

Users with low vision typically rely on browser zoom, operating-system text scaling, or dedicated magnification software. Real text scales crisply at any zoom level; an image of text blurs and pixelates, making it illegible at high magnification. Approximately 2.2 billion people globally have some form of vision impairment, and many of them use zoom or magnification as their primary coping strategy rather than a screen reader.

Users with dyslexia or other reading disabilities frequently use browser extensions or assistive technology to override fonts, increase letter-spacing, and switch to high-contrast color schemes. None of these customizations work on images of text — the pixels are immutable. A user who needs OpenDyslexic or a wide-spaced sans-serif font simply cannot apply it to a heading rendered as a PNG.

Users who rely on custom color schemes — including those with photophobia, migraine disorders, or contrast sensitivities — may set their operating system to a high-contrast or inverted-color mode. CSS text responds to these system-level overrides; image text does not, and may actually become harder to read when colors are inverted unexpectedly.

Consider a concrete scenario: a Turkish e-commerce site renders its promotional campaign headlines as JPEG images to preserve the custom display font used in the brand style guide. A user with low vision zooms their browser to 200%. The product images scale up acceptably, but the campaign heading — an image — becomes a blurry smear of pixels. The user cannot read the promotion and misses the sale. Had the same font been delivered via @font-face and applied to a real <h2> element, the text would remain sharp at any zoom level, because vector-based font rendering scales infinitely.

Beyond accessibility, using real text has measurable SEO benefits. Search engine crawlers index text nodes directly; they cannot reliably extract the text content of images without OCR. A heading embedded in a PNG is invisible to Google's ranking algorithm. Switching to real text can improve keyword indexing and page ranking for the same content.

Related Axe-core Rules

WCAG 1.4.5 requires manual testing. There is no single automated axe-core rule that reliably detects images of text, for reasons explained below.

• Manual testing required — no dedicated automated rule: Automated tools can detect that an <img> element exists and that it has an alt attribute, but they cannot determine whether the visual content of that image is primarily rendered text. Doing so would require image recognition / OCR on every image on the page, which is computationally expensive and context-dependent. A tool scanning a page cannot distinguish between a photograph that incidentally contains a sign with words versus a deliberately rendered heading image. Human judgment is required to evaluate whether a given image exists for the purpose of presenting stylized text that could instead be marked up as real HTML text with CSS styling.
• Partial signal from color-contrast rules: Axe-core rules such as color-contrast will not fire on text embedded inside images, because they operate on DOM text nodes and computed CSS color values. If an image of text has insufficient contrast, automated contrast checking will silently miss it. This means that images of text may simultaneously fail both 1.4.5 and 1.4.3 (Contrast Minimum) without any automated flag — a strong reason to perform thorough manual audits.
• SVG text-as-paths: When an SVG exports text as outline paths (<path> elements) rather than <text> elements, axe-core has no way to know the paths spell out words. Manual inspection of SVG source code is necessary to determine whether text has been outlined and whether it should instead be a real <text> element with a web font applied.

How to Test

1. Run an automated scan as a baseline. Use axe DevTools (browser extension) or Lighthouse in Chrome DevTools to identify any flagged issues on the page. While neither tool has a dedicated 1.4.5 rule, the scan output may surface related issues such as missing alt text on images or failing color contrast on text nodes. Note any images flagged — these become candidates for manual review.
2. Visually inspect all images on the page. Open the page in a browser and systematically look at every <img> element, every inline SVG, every CSS background image, and every canvas element. Ask for each one: is the primary purpose of this image to display text? If yes, proceed to the next step.
3. Check whether CSS could achieve the same result. For any image identified in step 2, ask: could a web font (@font-face) combined with CSS properties (color, text-shadow, letter-spacing, gradient background) produce a visually equivalent result? If the answer is yes, the image of text is a failure unless the logotype exception applies.
4. Verify logotype exceptions. If a site claims a logotype exception, confirm that the image is genuinely a brand logo where the letterform design is inseparable from the brand identity, not simply a headline set in the brand font.
5. Test with browser zoom. Zoom the browser to 200% and 400% (using Ctrl/Cmd + or browser settings). Observe whether text on the page remains sharp. Images of text will blur or pixelate; real text will remain crisp. This test simultaneously checks for 1.4.5 violations and related reflow concerns (WCAG 1.4.4 and 1.4.10).
6. Inspect SVG source code. Right-click any SVG and choose "View Source" or use browser DevTools to inspect the SVG DOM. Confirm that text content uses <text> elements rather than <path> elements that trace letter outlines. If all text has been converted to paths, the SVG has the same problem as a raster image of text.
7. Test with a screen reader to understand compounding impact. Use NVDA with Firefox, VoiceOver with Safari on macOS/iOS, or JAWS with Chrome. Navigate to images of text and confirm that the alt attribute accurately conveys the text content. While a meaningful alt attribute addresses WCAG 1.1.1 (Non-text Content), it does not resolve the 1.4.5 failure — the text is still not user-customizable. Document both issues separately.
8. Apply a custom user stylesheet or browser extension. Install a browser extension such as Stylus or use Firefox's built-in user stylesheet feature to override font families and increase font size globally. Real text will change; image text will not. This directly simulates what users with reading disabilities experience when they apply their preferred fonts.

How to Fix

Decorative banner heading — Incorrect

<!-- 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>

Decorative banner heading — Correct

<!-- 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 with outlined text — Incorrect

<!-- 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 with outlined text — Correct

<!-- 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 background image with text overlay — Incorrect

<!-- 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 background image with text overlay — Correct

<!-- 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>

Logotype — Acceptable exception

<!-- 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>

Common Mistakes

• Using a JPEG or PNG for page headings because the design mockup uses a font not available on Google Fonts — the correct fix is to self-host the font as a WOFF2 file using @font-face, not to bake the heading into an image.
• Exporting entire hero sections as a single flat image from design tools like Figma or Photoshop, which embeds all text, buttons, and labels into one raster file. Each text element must be a separate HTML node.
• Converting SVG text to paths during export to avoid font-loading dependencies on the server. This eliminates accessibility and searchability of the text. Use <text> elements with a CSS font reference instead.
• Placing promotional or legal text (such as terms and conditions, pricing, or contest rules) inside an image to preserve precise layout control. Any text that users need to read must be real HTML text.
• Claiming the logotype exception for every piece of branded text — the exception applies only to the actual logo mark, not to any heading or label set in the brand's typeface. A heading in Helvetica Neue is not a logotype.
• Providing an accurate alt attribute and assuming that resolves the 1.4.5 failure — it does not. Alt text satisfies WCAG 1.1.1 (Non-text Content) but does not make the image text user-customizable, which is the distinct requirement of 1.4.5.
• Using HTML5 <canvas> elements to render styled text for visual effect without providing a real-text alternative in the DOM. Canvas-rendered text has all the same drawbacks as image text.
• Embedding text in Open Graph or social sharing preview images and forgetting that these images also appear on the page (for example, as a featured image in a blog post). If the featured image is decorative context, that may be acceptable — but if it is the primary heading of the article, it is a failure.
• Ignoring email newsletter templates — while email clients are outside browser WCAG scope, many organizations publish their newsletters as web pages. Text in email header images embedded as web content still triggers 1.4.5.
• Assuming that high-resolution Retina images solve the problem — a 2× or 3× resolution image of text is sharper than a 1× image but still fails 1.4.5 because the text remains non-customizable, non-reflowable, and invisible to search engines and assistive technologies.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility standards for a broad range of entities operating in Turkey. The circular explicitly references WCAG 2.2 as the normative technical standard, and Level AA conformance — which includes WCAG 1.4.5 — is required for eligibility for the Erişilebilirlik Logosu (Accessibility Logo), issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı). This logo serves as an official certification mark indicating that a digital product meets the accessibility requirements defined in the circular.

The entities covered by the circular span a wide cross-section of Turkey's digital economy. Public institutions and government agencies at all levels are required to comply, as are banks and financial institutions regulated by the BDDK (Banking Regulation and Supervision Agency). Hospitals and healthcare providers, both public and private, are covered. In the private sector, e-commerce platforms, telecommunications operators with 200,000 or more subscribers, travel agencies, private transport companies, and private schools and educational institutions authorized by the Ministry of National Education (MoNE / Milli Eğitim Bakanlığı) all fall under the scope of the circular.

For these organizations, WCAG 1.4.5 has direct and practical implications. Many Turkish e-commerce and institutional websites use promotional imagery, custom-font banners, and campaign headers that embed text as raster images — a common practice in web design workflows that originate in visual design tools. Under the Presidential Circular, such implementations constitute a Level AA non-conformance and would disqualify the site from obtaining or maintaining the Erişilebilirlik Logosu. Banks displaying interest rate tables as images, hospitals listing department names in PNG banners, or telecom operators presenting promotional tariffs as flat image files would all be in violation of this criterion.

Organizations seeking to comply should audit all images on their web properties for embedded text content, prioritize converting high-traffic pages (homepages, product pages, service landing pages) first, and establish a design-to-development workflow that prohibits the delivery of text content inside image files. Investing in a web font strategy using @font-face with WOFF2 format and appropriate font-display values will enable designers to achieve the same typographic richness required by brand guidelines while remaining fully compliant with both WCAG 2.2 Level AA and Turkey's 2025 accessibility mandate.