Objects and Motion, Then Ship It

Presentation track, branch pr-mechanics (Mechanics) · Node PR1.03 · ~12 focused hours · Mastery gate ≥ 85%

A 42-slide deck left a laptop at 84.20 MB, bounced off a 25 MB attachment ceiling, and went into a shared folder instead. The recipient opened the PDF on a train. On slide 9 a five-band navy ladder had become five bands that no reader could tell apart. The darkness of each band was supposed to say how mature a business line was, and the contrast between adjacent bands runs from 1.40:1 to 1.51:1. None of the four adjacent pairs reaches the 3:1 that a graphical element needs. On slide 14 a 0.25 pt table rule had vanished, because at 300 dpi that weight asks the printer for 1.04 device pixels and a printer gives it one or none.

Nothing about that deck was ugly. Every object was aligned, the type scale was correct, and the colours came from a real palette. Every failure happened at the boundary between the machine it was built on and the machine it was read on. Someone who knew what to look for could have found each one in about ninety seconds.

Objects are cheap to add and expensive to ship. A shape costs two seconds, an icon costs a search, an animation costs one click on a menu, and a photograph costs nothing at all if you don't check its pixels. That same deck carried 486 objects across 42 slides, which is 11.57 objects a slide. It also carried 61 animation effects, and 9 of them survived the review. Each survivor told the audience something the still slide couldn't.

So the hours ahead split into two unequal halves. The first is object craft: the six shapes that carry almost all real work, the selection pane, the traps in a diagram tool that autofits, the table set so it can be read, images at the right pixel count, and icons that mean something. The second is the shipping pass. It's what turns a deck that works on your screen into one that works on a projector in a room 9.1 metres deep, in an inbox with a size limit, in a PDF, on an office laser, and in a screen reader.

One fact joins the two halves, and it's worth carrying through everything below. The accessible slide is almost always the clearer slide. The pass that makes a deck accessible is the same pass that finds the reading order nobody thought about, the contrast nobody measured, and the animation that was hiding a missing argument. On that 42-slide deck, 17 slides had a reading order that differed from the visual order. That's 40.48% of the file, and on every one of those slides a sighted reader's eye also had to guess where to start.

What you'll learn here is mechanical, and you can check it. Whether a five-box process diagram is the right way to explain the process is a question about visual thinking, and it belongs with the diagramming work. Whether slide 9 needed a bar chart instead of a ladder belongs with chart craft. Everything below assumes both of those are settled and asks something narrower. Given that this object belongs on this slide, is it built so it still works when it reaches the reader?

Learning objectives

You can:

1. Build a slide from the six shape types that carry the overwhelming majority of real work, and state for any seventh shape what it adds beyond what those six already do.
2. Manage a crowded slide with the selection pane, using grouping, naming, hiding and z-order to take a 47-object slide to 9 top-level entries without changing what a reader sees.
3. Decide when a diagram tool helps and when it traps you, naming the three failure cases (the autofit that sizes type from the longest node, the layout that asserts a relationship you do not mean, and the block that cannot sit on the grid).
4. Set a table so it can be read, choosing a table over a chart on the three stated grounds, and cutting a full grid of 13 rule lines to the 4 that do work.
5. Size an image correctly, computing effective resolution from pixels and placed width, choosing the export target from the destination, and stating the licence position before the image goes on a slide.
6. Apply the icon consistency rule, diagnosing a mixed set by grid, stroke weight and corner radius, and computing what a 24 px icon's 1.5 px stroke becomes when it is placed at 40 px.
7. Cut animation to what carries meaning, distinguishing the three effects that do work from the ones that only cost time, and defending a build against the all-at-once alternative with a comprehension argument rather than a taste argument.
8. Build a reveal that matches the narration, computing the audience's reading time against the speaker's talking time and showing that the slide never holds information the speaker has not reached.
9. Run the accessibility pass, fixing reading order, writing or waiving alt text on every object, and measuring contrast against the 4.5:1, 3:1 and 3:1 thresholds for body text, large text and graphical objects.
10. Ship the deck, exporting to the right target for each destination, predicting what breaks in a PDF and on a printer, and filling the eight-item checklist so that a deck leaves your machine once rather than three times.

Prerequisites & connections

Builds on. Alignment, distribution, grids, the type scale and colour as a role, all of which the precision-and-type node teaches and none of which is rebuilt here. You should be able to put an object on a 12-column grid, set a four-level type scale, and say why an outer margin obeyed everywhere reads as competence. You also need a master and a set of layouts, because several fixes below are stored in the master and not on the slide. A deck that fights its own master can't be shipped cleanly. From the tool node you need the four views, the selection habits and file naming. The ship pass assumes you can already save, version and reopen a file without losing it.

Feeds forward. The chart-craft branch takes the object mechanics for granted and argues about form, colour and the action title. The diagramming node takes the shape vocabulary here and asks what a diagram should assert. The archetype nodes assume that a deck you hand over is already accessible, already the right size and already exported correctly, because a board pack that arrives as a 26.72 MB attachment is not a board pack. The capstone runs the whole sequence, and the ship checklist below is the last gate it applies before a submission counts.

Four neighbours own material that touches this one, and the boundaries are deliberate. PR3.01 owns diagram construction as visual thinking: which relationships a picture can assert, the concept, process, flow, framework and matrix forms, and the Gestalt grouping that makes a diagram legible. What's owned here is the mechanics of the objects a diagram is made from. PR1.02 owns alignment, distribution, grids and typography, so the geometry below is applied here and taught there. PR0.02 owns the file as a file: naming, versioning, autosave, recovery, opening someone else's deck and the difference between a theme and a template. What's owned here is the export pass, and it asks a different question, namely what happens to this file's contents at the destination. PR2.02 owns colour and decluttering as data-visualisation craft, so the contrast arithmetic below is treated as an accessibility threshold and not as a palette design method.

Core teaching content

9. Building a reveal that helps rather than delays

A build is the one animation that pays for itself, and the payment is computed from two rates. An audience reads to itself at roughly 250 words a minute, and a speaker delivers at roughly 130. Both are model assumptions and not laws, but they're stable enough to plan with.

Take a five-step process slide whose boxes carry 9, 7, 11, 8 and 6 words, which is 41 words, and whose narration is 254 words. The narration takes 254 / 130 × 60 = 117.23 seconds. The boxes take 41 / 250 × 60 = 9.84 seconds to read. Put everything on screen at once and the audience finishes the slide in under ten seconds. Then they stare at a static slide for 107.39 seconds, which is 91.61% of the time it's up. The desynchronisation is worse than the boredom. Step 1's narration alone runs 20.31 seconds, so the audience has read step 5 roughly 10.47 seconds before the speaker has finished step 1. The question that arrives at the end of step 1 will be about step 5.

