Check readability and accessibility

Complete Make the image and diagram plan first.

A deck has to work on the screen, in the room, and in the exported file. This lesson asks you to make a deck readability QA pass, not a prettier version of scattered notes. The output should be specific enough that someone could open the deck file and see what changed.

Here is the before and after: Before, the deck looks good on one laptop. After, slide text, charts, captions, contrast, and exports are checked for real viewing conditions. For example, if you are preparing a sales presentation, the artifact should name the audience, slide job, proof, speaker note, or export check where that detail matters. A reviewer should be able to tell whether the deck is closer to being presented, sent, or handed off.

Now try it: Run a QA pass for projector view, laptop view, mobile preview, and PDF export. Make one choice before asking Claude to write: which audience, which decision, which proof, which slide job, or which delivery mode matters most right now. That choice keeps the deck from becoming a generic presentation outline.

The lesson is done when the artifact moves the deck toward a real room, reader, or file handoff.

Create a readability and accessibility QA pass for this deck. Check text size, contrast, chart labels, captions, alt text or speaker description needs, mobile preview, projector view, and PDF export. Deck: [paste or describe].

If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic Deck Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Present Or Send This Without Fixing It. Keep the answer practical enough that I can paste it into my deck working doc.

Finished Artifact:
- a deck readability QA pass
- Why it matters: it gives the deck a concrete thing to inspect instead of a vague intention.
- Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything.

Reality Check:
- The artifact names the user, input, decision, owner, or proof it depends on.
- The weakest assumption is visible.
- The next step can be completed in one sitting.

What good looks like

• Text size and contrast issues are listed.
• Charts and diagrams have readable labels.
• Export-specific issues are checked.
• Fixes are separated from nice-to-have polish.

Without rereading the lesson, explain why a deck readability QA pass matters in three bullets. Then apply it to a second deck example: [describe a different audience, room, or topic]. Return What Changed, What Stayed The Same, What To Check Before Presenting Or Sending, and the exact next action.

Transfer Check:
- What changed: the second example has a different audience, input, or delivery context.
- What stayed the same: a deck readability QA pass still needs a source, a review check, and a next step.
- Before trusting it: inspect the delivery check that would catch a wrong assumption.
- Next action: run the check once, then carry the revised artifact into the next lesson.

What good looks like

• You explained the lesson idea from memory before applying it again.
• The second example changes the artifact instead of copying the first answer.
• The delivery check names a real risk.
• The next action can be done in one sitting.