AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.
Our own slide check looked at the thumbnails and reported no problems. The thumbnails were small, the body text inside them stood four pixels high, and the check had a rule about declared font sizes rather than about pixels. Every slide passed. In the room, half the slide deck was unreadable from row ten, signed off by a gate that never opened the surface the audience would see.
What we assumed a slide deck check was checking
We assumed the risk in building slides from a document was design: uneven spacing, a template applied inconsistently, colours that fight. So the check read the markup. It could see a declared type size, a class name, a template’s font scale, and compared those against a floor. On paper that is a legibility check. In practice it verifies that a stylesheet contains the number we told it to look for.
A declared size and a rendered size are not the same quantity. A container constraint, a scaling transform, a font that failed to load — any of them collapses the glyph while the declaration sits where it was written. Our check read the declaration back to itself and agreed. The four-pixel text was in the picture the whole time; nothing in the pipeline had opened the picture.
The second assumption was quieter. Every slide carried an anchor: a claim, a span ID, a verbatim excerpt. The anchors resolved — each excerpt was found in the source document. We read that as traceability. It was a substring search across a whole file.
Two failures with one shared property
Density and traceability are separate problems that broke the same way: both were measured on a convenient surface rather than the one where the failure lives.
For density the real surface is the raster: an image of the slide at the resolution the room will show it at. What matters there is the pixel height of actual lowercase ink, smaller than the em box holding it by roughly the x-height ratio of the face being shipped. A 24 pt minimum on a slide 540 pt tall is a 48-pixel em box on a 1080-pixel render, and a face putting about half its em into ink leaves around 24 pixels — a ratio of 1:45, not the 1:22.5 the type size suggests. State the floor in the quantity you measure. A ratio survives a change of resolution; a pixel threshold does not, and a type-size floor compared against a measured ink height condemns every slide for nothing.
The thumbnail is the seductive form of the mistake. It is a picture, and genuinely a render. It is just not the render anyone will look at, and every number taken from it is wrong by whatever factor separates it from delivery resolution.
An anchor that points at a document proves nothing
Traceability has the same shape. The convenient surface is the document; the failure lives in the span. If a slide cites one span and the excerpt turns up inside a different paragraph, the words exist and the citation is false — both at once. A whole-file search cannot tell those apart. It returns a hit, the table prints anchored, and the build proceeds.
The hit has to land inside the byte range of the cited span: that is the difference between evidence and a status code.
Drift survives even a correct anchor. A number rounded the wrong way still points at a real passage, in the right span, through a genuine excerpt. The link check passes because the link is real; what broke is the claim, not the pointer. Every proper noun, number, unit and date on a slide has to be checked against the span itself, not against the fact that a span was named.
What follows for anyone generating a slide deck
Two rules, both narrow. Measure on the surface the reader sees — for a deck that means a retained raster at delivery resolution, with the renderer and its version written down, because a measurement whose surface has been discarded cannot be rechecked. And make a citation point at a place rather than a document: an offset inside a stated range.
One consequence gets resisted. When a claim will not fit, splitting it is the only move available. Shrinking the type converts a problem you can see into one you cannot, and that conversion produced our four-pixel text. An overflow you can see is a bug; an overflow you solved by shrinking is a bug you shipped.
The budget has to come from the room, not the deck: a ceiling derived from the longest slide already drafted is exceeded by nothing. And both halves must emit numbers. A slide that passed without a recorded character count, ink height and byte offset was not measured, it was described.
Legibility and traceability give no coverage of each other. A readable slide can misquote its source and an anchored slide can be illegible, so a slide deck build that reports one is silent about the other.
The runnable procedure — the freezing of spans, the derivation of the budget, and the guards that catch these failures — lives in the member library.
How we know
What accessibility guidance says about slide text
The published guidance points at the same surface our check skipped. W3C’s advice on presentations asks for text and important visuals that are big enough to be read, even from the back of the room. That is a requirement about the room. It says nothing about the file.
Microsoft gives a number. Its PowerPoint accessibility guide says to Use a larger font size (18pt or larger), together with sans serif fonts and enough white space. A separate Microsoft page on designing slides for people with dyslexia recommends at least an 18-point font size. Both figures are inputs to a design. Neither tells you what happens after a declared size meets a container that scales it down.
WCAG is more explicit about where the measurement belongs. The Understanding document for contrast says that when large text is evaluated, the font size in points should be obtained from the user agent or calculated from font metrics the way user agents do it. The renderer is the authority, not the stylesheet. The same document asks for a contrast ratio of at least 4.5:1 for normal text and treats the figure as a hard line, so 4.499:1 would not meet the 4.5:1 threshold.
The Understanding document for resizing text adds two points that matter for generated decks. It calls scaling primarily a user agent responsibility, with the author’s job being to avoid blocking it. And it warns that images of text do not scale as well as text, because they pixelate. A slide exported as a picture is an image of text from then on.
Microsoft’s guide also asks authors to make sure that color is not the only means of conveying information. That one is easy to lose in a deck where a red or green cell carries the point of the slide.
How this lines up with what our check missed
Our gate compared declared type sizes against a floor. The guidance above assumes the opposite: size is read from whatever renders the text. The four-pixel body text in our thumbnails is the case those rules are written around. The declaration was fine. What the audience would see was not.
The thumbnail fits the same frame. It was a real render at the wrong resolution, so every height taken from it was off by the scale factor between it and delivery. The rule in this article, measure at delivery resolution and keep the raster with its renderer and version, is what reading size from the user agent looks like when the user agent is a projector in a meeting room.
The anchor failure has no counterpart in accessibility guidance, and that is worth saying plainly. A slide can meet every size and contrast rule and still cite the wrong span. Legibility and traceability give no coverage of each other. The standards only speak to the first.
A slide deck quality check, step by step
- Render every slide at the resolution the room will show it at. Keep the image, and write down the renderer and its version.
- Measure the smallest lowercase ink height on that image. Ignore the declared type size.
- State the floor as a ratio of ink height to slide height, so it survives a change of resolution.
- Check contrast on the rendered colors and treat 4.5:1 for body text as a line, without rounding.
- When text does not fit, split the slide. Never shrink the type to make it fit.
- For each excerpt, record the byte offset and confirm it falls inside the cited span.
- Check every number, unit, date and proper noun against the span itself.
More questions
Is 18 point big enough for slide body text?
Microsoft uses 18 point as a minimum, which makes it a starting figure rather than a pass. What reaches row ten depends on how the slide is scaled and projected. That is why the measurement belongs on the rendered image at delivery resolution.
Will a check that reads the slide markup catch shrunken text?
Not the way it happened to us. A check that reads declared properties sees the declared size. Text that collapses because of a container constraint, a scaling transform or a font that failed to load only shows up when something looks at the render.
Grounded in: our own deck builds behind deck-from-source v1.1, 2026-09-04 — a slide check that inspected thumbnails in which body text stood four pixels high and reported every slide in order, and anchors that resolved against the whole source document instead of the cited span. Verified: slides were re-rendered at delivery resolution and the smallest lowercase ink height measured on the image, and each excerpt was string-matched with its offset compared against the byte range of the span it cited. The runnable procedure lives in the member library.