Build a Local Task Aid from Approved Instructions

Start with approved instructions, not a blank checklist

A task aid helps a person follow a defined piece of work. It does not decide what the work should be or authorize actions that the underlying process has not approved. Before building a checkbox interface, identify the source instructions, their version, the intended user and the point at which the task ends. The interface should preserve those boundaries rather than making an incomplete process look official.

This guide builds an original local HTML teaching aid for preparing a fictional newsletter draft for review. It is not an excerpt from Built to Run, a client procedure or an observed AI output. The supplied task and source are deliberately invented. No newsletter is sent, no customer record is accessed and no actual organization has approved this fictional process. The example demonstrates how to connect instructions, controls and a clear completion message.

The practical deliverable is a single HTML file that can be saved locally and opened in a browser. It contains six fixed checkboxes, a count of marked items and a reset button. It makes no network requests and uses no application storage. Its scope is intentionally small enough that a reader can inspect the instructions and try the interactions without setting up an account, server or external service.

Separate the procedure from the aid

The source procedure explains what should happen, including responsibilities, conditions and escalation. The aid is a smaller representation intended to support a particular task. A checkbox list can omit useful context if it tries to replace the entire procedure. Keep the source reference visible and decide which details must remain in the aid for its limited use.

For the fictional example, the source version is SAMPLE-1. The task ends when a draft is prepared for a separate review. It does not end with publication, approval or sending. Those distinctions belong in the interface because a completion message saying finished could otherwise be mistaken for completion of the whole newsletter workflow.

If the actual source is ambiguous, resolve that issue through the authorized process before turning the wording into a control. An interface cannot repair an unresolved instruction merely by making it easy to click. Keep proposals and questions separate from the source that the aid claims to represent, and do not present an AI-generated improvement as an approved procedure without the relevant review.

Choose a task with an observable boundary

A useful first prototype supports a small, clearly bounded action rather than an entire department's work. Identify what the person needs to have before starting, what they should produce and what they should do when an input is missing. This helps distinguish a usable task aid from a collection of general reminders that cannot tell the user what stage they have reached.

In the teaching source, the inputs are the SAMPLE-1 instructions and an invented headline, Neighborhood Notes. The output is a draft prepared for review, with any unresolved image or review-owner question still visible. The exercise contains no actual audience list, publishing account, image upload or approval record. Those omissions define the demonstration's scope; they are not instructions to bypass those steps in a real operation.

Avoid combining tasks with different authority into one finish button. Preparing a draft, approving it and sending it are separate actions even when a small team sometimes performs them close together. A local aid can support the preparation stage while making its end state explicit. The example never provides a send button or claims to perform the later stages.

Map each control to a source instruction

Write the source step and its proposed checkbox wording side by side before coding. Look for changed verbs, missing conditions and new assumptions. A checkbox label should not ask the user to confirm something different from the source. If a proposed label introduces a new action, identify it as a change request rather than treating it as a harmless shortening.

The six teaching steps are to confirm source version SAMPLE-1, copy the approved fictional headline, retain draft-not-for-publication status, record a missing image as an unresolved question, preserve the unassigned review-owner status, and mark the package ready for separate review. Each checkbox refers to one of these authored steps. None asserts that a real person has completed a task or that an external system has verified it.

The fourth and fifth steps illustrate why conditions matter. Record the missing image as a question does not mean choose a replacement image. Preserve unassigned review owner does not mean assign yourself or a familiar colleague. The interface should keep these unresolved states intact rather than encouraging the user to make the list look complete by inventing missing information.

Use AI to propose wording without transferring approval

AI assistance can be used to propose shorter labels or identify potential ambiguity in the supplied instructions. A useful request identifies the authorized source, asks for one proposed label per step and asks that missing information remain unresolved. It should also ask for an explanation of any proposed change that would alter the action or its conditions.

Review those suggestions against the actual source before incorporating them. A fluent label such as choose the reviewer would change the teaching source's unassigned status. A label such as publish the completed newsletter would exceed the preparation-only boundary. The important check is whether the proposed wording preserves meaning and authority, not whether it sounds more decisive.

NIST's Generative AI Profile provides broader voluntary risk-management context for designing, using and evaluating generative AI. It does not endorse this aid or establish that a prompt produces correct labels. No model run or measured output is supplied here. The public teaching source and interface are authored examples, not a blind evaluation or evidence of improved operating performance.

Build the page around visible instructions

