WCAG 1.4.9: Images of Text (No Exception)

What This Rule Means

WCAG 1.4.9 — Images of Text (No Exception) is a Level AAA criterion that takes the requirements of WCAG 1.4.5 (Images of Text, Level AA) to their logical conclusion. Where 1.4.5 permits images of text when the image is visually customizable or when a specific visual presentation is essential, 1.4.9 eliminates nearly all of those exceptions. Under this criterion, text must be rendered using actual text — real characters in the DOM — rather than as rasterized or vector images containing text.

The only permitted exception under 1.4.9 is text that is purely decorative (carrying no informational value whatsoever) or text that forms part of a logo or brand name where the specific visual treatment is inseparable from the identity being conveyed. In practice, this means product screenshots containing text, banner graphics with promotional copy, infographics with labeled data, certificate images, social-media-style quote cards, and scanned documents displayed on the web must all be replaced with, or at minimum supplemented by, real rendered text.

A pass under 1.4.9 occurs when every piece of meaningful text visible to the user is rendered by the browser's text engine — whether through HTML text nodes, CSS-generated content where appropriate, or SVG <text> elements — so that the user agent can reflow, resize, recolor, and respace it. A fail occurs whenever an <img>, <canvas>, CSS background image, SVG <image>, embedded PDF, or any other non-text resource is used to display text that carries meaning, regardless of whether an alt attribute is provided. Note that a well-written alt attribute does address 1.1.1 (Non-text Content) but does not satisfy 1.4.9, because the alternative text is not visually rendered and the original image still denies sighted users the ability to adapt the visual presentation of the text.

The criterion affects the following common HTML patterns: <img> elements whose source files contain text; CSS background-image properties pointing to images with embedded text; <canvas> elements on which text has been drawn programmatically; inline SVG elements that use <image> rather than <text>; and third-party embeds such as iframes containing rendered-image content. Even technically scalable formats like SVG fall under scrutiny when text is embedded as a path or image rather than as an SVG <text> node.

Why It Matters

Approximately 2.2 billion people worldwide have some form of vision impairment, according to the World Health Organization. A significant subset of these individuals — including people with low vision, color vision deficiencies, dyslexia, and other print disabilities — rely on browser-level or operating-system-level text customization tools to make content readable. These tools include zoom functions, font substitution, increased letter and word spacing, high-contrast or custom color schemes, and text-to-speech engines that operate on rendered DOM text. When text is embedded inside an image, every single one of these adaptations becomes unavailable for that content.

Consider a user with low vision who has set their browser to render text in a large sans-serif font with high-contrast yellow-on-black coloring. When they encounter a promotional banner that reads "Summer Sale — 50% Off" baked into a JPEG, the browser cannot recolor or reflow that text. The image may scale up with the page zoom, but it quickly becomes pixelated and harder to read rather than clearer. If the same message were rendered as real HTML text styled with CSS, the user's browser preferences would apply automatically, and the content would remain crisp, adjustable, and accessible.

Users with dyslexia frequently install browser extensions or apply custom stylesheets that switch fonts to dyslexia-friendly typefaces such as OpenDyslexic, and increase character and word spacing to reduce visual crowding. Images of text completely bypass these adaptations. A call-to-action button rendered as an image rather than a styled HTML element is effectively invisible to these customizations, potentially hiding critical interactive elements from users who depend on personalized rendering.

Motor-impaired users who rely on switch access or eye-tracking software may use zoom tools aggressively to hit precise targets. Blurry, low-resolution text images at high zoom levels create additional targeting difficulty. Screen reader users who have some residual vision but still use a screen reader for comprehension may also find that images of text are announced inconsistently depending on whether the author remembered to write a complete alt attribute — and even a perfect alt text does not restore the visual presentation they need.

