Design an H5P Course Presentation around a small teaching sequence and an event ledger. Keep the slide, option interaction, submitted response, and container outcome in separate records.
Use three authored slides with one focused task
H5P describes Course Presentation as a slide-based content type combining text, media, and interactions, including multiple-choice questions. Use that structure for this original practice packet. Course Presentation description.
The fictional task is returning equipment to the locker whose identifier matches the supplied label:
| Authored slide | Original content | Purpose |
|---|---|---|
| 1 | Context: return the practice equipment to the matching locker | Establish the task |
| 2 | Inspect a fictional locker label displaying L2 | Supply the identifying evidence |
| 3 | Multiple choice: choose the matching ID from L1, L2, L3 | Submit a task-specific response |
The authored key is L2. Feedback for L1 or L3 should explain that the supplied label reads L2; it should not diagnose the learner's general ability. The label and any artwork are original specifications, not a photographed locker or copied H5P sample.
The target module has these three authored slides plus the configured native sum-up screen. Do not add a fourth text slide titled Summary and claim it has the container's sum-up behavior. Confirm the native content type, libraries, options, and host before building that distinction.
No .h5p package, artwork, listener, learner response, or event has been created or collected for this manuscript.
Keep the documented event triggers in separate rows
H5P's coverage page associates slide changes with progressed, multiple-choice option clicks with interacted, the multiple-choice Check button with answered, and reaching the Course Presentation sum-up screen with completed. Those are source-described triggers, not observed events from an installed module. Course Presentation xAPI coverage.
| Planned action | Expected event concept | Evidence it describes |
|---|---|---|
| Change authored slide | progressed | Slide navigation |
| Select L2 on the multiple-choice slide | interacted | Option interaction |
| Activate Check | answered | Submitted question response |
| Reach the native sum-up screen | completed | Container completion trigger |
Selecting L2 and submitting L2 are different actions. An option click may be followed by a changed selection or no submission. Record the submitted response and any score from the actual answered payload rather than inferring them from the earlier interaction row.
Likewise, correlate the question event with its question object and the container event with its presentation object. A verb without the associated content identity can be easy to misread.
Test a sum-up route with no checked answer
Define one planned trace that navigates through the authored slides to the native sum-up screen without activating Check. Under the documented completion trigger, reaching that screen does not by itself demonstrate an answered or correct multiple-choice response.
Keep the question outcome unverified. Do not fill the missing response with L2 because the answer key is L2, or fill a missing score with zero because no score was captured. In the later native test, record the actual question and container events, including any absent fields or additional events.
The source coverage table is not a guarantee that every host or configuration permits this navigation path or emits exactly the proposed rows. Confirm actual settings and capture the observed trace. If the path is blocked, record that behavior rather than asserting that the expected trace occurred.
Compare checked responses without equating them to mastery
A second planned trace selects L2, checks the response, and reaches sum-up. Verify the actual answered event's response, result, and object identity against the authored key. A third selects L1 and checks it; its feedback should reference the same visible L2 label.
An answered event is evidence of a submission, not necessarily a correct response. Even a correctly scored response to this one fictional task does not establish broader mastery. Keep result fields, feedback, and completion status distinct.
Record package revision, content-type and library versions, host configuration, event sequence, verb, object ID, content ID, parent/context IDs where actually present, response, and score. Expected-result cells and actual captured fields should not share one column.
Emission is separate from storage
Capturing a local event does not establish that an LRS or LMS stored it, correlated it with a learner, or transferred a grade. Those steps need their own host-specific evidence and authorization. No learning records or learner identities are collected in this packet.
If the slide content, key, options, library, or host configuration changes, invalidate the active acceptance trace. Retain older traces with revision labels so a previous package does not appear to verify a new one.
The native module specification, assessment feedback, and actual event evidence remain authoritative. An HTML reading ledger is a separate explanation of those records.
Copyable module-and-event prompt
Create one complete, self-contained US-English HTML companion for “Equipment return · course companion”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for L1; L2; L3; Check response; 1 · Context; 2 · Label; 3 · Question; Next slide; Start a fresh local trace. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an English original H5P Course Presentation specification and expected-versus-actual event ledger. Do not create packages/files/art, run a module/listener, collect events/learner identities, or connect an LMS/LRS.
Use three authored slides: equipment-return context; inspect an original fictional locker label L2; multiple-choice matching ID from L1,L2,L3, key L2. Feedback explains the supplied label, not learner mastery. Include a configured native Course Presentation sum-up screen separately from the three authored slides. A custom text slide called Summary is not a substitute.
Record actual content-type/library/package/host versions/options as unconfirmed. Source coverage associates slide changes with progressed, option clicks with interacted, MCQ Check with answered, and reaching native sum-up with completed. These are expected concepts, not captured payloads or guarantees for all hosts/configurations.
Plan separate traces: reach native sum-up without Check; select L2 then Check and reach sum-up; select L1 then Check. Verify actual navigation/settings and capture native events later. Completion alone cannot establish all questions answered/correct. Option interaction is not submission. Record actual response/score and question/container object scope separately; missing fields remain unverified, not guessed zero or the answer key.
Ledger fields include package revision, versions/options, sequence, verb, object/content/parent IDs where present, response, score, expected interpretation and blank actual result. Event emission is not LMS/LRS storage, learner correlation or grade transfer. Content/key/options/host changes invalidate old acceptance. Keep the required native records authoritative; any prepared HTML reading ledger and NOS saving/rendering connection are separate, not LMS execution. Mark visuals, keyboard/focus, article-width, narrow-screen and native payload tests pending.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# H5P Course Presentation: Separate Slide Progress From Submitted Answers
A learner reaches the end of a module, and the report says Completed. Before treating that as a correct answer, inspect which action generated the event. Reaching a container's sum-up screen can describe navigation without establishing that a question was checked.
Design an H5P Course Presentation around a small teaching sequence and an event ledger. Keep the slide, option interaction, submitted response, and container outcome in separate records.
## Use three authored slides with one focused task
H5P describes Course Presentation as a slide-based content type combining text, media, and interactions, including multiple-choice questions. Use that structure for this original practice packet. [Course Presentation description](https://h5p.org/presentation).
The fictional task is returning equipment to the locker whose identifier matches the supplied label:
| Authored slide | Original content | Purpose |
| --- | --- | --- |
| 1 | Context: return the practice equipment to the matching locker | Establish the task |
| 2 | Inspect a fictional locker label displaying L2 | Supply the identifying evidence |
| 3 | Multiple choice: choose the matching ID from L1, L2, L3 | Submit a task-specific response |
The authored key is L2. Feedback for L1 or L3 should explain that the supplied label reads L2; it should not diagnose the learner's general ability. The label and any artwork are original specifications, not a photographed locker or copied H5P sample.
The target module has these three authored slides plus the configured native sum-up screen. Do not add a fourth text slide titled Summary and claim it has the container's sum-up behavior. Confirm the native content type, libraries, options, and host before building that distinction.
No .h5p package, artwork, listener, learner response, or event has been created or collected for this manuscript.
## Keep the documented event triggers in separate rows
H5P's coverage page associates slide changes with progressed, multiple-choice option clicks with interacted, the multiple-choice Check button with answered, and reaching the Course Presentation sum-up screen with completed. Those are source-described triggers, not observed events from an installed module. [Course Presentation xAPI coverage](https://h5p.org/node/612/xapi-coverage).
| Planned action | Expected event concept | Evidence it describes |
| --- | --- | --- |
| Change authored slide | progressed | Slide navigation |
| Select L2 on the multiple-choice slide | interacted | Option interaction |
| Activate Check | answered | Submitted question response |
| Reach the native sum-up screen | completed | Container completion trigger |
Selecting L2 and submitting L2 are different actions. An option click may be followed by a changed selection or no submission. Record the submitted response and any score from the actual answered payload rather than inferring them from the earlier interaction row.
Likewise, correlate the question event with its question object and the container event with its presentation object. A verb without the associated content identity can be easy to misread.
## Test a sum-up route with no checked answer
Define one planned trace that navigates through the authored slides to the native sum-up screen without activating Check. Under the documented completion trigger, reaching that screen does not by itself demonstrate an answered or correct multiple-choice response.
Keep the question outcome unverified. Do not fill the missing response with L2 because the answer key is L2, or fill a missing score with zero because no score was captured. In the later native test, record the actual question and container events, including any absent fields or additional events.
The source coverage table is not a guarantee that every host or configuration permits this navigation path or emits exactly the proposed rows. Confirm actual settings and capture the observed trace. If the path is blocked, record that behavior rather than asserting that the expected trace occurred.
## Compare checked responses without equating them to mastery
A second planned trace selects L2, checks the response, and reaches sum-up. Verify the actual answered event's response, result, and object identity against the authored key. A third selects L1 and checks it; its feedback should reference the same visible L2 label.
An answered event is evidence of a submission, not necessarily a correct response. Even a correctly scored response to this one fictional task does not establish broader mastery. Keep result fields, feedback, and completion status distinct.
Record package revision, content-type and library versions, host configuration, event sequence, verb, object ID, content ID, parent/context IDs where actually present, response, and score. Expected-result cells and actual captured fields should not share one column.
## Emission is separate from storage
Capturing a local event does not establish that an LRS or LMS stored it, correlated it with a learner, or transferred a grade. Those steps need their own host-specific evidence and authorization. No learning records or learner identities are collected in this packet.
If the slide content, key, options, library, or host configuration changes, invalidate the active acceptance trace. Retain older traces with revision labels so a previous package does not appear to verify a new one.
The native module specification, assessment feedback, and actual event evidence remain authoritative. An HTML reading ledger is a separate explanation of those records.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the event ledger separately
Keep the native H5P package and actual host events in their own workflow.
The useful review can name the action behind each event and the question outcome that the event actually supports.