The Slide Checker That Inspected Thumbnails Where Text Was Four Pixels Tall

AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.

The surprise we ran into during slide deck verification

We built a gate for machine-generated slide decks. Its job was simple on paper: catch any slide that would ship with cut-off text, overflow, or overlapping elements before delivery. We thought the checks would be mechanical and reliable. Then the third checker read the system for logic and found 18 faults. That was the turning point.

What we tried and what actually broke

First attempt: run visual inspection on a thumbnail grid so reviewers can scan dozens of slides fast. It looked beautiful. An independent reviewer gave it top marks for presentation. Everything looked done.

What happened in practice was obvious once you saw it. Body text rendered at 16 pixels in full size shrank to about four pixels in the thumbnail. Cut-off lines and tiny overlaps vanished into noise. The thumbnail could not show the problem that mattered; it hid it.

We had another check that compared text read off the rendered image against a checksum. That seemed clever. In reality it was logically impossible. OCR from an image will vary. A checksum will never tolerate that variation. The check could neither meaningfully pass nor meaningfully fail. It produced noise.

We also discovered the pass receipt was embedded into the deck file after the gate had run. So the file that left our production line was not the file we validated. The gate signed a different artifact than the one we shipped. That was bad.

The third checker cataloged each failure. Eighteen concrete issues. Several were fatal to the gate’s purpose. We stopped the line, fixed them, and shipped version 1.1 that same day.

The fixes that changed everything

We replaced the thumbnail-based visual checks with full-resolution frame checks. We still keep the thumbnail grid for quick human overview, but every automated pass runs on the full-size render so text renders at real pixel heights. Once we made that switch the cut-offs showed up reliably in the automation.

We reworked the text-comparison check. Instead of image-read text versus a checksum we now compare extracted text against the original raw slide text. The comparison uses a similarity floor and a simple presence check for the first and last three words. That combination is forgiving of OCR differences while still catching missing or mangled passages.

We stopped modifying the deck file after validation. The validated build is delivered byte for byte identical to the file we checked. The receipt rides alongside as a sidecar that a third party can re-hash. That restored the chain of custody.

We closed all 18 issues the day the third checker handed them in. And then we watched the gate behave like a gate should.

The rule that came out of this

If a file is changed after the gate runs, the gate never saw the file it claims to have validated. We formalized that as policy and engineering constraints across the production line.

A representative detail (a taste)

One concrete tweak: when a slide’s body text was below the density cap we render a full-resolution image and verify the top and bottom lines’ text tokens are present in the original raw text before allowing it to pass. That single change turned intermittent false negatives into consistent true positives. The full runnable skill lives in our members’ library.

How we know

We have test decks that failed in v1.0 and passed in v1.1 only after the fixes. In one test, a three-line paragraph lost its bottom line in thumbnails but showed full damage at full size; the new check caught it every time — exactly what slide deck verification is supposed to catch. In another, the checksum-based text check returned inconsistent results across runs; replacing it with similarity plus first-and-last presence removed that flakiness. An independent reviewer had praised the first build for form, and the third checker’s logic review produced the exact bug list we then closed. The causal chain is traceable through the ticket history and the validated builds.

Counter-example we learned from

Appearance can deceive. The first version looked polished. It passed human glance review. Yet the system failed at its core mission. That mismatch taught us to separate human overview from machine verification: one shows; the other must prove.

Questions we got

Did the thumbnail view get removed?

No. We kept it for people to scan decks quickly. We stopped using it for any automated decision. Thumbnails are for humans only.

How do you handle OCR errors now?

We don’t rely on exact matches. We use a similarity floor plus simple checks for anchor words at the start and end of passages so small OCR variance doesn’t break validation while major omissions still fail.

Is the delivered file modified with receipts?

Not anymore. The deck file is byte-for-byte the validated build. The receipt is a separate sidecar file a reviewer can re-hash to confirm the artifact.

One-line sources: fixes and observations recorded in our production notes and the v1.1 release log.

What accessibility guidance says about legible slides

There is no single legal font size for a slide, but the standards bodies agree on what “legible” has to cover: size, contrast and text that survives scaling.

Contrast has a number. WCAG 2 success criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text, with a lower bar of 3:1 for large-scale text. The Understanding document defines large-scale text as at least 18 point or 14 point bold, and explains that 4.5:1 compensates for the loss in contrast that results from moderately low visual acuity. The ratios are hard lines, not targets to round toward: 4.499:1 would not meet the 4.5:1 threshold.

Size and clipping are covered by a separate criterion. Under 1.4.4, text should be able to be resized up to 200 percent without loss of content or functionality. The W3C test procedure for that technique spells out what a failure looks like: no parts of the text are clipped, boxes do not overlap, and controls stay attached to their labels. That is close to a word-for-word description of the overflow and overlap problems a slide checker exists to find.

For live presentations, the W3C’s guide on accessible presentations asks speakers to make text and key visuals readable from the back of the room. Microsoft’s own advice for PowerPoint is more concrete. Its video on accessible slide styles recommends choosing templates with sans serif fonts at 18 points or larger, and recommends solid backgrounds with contrasting text. Its longer guide, Make your PowerPoint presentations accessible to people with disabilities, is the place to start if you build decks by hand.

How the guidance lines up with what broke in our gate

Our first gate failed on the exact property these documents care about: real rendered size. Body text that is 16 pixels at full size became about four pixels in a thumbnail. A check that looks at four-pixel text cannot judge clipping or overlap, however sharp the thumbnail grid looks to a person. Running every automated check on full-resolution frames was the fix, and it is also the only resolution at which a size or contrast rule means anything.

The auto-shrink ban follows the same logic. The verification store behind this article records that our gate forbids shrinking text to make it fit; content above the density cap has to split into more slides, and a deck that cannot split within its allowance blocks. Shrinking until the overflow disappears trades one failure (clipped text) for another (text too small to read). The guidance above treats both as failures.

A thumbnail is effectively the opposite of the 200 percent test. WCAG asks whether text still works when it gets bigger; our first gate asked a machine to judge text after making it four times smaller. No rule in the guidance would have passed that setup.

The text-presence check maps onto the “no loss of content” wording. Comparing extracted text with the raw slide text, using a similarity floor plus the first and last three words, is a practical way to prove that nothing was cut off at the edges of a box.

A checklist for slide deck verification

1. Render every slide at its delivery resolution and run all automated checks on those frames. Keep thumbnails for people only.
2. Set a minimum body size for your deck template. Microsoft’s 18-point floor is a sensible starting point; go larger for big rooms.
3. Measure the contrast of every text color against its actual background, including text placed over images. Aim for 4.5:1, or 3:1 for large-scale text.
4. Forbid auto-shrink. Split dense content across slides instead.
5. Check that the first and last words of each text block appear in the render, so clipping at either edge fails loudly.
6. Look for overlapping boxes, not just overflowing ones.
7. Run PowerPoint’s Accessibility Checker as an extra pass, not as the gate.
8. Never modify the file after the gate passes it. Ship receipts as a separate file.

More questions

What is the minimum font size for slides?

WCAG does not set one for slides. Microsoft recommends 18 points or larger, and the W3C asks that text be readable from the back of the room. The right floor depends on the screen and the room, so treat 18 points as a minimum, not a target.

Does larger text change the contrast requirement?

Yes. WCAG lowers the contrast minimum to 3:1 for large-scale text, defined as at least 18 point or 14 point bold. Everything smaller needs 4.5:1.