1.4.5 Images of Text
- Level AA
- Perceivable
- Since WCAG 2.0
Summary
Real text can be enlarged without blurring, reflowed to fit a narrow viewport, recoloured for contrast, respaced for readability, and read aloud by a screen reader. A picture of text can do none of that. This criterion protects people with low vision who scale or recolour text, readers with dyslexia who apply their own fonts and spacing, and anyone relying on user stylesheets or reading modes: if the visual effect can be achieved with styled text, it must be, rather than baking the words into a bitmap.
The auditor's mental model is a two-step question for every piece of visible text: is this actual text, and if not, does an exception apply? There are only two exceptions. Essential covers cases where the specific presentation is the point: logos and logotypes, screenshots that show a real interface, and text captured inside photographs. The "customizable" exception covers the rare interface where the user can restyle the image text to their own requirements, such as a font-preview tool. Everything else, most classically the promotional banner with a headline exported inside the JPEG, is a fail, and a perfectly written text alternative does not rescue it: alt text is the SC 1.1.1 Non-text Content half of the problem, not this one.
Official wording
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:
Customizable:
The image of text can be visually customized to the user's requirements;
Essential:
A particular presentation of text is essential to the information being conveyed.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.5
- Software and native apps
- Clause 11.1.4.5
- Closed functionality (kiosks, terminals)
On closed systems the requirement becomes built-in speech output for non-text content under clause 5.1.3.6.
Clause 9.1.4.5 applies this criterion to web pages unchanged and clause 11.1.4.5 applies it to software that supports assistive technologies. On closed systems the requirement becomes built-in speech output for non-text content under clause 5.1.3.6.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start with the zoom test. Zoom the page to 200 percent or more (Ctrl or Cmd plus). Real text stays crisp at any magnification; images of text go soft, pixellated, or jagged. Anything that blurs when everything around it stays sharp is a bitmap, and the words inside it are your candidates.
Confirm with the browser's developer tools. Right-click the suspect text and inspect it: real text is a DOM text node you can select with the cursor and restyle live in the styles panel; an image of text is an img element, an SVG raster embed, or a CSS background-image with no corresponding text in the markup. Trying to select the words with the mouse is a quick field version of the same check: if the selection highlight refuses to land on individual words, you are looking at a picture.
The classic web failures are promotional content: hero banners and campaign tiles with the headline, offer, and terms baked into the artwork, CTA buttons exported as images, and "designed" pull quotes rendered as graphics for typography reasons. Webfonts and modern CSS can achieve almost any typographic treatment, which is exactly what the criterion's opening condition ("if the technologies being used can achieve the visual presentation") is pointing at: on the modern web that condition is nearly always met, so the fancy-font justification almost never survives scrutiny. Logos are essential and pass; genuine screenshots of an interface are essential and pass, because recreating a UI in styled text would misrepresent what the screen actually shows.
iOS
The European standard applies this criterion to apps that support assistive technologies, so grade iOS screens against it directly. The sharpest test is Dynamic Type: raise the text size (Settings, Accessibility, Display and Text Size, Larger Text) and revisit the screen. Real text set with system text styles grows; words baked into image assets do not move, which both exposes the bitmap and demonstrates the practical harm (the failure to scale itself is graded under SC 1.4.4 Resize Text, but the fixed text is your 1.4.5 evidence).
Use Accessibility Inspector or Xcode's view debugger to confirm what the element is: a text element (UILabel, SwiftUI Text) is real text; words that exist only inside a UIImageView or an asset-catalogue graphic are an image of text. A magnification pass (pinch-zoom where available, or simply a screenshot enlarged) shows the same blur signature as on the web.
Common iOS failure spots: marketing carousels and home-screen promo tiles served from a CMS with copy composed into the artwork, image-based buttons where the label is part of the PNG, onboarding illustrations that carry instructional text inside the image, and badge graphics with baked-in wording. App icons and splash branding are logo territory and essential.
Android
The same rule applies to Android apps that support assistive technologies. Test with the system font size and display size settings (Settings, Accessibility, then font size, or the display size sliders): real text in TextView or Compose Text elements scales with the sp-based setting; text drawn into a drawable or served inside a bitmap stays fixed. As on iOS, the refusal to scale is the tell.
In Android Studio, Layout Inspector settles the question definitively: words rendered by a text component are real text, words that only exist inside an ImageView or a background drawable are an image of text. On device, TalkBack offers a secondary signal: if the words are only announced because someone wrote them into a contentDescription, the visible rendering is an image (a good description passes SC 1.1.1 Non-text Content, and the screen still fails here).
Common Android failure spots: remote-config promo banners with baked-in offers and terms, image-based CTA buttons, feature-announcement cards composed as single bitmaps, and instructional text flattened into onboarding artwork. Screenshots shown in a help centre, and the app's own logo, are essential and pass.
Pass and fail examples
Passes:
- A hero headline rendered as real text over a background photograph, styled with a webfont: the technology achieves the visual presentation with text.
- The company logo in the site header or app toolbar: logotypes are the canonical essential exception.
- A screenshot of the app's settings screen inside a help article: showing the actual interface is essential, since styled text would not be a faithful record of the UI.
- A street sign captured inside a news photograph: the text is incidental content of the photo, and the photo is the point.
- A font-preview tool where the user picks the face, size, and colour of the rendered sample: the "customizable" exception applies because the user controls the presentation.
Fails:
- A promotional banner with the headline, discount, and terms exported inside the JPEG, even though its alt text repeats every word: the alt satisfies SC 1.1.1, and the screen fails 1.4.5 regardless.
- A "Start free trial" button that is a PNG with the label drawn into the artwork.
- A pull quote rendered as a graphic because the designer wanted a specific typeface: webfonts achieve that presentation, so the exception does not apply.
- An app carousel tile with three lines of body copy baked into the image, which stays fixed while every real label on the screen grows under Dynamic Type or Android font scaling.
Not a fail under this criterion:
- An image of text with a missing or wrong text alternative: file that under SC 1.1.1 Non-text Content. The two findings are independent halves of the same banner.
- Image text with poor contrast against its background: text inside images is still graded for contrast, and that finding files under SC 1.4.3 Contrast (Minimum).
- Real text that breaks or clips when scaled to 200 percent: that is SC 1.4.4 Resize Text, not an images-of-text finding.
- A logo that is hard to read at small sizes: logotypes are exempt here; if it carries a function (a home link) grade its alternative and name under the appropriate criteria instead.
Commonly confused with
- SC 1.1.1 Non-text Content. The most common misfiling. 1.1.1 asks whether the image has a text alternative; 1.4.5 asks whether it should have been an image at all. A promotional banner with immaculate alt text passes 1.1.1 and still fails 1.4.5. Grade the two independently and never let a good alt close an images-of-text finding.
- SC 1.4.3 Contrast (Minimum). Text inside an image gets no contrast amnesty. Low-contrast baked-in text produces two findings: the contrast fail under 1.4.3 (measured by sampling the image's pixels) and the images-of-text fail here. Keep the evidence separate.
- SC 1.4.4 Resize Text. 1.4.4 grades whether text can be resized to 200 percent without loss; bitmap text that cannot scale is often what surfaces during that test. The resize behaviour files under 1.4.4, the decision to use an image of text files here. One screen can legitimately carry both.
- SC 1.4.9 Images of Text (No Exception). The Level AAA sibling removes the "customizable" option: at AAA, images of text are allowed only where the presentation is essential or purely decorative. If an auditor refuses the customisation defence on a Level AA audit, they are applying the AAA bar.
How AUDITSU tests this
AUDITSU's audit walkthrough covers images of text on every screen you review. The per-screen questions prompt you to scale the text (browser zoom on web, Dynamic Type on iOS, font size on Android) and flag any words that stay fixed or blur, then confirm each suspect with an inspection step (devtools, Accessibility Inspector, or Layout Inspector) before grading. Each question records a pass, fail, or not applicable result per screen with the evidence attached, and the exception reasoning (logo, screenshot, customisable presentation) is captured alongside the grade so the finding is defensible in the final report.
The European standard applies this requirement to web content and to software that supports assistive technologies, which is how the walkthrough grades websites and standard mobile apps. For closed systems, where users cannot attach their own assistive technology, the requirement changes shape: the product itself must provide speech output for non-text content, and the walkthrough branches accordingly when an audit targets that kind of hardware.
For the full guided workflow, see the audit platform.