Beyond disability access, using real text instead of images of text carries meaningful SEO benefits. Search engine crawlers index DOM text far more reliably than they can interpret image content, meaning that promotional headlines, product names, and category labels embedded in images may receive little or no search ranking weight. Real text is also lighter in file size for most typographic use cases, improving Core Web Vitals scores and reducing bandwidth consumption for users on mobile data connections — a particularly significant concern in markets where mobile internet penetration is high and data costs remain a factor.

Related Axe-core Rules

WCAG 1.4.9 requires manual testing because no automated tool can reliably determine whether an image contains meaningful text, whether that text is purely decorative, or whether its specific visual rendering is essential. The following considerations apply when using axe-core or related tooling:

• Manual inspection required (no dedicated axe rule): axe-core does not ship a rule that automatically detects images of text under 1.4.9. Automated tools can flag <img> elements missing alt attributes (the image-alt rule) and background images that may carry meaning, but they cannot analyze the pixel content of an image to determine whether it contains text, nor can they judge whether that text is decorative. A human tester must visually inspect each image and background graphic on the page and decide whether it conveys textual information that is not also available as real rendered text in the DOM. This is an inherent limitation of static analysis: optical character recognition could theoretically be applied, but it would produce significant false positives on images that happen to contain incidental letters or logotype treatments.
• image-alt (axe rule): While not a direct test of 1.4.9, the image-alt rule checks that all <img> elements have a non-empty alt attribute or are explicitly marked as decorative. Running this rule helps auditors identify images that need closer inspection: any image with a descriptive alt attribute that reads like a sentence or contains promotional copy is a strong signal that the image itself may be an image of text and therefore a 1.4.9 candidate.
• Lighthouse "Image elements do not have [alt] attributes" audit: Similar to image-alt, this Lighthouse check surfaces images that are completely undescribed. Testers should review flagged images manually to assess whether they depict text.

How to Test

1. Run an automated scan as a first pass. Open axe DevTools, the Deque browser extension, or Lighthouse in Chrome DevTools and run a full-page audit. Review any flagged image-related issues. While no automated rule directly covers 1.4.9, this step surfaces all <img> elements and CSS background images for follow-up manual review. Export the results and note every image that carries a non-empty, sentence-like alt attribute or that axe flags under image-alt.
2. Visually inspect all images and background graphics. Scroll through the page and examine each image, CSS background, canvas element, and SVG graphic. Ask: does this image contain text? If yes, is that text purely decorative (it adds no information and could be removed without loss)? Is it a logotype where the specific lettering style is inseparable from the brand identity? If neither exception applies, the image is a 1.4.9 failure.
3. Disable images in the browser. In Firefox, go to about:config and set permissions.default.image to 2, or use an extension like "Disable Images." Reload the page. Any textual information that disappears and is not replaced by visible DOM text (not just an alt attribute announced by a screen reader) represents a 1.4.9 failure. Re-enable images after testing.
4. Apply a custom user stylesheet. In Firefox, place a file at your profile's chrome/userContent.css and add a rule such as * { font-family: OpenDyslexic, sans-serif !important; color: yellow !important; background-color: black !important; }. Reload the page. Text rendered as actual HTML will adopt these styles; text embedded in images will not change. Any textual content that remains visually unchanged and unreadable under these forced styles is a failure.
5. Test with NVDA and Firefox. Navigate the page using NVDA's browse mode. For each image, note what NVDA announces. If NVDA reads an alt attribute that contains substantial text content, compare that content to what is visually displayed in the image. The presence of meaningful text content in an alt attribute is a strong indicator that the image contains text — and confirms a 1.4.9 failure even if 1.1.1 is technically satisfied.
6. Test with VoiceOver and Safari on macOS. Use VO + Right Arrow to move through content. Listen for image descriptions that narrate complete sentences, headings, or promotional text. Cross-reference with visual inspection to confirm the source is an image rather than real text.
7. Zoom to 400%. WCAG 1.4.4 and 1.4.10 require text to remain readable at high zoom levels. Images of text become pixelated when zoomed with browser zoom; real text rendered by the browser engine remains crisp. At 400% zoom, any text that appears blurry or pixelated is likely an image of text and should be investigated as a 1.4.9 failure.

