The companion tracks two illustrative concerns on page D1: an initial-state naming concern and an untested dialog keyboard check. Propose a label correction to move F1 into Pending retest, then filter that queue while a hidden-unresolved count preserves F2. No action scans or certifies a website.
Define the state before interpreting a finding
WAI's evaluation-tool guidance explains that tools assist evaluation, cannot automatically check every aspect and can produce misleading results. It also describes differing purposes, products and scopes. Those limits support a record that identifies what a particular run covered, rather than one page-wide “accessible” switch.
This example is a review organizer, not a website scanner. D1 names a sample page with Initial and Rendered Dialog states. The page tracks questions about those states, but it does not contain the dialog or inspect another website. R1 is an unexecuted example run.
| Record | State | Illustrative concern | Actual evidence status |
|---|---|---|---|
| F1 | D1 Initial | A control's accessible name may be missing | Illustrative finding only; no actual report attached |
| F2 | D1 Rendered Dialog | Keyboard focus behavior needs review | Untested; no human observation supplied |
Treat F1 as a concern to investigate. First identify the control and page version, then attach the report or observation that explains the naming issue.
Keep run identity and finding identity stable
For a real review, identify the page version and how to reach the state. Keep the relevant report with the finding, including the tool version if you used one. Write what the reviewer observed so someone else can repeat the check.
If a report covers only the initial page, retain its wording and scope. It cannot answer the separate question about keyboard behavior in the open dialog.
Capture state setup sufficiently for a retest: “D1 dialog open after its trigger” is more useful than “page.” Do not attach a different page version's result to the old record as though it were the same observation.
Record a proposed correction without closing the finding
Suppose the team proposes a corrected label for F1. Record the revision and its source, but keep F1 pending retest until the same state on the corrected version is actually observed and the relevant evidence is attached.
Pressing Propose label correction changes F1 to Pending retest for the entered version. F2 keeps its own status. Another version edit marks both for recheck. To evaluate the correction, inspect the actual control and its exposed name in the page version you are reviewing; this organizer does not edit that markup.
When a real retest is performed, add its own run/version/state reference and observed outcome, retaining the original record. A successful scoped F1 retest can close F1 for that checked context. It does not close F2 or every state on D1.
Leave human checks open until they occur
For F2, prepare a keyboard observation record for opening the intended modal dialog, moving through its controls and observing entry, containment and return behavior against the approved interaction specification. Leave the actual sequence and outcome blank until tested.
Describe the intended modal behavior first; do not prescribe trapping focus in every kind of overlay. If the dialog's actual design or state is unknown, record that uncertainty before interpreting a result.
An automated report with no entries supplies no observation for this human check. “Not tested,” “observed problem,” “pending retest” and “observed scoped result” need different statuses. Keep the result scoped to the state you actually observed.
Review the queue without hiding the gap
Press Propose label correction to stage F1 as Pending retest. Retest only shows that record, while the status still counts the hidden unresolved F2. Show all returns both. Observed only initially has no rows because no observation has been supplied. These filters change visibility, not evidence.
Enter a page version and report reference and press Check record fields to identify missing metadata. A complete pair of text fields still does not establish an actual test. Changing the version marks both concerns for recheck. The page does not attach a new report or create an observed result. Let evidence, not a filter, close a concern. Use the remaining unresolved count to choose the next check, even when its card is hidden by the current filter.
Copy this prompt
Build an accessibility review organizer with two illustrative concerns for sample page D1. It should make untested work visible, rather than scan a website or assign a conformance score. Show finding cards, status filters and a small metadata check.
F1 concerns a possible missing accessible name in D1's Initial state. It begins as Pending observation, with no actual report attached. F2 concerns keyboard behavior in the Rendered Dialog state and begins as Not tested. R1 is an unexecuted example run. The page does not need to implement the dialog itself.
Provide All, Pending, Retest and Observed filters. Display both the visible count and the hidden unresolved count. Observed initially shows zero records. Hiding a finding must never mark it resolved. Propose label correction changes F1 to Pending retest while F2 remains untested. Retest then shows F1 and reports one hidden unresolved concern.
Include labeled inputs for page version and actual report reference. Check record fields lists missing values. Supplying both values confirms only that metadata is present; it must leave the findings open. Editing the version marks both linked concerns for recheck and removes any implication that earlier evidence applies to the new version.
Reset restores both original statuses, clears the inputs and shows all cards. Keep the text clear that actual report review and keyboard observations happen separately. For a dialog check, the reviewer needs the intended interaction and a repeatable way to reach the state.
Return one responsive, self-contained HTML file with readable finding cards, prominent unresolved counts and buttons connected through click handlers.
Find the check the filter hides
Propose the label correction and choose Retest. F1 remains visible, while the hidden-unresolved count reminds you that F2 still needs a keyboard observation. NOS can render the HTML organizer for this review-planning discussion. Return to All and write down how the reviewer will reach the actual dialog before assessing its behavior.