Now build it. Five entrances at 0.5 seconds each cost 2.5 seconds, which is 2.13% of the narration. In exchange, the slide never holds a step the speaker hasn't reached. The cost is real and small, and it keeps the audience's attention and the speaker's sentence in the same place.

Three rules keep a build straight. Reveal by idea, so a step's box, icon and label appear together on one click. Never build a slide that will mostly be read, because a reader clicking through a build is waiting for information they could have taken in at a glance. And keep the still version correct. The exported PDF shows the final state, and that state has to make sense with nothing hidden.

The counter-case is worth stating plainly. A build that hides a conclusion the audience has already worked out is a delay dressed as suspense, and audiences resent it. Build to keep pace with the speaker. Keeping secrets is a different thing.

12. Add-ins, and the trust question

An add-in is third-party code running inside your presentation tool with access to your file. Some are excellent. What you need to settle is what you're agreeing to when you use one.

Three questions settle it. Where does the data go? A charting add-in that renders your figures on its own servers has taken your numbers off your machine. For a deck built from unpublished results, that's a disclosure question. Preference has nothing to do with it. What does it leave behind? On the audited deck, a charting add-in had rendered 11 charts as pictures at 3.10 MB each, which is 34.10 MB, or 46.52% of all the image bytes in the file and 40.50% of the whole 84.20 MB. Those pictures carried 0 editable series between them. Nobody could correct the numbers, the accessibility pass had only the picture to write alt text from, and the only route to a fix was to rebuild each chart. And what happens on the recipient's machine? An add-in's output must stand alone, because the person who opens your file won't have the add-in. Content that renders only when the add-in is installed doesn't exist for them.

The working position is straightforward. Add-ins that produce native objects, meaning real charts, real shapes and real text, are safe to use and leave nothing behind. Add-ins that produce pictures are acceptable for a final artefact and dangerous for anything that will be revised. Add-ins that need your data to leave the building need a decision from someone entitled to make it.

Verify (checked 2026-09-08): the administrative controls for add-ins, the store's review process and the distinction between web add-ins and older COM add-ins all vary by platform and by tenant policy. Check your organisation's position before installing anything into a tool that holds unpublished numbers.

The AI-augmented presenter

{
  "skill": "Running the shipping pass on a finished deck: finding reading-order defects, missing alt text, contrast failures and export risks before the file leaves your machine",
  "use": "After you have run the eight-item checklist yourself and recorded what you found, describe each problem slide to an assistant in structured text (object list in pane order, the visual layout, the hex colours in use, the placed size and pixel width of each image) and ask it to predict what will fail at a named destination. Use it to widen the search, never to replace the check: the assistant cannot see your file and will accept whatever you tell it about the slide.",
  "tools": ["Chat assistants (Claude, ChatGPT, Gemini)", "The presentation tool's own accessibility checker", "A contrast-ratio calculator that implements the WCAG relative-luminance formula", "A spreadsheet or Python for the pixel and point arithmetic"],
  "prompt": "Here is one slide described in full. Objects in selection-pane order, top to bottom: <LIST>. Visual layout, left to right and top to bottom: <LAYOUT>. Colour pairs in use as hex, foreground on background: <PAIRS>. Images: <PIXEL WIDTH> px placed at <INCHES> in. Rule weights in points: <WEIGHTS>. Destination: <PDF for screen reading | office laser at 300 dpi | projection on a 3.6 m screen viewed from 9.1 m>. Do four things. 1) State the order a screen reader will announce these objects and say where it differs from the visual order. 2) For each colour pair, state whether it can meet 4.5:1 for body text and 3:1 for graphical objects, and say which side you would change. 3) For each image, compute effective resolution and say whether it clears the destination's target. 4) Name what will break at that destination that I have not asked about. Do not rewrite the slide.",
  "verify": "Recompute every ratio and every resolution yourself before you act on it: contrast from the relative-luminance formula on the actual hex values sampled from the file, effective resolution as pixel width divided by placed width, and rule weights in device pixels as points divided by 72 times the printer's dpi. An assistant that reports a contrast ratio has computed it from the hex you typed, so a mistyped hex produces a confident wrong answer. Then run the tool's own accessibility checker and export the file, because the only proof that a gradient survives is the exported gradient, and the only proof that a hairline prints is the printed page. Any claim about a feature's availability in a specific release is a claim to check against the vendor's current documentation with the date recorded.",
  "diy": "You must be able to run all eight checks by hand on a deck with no assistant available, because the pass happens at the end of a build under time pressure and the description step alone costs more than the check for most slides. The gated skills are the three pieces of arithmetic: contrast from hex, effective resolution from pixels and placed width, and rule weight in device pixels at a stated dpi. Each takes ten seconds, each has one right answer, and each is the difference between a deck that arrives and a deck that arrives broken.",
  "market": "US"
}

Common mistakes & how experts think differently

1. Judging contrast with your eyes. A screen at full brightness in a lit room flatters everything, and two colours that look clearly different can sit at 1.40:1. The five-band ladder below fails on all four adjacent pairs and looks fine to the person who built it. Experts treat contrast as arithmetic with a published threshold. They sample the hex values from the file itself and not from the palette document, and they check the pair that's easiest to get wrong: a light tint carrying white text.

1. Adding an animation because the slide feels static. The feeling is real and the diagnosis is wrong. A slide that feels static usually has nothing to say, and motion won't give it something. The expert's test is to state what the audience learns from the movement. If the sentence that comes out is about the content, keep the effect. If it's about the slide, what the slide needs is an argument.

1. Letting the diagram tool choose the type size. Autofit shrinks every node to fit the longest one, and it doesn't ask, so nobody decides. Seven nodes at 10 pt on a 3.6 m screen are legible to 5.25 m in a room 9.1 m deep. Experts set a floor first, usually 18 pt for a presented deck. Any autofit below that floor tells them to cut words.

1. Grouping objects because they are near each other. A group that does not correspond to a thing makes every later edit harder, because the group has to be entered, changed and left. Experts group by meaning and name the group for what it is. Their pane reads like the document's table of contents. Yours shouldn't read like a list of accidents.

1. Writing alt text that describes the object. "Chart showing revenue by service line" is what a sighted reader already knows before they read anything, and it gives a listener nothing. The message is the alt text, and you have usually written it already in the title. If you can't write the alt text, the exhibit has no message. That's a finding about the slide. Accessibility is just where it showed up.

1. Compressing images at the end instead of choosing a target at the start. Recompressing at the end works, and it costs a rebuild when a print destination appears late. The expert asks where the deck is going before placing the first image. They keep the source files and place each image at a size its pixels support, so nothing gets stretched now and repaired later.

1. Repairing reading order by moving objects on the slide. The pane's order is creation order, and dragging an object on the canvas does not change it. Experts fix the pane, then tab through the slide to prove it. Tabbing is the only check that tests what the reader will actually get.