Give the local file a title that identifies it as a fictional teaching aid. Put its source version and preparation-only boundary before the checkboxes so the user encounters them first. The instructions should remain readable even before a box is marked. Do not make essential context available only after a completion action or hide it in a tooltip.

The example's page contains a single main region, a heading, a brief scope statement, a fieldset grouping the six checks and a legend describing their purpose. These elements make the structure understandable without relying on a decorative card layout. The visual design uses ordinary text and spacing so the exercise can be read at different sizes without a complex application shell.

Keep the procedure reference separate from the current checkbox state. The file identifies SAMPLE-1 whether zero or six items are marked. That reference should not change merely because someone resets the controls. In a real aid, a source-version change would be a document-review event, not a side effect of checking an item or opening the page.

Give every checkbox a clear label

W3C's labeling tutorial explains how labels identify controls and associate text with them. In the supplied file, each checkbox has a unique identifier and a visible label whose for attribute matches it. This lets the text and control work together rather than requiring the user to target a small unlabeled square. The example uses native checkbox behavior instead of imitating a checkbox with a generic clickable element.

The label should describe what the user is marking. A short phrase such as done does not identify the underlying instruction. The teaching labels preserve the source step, including its qualification where needed. They do not use a checked box as a substitute for explaining whether an item concerns source review, draft status, an unresolved question or the preparation boundary.

This is a concrete implementation choice informed by the primary guidance, not a certification of the whole file or every assistive-technology interaction. A production aid needs the review appropriate to its actual users and environment. The guide demonstrates the inspected label relationships and tested behavior of this small example without claiming that the prototype validates an entire organization's accessibility requirements.

Make the progress message honest

The counter reports how many boxes the user has marked. It does not verify that the underlying actions occurred. Use language that preserves that distinction. The example's initial message says zero of six items marked. Its completed message identifies six marked items and repeats that the draft is ready for separate review, not approved or sent.

This matters because a numerical indicator can look like an automated quality result. A person can mark a box without reading the source or doing the work. The aid has no connection to a document system and no evidence of external completion. Do not interpret six marked boxes as a validated result, a supervisor's approval or a record that a customer communication was issued.

The message is visible text in a status region with a polite live-announcement setting. The implementation updates that text after a checkbox change. It does not rely on color alone to convey the count or end state. The exact behavior is tested as part of the teaching file, while real deployment would still need the appropriate interaction review for the intended environment.

Keep state changes small and understandable

The script reads the six checkboxes, counts those currently checked and writes the corresponding status message. It does not inspect documents, call an AI service, validate the headline against a remote source or make decisions about the missing image. Keeping this behavior small helps readers distinguish what the program actually does from what the surrounding task asks the person to do.

When a checked item is unchecked, the count should decrease again. Completion is therefore a description of the current marked state, not an irreversible certification. The example supports this by recalculating from the current controls rather than incrementing a counter that could drift away from the actual checkboxes after repeated interactions.

The reset button clears all six checks and updates the displayed count. It does not reset a business process or retract an approval because the aid never performs those actions. A clear reset label describes the interface operation, Reset checks, rather than a broader phrase such as restart project that could imply effects outside the file.

Be explicit about what is not saved

This example uses no localStorage, sessionStorage, cookies or server. It does not provide a completion-history feature or an audit trail. A current browser view of marked boxes is not a durable record of work. If an actual process needs retained evidence, decide that requirement explicitly rather than assuming a local checklist already supplies it.

A browser may manage page state in ways specific to how a tab is restored, so the guide does not use reopening a page as its formal reset mechanism. The supplied Reset checks button is the explicit way to clear the current controls in the exercise. The tested program behavior concerns that reset and the displayed state, not every browser's session-restoration policy.

Do not add persistence casually while adapting the file. Saving progress creates new questions about what is recorded, whose work it represents and how the record will be used. Those decisions belong to the actual application and authorized process. The small teaching file deliberately avoids making claims about those requirements or providing a substitute for a system designed to retain business records.

Walk through the fictional source once

Open the file and read the SAMPLE-1 boundary statement before interacting with it. Then mark the source-version check and observe the count. Mark the fictional headline step and confirm that the interface still describes preparation work. The displayed count is useful feedback about the exercise, but the actual source text remains the authority for what each step means.

At the missing-image step, keep the question unresolved in the teaching scenario. Nothing in the file provides an image, licenses an image or uploads it anywhere. At the review-owner step, retain the authored unassigned state. The aid does not supply a real person whose name can be inserted to turn an unresolved assignment into an apparent decision.

