What the Screen Reader Hears: A Practical Audit for Machine-Written Image Descriptions

The difference between a description and a guess

A screen reader does not see an image. It hears whatever the page, document or post supplies. When that text is generated by an AI tool, the result can sound confident, grammatical and entirely wrong. A product photo may be described accurately in general terms but miss the variant colour. A chart may be summarised in a way that reverses the trend. A video caption may turn a client name into a stranger's name, or drop the word not from a safety instruction.

For UK small and medium-sized firms, this is no longer a niche concern. AI-assisted content production is spreading through marketing, e-commerce, HR, training and customer service. The same tools that draft image descriptions can also generate captions for video, summaries of PDFs and descriptions for social posts. The operational risk is simple: machine-written text can be published at speed, but the check that makes it usable is often skipped.

Accessibility is not only a compliance matter. It affects whether a disabled customer can understand a product, complete a purchase, follow a training module or use a public document. The practical question for 2026 is not whether AI can generate descriptions. It is who checks them, against what standard, and before which publication gate.

Where plausible text becomes unusable text

AI-generated accessibility text tends to fail in predictable ways. It may describe what is visibly obvious but omit the information the image is there to convey. It may invent details that were not present. It may use vague language such as image of a person or screenshot of a document, which adds little for a screen reader user. It may treat decorative images as meaningful, or meaningful images as decorative. It may produce captions that are readable but not synchronised, or that miss speaker changes and non-speech sounds.

Document descriptions bring a further layer. An AI tool may summarise a PDF accurately in places while ignoring reading order, table structure, headings and form labels. A summary is not a substitute for an accessible document. For customer-facing material, the description must serve the task the reader is trying to complete, not merely prove that a tool has been used.

There is also a governance gap. Many teams assume the platform, the agency or the content management system owns the problem. In practice, ownership often sits nowhere. The tool generates text, a content editor publishes it, and no one is accountable for whether the description is correct. That is the point at which a low-cost efficiency becomes a customer-facing defect.

A lightweight audit in five passes

A full accessibility programme can be extensive. A useful audit does not need to begin that way. For an SME, a sample-based review is often enough to find the pattern of failures and decide where controls are needed.

1. Choose a representative sample

Select 20 to 30 assets across the places where customers meet your content: product pages, landing pages, social posts, email templates, PDFs, training videos and forms. Include high-risk examples such as pricing, product specifications, safety information, financial details and legal notices. Include low-risk decorative imagery too, because that is where empty alt text and over-description often go wrong.

2. Read the text without the image

Ask a colleague who has not seen the image to read the alt text aloud. Can they explain the purpose of the image, not merely its appearance? For a functional image such as a button or icon, does the text describe the action? For a complex chart, is there a short description plus a longer explanation elsewhere? For a decorative image, is the alt attribute empty so that the screen reader can skip it?

3. Check the facts against the source

AI-generated descriptions can drift on names, numbers, dates, locations, product variants and relationships. Compare the description with the image and the surrounding page copy. A caption that says a person is presenting to a team may be harmless; a description that misstates a medication dose, a financial figure or a safety instruction is not.

4. Test with assistive technology

A short spot check with a screen reader is more revealing than reading the text on screen. Use a common combination such as NVDA with a desktop browser, or VoiceOver on a Mac or iPhone. Navigate the page or document with the keyboard. Check whether the description is announced in a useful order, whether form fields have labels, and whether the alt text is repeated unnecessarily alongside a visible caption.

5. Record what you find

Keep a simple register: asset type, owner, tool used, date checked, issue found and action taken. This does not need to be a heavy compliance artefact. It is an operational record that shows where AI-generated text is entering customer-facing content and which checks are actually happening.

Assign ownership before publication

Accessibility text should have a named owner before it goes live. In a small firm, that may be the digital content lead, the marketing manager or the operations lead. The important point is that the role is explicit and has a backup. The person who operates the AI tool is not automatically the person accountable for the published result.

A practical model is to separate generation from approval. The tool may draft alt text, captions or document descriptions. A content owner then reviews them against the page purpose and the source material. High-risk assets should require a second check. Low-risk decorative imagery can be sampled rather than individually approved. The approval step should sit inside the existing publishing workflow, not in a separate document that no one reads.

It also helps to define what must never be auto-published. Customer-facing product information, safety content, financial promotions, legal notices, health information and anything involving vulnerable customers should not rely on unreviewed machine text. For those categories, the default should be human sign-off.

UK expectations without the legal fog

The UK accessibility landscape is often described in legal terms, but the operational point is narrower. The Equality Act 2010 sets expectations around reasonable adjustments and avoiding discrimination. Public sector bodies have specific accessibility regulations for websites and mobile applications. Many private firms encounter accessibility through procurement, customer contracts, insurer questionnaires or their own published standards. WCAG 2.2 AA is widely used as a practical benchmark, even where it is not a direct legal obligation.

The sensible approach for an SME is not to attempt a legal treatise. It is to show that customer-facing content is being checked, that issues are recorded and that responsibility is assigned. If a customer, auditor or procurement team asks how AI-generated descriptions are controlled, the firm should be able to point to a process rather than a promise.

A small discipline with a customer-facing payoff

AI can reduce the time spent drafting alt text and captions. That is a genuine operational gain. But the value depends on the review that follows. A description that is plausible but wrong is worse than no description at all, because it gives the reader false confidence and can misrepresent the business.

The audit does not need to be elaborate. A representative sample, a read-aloud test, a fact check, a short assistive-technology spot check and a named owner will catch many of the failures that matter. For UK firms adopting AI in everyday workflows, that is a practical control: small enough to run, clear enough to assign and close enough to the customer experience to be worth doing.