An email goes out to 12,000 subscribers with a big code in the middle and the alt text set to "QR code." A subscriber using a screen reader hears "graphic, QR code," and that is the entire message: no destination, no purpose, no link. She deletes it. So does every subscriber whose email client blocks images by default, because they saw the same two words on screen.
Alt text on a QR image fails in a specific, fixable way. The wider subject is covered in our post on making codes work for everyone. This is the narrow version: what to type into the attribute, and what to put beside the image because the attribute alone is never enough.
Describe the destination, not the graphic
"QR code" describes the picture. Nobody needs the picture described. A listener needs to know where it goes and why they would follow it.
Weak: QR code. Also weak: scan me. Slightly better and still useless: QR code for our website.
Useful: "Dinner menu for Bar Vega." Or "Register for the October safety training." Or "Check the status of your repair." The pattern is destination plus purpose, in the plainest words available, short enough to take in on one hearing.
Drop the word "image" and drop the word "code." Screen readers already announce that the element is a graphic, so "image of a QR code for..." makes the listener sit through redundant words before reaching anything they can use.
The picture is not the point, the link is
Here is the part markup alone cannot solve. Even perfect alt text gives a screen reader user no access to the destination, because a QR code is an optical format. Reading it requires pointing a camera at it. Anyone hearing about the code on the same phone that would do the pointing cannot scan their own screen, sighted or not.
So the rule for any code that appears on a screen: put the real link next to it, as text. Not a decorative image of a URL. An actual link element with meaningful text a reader can activate.
Once that link exists, the image is decoration for the people who can use it. Give it an empty alt attribute (alt="") and let the text link carry the meaning. A screen reader then announces one thing rather than two nearly identical ones. If no adjacent text link exists for some reason, the image needs descriptive alt text and should itself be wrapped in a link to the same destination.
Web, email, and PDF each behave differently
Web. Standard alt attribute rules apply. Decide first whether the image is informative or decorative, then either write the destination-and-purpose sentence or use an empty alt. Never leave the attribute off entirely; a missing attribute makes some screen readers fall back to the file name, which is how listeners end up hearing "q r underscore final underscore v 4 dot p n g."
Email. Alt text does double duty here, because many clients block remote images until the reader allows them. That text is what everyone sees at first render, not only assistive technology users. Keep it short, make sure it is legible against the background, and always include a typed URL line as well. Exporting the code as a PNG keeps rendering predictable, since email clients handle vector formats inconsistently at best.
PDF. Alternate text does exist in PDF, set on a tagged figure, and most exports never set it. In practice: turn on tagging in your layout tool's export settings, add alternate text to the code image, then verify with the accessibility checker built into a PDF reader. An untagged export hands a screen reader a page of unlabeled shapes.
Print has no alt attribute, so the URL is the alt text
On a poster, a table tent, a shipping label, or a wall sign there is no markup layer at all. The equivalent accommodation is a short, human-readable URL printed beside the code at a size someone can read and type.
Typeable is the operative word: no long query strings, no random-looking identifier, ideally a path a person can copy from across a room. A tidy short link does exactly this job. The same line rescues anyone with an older phone, a dead battery, a scratched lens, or no signal in that basement corridor.
While the artwork is open, check contrast too. Low-vision readers and cheap camera sensors fail on the same designs, and our contrast rules cover where the thresholds sit. Sizing, margins, and output settings for physical pieces are in the print guide.
Not everyone can hold a camera steady
Aiming a phone at a small target and keeping it still is a motor task. Tremor, limited grip strength, a wheelchair user facing a code mounted at standing eye height, someone holding a child in the other arm: all of them are approaching your code with a device that will not lock focus.
What helps:
- A bigger code. Larger modules tolerate blur, angle, and shake far better than small ones. Size is the cheapest accessibility improvement available on any physical code.
- A shorter payload. Fewer encoded characters means a lower version number and physically larger modules at the same overall dimensions.
- The typed URL, again. It is the fallback for every failure mode at once.
- A second channel. An NFC tap target, a phone number, or a staff member at a desk who can help.
- Dedicated scanner apps. Some tolerate motion better than the default camera app and read results aloud as text; our notes on scanning tools cover the differences.
Mounting height matters as much as any of that. A code placed at a standing adult's eye level sits out of comfortable reach for a seated user, and a code at knee height is bad for everyone. Somewhere between a doorknob and a light switch works for more bodies than either extreme.
Open the last three emails your team sent and look at the alt attribute on every image. Rewrite anything that says "QR code" into a sentence naming the destination, then confirm a real text link sits beside the image. That pass takes about ten minutes and fixes the most common version of this problem.
