Review a mini-lesson for keyboard, text and media barriers

Preserve the decision when the presentation changes

Use the room-booking question as a test: can the learner identify the overlap and choose the next action when the colored calendar is unavailable? If the answer depends on noticing a red block, supply the room name, existing interval and requested interval in text. “Red means unavailable” is not enough for someone who cannot perceive the color or see the image.

W3C WAI’s introductory checks cover headings, image alternatives, keyboard focus, zoom, media alternatives and form labels, while explicitly warning that these are not a complete assessment. The checks below adapt those concerns to an original lesson example; they are not a claim that Mini Course Generator or this checklist establishes conformance.

Read the question without its illustration

A weak image description says “calendar screenshot.” A useful equivalent for our fictional case says “Room Birch is booked 10:00–11:00; the new request is 10:30–11:30.” It preserves the information needed to reason without giving away the answer. If the prose already carries that information, an image may be decorative rather than the only source of the rule.

The merchant documents an image alternative-text field. Use the field deliberately, then inspect the learner output. Do not assume a file name or an automatically generated caption communicates the purpose. Keep essential instructions in ordinary text rather than embedding them only inside an image.

Walk the entire question with the keyboard

• Start before the lesson and move forward using the keyboard. Can you see where focus is?
• Reach each relevant control in a sensible order without entering a loop.
• Select an answer, submit it and find the resulting explanation.
• Move to the next page and back without losing access to the instructions.
• Confirm that a sticky bar, modal or embedded frame does not cover the focused control.

Record the specific failure, such as “focus reaches the answer but the visible Submit control cannot be activated with the keyboard.” Do not report merely “accessibility failed.” If the interaction cannot be corrected within the tool, provide an equivalent usable route and explain the limitation before assigning it.

Make feedback and media carry meaning in more than one way

Show why an answer is supported or unsupported; a green tick or buzzer alone loses the explanation. For a spoken demonstration, provide the information in readable form. If the video shows a step that is never described aloud, a transcript of speech alone may still omit it. Review what a learner must know, not just whether a captions button exists.

Zoom the learner view and inspect long choices, labels, error messages and the end of the lesson. The small-screen review is useful alongside this, but a narrow viewport and enlarged text are different conditions. Do not shrink text to conceal a layout defect.

Write an honest outcome and fallback

A good result note lists the tested route, device, interaction and remaining limitation. “Keyboard navigation through this three-page practice exercise worked in the reviewed browser; screen-reader testing is outstanding” is more useful than “fully accessible.” For higher-stakes training, arrange evaluation with relevant users and accessibility expertise rather than stretching a quick check into a certification.

If an interaction is unusable, a text-based case with a supported response route can preserve the decision practice. Do not assume a PDF is automatically accessible. Inspect any exported alternative separately and retain the same source, exception and feedback.