How to Fix

Promotional banner with embedded text — Incorrect

<!-- A marketing banner where the headline and CTA are baked into the image.
     Even with alt text, users cannot customize the text rendering. -->
<a href='/sale'>
  <img src='/images/summer-sale-banner.jpg'
       alt='Summer Sale — Up to 50% off all products. Shop Now.'
       width='1200' height='400'>
</a>

Promotional banner with embedded text — Correct

<!-- The banner uses a real background image for visual decoration,
     while all text is rendered as real HTML so users can resize,
     recolor, and reflow it independently. -->
<a href='/sale' class='sale-banner'>
  <!-- Background image set via CSS: .sale-banner { background-image: url(/images/summer-bg.jpg); } -->
  <h2 class='sale-banner__headline'>Summer Sale</h2>
  <p class='sale-banner__offer'>Up to 50% off all products</p>
  <span class='sale-banner__cta'>Shop Now</span>
</a>

Infographic with labeled data points — Incorrect

<!-- An infographic where category labels and percentages are drawn
     into the PNG. Screen reader users hear the alt; sighted low-vision
     users cannot enlarge or recolor the labels. -->
<img src='/images/market-share-2024.png'
     alt='Market share 2024: Product A 42%, Product B 31%, Product C 27%'
     width='800' height='600'>

Infographic with labeled data points — Correct

<!-- An accessible SVG chart where all labels are SVG <text> nodes.
     Users can zoom, reflow, and apply high-contrast themes to the text.
     An adjacent <table> provides the same data in tabular form. -->
<figure>
  <svg viewBox='0 0 800 400' role='img'
       aria-labelledby='chart-title chart-desc'>
    <title id='chart-title'>Market Share 2024</title>
    <desc id='chart-desc'>Pie chart: Product A 42%, Product B 31%, Product C 27%</desc>
    <!-- chart paths -->
    <text x='200' y='150' class='chart-label'>Product A — 42%</text>
    <text x='450' y='200' class='chart-label'>Product B — 31%</text>
    <text x='350' y='320' class='chart-label'>Product C — 27%</text>
  </svg>
  <figcaption>
    <details>
      <summary>View data as table</summary>
      <table>
        <caption>Market Share 2024</caption>
        <thead><tr><th>Product</th><th>Share</th></tr></thead>
        <tbody>
          <tr><td>Product A</td><td>42%</td></tr>
          <tr><td>Product B</td><td>31%</td></tr>
          <tr><td>Product C</td><td>27%</td></tr>
        </tbody>
      </table>
    </details>
  </figcaption>
</figure>

CSS background image containing a text-heavy header — Incorrect

<!-- The page title is set as a CSS background image rather than real text.
     This is a common design pattern from the early 2000s image-replacement era
     that should not appear in modern codebases. -->
<h1 class='logo-header'></h1>
<!-- CSS: .logo-header {
       background: url('/images/page-title-about-us.png') no-repeat;
       width: 400px; height: 80px; display: block;
       text-indent: -9999px;
     } -->

CSS background image containing a text-heavy header — Correct

<!-- Real text is rendered by the browser. Custom web fonts reproduce
     the desired typographic style without sacrificing adaptability.
     The background image, if needed at all, is purely decorative texture. -->
<h1 class='page-title'>About Us</h1>
<!-- CSS: .page-title {
       font-family: 'BrandTypeface', serif;
       font-size: 3rem;
       color: #1a1a2e;
       letter-spacing: 0.05em;
     } -->

Common Mistakes