1. Using the full grid because the table drew one. Twenty-eight cells arrive with 13 rule lines and no decision. Nine of them can go, which is 69.23% of the ruling, and what's left is a table where the eye follows the numbers. Experts set the ruling to what separates groups, then right-align the numerals and let alignment do the work the lines were doing badly.

1. Trusting the machine that built the file. Your fonts are installed, your links resolve, your add-in is present, and none of that is true at the destination. Experts open the exported copy, on a different machine when they can. For them the first open of an exported file is part of the build. It isn't a formality.

1. Treating the still version of a build as an afterthought. Every animated deck becomes a static one the moment it is exported, printed or forwarded, and a build whose final state is an unreadable pile of overlapping objects has just become the version that circulates. The expert designs the still state first and adds the reveal to it. As a bonus, the slide still works if the clicker fails.

Worked examples

Every figure below comes from the same computation, and the Verify block at the end restates each one at full precision. All companies are synthetic composites.

Worked example 1: One process, three animations (India, ₹)

The setting. Kalpavriksha Finance (synthetic) is explaining its loan origination flow to a bank's credit committee. One slide carries five steps, each a rounded rectangle with an icon, a heading and a numeral. The box text runs 9, 7, 11, 8 and 6 words, which is 41 words in total. The speaker's narration for the slide runs 44, 51, 62, 58 and 39 words per step, which is 254 words. Plan on an audience reading silently at 250 words a minute and a speaker delivering at 130. Entrance animations are set to 0.5 seconds; a Morph transition is set to 0.75 seconds. The slide was assembled by pasting the five step groups in the order 3, 1, 5, 2, 4.

Solution. Step 1, price the narration. The slide is on screen for 254 / 130 × 60 = 117.230769 seconds, which is the fixed quantity every option is measured against. Per step, the narration runs 20.307692, 23.538462, 28.615385, 26.769231 and 18.000000 seconds, so step 1 ends at 20.307692 s and the slide ends at 117.230769 s.

Step 2, the wrong version, everything at once. All five boxes are on screen from the first second. Watch what happens to the room. The audience reads 41 words in 41 / 250 × 60 = 9.840000 seconds. From that point the slide holds nothing new for 117.230769 − 9.840000 = 107.390769 seconds, which is 91.606299% of its life. The sharper cost is desynchronisation. The audience has finished step 5 at 9.84 s, and the speaker finishes step 1 at 20.31 s. So the room is 10.467692 seconds ahead of the speaker before the first step is done, and the first question is about step 5.

Step 3, the corrected version, one click per step. Five entrances at 0.5 s cost 2.500000 seconds, which is 2.132546% of the narration, and take the slide's running time to 119.730769 seconds. The slide never contains a step the speaker has not reached, so the audience's attention and the sentence being spoken are on the same object throughout. Each click reveals a step's box, icon, heading and numeral together, as one idea.

Step 4, the third option, Morph. Five slides, one per state, with four transitions at 0.75 s, is 3.000000 seconds of transition, which is 2.559055% of the narration and takes the running time to 120.230769 seconds. The bookkeeping is 5 objects matched per transition across 4 transitions, which is 20 name matches to keep correct. Time isn't the objection. Nothing in a five-step list actually moves, so the movement would assert a motion the content doesn't have.

Step 5, the accessibility repair the build made necessary. The paste order 3, 1, 5, 2, 4 is the order a screen reader announces, and it takes 4 adjacent swaps to reach 1, 2, 3, 4, 5. All 5 steps are announced in a position that does not match the visual layout. Animation order and reading order are separate lists, so setting a click sequence doesn't repair the pane. Building a reveal introduces this defect more often than any other.

The two versions, side by side.

Read it. The 2.13% of running time that the build costs is the entire price, and what it buys is synchronisation. The arithmetic doesn't say a build is always right, though. On a slide that will be read, the same build makes a reader click five times for information they could have taken in at a glance, and there the all-at-once version is correct. What decides it is whether a speaker is present.

The checklist you apply. Each click corresponds to one idea. Total animation time stays under about 3% of the narration. The final state stands alone in an export. The pane order matches the visual order after the build is set. And you can say, in one sentence about the content, what the audience learns from the movement.

Worked example 2: One slide, two destinations (US, $)

The setting. Cascade Health (synthetic) has one slide carrying four things. A full-bleed photograph 1600 by 1067 px on a 13.333 in by 7.5 in widescreen slide. A five-band maturity ladder whose bands are cut from a gradient running #1F3B57 to #7FA8C9. White labels on band 1 and band 5. And a small table ruled at 0.25 pt. Two destinations: a PDF that will be read on screen, and an office laser at 300 dpi, three slides to a page.

Solution. Step 1, the photograph. Effective resolution is 1600 / 13.333333 = 120.000000 ppi. Against the four standard targets the picture is comfortable only for projection.

You don't need a new photograph. You need a new placement: 1600 px holds 150 ppi up to 10.666667 in and 330 ppi up to 4.848485 in, so the photograph moves from full-bleed to a 10.5 in band with the ladder beside it. Cropping to 16:9 first keeps 900 px of the 1067 px height and discards 167 px, and committing the crop stops those pixels from travelling inside the file.

Step 2, the ladder, which is where the slide actually fails. Five bands cut evenly from the ramp give #1F3B57, #375674, #4F7290, #678DAC and #7FA8C9. Compute relative luminance and the contrast between adjacent pairs.

Zero of the four adjacent pairs reaches the 3:1 that a graphical object needs. End to end, band 1 against band 5 is 4.582487:1. That's how the ladder convinces as a whole and still fails the moment a reader must tell band 3 from band 4. The white label on band 1 measures 11.529143:1 and is fine. The same label on band 5 measures 2.515914:1 and misses the 4.5:1 body threshold by a factor of 1.788614.

Step 3, the corrected ladder. Lightness alone can't separate five categories at 3:1 on one ramp, so you change the encoding and leave the shades alone. Two levels is the most this ramp will carry, because adjacent ratios multiply: three levels need two gaps of 3:1, or 9:1 of range, against a ramp that measures 4.582487 to one end to end. Cut to its two ends, the ladder clears the threshold, and every finer distinction is carried by position and an explicit label, with a single accent fill marking the one band the title is about. Even a ramp running white to black stops at three levels, since it holds 21:1 and a fourth level would need 27:1 of range. The white labels move to the dark end, or become the dark navy on a pale fill, where #1F3B57 on a #EDF1F5 panel measures 10.157470 to one.

Step 4, the hairline. A 0.25 pt rule is 0.088194 mm wide and resolves as follows: 0.520833 device px at 150 dpi, 1.041667 at 300, 2.083333 at 600 and 4.166667 at 1200. At the office laser's 300 dpi that is one device pixel, which prints as a grey suggestion or not at all. The weight that first reaches one device pixel at 300 dpi is 0.240000 pt and at 150 dpi is 0.480000 pt, so the floor for a rule that must survive an office printer is 0.75 pt, which is 3.125000 device px at 300 dpi.

