Search topics
Scanned and untagged PDFs that screen readers can't read
A café links its lunch menu as a PDF that is either a scan of the printed menu, with no words in it at all, or an export with tags turned off, whose words are read across both columns with no headings.
q 595 0 0 842 0 0 cm /Im0 Do Q The problem
Blind visitors open the café's menu and hear nothing, or a jumble of two columns with no headings, so they can't find out what there is to eat or what it costs.
A neighbourhood café, Corner Kitchen, links its lunch menu from every page: "Lunch menu (PDF)". On screen the PDF looks like the card on the tables: the title, then two columns, soups and salads on the left and mains on the right, each dish with its price. The café made it in one of two ways, and each fails differently.
In the first, someone scanned the printed card on the office copier and uploaded the scan. Exporting from a design tool can give the same file: Canva's Flatten PDF option, often ticked so the print shop gets exactly what was designed, turns the words into an image too. A blind visitor follows the link, the PDF opens, and the screen reader says the file name and then nothing at all: the page is one picture, and there are no words in it. Selecting a line selects nothing, and searching for "soup" finds nothing. Zooming in shows a blurred photo of paper.
In the second, the menu was exported from a design app with its tags turned off. The words are real text, so the screen reader reads them, but as one run, in the order the file draws them: "Lunch menu. Soups and salads Mains. Tomato soup 6.50 Mushroom risotto 12.00. Green salad 7.00 Grilled chicken 13.50." The lines go straight across both columns, so each soup is followed by a main course, and nothing says the title and the two section names are headings. Pressing H to jump to the next heading finds none.
A PDF the site links to is part of the site's content, and WCAG applies to it as it does to the page; the W3C keeps a set of PDF techniques for exactly that. The two forms fail different criteria:
- The scan is non-text content with no text alternative, which fails 1.1.1. Every word of the menu exists only as pixels, and an untagged PDF has no Figure tag on which alternative text could even be set.
- The untagged export fails 1.3.1 and 1.3.2. In a PDF, headings, lists and tables, and the order to read them in, are carried by tags, as HTML elements carry them in a page. With no tags, the title's size and the section names' weight are presentation only, and the reading order is whatever order the file happens to draw its text in. Here that runs across the columns, which changes the meaning: a price ends up next to the wrong dish.
A PDF that fails can still be part of a conforming site, if a conforming alternate version sits beside it: a page with the same content, kept as current, that people can reach from where they find the PDF. That is the first fix below.
Menus, price lists, size guides, terms and brochures are often published only as PDFs, so a visitor who can't read the file has no other way to get what is in it, short of asking the café to read it out.
3 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision In the scan there is no text for a screen reader to read, so the menu is an empty page with a file name. In the untagged export the words are there, but with no headings to jump between, and the two columns run together line by line, so dishes and prices from both sides are read as one.
- Limited vision Zooming into a scan enlarges a blurred photo of paper, and nothing in it reflows, takes larger text or changes colour. On a phone, a PDF of a printed page has to be pinched and panned line by line either way.
- Limited language, cognitive and learning abilities People who listen with read-aloud tools, change the font or translate the page get nothing from the scan, and the untagged export is read out in an order that mixes the two sections.
Page checkers such as axe test the page's own HTML. The PDF is a separate file they never open, so a site whose every document is a scan can pass them with no errors; all they see is a link, and the link is fine. This audit opens the PDFs a page links to, the first five on each page and each one once per run, and reads their bytes. A PDF with no font, no tags and no alternative text, only pictures, is reported: the code alone proves there is nothing in it to read. Every other linked document goes to a person as a lead, because whether it works depends on what is in it. An untagged PDF with text may lose a little structure or a lot. A tagged one may have its tags in the wrong order, a heading tagged as a paragraph, or a table tagged as loose text. Word and Excel files aren't opened at all.
Two shortcuts look like fixes and aren't. Running OCR on a scan ("make searchable") adds a hidden text layer, which gets past the "has text" test, but it adds no tags, and it misreads: "6.50" can come out as "650" and a column break as nothing. Some PDF viewers now run OCR on a scan for screen reader users themselves, with the same limits, and only in those viewers. Asking an AI tool or Acrobat's automatic tagging to "make the PDF accessible" usually sets a title and language and guesses the tags from the layout, and on a two-column page the guess often keeps the order straight across.
Try it
Open the café’s lunch menu, then listen to it the way a screen reader user would.
The panel shows what a screen reader reads from the top of the menu. Are there any words, and are the dishes read with their own section and price? Broken 2 is the same menu exported without tags.
Broken Can you fix this?
Reading the menu from the top, a screen reader says:
(Open the lunch menu)
The fix
Put the menu on an HTML page, or replace the file with a tagged PDF exported from its source.
- 1Every word in a document is real text, never only a picture of it.
- 2Headings, lists and tables are marked, as HTML elements or PDF tags, in the order they are shown.
- 3A PDF kept beside a page as its print version says exactly what the page says.
A scanned menu
<a href="/files/lunch-menu.pdf">Lunch menu (PDF)</a>The menu as a web page
<a href="/lunch-menu">Lunch menu</a> <!-- /lunch-menu --><h1>Lunch menu</h1><div class="menu"> <section> <h2>Soups and salads</h2> <ul> <li>Tomato soup, 6.50</li> <li>Green salad, 7.00</li> <li>Lentil salad, 7.50</li> </ul> </section> <section> <h2>Mains</h2> <ul> <li>Mushroom risotto, 12.00</li> <li>Grilled chicken, 13.50</li> <li>Bean chilli, 11.00</li> </ul> </section></div><p><a href="/files/lunch-menu.pdf">Print version (PDF, 1 page)</a></p>Why this fix: Publish what people read on screen as a page, not a PDF
The page's only content is the image Im0, drawn at the size of the page. The file uses no font, so there are no words in it to read, select, search or enlarge, and with no tag tree there is nowhere to put alternative text.
The menu is now text in the page, so a screen reader reads every dish, announces the title and both section names as headings, and reads each section as a list of three, one column after the other, because that is the order of the HTML. It also reflows on a phone, grows with the reader's text size, and can be searched and translated. The site links to the page, not the file.
The print version is optional. If you keep it, link it only from this page, make sure it says exactly what the page says, and replace it whenever the menu changes: the page counts as the PDF's conforming alternate version only while the two match. A print stylesheet on the page itself (@media print) can do the same job with nothing to keep in step.
Both pass 1.1.1, 1.3.1 and 1.3.2. The page is usually the better home for something people read on screen and that changes often, such as a menu, a price list or opening hours: it costs one page in the site's own templates, needs no PDF tools, works the same in every browser and on every phone, and has no tags to check after each edit. The tagged PDF is the one to keep when the file itself is the point: an invoice, a signed agreement, terms someone saves, or a brochure designed for print. It costs an export with tags on and a check after every change, and a scan costs a retype or a careful repair. Many sites do both: a page for the content, and a tagged PDF as its print version.
While the PDF is open in a checker, set what it needs to work as a document of its own. Each comes from the same export or from Acrobat's document properties.
- A title. Set the document title (File > Properties) and turn on "show document title" (DisplayDocTitle), so the window and the screen reader announce "Lunch menu", not "lunch-menu.pdf".
- A language. Set the document language, so a screen reader reads the words in the right voice. A passage in another language needs its own.
- Decoration as artifacts. Borders, background textures and page numbers are marked as artifacts, so they aren't read between the dishes.
- Prices that line up. When dishes and prices sit in two aligned columns of their own, tag them as a table with header cells, or keep each price in the same text run as its dish, as here.
Say on the link what it opens. A link named "Lunch menu (PDF, 1 page)" tells people a file is coming, which matters on a phone, and a link to a page needs no label at all.
Treat the PDFs a site already has as a list to work through. Start with the ones people need to buy or book (menus, price lists, size guides, terms), retire the ones nobody needs, and turn each remaining one into a page or a tagged PDF when it is next updated.
Interactive forms in PDFs, such as an order form with fields to fill in, raise more than this guide covers: every field needs a name, and the order of the fields needs checking. Build them as HTML forms where you can.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
5 checks, no mouse.
Test with: Screen reader
Record the OS, browser, PDF viewer and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever the document is replaced, re-exported or edited.
Limits
This is a starting pattern, not a guarantee for every document. The PDF code is cut down to the lines that matter: object numbers, fonts and coordinates are placeholders, and … stands for the rest of the page's tagged lines. Screen readers and PDF viewers handle untagged files differently, some guessing an order or running their own OCR, so test in the viewers your visitors use, not only one. This guide covers whether a document's words exist as text and its structure and order are tagged. It doesn't cover PDF forms, the contrast or text size inside a document, or Word and Excel files, which need their own app's checker. Test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: non-text-content (opens in a new tab)
- WCAG Understanding: info-and-relationships (opens in a new tab)
- WCAG Understanding: meaningful-sequence (opens in a new tab)
- WCAG Understanding: conformance (opens in a new tab)
- WCAG Technique PDF7 (opens in a new tab)
- WCAG Technique PDF9 (opens in a new tab)
- WCAG Technique PDF21 (opens in a new tab)
- WCAG Technique PDF3 (opens in a new tab)
- WCAG Technique PDF1 (opens in a new tab)
- gov.uk: publishing-accessible-documents (opens in a new tab)
- support.microsoft.com: create-accessible-pdfs-064625e0-56ea-4e16-ad71-3aa33bb4b7ed (opens in a new tab)
- pac.pdf-accessibility.org: en (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.