Can a screen reader read a PDF turned into slides?
You converted a forty-page PDF into slides, dropped them into a deck, and it looks exactly like the document. Then someone in the room — the accessibility lead, the disability office, a procurement form with a tick box on it — asked whether a screen reader can read it.
You searched for an answer and got page after page about the opposite journey: how to export a PowerPoint deck to an accessible PDF. Every one of them assumes you started with real slides. You started with a PDF, and what you have now is forty pictures.
The short answer is no, and the reason is worth two minutes of your time, because it also tells you exactly which part of the deck you have to rebuild and which part you can leave alone.
What a screen reader actually finds on a slide
A screen reader does not look at a slide. It reads an accessibility tree that PowerPoint builds from the objects on the slide, and there are only four kinds of thing in it:
- The slide title, from the title placeholder. This is how a listener navigates a deck — "slide twelve, quarterly results" — and it is also what shows up in outline view.
- Text in placeholders and text boxes, read in whatever order the reading order says.
- The alt text of every picture, shape, chart and table. One short string per object.
- The reading order itself, which is a list, not something inferred from where things sit.
A picture contributes precisely one item to that list: its alt text. Not the words printed in it — the alt text someone typed. There is no step anywhere in PowerPoint that looks inside an image and finds letters.
So a deck built from page images has, per slide, one object, no title, and whatever alt text you have written. If you have written none, a listener hears "image" or "graphic", forty times, and that is the whole document. There is nothing else in the file.
Why the words did not survive the conversion
The words were in the PDF. They are not in the PNG, and the reason is that rendering is a one-way operation: a renderer reads instructions saying "draw glyph 47 of this font at these coordinates" and turns them into pixels. After that the page is a grid of coloured dots. The letters are as gone as they are in a photograph of a page.
This is what our PDF to PowerPoint produces, and we say so on the tool: one PNG per page plus an index, never a .pptx, because a PDF holds no slide structure to convert into one. It is not a defect in the converter. Every converter that shows you the page as it looks is doing the same thing, whatever it calls the output.
The part that surprises people: it makes no difference whether the source PDF was accessible. A properly tagged PDF carries a structure tree — headings, lists, reading order, alt text on its figures — sitting alongside the page content. Render that page and the tree stays behind in the PDF. You have thrown away the good version and kept a picture of it.
Alt text is not a text alternative for a page of text
The instinct at this point is to write alt text on all forty pictures and call the job done. It is better than nothing and it does not fix this.
Alt text is a short description of what an image conveys — a sentence, maybe two. A page of a report is 400 to 700 words with a heading structure, a table and three cross-references. There is no sentence that substitutes for it, and a listener cannot skim, search, jump by heading or copy a figure out of your description.
Two other things break at the same time, and they affect far more people than screen reader users:
- Someone who needs 200% text will get a blurry picture. Enlarging real text reflows it. Enlarging an image enlarges the pixels, which is the same arithmetic that made the slide look soft in the first place.
- High contrast and custom colour themes do nothing to it. Windows contrast themes and dark modes recolour text, not photographs. A reader who needs yellow on black gets black on white anyway.
This is also why WCAG has a separate rule about images of text (1.4.5) on top of the one about alternative text. The two failures are different, and page images fail both.
Getting the words back, and building slides that hold them
The route back is unglamorous: take the text out of the PDF and put it into real placeholders.
- Check there is text to take. If the PDF is a scan, the pages are already pictures and there is nothing to extract. Our OCR PDF tool reads every page and tells you which are real text, which are pictures and which are blank — read the limits before you upload, because it does not add a text layer, it only reports. For an actual text layer you need OCRmyPDF or your scanner's own software.
- Extract the text. PDF to text hands you a UTF-8 .txt file. Turn on keep the layout if the document is in two columns or built round tables, since that sorts by position on the page instead of by the order the glyphs happen to be stored in.
- Cut it down. A page of a report is not a slide. This is the step people resent and it is the one that produces a deck worth listening to.
- Paste it in outline view. View → Outline View, then paste. Each top-level paragraph becomes a slide with a real title placeholder; Tab demotes a line into the body placeholder underneath. This is the fastest way to get text into placeholders rather than into floating text boxes, and placeholders are what the reading order and the accessibility checker are built around.
- Bring the figures over as figures. Extract images from PDF pulls the photographs, charts and maps out of the PDF at the pixel size the file stores them at, so you place the chart on the slide rather than the whole page it sat on — and then write alt text describing that, which is a job alt text can actually do.
For a long document with headings, PDF to Word is a shortcut worth knowing. It marks headings up by type size, and PowerPoint's Home → New Slide → Slides from Outline builds one slide per Heading 1 with the lower levels as bullets. Save the file as a real .docx from Word first: what the tool gives you is an HTML document named .doc, and the outline importer wants a Word file.
Titles and reading order, the two things checkers care about
Once the text is in placeholders, two settings finish the job.
Every slide needs a title. It is the primary means of navigating a deck with a screen reader, and a deck of untitled slides is announced as "slide one, slide two, slide three". If a visible title would spoil the design, drag the title placeholder off the edge of the canvas — the text stays in the accessibility tree and never appears on screen.
Set the reading order explicitly. Review → Check Accessibility → Reading Order Pane lists the objects on the slide in the order they will be read, top to bottom, and you drag them into the order you want. Do not use the Selection pane for this: it lists z-order, and a screen reader reads it from the bottom up, which is how people end up with the footnote read before the heading. Anything purely decorative — a rule, a background flourish — should be marked decorative so it is skipped entirely.
Handing out the PDF instead — only if the PDF is tagged
The cheap answer everyone reaches for is to circulate the original PDF alongside the deck. It is a good answer when it is true, and it is often not true.
An accessible PDF is a tagged PDF: it carries a structure tree naming headings, lists, table cells, reading order and alt text. Most PDFs in the wild have none. A PDF exported from Word with tagging ticked has one; a PDF printed to a virtual printer, or produced by a scanner, does not. Untagged, a screen reader is left guessing reading order from geometry, and on a two-column page it guesses wrong.
Our PDF inspector reads the file in your browser, without uploading it, and tells you among other things whether the document is tagged and whether it has a real text layer. Those are the two facts that decide whether "here is the PDF as well" is a genuine alternative or a gesture. If it says untagged, the honest position is that neither artefact is accessible and the deck is the thing to fix.
Test it rather than believing anyone, including us
Screen readers are free, so there is no reason to guess.
- NVDA is free on Windows. Install it, open your deck, start the slideshow and let it read. Thirty seconds tells you what a listener gets, and hearing "graphic, graphic, graphic" is more persuasive than any checker report.
- PAC — the free PDF Accessibility Checker — is the tool for the other half of the question. It tests a PDF against PDF/UA properly, which is a stronger test than "does it have tags".
pdftotext -layout in.pdf out.txt(from poppler-utils) is the command line equivalent of step 2 above, and it will happily churn through a folder of files while you do something else.
Where the obligation comes from
One paragraph, because the rules differ by where you are and they move. In the UK, public sector bodies are covered by the 2018 accessibility regulations, which point at WCAG 2.2 AA. In the EU, EN 301 549 does the same job and the European Accessibility Act extends similar duties to a range of private-sector services. In the US, Section 508 covers federal agencies and the Department of Justice's Title II rule sets WCAG 2.1 AA for state and local government, phased in from April 2026. Teaching materials, board papers and published decks all tend to fall inside these. Check the current dates for your own body rather than trusting a blog post about PDFs — but if a deck is going anywhere near a public institution, assume the obligation applies.
None of this makes page images forbidden. It makes them something you have to provide an equivalent for, and rebuilding twelve slides of real text is usually less work than arguing about it.
The short version: a picture of a page carries one string of alt text and nothing else, no converter can change that, and the deck has to be rebuilt from the document's words rather than from its pages. While you are rebuilding, the white bars down the sides of every slide will go away too — real text boxes fill a slide of any shape.