Step 5, the handout. Three slides to a page prints each slide 3.10 in wide against 13.333333 in, a scale of 0.232500. Type set at 18 pt on the slide prints at 4.185000 pt, and to print at 8 pt you would need 34.408602 pt on the slide. Two-up at 5.50 in gives 7.425000 pt from the same 18 pt. The handout is a separate artefact. No print setting will fix it.

Read it. Three of the four failures on this slide were invisible on the machine that built it, and all four were computable in under two minutes. The ladder matters most. The photograph and the hairline degrade where you can see it, but a failed colour encoding gives no sign. The reader sees five bands, believes they carry five levels, and can't tell which band they're looking at. What the arithmetic won't tell you is whether the ladder should have existed. That's a chart-craft question about whether lightness was ever the right encoding for maturity.

The checklist you apply. Effective resolution against the destination's target. Every adjacent pair in a colour encoding measured against 3:1. Every text-on-fill pair measured against 4.5:1, or 3:1 if the type is 18 pt or 14 pt bold. Every rule weight converted to device pixels at the destination's dpi. And the exported file opened and read, because the export is where flattening happens.

Worked example 3: The table that beats the chart (India, ₹ crore)

The setting. Meridian Diagnostics (synthetic) reports five service lines. FY25 and FY26 revenue, in ₹ crore: pathology 412 and 448, radiology 286 and 372, cardiology 154 and 168, home collection 97 and 131, corporate wellness 121 and 106. The audience is a board whose minutes will record the figures. The message is that radiology delivered most of the year's growth while corporate wellness shrank.

Solution. Step 1, the arithmetic, and the two checks it has to pass. Totals are 1,070.000000 and 1,225.000000, a change of 155.000000 and a growth rate of 14.485981%. Shares of FY26 revenue sum to 100.000000% and shares of the growth sum to 100.000000%, and both checks must hold before anything is drawn.

Step 2, the wrong version. A pie of the FY26 mix with five slices and a legend. It shows one period, so it can't express change at all, and the message is entirely about change. It can't represent the one negative in the data either, since a pie has no way to draw −9.68% of growth. And four of the five slices sit between 8.65% and 30.37%, which is the range in which angle comparison is least reliable. The pie answers a question nobody asked: what share is each line now?

Step 3, the chart that would work, and why it is still not what this audience needs. The message is a change across categories between two periods with one negative. The grammar points at a sorted bar of the change, running from +86 down to −15, with the negative bar drawn below the baseline and the title stating the claim. That's the right chart. But the board's minutes will record that radiology was ₹372 crore, and a reader recovering that from a bar is estimating. On an axis running 0 to 500 with gridlines every 100, interpolation to about one fifth of a gap gives ±20, which is 4.000000% of the axis. So 372 is read as somewhere in 352 to 392, an error of up to 5.376344% of the value.

Step 4, the corrected version. A table, set for reading, with the growth column carrying the message and the two extreme rows emphasised. The setting arithmetic: 5 service lines plus a total plus a header is 7 rows, and 4 columns, so 28 cells. A full grid draws 8 horizontal and 5 vertical rules, which is 13. The set version keeps 4: above the header, below the header, above the total, at the foot. Nine rules go, which is 69.230769% of the ruling. Numerals right-aligned, one decimal, unit in the header once, a sign on every change, rows sorted by share of growth so the message is the reading order, and one emphasis on the radiology row.

Step 5, what goes where. The table is the slide, because the audience is doing lookups on ten numbers that will be quoted. The sorted change bar goes in the appendix for the question that starts "which line drove it", where its shape answers faster than the table does.

Read it. The table wins here on three grounds that all have to hold. The numbers will be quoted, the reader is doing lookups, and there are only ten of them. Change any one of those, and the bar wins. With 400 numbers, or with an audience deciding whether a trend has turned, a table is a wall and the chart is the only readable form. So tables don't beat charts in general. Precision beats shape when the reader needs a value.

The checklist you apply. The shares sum to 100%. The form matches the message type, and you can name the rejected alternative and the rule that rejected it. The ruling is cut to what separates groups. Numerals are right-aligned with one consistent decimal. The sort order is an argument you'd defend. Only one row or cell carries the emphasis.

Worked example 4: Forty-two slides, one shipping pass (US, $)

The setting. Cascade Health's quarterly operations deck runs 42 slides and 486 objects. Of those objects, 173 carry content and the rest are decorative; 19 currently have alt text. Reading order differs from visual order on 17 slides. The file carries 61 animation effects and 38 embedded images occupying 73.30 MB of an 84.20 MB file, of which 34.10 MB is 11 charts that a charting add-in rendered as pictures at 3.10 MB each. There are 23 rules below 0.75 pt. Subset font embedding costs 1.10 MB; full embedding costs 4.80 MB. The recipient's mail system rejects attachments over 25 MB.

Solution. Step 1, score the checklist before touching anything. Eight checks, and the deck passes none of them.

Step 2, accessibility, which is the largest single cost and the most predictable. Alt-text coverage is 19 / 173 = 10.982659%. The pass writes 154 entries and flags 313 objects as decorative. At about 25 seconds an entry and 3 seconds a flag, that is 64.166667 minutes plus 15.650000 minutes, a total of 79.816667 minutes, or 1.330278 hours, which is 1.900397 minutes a slide. Reading order is wrong on 17 slides, which is 40.476190% of the deck, and each is repaired in the pane rather than on the canvas.

Step 3, animation. Sixty-one effects against 42 slides is 1.452381 effects a slide. In this deck, animation was a habit. Nobody decided on it. Applying the test one effect at a time leaves 9, a deletion of 52 effects, or 85.245902%. After the pass, 3 slides carry any animation.

Step 4, size, which is the constraint that actually blocked the send. Images at 73.30 MB average 1.928947 MB each. Recompressing to the 150 ppi target takes them to 11.02 MB, an average of 0.290000 MB, a factor of 6.651543 with no visible change on screen. Everything that is not an image is 84.20 − 73.30 = 10.900000 MB, so the file reaches 11.02 + 10.90 = 21.920000 MB. Subset font embedding adds 1.10 MB for 23.020000 MB and 1.980000 MB of headroom under the ceiling. Full embedding would add 4.80 MB for 26.720000 MB, overshooting by 1.720000 MB. The whole pass reduces the file by 72.660333%.

Step 5, the add-in's residue. The 11 pictures account for 34.100000 MB, which is 46.521146% of all image bytes and 40.498812% of the original file, and they carry 0 editable series between them. They cannot be corrected, cannot be recoloured to the palette, and give the accessibility pass nothing to write alt text from beyond what a human types. Rebuilding them as native charts is the only repair, and it's also the largest item of work left after the pass.

The before and after.

