Image Accessibility Beyond Alt Text: Captions, Contrast and Text in Images

Most image accessibility work stops at alt text, and alt text is genuinely the largest single item. It is not the only one, and the failures that remain after it are the ones that produce complaints, audit findings and — for organisations covered by accessibility legislation — legal exposure.

They also tend to be invisible to automated checkers. A scanner reports missing alt attributes accurately and cannot tell you that the alt text is wrong, that a chart has no text equivalent, or that your hero headline is baked into a JPEG.

This is what remains once the alt attributes are filled in. It assumes you have the rules for writing alt text itself already settled, because everything here sits on top of that.

Text baked into images

This is the most consequential and the most common, and it is the one people are most reluctant to fix because the image usually looks good.

A headline, a price list, a set of opening hours or a promotional banner rendered as an image is inaccessible in several directions at once. A screen reader cannot read it beyond whatever the alt text says. A user who increases their font size gets nothing, because the image does not respond. Someone zooming to 200 percent gets a blurry approximation — and no amount of correct responsive image delivery helps, because the problem is that the words are pixels rather than that the file is the wrong size. Translation tools skip it. Nobody can select or copy it.

WCAG success criterion 1.4.5 addresses this directly: use real text rather than images of text where the same visual presentation can be achieved with text. The exceptions are narrow — logotypes, and cases where a specific presentation is genuinely essential.

The reason this persists is that images of text are convenient. A designer produces a banner in one tool and it ships as one file. The fix is to rebuild the composition as an image plus real HTML text positioned over it, which is more work up front and free thereafter.

Where to look for it on your own site: promotional banners, hero graphics with headlines, pricing tables saved as images, opening-hours graphics, quote cards, and anything exported from a design tool as a single flattened asset. The quick test is to try selecting the words with your cursor. If you cannot, neither can anyone else.

There is a direct search consequence too, which is worth mentioning when justifying the effort: text inside an image is not indexed as page content. Your best-argued headline contributes nothing if it exists only as pixels.

Complex images: charts, diagrams, maps

An alt attribute is meant to be short. A chart conveying twelve data points and a trend is not a short thing.

Cramming it into alt text produces an unusable result — a screen reader reads it as one unbroken run with no structure, no ability to navigate back, and no way to re-check a single value. The user experience is worse than a bare "bar chart".

The pattern that works has two parts. The alt text identifies the image and its purpose: "Bar chart: monthly organic sessions, January to December 2026". Then the actual content appears as real text nearby — a short summary of what the chart shows, and where the precision matters, a data table.

Image type	Alt text does	Text equivalent needed	Where it goes
Simple photograph	Full job	No	—
Chart or graph	Names the chart	Yes — summary plus data	Below the image, or a details element
Process diagram	Names the diagram	Yes — ordered list of steps	Adjacent text
Map with pins	Names what is mapped	Yes — list of locations	Adjacent text, or the addresses on the page
Screenshot with UI text	Names the screen	Sometimes — if the text matters	Caption or body text
Decorative image	Empty alt	No	—

The visible-text-equivalent approach has a useful side effect. Sighted users on slow connections, users who print the page, and machines reading the page all get the content. This matters increasingly for how images and their surrounding text are used in AI-generated answers, where a chart with no text equivalent is simply an absence — the system has the alt attribute and nothing else to work with.

A <details> element containing the data table is a clean way to include a long description without dominating the page layout.

Captions, and what they are for

Alt text and captions are often confused and they do different jobs.

Alt text replaces the image for someone who cannot see it. It is not displayed. Its audience is people using assistive technology and situations where the image fails to load.

A caption is visible to everyone and adds context the image alone does not carry — a source, a date, a name, an explanation of what to notice.

Because they have different audiences they should not be identical. An alt attribute that duplicates the caption word for word means a screen reader user hears the same sentence twice in a row, which is the specific annoyance the figure and figcaption elements exist to avoid.

The useful pattern:

<figure>
  <img src="/img/pcm-bench.webp"
       alt="A control module clamped in a bench harness with a programmer connected"
       width="1200" height="675">
  <figcaption>Bench programming avoids removing the vehicle's battery — Arlington workshop, 2026</figcaption>
</figure>

The alt describes what is depicted. The caption adds what a viewer would not know from looking. Neither is redundant.

Captions are also underused as ordinary page content. They sit immediately adjacent to the image, they are read by everyone, and they are crawlable text closely associated with the image — which makes them one of the better places to add genuine context. They are on the standing image checklist for that reason as well as the accessibility one.

Contrast on text over images

This is the failure that survives design review most often, because it is checked incorrectly.

A designer places white text over a photograph, samples a colour from the background, checks it against white, and gets a passing ratio. But a photograph is not one colour. Where the text crosses a bright area, real contrast may be 1.8:1 while the sampled figure said 6:1.

The requirement is 4.5:1 for normal text and 3:1 for large text, and it applies at every point the text overlays, not on average.

Three approaches actually work:

A scrim. A semi-transparent dark layer between image and text. Unglamorous, completely reliable, and easy to verify because the text now sits on a known colour.

A gradient overlay. Darkens only the region the text occupies, preserving more of the image. Verify against the busiest part of the region rather than its edges.

Move the text out. Put the headline in a solid panel beside or below the image. Loses the overlay aesthetic and removes the problem entirely.

Then check at the responsive breakpoints. Text positioned over a calm part of an image on desktop frequently lands on the busiest part on mobile, because the crop changes and the text reflows. This is why contrast failures survive: they were checked once, on one viewport.

Images as the only signal

A subtler failure: using an image to convey something with no text alternative anywhere in the interface.

A red dot indicating stock status. An icon distinguishing two plan tiers. A colour-coded map with no key. A ticked box that is an image with no accessible name. In each case someone who cannot see the image, or cannot distinguish the colours, loses information that exists nowhere else.

The fix is not more alt text — it is adding a text label. "In stock" beside the green dot. The word "Included" beside the tick. This overlaps with the general rule that colour must never be the sole means of conveying information, and it comes up constantly in e-commerce, where swatches, badges and availability indicators are all frequently image-only. Product image requirements for e-commerce covers the commercial side; the accessibility side is simply that every state indicated by an image or a colour needs a word somewhere.

An audit you can actually run

Automated tools find missing alt attributes and little else here. This pass takes about an hour on a mid-size site and finds what they miss:

1. Try to select text on every hero, banner and promotional graphic. Anything you cannot select is an image of text.
2. Zoom the browser to 200 percent. Note anything that becomes illegible — that is usually an image of text or a contrast failure.
3. Find every chart, diagram and map. Confirm each has a text equivalent nearby, not just alt text.
4. Check contrast on every text-over-image element, at mobile and desktop widths, against the busiest part of the image.
5. Turn off images entirely in the browser and load your key pages. What is now unusable is what depends on images alone.
6. Read one page with a screen reader. VoiceOver and NVDA are both free. Fifteen minutes of this teaches more than any checklist, particularly about decorative images that should have been skipped and were not.

Run it alongside your regular technical pass rather than as a separate project — several of these steps use the same crawl output as a site-wide image audit, and the two lists of findings are worked through by the same people.

Step five is the fastest of these and the most revealing. A page that becomes incomprehensible without images is telling you exactly where the missing text equivalents are.

Why this is worth the time

The access argument stands on its own, and for many organisations it is a legal requirement rather than a preference.

The secondary benefits are real and worth naming when arguing for the work. Real text instead of images of text is indexable text. Captions are crawlable context sitting adjacent to the image. A chart with a data table beside it can be read, quoted and summarised by search systems that would otherwise see nothing. Every one of these fixes makes the page more legible to machines for exactly the reason it makes it more legible to people — the information exists as text rather than only as pixels.

That is the pattern worth internalising. Accessibility failures around images are nearly always the same failure in different costumes: something meaningful exists only in a form that cannot be read.