PowerPoint's accessibility checker asks whether your slide has a title. Excel's doesn't ask that at all.

What the checker actually looks for in each app

Microsoft publishes the complete rule set, application by application (Rules for the Accessibility Checker). Word's list, covered in our earlier piece on Word exports, runs to seven rules. Here is where PowerPoint and Excel diverge from it and from each other:

Eleven rules for PowerPoint, seven for Excel — the same total as Word, purely by coincidence, and not one shared rule beyond the four at the top. Everything below that line is specific to what can actually go wrong in that kind of file: a slide is a stack of independently placed objects with no inherent order, so PowerPoint checks titles, sections and reading order; a worksheet is a grid that gets exported flat, so Excel checks headers and sheet names and says nothing about titles or reading order at all.

What public bodies actually publish

None of the 111 born-digital PDFs behind our Word measurement — drawn from the same crawl of 1,682 Hungarian municipal websites — came from PowerPoint or Excel. Every one was Word, an unidentified export chain, or a handful of niche tools. That is itself the finding: at least in this sample, town councils publish minutes and decisions, not their slide decks or their working spreadsheets.

Widening the search across the same crawl, by file name rather than by content, told the same story twice. A search for anything reading as a presentation turned up nothing genuine — the only near-hit was a name that contained the Hungarian word for "representation," not "presentation." The one real slide deck we found published as a PDF had been built in Canva, not PowerPoint. Searching instead for file names that read as a spreadsheet — a "report," a "table," a "budget" — surfaced real candidates. We downloaded eight and opened each one: three were genuinely Excel, two were scanned paper printouts, one had been built in Word instead, and two had passed through a generic PDF printer that erases the trail of what made them, the same way "Microsoft Print to PDF" does in the Word sample.

Three real files is not a statistic. What it is, honestly, is confirmation that the PowerPoint half of this article rests on how the application works rather than on our own failure count — we simply couldn't find enough publicly published decks to measure. The Excel half fared better, and what those three files showed was worth the trouble.

PowerPoint's problem is order, not content

A slide has no inherent reading sequence. Text boxes, images and titles are objects placed on a canvas, and PowerPoint stores them in whatever order they were added or last touched — which is why "all slides have titles" is an Error and "the reading order of the objects on a slide is logical" is a Warning, and neither concept exists for Word at all.

The title has to exist, even when it doesn't show

A slide's title placeholder can be deleted from the layout entirely, so a bold heading-styled text box can look exactly like a title to a sighted reader while the file has no title at all. Microsoft's own guidance for exactly this case is to build a layout where "the title moves to an off-slide position, but it still exists," and to verify it by switching to Outline view, because the outline lists every slide's title whether or not it's visible on the canvas (Title a slide). That makes Outline view the right five-second test for one specific question — does every slide have a title — and nothing more: it shows titles and body text only, not pictures, not tables, not the order a screen reader will actually read them in.

Reading order is checked separately, per slide

Newer PowerPoint has a dedicated Reading Order pane — opened from the drop-down on a slide's thumbnail, or directly from an Accessibility Checker finding — that numbers every object on the slide in the sequence a screen reader will announce them, and lets you drag or move each one up or down the list (Reading Order pane instructions). Older guidance describes the same idea through the Selection Pane (Home → Arrange → Selection Pane), which still works and is what you'll find on the Mac. Either way, the number next to an object is the only reliable way to know what order it will be read in — the position on the slide tells you nothing.

Excel's problem is the table, not the page

We validated our three Excel-origin files against PDF/UA-1 with veraPDF 1.30.2 (build 2026-06-03):

~/.local/share/verapdf/verapdf -f ua1 --format json FILE.pdf

Two of them — genuine "Microsoft® Excel® 2021" exports of the same kind of financial report — produced real /Table structure: one had 26 tagged table rows and 130 tagged cells, the other 18 rows and 90 cells. veraPDF found only two failing checks on either file, out of more than seven thousand it ran on each: no dc:title in the XMP metadata, and no PDF/UA identifier — the identical two invisible failures that dominated our Word measurement. Same gap, different application.

What neither file had, anywhere, was a single /TH element. Every one of those 220 cells was tagged /TD. The header row exists and reads correctly to the eye, but nothing in the tag tree marks it as a header — and veraPDF's automated PDF/UA-1 check doesn't fail a table for that, because deciding which row is the header is a judgement call the syntax-level validator can't make on its own. Excel's own in-app checker can, and does, as an Error: it looks at whether Header Row is ticked on the Table Design tab, not at what ends up in the PDF (Make your Excel documents accessible). A file can tick that box in Excel and still lose the distinction on the way out. That's a genuine hole between what the source app checks and what a PDF/UA validator can catch after export, and worth knowing before you trust either tool's "no issues found" on its own.

The third file made the contrast sharper. It carried real, extractable body text — 2,646 characters on its first page alone — so it plainly wasn't a scan. But it had no structure tree of any kind, not even paragraph tags: positioned text with no relationships between the numbers at all. Its /Title metadata field still read almost exactly like the original spreadsheet's file name, .xls extension included — the clearest possible sign that it had gone out through a generic print-to-PDF path rather than Excel's own export. veraPDF found 375 failed checks on that file, against two on the properly exported ones. The spreadsheet software didn't fail here. Printing it did.

When a PDF is the wrong deliverable

For a genuinely tabular document — a full line-by-line budget, a register, a contract list — even a perfectly tagged PDF asks a screen reader user to reconstruct with the arrow keys what a real spreadsheet gives them for free: sorting, filtering, jumping to a specific row. A published .xlsx with the header row properly set, or an HTML table on the page itself, usually serves that reader better than any PDF, however well the table is tagged. A PDF still earns its place where the document itself needs to be a fixed, signed, citable record — an adopted budget, a formal decision — but the working data behind it belongs in a format someone can actually work with, not only in a flattened picture of one.

What to check this week

For a deck: open Outline view and confirm every slide has a title, even one you've deliberately hidden. Then open the Reading Order pane (or the Selection Pane on a Mac) on any slide with more than a heading and a body text box, and check the numbers match the order you'd want a listener to hear them in — not the order you happened to draw them.

For a workbook: before exporting, select your data range and use Ctrl+T → Header Row on the Table Design tab rather than leaving it as plain cells, give the table a real name instead of Table1, and rename sheet tabs off Sheet1. Then check what actually came out the other end — a /Table in the tag tree with proper headers, or just text sitting where it looks right.

If you want the full clause-by-clause list for a file you've already published, our PDF accessibility checker runs the same PDF/UA-1 checks as veraPDF, and the error reference explains what each failing clause means and which of them can be fixed automatically. Start with whichever export — deck, workbook or Word file — people actually download most.