Read it. The pass took under two hours, and the deck had been circulated four times before it. What the numbers don't show is the ordering effect. Fixing size first would have compressed images inside charts that were about to be rebuilt. Fixing fonts first would have made every later measurement wrong. The checklist is ordered so that the cheap irreversible things happen after the expensive reversible ones, and you open the file from the export at the end.

The checklist you apply. Score all eight before starting, so you know what you are fixing. Do accessibility before compression, because compression changes objects. Do fonts last, because embedding is the only step that adds bytes. Rebuild add-in pictures instead of compressing them. And open the exported copy on a machine that did not build it.

Worked example 5: The diagram that shrank itself (US, $)

The setting. Brightline Logistics (synthetic) has a seven-node process diagram built with the tool's own gallery. The nodes carry 4, 6, 9, 5, 12, 7 and 6 words, which is 49 words; the longest is 12 and the median is 6. Autofit has set every node to 10 pt. The deck will be shown on a 3.6 m screen in a room whose back row is 9.1 m from the screen. Use the signage rule of thumb that legible cap height is about the viewing distance divided by 200, and take cap height as about 0.70 of the point size.

Solution. Step 1, the room's floor. A 13.333333 in slide projected 3.6 m wide is scaled by 10.629921 times. The back row at 910 cm needs a cap height of 910 / 200 = 4.550000 cm on the screen. Working back through the scale gives a minimum of 17.333333 pt on the slide, so 18 pt is the floor for this room.

Step 2, what 10 pt actually delivers. At 10 pt the cap height on that screen is 2.625000 cm, which is legible to 5.250000 m and no further. The type is short of the requirement by a factor of 1.733333. At 18 pt the cap height is 4.725000 cm, legible to 9.450000 m, which covers the room with a little to spare. Everybody behind the halfway point of the room is trying to read a diagram they can't read.

Step 3, why it happened. Autofit sizes the type to the longest node and applies that size to all seven. Five of the seven nodes carry 7 words or fewer and would have held 18 pt without trouble. One node of 12 words has cost the other six their legibility. Nobody decided it, and that's what makes it a trap.

Step 4, the corrected version. Cut the longest node from 12 words to 6, which is 6 words removed, and the whole diagram holds 18 pt. You aren't compromising here. A 12-word node in a process diagram is a sentence pretending to be a step, and the words that come out belong in the narration or the speaker notes. If the content really won't compress, the diagram is the wrong form, and the content is a table or a sequence of slides.

Step 5, the two other traps, checked on the same diagram. The gallery layout in use is a cycle, and the process is not a cycle, since step 7 does not feed step 1. A layout chosen for its shape has made a false assertion, and a linear chevron sequence corrects it. The diagram block also cannot sit on the slide's grid, so its left edge misses the content column by a few millimetres. Converting to shapes repairs that, once the wording is settled and never before.

Read it. The legibility rule of thumb is only a rule of thumb. It depends on the typeface's cap-height ratio, on contrast, on projector brightness and on eyesight, so treat it as a floor to design against. It isn't a law. What it's good for is turning an argument about taste into an arithmetic question with an answer. And 10 pt on a 3.6 m screen fails that arithmetic by so wide a margin that no assumption in the model could rescue it.

The checklist you apply. Everything on the slide was sized by a decision, and nothing by autofit. The deepest row in the room is known, and so is the point size it requires. The gallery layout asserts a relationship the content actually has. The diagram is on the grid. And the longest node can be cut to the median without losing the step.

Worked example 6: Forty-seven objects and fourteen icons (India, ₹)

The setting. Aarohan Microfinance (synthetic) has a slide showing its five-stage borrower journey. The slide holds 47 objects: five stages, each built from a rounded rectangle, an icon, a heading, a body line and a numeral, which is 25; a title, a subtitle, a source line and a background panel, which is 4; and 18 loose rules and spacers left behind by earlier edits. The icon set has 14 icons, of which 9 were drawn on a 24 px grid with a 1.5 px stroke and a 2 px corner radius, and 5 were drawn natively at 40 px with a 1.5 px stroke. All icons are placed at 40 px.

Solution. Step 1, the pane before. Forty-seven entries with names the product invented. You can't select anything on the slide reliably. Moving a stage means selecting five objects without missing one. And a transparent rectangle sitting above the content is catching clicks that the mouse can't diagnose.

Step 2, group by meaning, then name, then use the hide test. Each stage becomes one group of 5 objects, so 25 objects hide behind 5 entries, and grouping on its own takes the pane to 5 + 4 + 18 = 27 entries. The 18 loose rules and spacers are then hidden one at a time, and the slide misses none of them, so they are deleted. That leaves 5 groups and the 4 objects that belong to no stage, which is 9 top-level entries against 47, a reduction of 80.851064%. Names replace the invented ones, so the pane now reads "Stage 3 card", "Source line" and "Background panel", and nothing a reader sees has changed.

Step 3, the icon arithmetic, which explains why the slide looked wrong in a way nobody could name. An icon drawn on a 24 px grid and placed at 40 px is scaled by 40 / 24, so its 1.5 px stroke arrives as 2.500000 px against 1.500000 px for a natively drawn icon. The mismatch is 1.666667 times, and the eye reads it as two weights of icon. The same scaling hits the corner radius, so a 2 px radius arrives at 3.333333 px and the small-grid icons also read as rounder. To match at 40 px, an icon on the 24 px grid must be drawn with a 0.900000 px stroke.

Step 4, the corrected set. Nine of the 14 icons need a redraw, which is 64.285714% of the set, and the practical repair is to take all 14 from one family on one grid, instead of rescaling nine of them. One grid, one stroke weight, one corner radius, one visual weight, one metaphor family. Colour follows: the set is set in one neutral, with the accent reserved for the single stage the title is about.

Step 5, what the grouping buys next. With five named groups, the reading-order fix is five drags instead of forty-seven and a build is five clicks instead of twenty-five. A Morph to the next slide has 5 objects to match instead of 47. Grouping is more than tidying. It makes every later operation on the slide cheap.

Read it. The stroke mismatch is the kind of defect that gets described as "these icons look a bit off". Then someone changes icons until the complaint stops, which can take an hour. Two divisions find it in ten seconds. What the arithmetic cannot tell you is whether the icons should be there at all: an icon that appears once and means nothing is decoration, and deleting all 14 is a legitimate outcome of this check.

The checklist you apply. Every group corresponds to a thing. Every top-level entry is named for what it is, and every loose object has been hidden once to prove that the slide misses it. All icons are drawn on one grid, and the placed size matches the drawn size. Compute the effective stroke for any icon whose placed size differs from its grid. And ask, once, whether each icon is a signal that repeats or a picture that decorates.

Verify

Every figure printed above, at full precision, in the order it appears.

