Start two mock operations, deliver their outcomes in a deliberate order, and see stale events ignored. Dismissing the current message leaves the operation’s terminal result intact.
Define the component's job without inventing an output
Start a mock preview operation with the exercise's Prepare Preview control.
Place a visible explanation beside the exercise: “Mock operation status; no preview file is generated.” The notification copy can then describe that mock operation without implying a download, saved file, or server result.
The message set is:
| Mock transition | Whole visible message |
|---|---|
| Prepare Preview | Preparing preview for this operation. |
| Complete current operation successfully | Preview ready for this operation. |
| Current mock failure | Preview preparation failed for this operation. |
| Reset | Ready to start a mock preview operation. |
The exact outcome still belongs to an operation record. An operation being called O2 is not proof that it completed. Later tests must supply and observe the mock transition deliberately.
This component uses neither the operating-system Notification API nor a permission prompt. It sends no external notification, network request, or global toast-queue event.
Keep result state and message state separate
Starting O1 creates a fresh operation and waiting message. Starting O2 retires O1 as the current owner and replaces its current feedback. A callback must match the active operation before it can update that feedback.
The key trace is:
| Step | Event | Current operation | Current visible feedback |
|---|---|---|---|
| 1 | Prepare Preview (O1) | O1 pending | Preparing preview for this operation. |
| 2 | Prepare Preview (O2) | O2 pending; O1 retired | Preparing preview for this operation. |
| 3 | Deliver O2 mock success | O2 mock succeeded | Preview ready for this operation. |
| 4 | Deliver late O1 mock error | O2 remains mock succeeded | O2 ready message remains |
Step 4 should neither change the current operation result nor publish a stale failure message. Retain any diagnostic history under O1 if needed; do not relabel it as O2.
If current O2 fails in an independent test, its own failure message is appropriate. Ignoring stale O1 is not a policy of hiding every error.
The operation ID and message ID are host-owned application state. The display need not announce internal IDs to the reader; the test ledger should retain them so updates can be checked.
Prepare a persistent status region before updates
W3C's status-message guidance addresses updates that inform users without changing their focus. Its ARIA22 technique describes role=status, polite behavior, whole-container context, and placing the role before a status occurs.
For this component, create an initially empty status region in the native implementation and keep that region in the DOM throughout the page session. Update its complete contextual message when a current mock transition occurs. Set aria-atomic=true so the update includes the whole message's context.
Keep the dismiss button separate from the status text region. The intended update is the full sentence, not merely “ready,” a changing number, or a colored icon. Decorative styling must not carry the only meaning.
“Persistent” here means the status element remains present during the session. It does not mean messages or operation records survive a reload, synchronize, or enter storage.
At initial load, show the mock explanation and a ready-to-start instruction outside the empty live region. After a user-triggered Reset, the current status can become the complete ready-to-start message. Check actual announcements with the intended screen reader and device.
Avoid moving focus for automatic updates
Starting, succeeding, or failing the mock operation should update text while leaving focus at the user's current control. Do not automatically focus the banner to force attention.
Ordinary waiting and completion feedback does not require an assertive alert on every keystroke or intermediate change. The WAI alert pattern cautions against disrupting focus, excessive interruption, and automatically disappearing important messages.
Dismiss the message without undoing the result
| Action | Message result | Operation result |
|---|---|---|
| Dismiss current O2 ready message | Current ready banner hidden | O2 mock success retained |
| Delayed Dismiss from an older message | New current message unaffected | Current operation unchanged |
| Prepare Preview after dismissal | New waiting message appears | New operation pending |
Try the worked example
Select Prepare Preview twice, complete the current operation, then deliver the first operation’s error. The ready message remains because the late callback has the wrong identity. To test delayed dismissal, capture the terminal dismissal, select Prepare Preview again, complete the new operation, and deliver the captured dismissal. The newer ready message remains. Dismiss its current terminal message and inspect the retained outcome. Dismissing feedback does not cancel or undo the operation.
Operations are controlled local mocks and generate no preview file. Screen-reader speech and device behavior still need actual assistive/device checks.
Recreate this example
Build one complete self-contained HTML page for this task: demonstrate the original local notification operation/message identity contract.
Use these exact original practice data and worked expectations: Select Prepare Preview twice, complete O2, then deliver O1’s late error: O2’s success remains. Capture a terminal dismissal, create and complete a newer operation, then deliver the captured dismissal: the newer message remains. Dismiss hides only its current terminal message and preserves the outcome. Reset retires prior operation identities. The persistent status region starts empty; these mock controls generate no preview file.
Implement the following useful local interactions: Native buttons Prepare Preview, Complete current, Fail current, Deliver first-operation error, Dismiss terminal message, Capture terminal dismissal, Deliver captured dismissal, and Reset. An initially empty persistent status region uses aria-atomic=true. No automatic focus movement for updates. Dismiss terminal messages only. Capture both message ID and operation identity, including generation, before dismissal. Expose capture/deliver controls to reproduce an old dismissal after a newer message; reject mismatches without changing message, outcome, or focus; if focused dismiss hides itself, focus Prepare Preview. Old callbacks after Reset cannot recreate message. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. Operations are controlled local mocks and generate no preview file. Screen-reader speech and device behavior still need actual assistive/device checks. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the controlled notification-state component in NOS
Carry the identity checks into your actual component before connecting asynchronous work. Review O2's retained success beside the ignored O1 error in NOS, and revise eligible static mock-status wording in visual editing mode if dismissal appears to undo the result.