• Assuming a complete alt attribute satisfies 1.4.9. Providing a thorough text alternative in the alt attribute addresses WCAG 1.1.1 but does nothing for 1.4.9. The criterion is specifically about the visual rendering of text being accessible to customization, not about programmatic equivalents for screen readers.
• Using image-replacement CSS techniques (text-indent: -9999px or clip methods) on <h1> through <h6> elements. These legacy techniques hide real text visually and substitute a background image, meaning sighted users with low vision receive only the image while screen reader users receive only the hidden text — a mismatch that fails both populations in different ways.
• Exporting web typography as PNG or JPEG because a custom font is not available as a web font. If a licensed typeface cannot legally be served as a web font, the correct solution is to negotiate web font rights or choose an alternative typeface, not to rasterize text into images.
• Treating SVG files as inherently accessible. An SVG that embeds text as <path> elements (common output from graphic design tools like Illustrator's "outline text" option) is just as inaccessible as a PNG. The SVG must use <text> elements to pass 1.4.9.
• Embedding text in <canvas> elements without a real-text fallback. Canvas content is rasterized at the pixel level. Any text drawn via ctx.fillText() is not part of the DOM and cannot be adapted by user agents. A real-text overlay or alternative is required.
• Leaving scanned document images (PDFs rendered as images) without OCR-based real text layers. Scanned documents presented in <img> tags or as image-only PDFs fail 1.4.9. Running OCR and embedding a selectable text layer, or converting the document to properly tagged HTML, is required.
• Using images of text for dynamic data such as prices, stock quantities, or user-generated content. Any time a server generates an image that contains text data, that data is locked into the image format. Prices in product listings, seat availability on booking platforms, and live sports scores must be rendered as real text so that users can resize and recolor them.
• Overlooking email signature images. Marketing teams often create signature blocks as images to preserve visual branding. When those emails are archived and linked from websites, the signature images become web content subject to 1.4.9.
• Ignoring third-party widget content. Chat widgets, social proof badges, and review carousels provided by third-party vendors may inject images of text into the page. Site owners remain responsible for the accessibility of all content on their pages; if a vendor cannot provide text-based rendering, a different vendor should be sought.
• Confusing logotype exceptions with general branding exceptions. The logotype exception covers only the logo or wordmark itself — the stylized brand name. It does not extend to taglines, navigation labels, or any other text that appears alongside the logo in the same image.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility obligations for a broad range of organizations operating in Turkey. The circular requires covered entities to conform to WCAG 2.1 Level AA as a minimum baseline. The entities explicitly covered include public institutions and government bodies, e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education.

WCAG 1.4.9 is a Level AAA criterion and therefore sits above the mandatory minimum established by Presidential Circular 2025/10. Covered entities are not legally required to comply with 1.4.9 to meet the circular's baseline obligations. However, achieving Level AAA on applicable criteria demonstrates a best-in-class commitment to inclusion and significantly broadens the audience that can effectively use the service.

Several sectors covered by the circular have particularly strong incentives to pursue 1.4.9 compliance voluntarily. E-commerce platforms frequently use promotional banners, sale graphics, and product-category headers rendered as images — all of which are common 1.4.9 failure patterns. For users with low vision or dyslexia who rely on text customization to make purchasing decisions, these failures translate directly into lost conversions and potential legal exposure under Turkey's broader consumer protection and anti-discrimination frameworks. Banks and financial institutions similarly present loan rates, account summaries, and fee schedules; if any of this information is embedded in images, low-vision customers cannot adapt the presentation to read it confidently, raising concerns both under the circular and under financial services consumer protection rules. Hospitals and healthcare providers displaying dosage instructions, appointment details, or patient information in image form create patient safety risks for users who cannot adapt the text rendering.

Organizations seeking to future-proof their digital properties against regulatory evolution — or those pursuing public procurement contracts that require demonstrated accessibility leadership — are well advised to audit and remediate 1.4.9 failures as part of a comprehensive accessibility programme. Accsible's overlay SDK can assist with runtime text adaptation for some legacy image-of-text scenarios, but permanent code-level remediation — replacing images of text with real HTML text styled via CSS and web fonts — remains the most robust and durable solution for long-term conformance.