Meridian: totals 1070.000000 and 1225.000000; change 155.000000; growth 14.485981%. Segment changes 36.0, 86.0, 14.0, 34.0, −15.0; growth rates 8.737864%, 30.069930%, 9.090909%, 35.051546%, −12.396694%; FY26 shares 36.571429, 30.367347, 13.714286, 10.693878, 8.653061, summing to 100.000000; shares of growth 23.225806, 55.483871, 9.032258, 21.935484, −9.677419, summing to 100.000000. Table geometry: 7 rows, 4 columns, 28 cells, 13 full-grid rules, 4 kept, 9 removed, 69.230769%. Bar-read model: axis 500.000000, gridline 100.000000, band ±20.000000 = 4.000000% of the axis, range 352.000000 to 392.000000, worst-case error 5.376344%.

Kalpavriksha: box words 41; narration 254 words; narration time 117.230769 s; per-step 20.307692, 23.538462, 28.615385, 26.769231, 18.000000 s, cumulating to 20.307692, 43.846154, 72.461538, 99.230769, 117.230769. Silent read 9.840000 s; static period 107.390769 s = 91.606299%; audience ahead at the end of step 1 by 10.467692 s. Build overhead 2.500000 s = 2.132546%, running time 119.730769 s. Morph overhead 3.000000 s = 2.559055%, running time 120.230769 s, 4 transitions, 20 object matches. Paste order [3, 1, 5, 2, 4], 4 adjacent swaps, 5 of 5 announced out of place.

Legibility: slide width 13.333333 in; screen 3.600000 m; scale 10.629921; back row 9.100000 m; cap height needed 4.550000 cm; minimum 17.333333 pt, rounded to 18 pt. At 10 pt, cap 2.625000 cm, legible to 5.250000 m, shortfall 1.733333. At 18 pt, cap 4.725000 cm, legible to 9.450000 m. Diagram: 7 nodes, 49 words, longest 12, median 6, 5 of 7 at or below 7 words, autofit 10.000000 pt, 6 words to cut.

Objects and icons: 47 entries to 27 on grouping alone and to 9 once the 18 dead objects go, a reduction of 80.851064%; 25 objects inside five groups; 4 deliberately ungrouped; 18 deleted. Icons 14, of which 9 on a 24 px grid and 5 at 40 px; effective stroke 2.500000 px against 1.500000 px, ratio 1.666667; matching stroke on the 24 px grid 0.900000 px; corner radius 2 px becomes 3.333333 px; 64.285714% of the set needs a redraw. Shape census: 168, 92, 74, 61, 31, 22 for the six types, 448 of 486 objects, 92.181070%, leaving 38 objects at 7.818930%.

Colour: bands #1F3B57, #375674, #4F7290, #678DAC, #7FA8C9; relative luminances 0.041074, 0.087288, 0.157105, 0.249119, 0.367343; adjacent contrasts 1.507436, 1.508550, 1.444285, 1.395243, none at or above 3.0; end to end 4.582487; white on band 1 11.529143, on band 5 2.515914, shortfall factor 1.788614; navy #1F3B57 on the pale panel #EDF1F5 10.157470. Levels a ramp carries at 3:1: 2 on this ramp, which measures 4.582487 end to end against the 9.000000 two gaps would need, and 3 on a white-to-black ramp, which measures 21.000000 end to end against 27.000000 for four levels. Thresholds 4.500000, 3.000000 and 3.000000.

Images: 1600 / 13.333333 = 120.000000 ppi; pixels needed 1280.000000, 2000.000000, 2933.333333, 4400.000000 at 96, 150, 220 and 330 ppi; supplied 125.000000%, 80.000000%, 54.545455%, 36.363636%; widest placement 10.666667 in at 150 ppi and 4.848485 in at 330 ppi; 16:9 crop keeps 900 px and discards 167 px.

Rules: 0.25 pt = 0.088194 mm = 0.520833, 1.041667, 2.083333, 4.166667 device px at 150, 300, 600 and 1200 dpi; 0.75 pt = 3.125000 device px at 300 dpi; one device pixel at 300 dpi first at 0.240000 pt and at 150 dpi first at 0.480000 pt.

Cascade Health: 42 slides, 486 objects, 11.571429 a slide; 173 content objects, 19 with alt text = 10.982659%, 154 entries to write, 313 decorative; 64.166667 + 15.650000 = 79.816667 minutes = 1.330278 h = 1.900397 minutes a slide. Reading order wrong on 17 slides = 40.476190%. Animation 61 to 9, deleted 52 = 85.245902%, 1.452381 effects a slide before, 3 slides after. Size 84.200000 MB, images 73.300000 MB averaging 1.928947 MB, non-image 10.900000 MB, images after 11.020000 MB averaging 0.290000 MB, ratio 6.651543, subtotal 21.920000 MB, subset embedding 23.020000 MB with 1.980000 MB of headroom, full embedding 26.720000 MB overshooting by 1.720000 MB, total reduction 72.660333%. Add-in pictures 11 × 3.100000 = 34.100000 MB = 46.521146% of image bytes and 40.498812% of the file, carrying 0 editable series. Handout pages 21, 14, 7 at two, three and six up; three-up scale 0.232500, 18 pt prints at 4.185000 pt, 34.408602 pt needed to print 8 pt; two-up 18 pt prints at 7.425000 pt.

Practice set

Work each one before you read the solution. You'll want a calculator. Numeric answers within ±2% of the stated figure count as correct unless the problem names a tighter band, and the contrast problems are exact because the formula is exact. The markets alternate deliberately, so the arithmetic is practised in both currencies and both paper sizes.

P1 (guided). Read the pane (India). A slide for Aarohan Microfinance holds 33 objects: four stages of six objects each, plus a title, a subtitle, a source line and six rules and spacers. Group by meaning, state the number of top-level entries afterwards, and give the reduction as a percentage. Then say which objects you would leave ungrouped and why.

Solution. Four stage groups hide 24 objects behind 4 entries. The title, the subtitle, the source line and the six rules and spacers are each still an entry of their own, so the pane shows 4 + 3 + 6 = 13, down from 33, a reduction of (33 − 13)/33 = 60.606061%. Every one of those six is doing a job a reader can see. So you keep them, ungrouped. They also stay out of the stage groups, because folding them in would move them whenever that stage moved. Proximity doesn't make a group. The test is whether the objects are one thing that moves, hides and means together. Had any of the six turned out to be an invisible spacer that nothing on the slide missed, the hide test would have taken the pane to 7.

P2 (guided). Price a build (US). A slide has four content blocks and a narration of 186 words. The speaker delivers at 130 words a minute and entrances are set to 0.5 seconds. Compute the narration time, the animation overhead, and the overhead as a share of the narration. Then say what would make you drop the build.

