The accessibility checks that belong in preflight

Accessibility work has a timing problem. Almost every team treats it as a check that happens after the course is built, usually as a pass someone does the week before launch. By then the storyboard is locked, the media is recorded, the interactions are authored, and every fix costs a rebuild.

The issues themselves did not appear at build time. Most of them were decided at storyboard time. A slide that signals correctness with a green checkmark and nothing else was an accessibility problem the moment someone wrote it down. Finding it after the voiceover is recorded does not make it a harder problem. It makes it a more expensive one.

Here is what you can catch on a storyboard, and what genuinely has to wait.

Nine checks that work on a storyboard

1. Alt text intent, not alt text presence. Do not check whether an image has alt text. Check whether the storyboard says what the image is for. A diagram that carries instructional content needs alt text describing the content. A decorative divider needs to be marked decorative so a screen reader skips it. If the storyboard does not distinguish the two, the person building it will guess, and they will guess wrong on the diagrams.

2. Color as the only signal. Search the storyboard for "green", "red", "highlighted", "in blue". Every one of those is a candidate for a learner who cannot see the distinction. The fix is cheap at this stage: add a label, an icon, or a text cue alongside the color. It is not cheap after the graphics are produced.

3. Contrast on the template, not the slide. Contrast is a template decision, so audit it once. Normal text needs 4.5:1 against its background, large text (18pt, or 14pt bold) needs 3:1. Checking the template once at design time covers every slide built from it. Checking slide by slide at the end covers nothing and takes a week.

4. Heading structure. Storyboards tend to describe visual hierarchy ("big bold title, then three subpoints") rather than semantic hierarchy. A screen reader user navigates by heading level. If the storyboard does not say what is an H1 and what is an H2, the build will produce styled text with no structure underneath it.

5. Link text that means something on its own. Screen reader users commonly pull up a list of links out of context. "Click here", "read more", and "this document" are useless in that list. Write the destination into the link text at storyboard stage, when it is a sentence edit rather than a rebuild.

6. Media obligations, budgeted. Every video needs captions. Every audio-only segment needs a transcript. Every complex visual needs a long description. These have real cost and real lead time. Counting them at storyboard stage turns them into a line item. Discovering them at launch turns them into a delay.

7. Reading and focus order. For any slide with more than one content region, the storyboard should state the order in which content should be read. Visual layout does not determine it reliably, and authoring tools default to creation order, which is whatever order the developer happened to drop the objects in.

8. Timing and auto-advance. Any slide that advances on its own, any interaction on a timer, any animation that carries meaning. Learners using assistive technology need more time, not less. Flag these at storyboard stage and decide whether the timing is instructionally necessary or just a default nobody questioned.

9. Flashing and motion. Anything flashing more than three times per second is a seizure risk and has to go. Large parallax and autoplay motion should have a reduced-motion path. Both are trivial to remove from a storyboard and awkward to remove from a finished build.

What genuinely has to wait

Being honest about the limits matters, because a preflight that overpromises gets skipped the second it misses something.

Keyboard traps cannot be found on a storyboard. Neither can actual focus order in the authored output, screen reader announcement quality, or whether a custom drag-and-drop interaction has a keyboard equivalent that works. Those need the built course and, ideally, a real screen reader rather than an automated checker.

The split is roughly two thirds and one third. Two thirds of what a full accessibility audit finds was decided at storyboard time. One third is genuinely a property of the build. The goal of preflight is to make sure the expensive post-build audit is spent on the third that actually needs it.

The compliance framing is a trap

Teams that treat accessibility as a WCAG 2.2 AA checkbox produce courses that pass an automated scan and remain unusable. Alt text that reads "image of a slide" passes a presence check. Contrast that clears 4.5:1 with a color pair nobody can read comfortably passes a ratio check.

The check that actually works is a person asking, for each slide: if I could not see this, could I still learn it? If I could not use a mouse, could I still complete it? If I could not hear it, would I miss anything?

That question does not automate well. What automates well is finding the slides where the question needs asking.

Where the tooling helps

CourseReady's personas include perspectives that surface this class of problem, and findings tagged as an accessibility or inclusion risk carry the same severity, confidence, and source citation as any other finding. They land in the same queue and go through the same revision workflow, which matters more than it sounds: accessibility findings that live in a separate spreadsheet get worked separately, which usually means last.

That is the real argument for pulling these checks forward. Not that a tool catches them better than a careful reader would, but that a finding raised at storyboard stage is a sentence edit, and the same finding raised three days before launch is a schedule conversation.