A cream slide headed 'Everything a designer would add. Already in.' with six feature tiles: charts, tables, diagrams, transitions, every format and your brand.
From the slaide design example deck, rendered with slaide.

Four Accessibility Checks to Run on a Deck

By ·

These four checks cover common ways a deck becomes unreadable to part of the room. This isn’t a compliance post, nobody’s grading your slides against a regulation. The problem is quieter than that: some people in any real audience can’t read what you put in front of them, and you have no way of knowing it happened.

Contrast

WCAG’s contrast minimum is 4.5:1 for normal text and 3:1 for large text. That’s an actual number, not a vibe, and light gray on white fails it. Non-text elements get their own 3:1 rule, which a soft pastel chart can easily miss. WCAG is written for the web, but people use the same ratios for slides.

Checking this costs nothing. Paste your two colors into any free contrast checker and it gives you the ratio directly, no guessing by eye required. Do it for your title text against its background and for your lowest-contrast chart line, because in my experience of how palettes get built, those are the two spots most likely to fail.

Alt text on the one chart that matters

You don’t need alt text on every decorative shape. You need it on the one chart actually carrying your argument, the one where a listener misses the point of the slide entirely if a screen reader skips over it. WCAG’s non-text content rule exists for exactly this: a text alternative standing in for the visual. Writing “chart” as the alt text satisfies a checker and helps nobody. Microsoft says you must add chart alt text manually, and it should briefly describe the chart’s intent and important information.

Good alt text states the conclusion, not the object. “Bar chart” describes what a sighted person already sees and tells a listener nothing. “Revenue grew every quarter except Q3, when it dropped” gives a listener the actual point of the slide, which is what the chart was for in the first place.

Reading order, which is not placement order

This is the one people get wrong even when they try. Reading order isn’t the order you placed the boxes on the slide, it’s a separate list the software keeps internally, and a screen reader or a keyboard-only user moves through your slide in that list’s order, not the order your eye would naturally travel. PowerPoint has a Reading Order pane for exactly this reason. Microsoft says a screen reader reads the elements on a slide in the order they were added, which might be very different from the visual order. Open the pane and look.

Shapes added late are the likely culprit. A chart pasted in after the text is placed can land at the end of the reading order wherever it sits visually. The pane exists to catch that drift, and you will not catch it by eye.

Meaning carried by color alone

If the only signal telling a viewer “this bar is the problem one” is that it’s red while the others are blue, that information is lost for some viewers. Microsoft warns that people who are blind, have low vision, or are colorblind might miss the meaning conveyed by color. The National Eye Institute calls red-green deficiency the most common type. (Red and blue are a poor example of the pair at risk. Red and green is the classic one.) The fix costs nothing: a label, a pattern, a shape difference, anything besides hue doing the actual communicating. Color can still be part of the design. It just can’t be the only thing carrying the fact.

This shows up constantly in status decks: red, yellow and green dots meaning at-risk, watch and on-track, with nothing else distinguishing them. Add the word next to the dot and the slide loses nothing for the part of the room that could already see the color, and gains the part that couldn’t.

What the built-in checker catches, and what it doesn’t

PowerPoint’s Accessibility Checker flags missing alt text, low text contrast, and slides without titles. Run it. What it can’t tell you is whether the alt text you wrote is any good, or whether your reading order matches what a sighted person would assume from looking at the slide. The checker catches the mechanical half of this. The half that actually matters, whether someone going through your deck non-visually gets the same information you meant to give them, still needs a person to check.

I make Slaide, where a deck is a text file. The docs say slaide validate --strict reports a low-contrast warning when text is about the same color as its background. That is a coarse check, not a WCAG ratio test. The docs do not describe screen reader order or alt text, so I make no claim about either. Check those yourself.

Run the four checks on the next deck you build.