Solution. Narration runs 186/130 × 60 = 85.846154 seconds. Four entrances at 0.5 s cost 4 × 0.5 = 2.000000 seconds, which is 2.000000/85.846154 = 2.329749% of the narration. The overhead is trivial, so cost is never the argument against a build. Drop it when the deck will be read, because a reader forced to click four times for four blocks is being delayed. Drop it too when the four blocks aren't sequential, because a build asserts an order and the content has none.

P3 (guided). Fix the reading order (India). Four stage groups were pasted in the order 2, 4, 1, 3. State the order a screen reader announces, count the adjacent swaps needed to reach the visual order, and name the check that proves the fix.

Solution. The screen reader announces stage 2, then 4, then 1, then 3, because the pane's order is creation order and assistive technology reads the pane. Counting pairs that are out of order gives 3 inversions, so 3 adjacent swaps in the pane reach 1, 2, 3, 4. A pane that looks right proves nothing yet. Press Tab repeatedly on the slide and watch the focus move. Tabbing follows the same order the reader will get, and it's the only check that tests what you delivered, and not what you meant to deliver.

P4. Size an image (US). A photograph 1024 px wide is placed 8.0 in wide on a slide. Compute the effective resolution, state whether it clears the 150 ppi web target, give the shortfall in pixels, and give the widest placement that holds 150 ppi.

Solution. Effective resolution is 1024/8.0 = 128.000000 ppi, which is below the 150 ppi target. At 8.0 in you would need 8.0 × 150 = 1200.000000 px, so the shortfall is 1200 − 1024 = 176.000000 px. The widest placement that holds 150 ppi is 1024/150 = 6.826667 in. Only two repairs are real: place the image smaller, or find more pixels. Enlarging a 1024 px image to 8 in and sharpening it produces a picture that looks acceptable on a laptop and soft everywhere else.

P5. Choose a grey (India). A deck sets body text in one of three greys on white: #767676, #757575 and #949494. Compute the contrast ratio of each against white, state which can carry body text at 4.5:1, and state which can be used for a graphical object at 3:1. Then say what you would do with the failing one.

Solution. Against white, #767676 measures 4.542225:1, #757575 measures 4.607518:1 and #949494 measures 3.033470:1. The first two clear the 4.5:1 body threshold, the first only just. #949494 fails body text and clears the 3:1 graphical threshold with almost nothing to spare, so it is usable for a rule or an icon and not for words. Darken the failing grey until it passes. Don't enlarge the type, because type set at 18 pt to rescue a colour is a layout decision made by a palette.

P6. Set a table (US). A table has 8 data rows plus a header and 5 columns. Compute the cells, the rule lines a full grid draws, the rule lines a properly set table keeps, and the number removed. Then list four setting decisions beyond the ruling.

Solution. Nine rows by 5 columns is 45 cells. A full grid draws (9 + 1) = 10 horizontal and (5 + 1) = 6 vertical rules, which is 16. A set table with no total row keeps 3: above the header, below the header, at the foot. That removes 13 rules. The four further decisions: numerals right-aligned; one consistent decimal place chosen from what the reader can act on; the unit stated once in the header and not in every cell; and rows sorted by the column that carries the message unless the order is intrinsic.

P7. Get under the ceiling (India). A deck is 61.4 MB, of which 52.8 MB is images. Recompression takes the images to 8.9 MB. Compute the file size afterwards, the reduction as a share of the original, and the headroom under a 25 MB attachment ceiling.

Solution. Everything that is not an image is 61.4 − 52.8 = 8.600000 MB, so the file becomes 8.6 + 8.9 = 17.500000 MB. The reduction against the original is (52.8 − 8.9)/61.4 = 71.498371%, and the headroom is 25.0 − 17.5 = 7.500000 MB. Notice what the headroom is for. Font embedding still has to be paid for out of it, and a subset embedding of a single family typically costs a little over a megabyte. So the deck is comfortable, and more than merely legal.

P8. Save the hairline (US). A table is ruled at 0.5 pt and will print on an office laser at 300 dpi. Compute the rule's width in device pixels at 300 dpi and at 600 dpi, compare it with a 1.0 pt rule at 300 dpi, and state the weight you would set for a deck that might print at 150 dpi.

Solution. At 300 dpi, 0.5/72 × 300 = 2.083333 device px; at 600 dpi, 4.166667 px. A 1.0 pt rule at 300 dpi is 4.166667 px, the same as the 0.5 pt rule at 600. So 0.5 pt survives a 300 dpi laser. At 150 dpi it's 1.041667 px and back in the zone where a printer renders it as a grey suggestion or drops it. For a deck whose destination is unknown, set 0.75 pt, which is 3.125000 px at 300 dpi and 1.562500 px at 150.

P9. Size the type for the room (India). A deck will be shown on a 4.2 m screen in a room whose back row is 12 m from the screen. Using the same rule of thumb (cap height at least distance divided by 200, cap height about 0.70 of point size, slide 13.333 in wide), compute the scale factor and the minimum point size, then round to a whole point.

Solution. The scale factor is 420/(13.333333 × 2.54) = 12.401575. The back row needs a cap height of 1200/200 = 6.000000 cm on the screen, which is 6.000000/12.401575 = 0.483810 cm on the slide, or 0.190476 in, so the point size is 0.190476 × 72 / 0.70 = 19.591837 pt, rounded up to 20 pt. A deeper room and a slightly larger screen have moved the floor from 18 pt to 20 pt. That's why you compute it instead of assuming it.

P10. Diagnose the diagram (US). A nine-node diagram carries 74 words and has autofit to 9 pt. Compute the mean words a node, state the two questions you would ask before editing, and give the repair.

Solution. The mean is 74/9 = 8.222222 words a node, and the autofit result of 9 pt tells you the longest node is well above that mean. The first question is what the room requires, because 9 pt is below every floor computed here, and the fix isn't optional. The second is whether the layout asserts a relationship the content has, since a nine-node gallery layout is usually a cycle or a matrix and a nine-step process is rarely either. Cut the longest nodes to the median and re-set the type to the room's floor, ignoring autofit. If nine steps really exist, split the diagram, because nine boxes on one slide make a reference diagram and not a presented one.

P11. Match the icons (India). An icon was drawn on a 32 px grid with a 2 px stroke and is placed at 48 px. Compute its effective stroke, and compute the stroke you would draw on the same 32 px grid to match a 1.5 px stroke at the placed size.

Solution. Scaling is 48/32 = 1.5, so the 2 px stroke arrives as 2.0 × 48/32 = 3.000000 px. To arrive at 1.5 px when placed at 48 px, draw at 1.5 × 32/48 = 1.000000 px. In general, the drawn stroke equals the target stroke times the grid divided by the placed size. The same factor applies to corner radii, so an icon set mixed across grids is inconsistent in two properties at once.

P12. Budget the accessibility pass (US). A deck has 96 objects that need alt text, of which 31 have it. Compute the coverage, the entries to write, and the time at about 25 seconds an entry. Then state what you would do about the objects that do not need alt text.