When all six are marked, read the full message rather than only the number. It should say that the draft is ready for separate review and is not approved or sent. Then uncheck a middle item and confirm that the count falls. Finally, use Reset checks and confirm that all controls and the status return to their initial marked-state condition.

Review failures as design information

If a reviewer cannot tell what a checkbox means, examine the wording and its relationship to the source. Do not automatically conclude that the person failed to follow instructions. The aid may have removed a condition, combined several actions or used a term that does not identify the relevant object. Make a specific change proposal and review it before updating an actual aid.

If the interface count is wrong, distinguish that program issue from the source procedure. A counter bug does not establish that the instructions are unsuitable, just as a correct counter does not establish that the instructions are complete. The teaching checks examine label associations, state transitions, the completion boundary and absence of network or storage operations as separate questions.

Keep an unresolved process question separate from a software defect. For example, uncertainty about who should review a real newsletter cannot be solved by changing JavaScript to display a default name. That would introduce a new operating decision. Identify the missing authority or information and use the actual process to resolve it, while keeping the interface honest about the current state.

Adapt the prototype without claiming automatic transfer

If the concept is useful for an actual task, begin again with that task's authorized source. Replace the fictional text deliberately rather than simply changing the page title. Check the start conditions, action verbs, exception handling and end boundary. The fact that the example has six steps does not mean every task should be forced into six controls.

Review the interface after any source change. A removed step can leave a stale count denominator or an old completion message. A renamed action can leave a label that no longer represents the procedure. Treat the mapping from instructions to controls as something to maintain, not a one-time conversion that stays valid as the process changes around it.

A real release decision should consider the actual task and users, the consequence of mistakes and the evidence appropriate to the workflow. The provided file is an inspectable prototype, not a production deployment package or a recommendation to replace a reviewed system. It makes the difference between an aid, a procedure and approval concrete without assuming those roles are interchangeable.

Keep useful links around the aid

An aid can identify the source procedure and a route for unresolved questions without trying to contain every piece of organizational knowledge. Keep those references clear and appropriate to the actual task. Avoid linking to a general document library when the user needs a particular version or section, and avoid making the aid claim authority that belongs elsewhere.

The related guides address separate questions: writing the source SOP, defining the process owner and designing a decision brief. They are not prerequisites invented by the prototype, and they do not automatically approve its use. Link related material because it helps a reader answer the next concrete question, not to make the checklist appear more authoritative through a long list of references.

For AI-assisted procedure review, the linked Elixir guide examines whether a proposed procedure preserves an approved source. That is a different output from this local interface. A sensible sequence keeps the source review, label mapping, interaction testing and actual release decision distinguishable so that success in one stage is not mistaken for completion of all the others.

The live count requires JavaScript. When it is unavailable, the example displays a notice instead of an apparently current count. The native checkboxes remain readable controls, but they provide no automatic counting or external verification.

Frequently asked questions

Does checking every box prove the work happened?

No. The count reports user-marked controls only. The file has no connection to a document system and verifies no external action. Six marked items in the fictional example means the displayed preparation checklist is marked; it does not approve a draft, send a newsletter or establish an independently verified completion record.

Can AI approve the source instructions or the finished aid?

No approval authority is supplied by this guide. AI can propose wording for review, but the actual authorized process determines approval. A suggestion that changes an action, condition or responsibility should remain a proposal until reviewed. NIST's broader guidance does not certify this prototype or establish that a prompt produces reliable controls.

Does the downloaded file send data or save progress?

The supplied example makes no network requests and uses no application storage. It contains only fixed fictional checkboxes and current-state feedback. It does not provide a history or audit trail. The Reset checks button explicitly clears the current controls; the guide does not make promises about every browser's tab-restoration behavior.

Why use a label element with each checkbox?

The primary W3C guidance explains how an associated label identifies a form control. The example pairs each visible label with its checkbox through matching identifiers. This is a concrete structure that can be inspected and tested. It does not by itself establish that every aspect of a production interface has passed an accessibility evaluation.

Is the fictional newsletter procedure taken from the book?

No. It is original teaching material authored for this guide. The headline, source version and preparation steps are invented and represent no client workflow or book quotation. The file is intended to demonstrate source mapping and interaction boundaries, not to attribute a specific procedure, result or recommendation to a chapter that has not been supplied.

Can I adapt the file for a real task?

Use the actual authorized instructions and review the changed mapping, controls and completion boundary. Do not assume the six-step example transfers automatically or that adding persistence and external actions is a minor wording change. Keep the procedure, interface behavior and release authority separate, and obtain the evidence and approval appropriate to the real use.