Solution. Coverage is 31/96 = 32.291667%, so 96 − 31 = 65 entries remain, costing about 65 × 25/60 = 27.083333 minutes. Flag the objects that carry no content as decorative. It takes about 3 seconds each and tells assistive technology to skip them. Leaving them unflagged is worse than leaving them without alt text, because a listener then hears the file's invented object names read aloud. Write each alt text as the object's message and the entries take less than 25 seconds each, because the message is already in the title.

Applied mini-project

Take one supplied 30-slide deck to shipping standard and hand back four artefacts: the repaired source file, a PDF export for screen reading, a handout export, and a filled eight-item checklist with a number against every line.

Each of the four has a test it must pass.

1. The repaired source file. Test 1: tabbing through every slide reaches objects in the order a reader should meet them, with no exceptions. Test 2: every object either carries alt text that states a message, or is flagged decorative. Test 3: every text-on-fill pair measures at or above 4.5:1, or at or above 3:1 where the type is 18 pt or 14 pt bold, with the measured ratios listed. Test 4: every remaining animation has a one-sentence justification naming what the audience learns from the movement, and the deck's still state is correct with every build in its final position.

1. The PDF export. Test 5: opened on a machine that did not build the file, with fonts checked for substitution, gradients checked for flattening and every hairline visible at 100% and at print size. Test 6: the file is under the stated size ceiling with the arithmetic shown: image bytes before, image bytes after, non-image bytes, embedding cost and headroom.

1. The handout export. Test 7: the smallest type on the printed handout is at or above 8 pt, with the computation from the slide's point size and the handout's scale factor. If it isn't, re-lay the handout instead of reprinting it smaller.

1. The checklist. Test 8: every line carries a number, not a tick. "Reading order: 4 slides repaired of 30" is a checklist entry; "Reading order: done" is a claim.

Three things are deliberately left unmarked here: whether the deck's argument is good, whether the charts are the right charts, and whether the deck should have existed. Those are marked elsewhere. A deck can score full marks here and still be wrong about everything that matters, which is worth knowing about any mechanical gate.

The rubric runs to 21 points, seven rows at three each, and a pass is 17 with no zero on any row.

Any artefact whose test fails scores zero on its row, however well it's presented. A shipping pass either happened or it didn't. A beautiful checklist attached to a deck whose reading order is still wrong is worth less than a plain one attached to a deck that works, and the rubric is built to say so.

Reading & resources

Core (do these).

1. Edward Tufte, The Visual Display of Quantitative Information (2nd edition, 2001). Paid. The data-ink argument is the source of the approach to ruling used on tables above, and reading it once changes what you notice about every grid you meet.
2. Stephen Few, Show Me the Numbers (2nd edition, 2012). Paid, intermediate. The best practical treatment of table design in print, including alignment, ruling and the choice between a table and a graph.
3. W3C, Web Content Accessibility Guidelines 2.1, success criteria 1.4.3 (contrast, minimum) and 1.4.11 (non-text contrast). Free. Read the two criteria themselves instead of a summary of them. Their thresholds and exceptions are short and precise.
4. W3C, Understanding Non-text Contrast. Free, beginner. Explains why a graphical object needs 3:1 and what counts as a graphical object, which is the criterion most often missed on a slide.
5. Microsoft, Make your PowerPoint presentations accessible. Free, beginner. The vendor's own procedures for alt text, reading order and the accessibility checker. Verify: procedures and menu paths change between releases; check the version you are running (checked 2026-09-08).

Going deeper.

1. Richard Mayer, Multimedia Learning (3rd edition, 2020). Paid, advanced. The experimental basis for the coherence and signalling principles, which is the strongest evidence available that decorative animation costs comprehension as well as time.
2. Nancy Duarte, slide:ology (2008). Paid, beginner. The chapters on visual elements and on movement are the useful ones here; treat the aesthetics chapters as one practitioner's taste.
3. Garr Reynolds, Presentation Zen (3rd edition, 2019). Paid, beginner. The restraint argument, made well, and the source most likely to persuade a colleague who thinks a slide should be full.
4. Cole Nussbaumer Knaflic, Storytelling with Data (2015). Paid, beginner. Chapter 3's decluttering method is the closest thing to a procedure, and it pairs directly with the ruling arithmetic above.
5. Alberto Cairo, The Truthful Art (2016). Paid, intermediate. On what a visual encoding claims and when it lies, which is the argument underneath the ladder that failed above.

Standards and tools (free).

1. A contrast-ratio calculator that implements the WCAG relative-luminance formula. Any implementation that shows the ratio to two decimals and states the thresholds is adequate; the arithmetic is short enough to check by hand once, which is worth doing so you trust it afterwards.
2. ISO 32000 (the PDF specification) and the PDF/A subset for archiving. Free summaries are adequate; skim one to understand that a PDF is a rendering and not a document. That explains every flattening surprise you've met here.
3. Your organisation's image licensing position, whatever it is, in writing. Free, and the single highest-value five minutes in this list, because the licence question is the only one here with a legal answer.

Teach it back & journal

Feynman prompt. Explain to a colleague who builds decks every week why a deck that looks finished on a laptop is not finished, without using the words design, professional or polish. Use the arithmetic. It's your whole argument. A 0.25 pt rule asks a 300 dpi printer for 1.04 device pixels, and the printer gives it one or none. Five bands cut from one gradient sit at 1.40 to 1.51 to one against each other, when a graphical element needs 3:1. A reader cannot tell band 3 from band 4, even though the ladder measures 4.58:1 end to end and looks convincing. A 1600 px photograph is 120 ppi full-bleed, which is fine on a projector and 80% of what a screen-read PDF needs. And 173 objects with alt text on 19 of them is 10.98% coverage, which is 154 sentences somebody has to write. Then make the harder point. None of those five failures is visible on the machine that built the file, and all five are computable in under two minutes each. If your colleague can tell you, unprompted, why the accessibility pass usually improves the slide for sighted readers as well, you've taught the idea and not just the numbers.

Journal prompt. Open the last deck you sent to somebody and run four checks on it. For each, write down a number. A verdict won't do. Tab through three slides and count how many objects are announced in a position that does not match the layout. Sample the two colours you use most and compute their contrast ratio against their background, then check them against 4.5:1 and 3:1. Take the largest image and divide its pixel width by the width you placed it at, then compare with 96, 150, 220 and 330. And count the animation effects in the file, then write down what each one teaches the audience about the content. Now write a paragraph about which of those four you felt surest of before you measured. The shipping defects hide in the gap between that confidence and the measurement. Finish by choosing one of the eight checklist items to make automatic this month. Reading order is the usual right answer. It's the cheapest to fix while you build and the most expensive to fix afterwards. And a deck whose objects were created in the order a reader should meet them was built in the order it was thought about.

This module's flashcards and mastery quiz are wired into the app: see the node's Quiz and Reviews.